Ostorlab frente al pentesting manual: más hallazgos críticos, menos tiempo y menor costo

Ostorlab automatiza el trabajo de pruebas de penetración que, de otro modo, requiere que un auditor investigue el comportamiento de la aplicación, formule hipótesis de ataque, ejecute pruebas y valide el impacto. Para los equipos de seguridad de aplicaciones (AppSec) que contratan pentests manuales, la comparación consiste en determinar si Ostorlab puede encontrar más vulnerabilidades críticas, entregar los resultados antes y reducir el costo de evaluación con el mismo alcance.

Nuestro equipo informa de que Ostorlab encontró más vulnerabilidades críticas, completó las pruebas antes y costó entre una décima y una cuadragésima parte de los pentests manuales con los que se ejecutó en paralelo en todas las pruebas de concepto (PoC) comparativas completadas. Las comparaciones completadas abarcaron aplicaciones móviles, aplicaciones web, código fuente y pruebas de Active Directory.

Ostorlab frente al pentesting manual: resultados comunicados de las PoC

Estos son los resultados de las evaluaciones de nuestro equipo para los alcances y las condiciones de acceso evaluados. No constituyen un benchmark independiente ni una garantía para otra aplicación. Este artículo no publica el tamaño de la cohorte, los recuentos de hallazgos emparejados, la duración de las evaluaciones ni un desglose de costos. Por tanto, el intervalo de costos comunicado no es una previsión de su ahorro total; una comparación sobre su alcance debería incluir la preparación, la revisión humana, las nuevas pruebas y el esfuerzo de ingeniería.

Los casos técnicos explican el trabajo de investigación y validación que sustenta los resultados de Ostorlab. En una evaluación móvil, el agente extrajo credenciales de un binario de Flutter para iOS, probó las audiencias de API permitidas y demostró acceso a una API de gestión de identidades. En una evaluación de una aplicación empresarial, obtuvo un token administrativo sin un secreto de cliente y lo utilizó para acceder a una función que ejecutaba código suministrado en el servidor. Son ejemplos del trabajo de investigación para el que un cliente contrata a un pentester.

Evidencia técnica detrás de la comparación

Los siguientes ejemplos anonimizados proceden de registros de hallazgos e historiales de ejecución de Ostorlab. Muestran qué investigó y confirmó la plataforma. No identifican hallazgos omitidos por un auditor humano concreto ni respaldan de forma independiente los resultados agregados de la comparación; aquí no se publican cuadros de resultados por cliente ni informes de auditores.

El caso de la credencial móvil y la cadena del token sin secreto hasta la ejecución en el servidor se detallan en los casos 1–3. La evidencia técnica adicional abarca la inscripción, la firma y el registro de eventos. Allí se incluye un ejemplo separado de laboratorio de AD para quienes evalúan las pruebas internas; no constituye evidencia comparativa de clientes. Los fragmentos de código usan valores sintéticos e ilustran los mecanismos descritos, en lugar de reproducir intercambios capturados de clientes.

Para examinar el entregable antes de concertar una llamada, abra el informe de ejemplo web o el informe de ejemplo móvil.

Caso 1: una credencial móvil filtrada dio acceso a la API de gestión del tenant

Ostorlab evaluó una aplicación iOS desarrollada con Flutter que usaba credenciales de máquina a máquina de Auth0 para obtener tokens de acceso a API. El binario compilado de la aplicación contenía client_id y client_secret, suministrados durante la compilación mediante el mecanismo DART_DEFINES de Flutter. La evaluación comprobó si esas credenciales eran válidas y a qué API podían acceder.

El límite esperado. Una credencial de máquina a máquina debería limitarse a la audiencia y al conjunto de operaciones que necesita su servicio. Una credencial integrada en un cliente distribuido no es un secreto: está disponible para cualquiera que pueda obtener la compilación. Por ello, la evaluación examinó tanto si la credencial seguía activa como en qué otros servicios podía autenticarse.

La investigación. El agente extrajo la credencial del binario Mach-O y solicitó un token al endpoint /oauth/token del tenant. La solicitud tuvo éxito con HTTP 200 y un JWT firmado; una credencial inventada devolvió HTTP 401. El token incluía el permiso read:TSC, una concesión de credenciales de cliente y una clave de firma rastreable hasta el endpoint JWKS del tenant.

El hallazgo inicial recibió una severidad alta. El registro también lo etiqueta como «Corregido y verificado», pero el material disponible para este caso no documenta la corrección ni la cronología de su comprobación. Esa etiqueta, por sí sola, no demuestra que se rotara la credencial ni que se retirara su acceso.

Para evaluar el acceso más allá de la API utilizada por la aplicación, Ostorlab envió solicitudes de tokens para 38 audiencias candidatas al mismo endpoint de tokens. En estas solicitudes, la audiencia identifica la API para la que se solicita acceso. Una solicitud de token para la audiencia de la Management API del tenant devolvió HTTP 200 con un token que incluía ocho permisos, entre ellos update:users, delete:users, create:users y create:client_credentials. Un único GET no destructivo a la Management API devolvió la primera página de un directorio de 1,000 registros de usuarios con correos electrónicos, números de teléfono, últimas IP y comportamiento de inicio de sesión. La evaluación demostró esta lectura; no ejerció los permisos del token para crear, actualizar o eliminar usuarios.

El endpoint de tokens aceptó las credenciales de cliente extraídas tanto para la audiencia del servicio interno como para la de la Management API. Una solicitud posterior al directorio confirmó el acceso de lectura a través de la Management API.

Secuencia HTTP ilustrativa · valores sintéticos de host, cliente y token.

# The credential is extracted from the mobile binary.
POST /oauth/token HTTP/1.1
Host: tenant.example.invalid
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&client_id=MOBILE_CLIENT&client_secret=EXTRACTED_SECRET&audience=AUDIENCE_A
# Article outcome: a read:TSC token for the internal service.

POST /oauth/token HTTP/1.1
Host: tenant.example.invalid
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&client_id=MOBILE_CLIENT&client_secret=EXTRACTED_SECRET&audience=MANAGEMENT_API
# Article outcome: a token with eight management scopes.

GET /api/v2/users?per_page=100 HTTP/1.1
Host: tenant.example.invalid
Authorization: Bearer FAKE_MANAGEMENT_TOKEN

# Article outcome: the first page of a 1,000-record directory.

Resultado de la evaluación. Las credenciales extraídas podían obtener tokens para el servicio interno y la Management API. La lectura del directorio confirmó el acceso a información personal; los permisos de escritura de gestión quedaron sin probar. Por tanto, la verificación de la corrección debe abarcar las audiencias permitidas del cliente, y no solo la API que llama la aplicación. Los registros disponibles no documentan qué corrección se intentó entre ambos hallazgos.

Qué automatizó Ostorlab. Esta evaluación combinó análisis de binarios, validación de credenciales activas, enumeración de audiencias y una lectura controlada de la API. Un auditor que realizara la investigación manualmente tendría que ejecutar y conectar esos mismos pasos. Ostorlab determinó el acceso utilizable de la credencial más allá de la API que llamaba la aplicación, proporcionando al equipo de AppSec una exposición validada para priorizar y un requisito más amplio para repetir las pruebas.

Orientación para la corrección. Elimine el secreto del cliente y rótelo. Revise las audiencias y los permisos autorizados del cliente, y separe las credenciales de gestión del tenant de las credenciales de servicio destinadas a clientes. Invalide los tokens emitidos bajo la configuración vulnerable. Las nuevas pruebas deben enumerar toda la superficie de autorización del cliente, no solo la audiencia que llama la aplicación.

Puede consultar una descripción más extensa en el caso de estudio de Agentic Deep Scan.

Caso 2: acceso administrativo mediante una solicitud de token sin secreto

En una evaluación de una aplicación empresarial, Ostorlab encontró una configuración del servicio de identidad que emitía tokens administrativos sin un secreto de cliente. La investigación demostró que el token era utilizable: una operación de directorio protegida lo aceptó y devolvió cientos de perfiles de la organización. La información de caducidad devuelta mostró que el token podía seguir siendo válido mucho más allá de una sesión breve, lo que aumentaba el riesgo de persistencia.

El límite esperado. Un cliente que solicita acceso administrativo debería acreditar la identidad y la autoridad necesarias para ese acceso. Un token emitido también necesita una audiencia, unos permisos y una duración adecuadamente restringidos. La prueba examinó tanto la emisión como el uso, porque son decisiones de seguridad distintas.

La investigación. Ostorlab envió una solicitud de token con un identificador de cliente y un permiso administrativo, sin secreto de cliente. El servicio de identidad devolvió un token de portador. Ostorlab inspeccionó entonces las declaraciones del token devuelto y lo utilizó contra una operación de directorio protegida, que devolvió perfiles de la organización.

La emisión y la aceptación son comprobaciones distintas. La evaluación demostró ambas: una solicitud de token sin secreto produjo una credencial que una operación de directorio protegida aceptó.

Secuencia HTTP ilustrativa · rutas, valores de campos y marcadores de tokens sintéticos.

# Request shape is illustrative; the article omits routes and exact fields.
POST /example/token HTTP/1.1
Host: identity.example.invalid
Content-Type: application/x-www-form-urlencoded

client_id=DEMO_CLIENT&scope=DEMO_ADMIN_SCOPE
# No client_secret and no client-authentication header.
# Article outcome: an administrative bearer token was issued.

GET /example/protected-directory HTTP/1.1
Host: directory.example.invalid
Authorization: Bearer FAKE_ISSUED_TOKEN

# Article outcome: protected access returned organizational profiles.
# Synthetic request shape; this is not a literal captured exchange.

Resultado de la evaluación. La prueba demostró tanto la emisión de un token sin secreto de cliente como su aceptación por una operación de directorio protegida. La solicitud al directorio utilizó el token obtenido mediante la ruta de emisión probada, en lugar de una credencial administrativa suministrada. Esto establece una conexión entre la configuración incorrecta del servicio de identidad y el acceso no autorizado a la API.

Orientación para la corrección. Revise los requisitos de autenticación y los tipos de concesión permitidos del cliente; restrinja sus permisos y audiencias; reduzca la duración para ajustarla a su propósito; e invalide, según corresponda, las credenciales emitidas bajo la configuración vulnerable. Las nuevas pruebas deben abarcar tanto los intentos de emisión nuevos como el tratamiento de las credenciales ya emitidas.

La comprobación de la corrección debe verificar ambos controles: la autenticación del cliente en el endpoint de tokens y la autorización en la API protegida.

Caso 3: una función de integración ejecutó código suministrado en el servidor

En la misma evaluación de la aplicación empresarial, Ostorlab utilizó el token administrativo del caso 2 para acceder a una función de integración autenticada en un módulo de gestión de identidades y accesos (IAM) proporcionado por un proveedor. La función aceptaba C# personalizado y lo compilaba dentro del proceso del servidor de aplicaciones. Las pruebas de temporización controlada, la ejecución de subprocesos, los diagnósticos del host y las comprobaciones de red saliente demostraron la ejecución bajo la identidad del grupo de aplicaciones de IIS de la aplicación: una cuenta miembro de BUILTIN\Administrators que disponía de SeDebugPrivilege y SeImpersonatePrivilege.

El límite esperado. Las funciones de extensibilidad necesitan un modelo de confianza explícito: quién puede suministrar código ejecutable, dónde se ejecuta y qué privilegios recibe. El acceso a una pantalla de configuración de integraciones no constituye, por sí solo, un límite de confianza aceptable para ejecutar código suministrado dentro de un proceso privilegiado de la aplicación.

La investigación. El agente trabajó con la interfaz esperada por la función. Escribió una sonda que implementaba esa interfaz, de modo que el payload superara las comprobaciones de compilación y tipos antes de ejecutar su constructor. La aplicación utilizaba Roslyn para compilar el código fuente dentro del proceso, cargaba el ensamblado resultante con AssemblyLoadContext.Default.LoadFromStream() y creaba la instancia con Activator.CreateInstance().

Una solicitud normal estableció la referencia. Los payloads del constructor introdujeron demoras controladas. Los tiempos de respuesta registrados siguieron la progresión solicitada: una referencia de unos 122 ms, y después aproximadamente 2.13 s, 5.14 s y 10.15 s para las sondas de dos, cinco y diez segundos, con el mismo patrón al repetirlas. Otras pruebas registraron la ejecución de subprocesos, la identidad que ejecutaba el código y conexiones DNS y TCP salientes a un host controlado por el auditor.

La función de integración compiló e instanció el C# suministrado dentro de su proceso de servidor. La progresión de demoras solicitada respaldó la ejecución del constructor; pruebas separadas de subprocesos, diagnósticos del host y comprobaciones de salida establecieron un impacto adicional.

Sonda ilustrativa en C# · adáptela a la interfaz de integración de un entorno de prueba autorizado.

using System;
using System.Threading;

public sealed class IntegrationProbe
{
    // Implements the interface the integration feature expects.
    public IntegrationProbe()
    {
        Thread.Sleep(2000);
        Console.WriteLine(Environment.UserName);
    }
}

// Compare baseline with 2, 5, and 10 second constructor delays.
// This snippet illustrates timing and identity diagnostics only.
// The article reports subprocess execution and egress from separate tests.

El control negativo. El agente también probó un endpoint de integración similar que imponía una comprobación de tipos previa a la instanciación. La misma sonda fue rechazada antes de la compilación o instanciación, y no apareció ningún efecto de temporización. Esta prueba de control mostró que los dos endpoints de integración aplicaban validaciones diferentes antes de ejecutar el código suministrado.

Resultado de la evaluación. Las pruebas de temporización demostraron la ejecución del constructor. Otras pruebas separadas de subprocesos, identidad y salida establecieron los privilegios de ejecución y el acceso a la red. El endpoint de integración requería autenticación, que proporcionó el token obtenido en el caso 2. La secuencia demostrada fue la emisión de un token sin secreto, el acceso administrativo a la API y la ejecución autenticada de código en el servidor.

Orientación para la corrección. Mantenga las integraciones no confiables fuera del proceso privilegiado de la aplicación:

• Use un proceso de trabajo separado con un límite de seguridad adecuado impuesto por el sistema operativo. Un AssemblyLoadContext descargable permite descargar ensamblados; no es una sandbox de seguridad. Microsoft describe la diferencia entre el aislamiento de carga y los límites de seguridad de los procesos.
• Asigne al proceso de trabajo una identidad con pocos privilegios, acceso restringido a secretos y una lista de destinos salientes permitidos.
• Restrinja quién puede crear o modificar integraciones.
• Vuelva a probar la autorización, la identidad del proceso, el acceso a recursos protegidos y la salida no permitida. Si ejecutar integraciones es una función prevista, una compilación correcta, por sí sola, no indica una corrección fallida.

Qué automatizó Ostorlab. Los casos 2 y 3 exigieron que el agente trasladara una credencial de un hallazgo a otra prueba, construyera una sonda compatible con la interfaz de integración, comparara resultados de temporización y estableciera los privilegios del proceso y el acceso a la red. Se trata de investigación de cadenas de ataque y validación del impacto dentro de la evaluación. La comparación con un pentest manual debe valorar si cada proveedor encontró y demostró la ruta completa, junto con el tiempo y el costo necesarios para hacerlo.

Ejecutar Ostorlab en paralelo con un pentest manual

Proporcione a Ostorlab y al proveedor del pentest manual objetivos, cuentas, acceso y acciones permitidas equivalentes. Así su equipo podrá comparar la investigación y los hallazgos validados bajo las mismas condiciones. Comience con un entorno de preproducción representativo y cuentas de prueba específicas cuando sea viable. Si se requieren pruebas en producción, acuerde las acciones permitidas, el acceso a datos, los límites de tráfico y la escalada de incidentes con el responsable de la aplicación antes de ejecutarlas. Una conexión descubierta en una aplicación no autoriza automáticamente a probar su proveedor de identidad o servicio de analítica.

Use este plan operativo al definir el alcance de la evaluación:

Son decisiones de la evaluación que deben confirmarse con el equipo responsable, no una promesa de que cada acción se apruebe o revierta automáticamente.

Controles de alcance y acciones

La actualización de octubre de la plataforma describe las directrices de alcance, las exclusiones del firewall, los controles de tráfico, la supervisión y las aprobaciones de acciones solicitadas. La lista de alcance permitido guía al agente; no es un límite de red estricto. Las exclusiones del firewall bloquean las direcciones y redes configuradas. La supervisión añade detección de desviaciones y detención opcional.

La configuración de aprobación rige las decisiones solicitadas por el agente. «Preguntarme, bloquear si no hay respuesta» mantiene una acción solicitada en espera de una decisión; no exige una revisión humana antes de cada llamada a herramientas. El operador debe configurar estos ajustes para la evaluación.

Ventanas de ejecución y condiciones de detención

Las ventanas de ejecución especifican días, horas y zona horaria. Un escaneo creado fuera de su ventana espera; uno que admite pausa se pausa al cierre y se reanuda en la siguiente ventana. Los escaneos que no admiten pausa continúan hasta completarse después del cierre. Confirme el comportamiento del tipo de escaneo elegido antes de considerar la hora de cierre como un límite operativo. Una programación recurrente también necesita una condición de detención final independiente.

Consulte la documentación de las ventanas de ejecución para conocer el comportamiento de programación admitido. Estas capturas son ejemplos de la plataforma procedentes de documentación pública, no evidencia capturada en las evaluaciones anonimizadas.

Comparar la evidencia de investigación y la entrega

Un recuento de hallazgos solo resulta útil si su equipo puede verificarlos. Compare la evidencia del proveedor manual con el registro de investigación de Ostorlab, incluida la forma en que cada uno estableció la explotabilidad y el impacto. La vista de análisis de AI Pentest de Ostorlab vincula planes y tareas con nombres de herramientas, argumentos, resultados y marcas de tiempo registrados. Examine un hallazgo importante desde su hipótesis inicial hasta la respuesta que demuestra el impacto. El informe debe permitir distinguir entre un seguimiento del código fuente, una prueba satisfactoria en ejecución y una etapa de ataque bloqueada.

La entrega debe identificar los privilegios iniciales, el impacto reproducido, las ramas sin éxito, las comprobaciones pendientes y la corrección propuesta. Cuente hallazgos validados distintos, conciliando las causas raíz duplicadas y las cadenas de ataque. No cuente una hipótesis no probada como una vulnerabilidad crítica confirmada.

Los registros de ejecución también ayudan al operador a verificar la limpieza. Una evaluación web revisada registró la creación de una sesión de soporte, su comprobación, su revocación y una nueva comprobación para confirmar el cierre de sesión. Aplique la misma disciplina a la configuración modificada, los archivos cargados y las credenciales emitidas. Registre explícitamente los artefactos pendientes y asigne un responsable; registrar una acción no equivale a revertirla.

Ampliar la comparación hasta la corrección

La comparación debe incluir el trabajo necesario para convertir un hallazgo en una corrección verificada. Ostorlab puede llevar un hallazgo hasta la corrección mediante recomendaciones personalizadas y propuestas de cambios de código entregadas a través de integraciones compatibles con repositorios. Los desarrolladores revisan el diff resultante en su flujo habitual de pull requests, ejecutan las comprobaciones pertinentes y utilizan pruebas de seguimiento para evaluar si la aplicación modificada resuelve el problema original.

La corrección propuesta debe abordar el control identificado en la evaluación. Los hallazgos de inscripción requieren comprobaciones de propiedad de registros; los logs que contienen credenciales requieren cambios en los puntos de registro y serialización; los hallazgos de tokens sin secreto requieren revisar la emisión de tokens y la autorización posterior.

La tabla enumera criterios de corrección y nuevas pruebas derivados de los casos; no afirma que se haya creado o integrado ningún parche concreto:

• Ostorlab Autofix permite recomendaciones de corrección personalizadas, cambios mediante pull requests y flujos de verificación posteriores.
• Las pruebas de código fuente mantienen las rutas afectadas y las revisiones de código conectadas con la corrección.

Un parche generado sigue pasando por revisión de ingeniería y pruebas adecuadas. La evidencia de la evaluación posterior fundamenta el cierre; un diff propuesto o una compilación satisfactoria, por sí solos, no demuestran que se haya eliminado una ruta explotable.

Compare este flujo con el servicio de corrección y nuevas pruebas incluido en su pentest manual. Registre si los desarrolladores pueden reproducir el hallazgo, implementar la corrección propuesta y verificar que la ruta original de acceso o ejecución está bloqueada, junto con el esfuerzo necesario de su equipo.

Medir Ostorlab frente a su proveedor de pentesting manual

Use los resultados comunicados de las PoC como la propuesta que debe probarse: más hallazgos críticos validados, menos tiempo de pruebas y menor costo de evaluación. Una comparación útil comienza con la misma compilación, objetivos, cuentas, acceso al código fuente, permisos y exclusiones. Acuerde la ventana de evaluación y decida cómo gestionar los cambios realizados durante las pruebas. Registre las evaluaciones incompletas y las limitaciones, en lugar de excluirlas de los resultados.

Antes de autorizar una PoC, solicite un presupuesto desglosado que identifique los conceptos incluidos, los límites de uso, las condiciones por exceso, las nuevas pruebas incluidas y el trabajo de preparación del cliente. Acuerde fechas de entrega tras confirmar el alcance y el acceso. Use esas condiciones y el esfuerzo real para determinar si la ventaja de costo de evaluación comunicada en nuestras PoC completadas se traduce en un menor costo total para su equipo.

Preguntas que resolver antes de sustituir un pentest existente

¿Dónde encaja Ostorlab en nuestro programa de pruebas? Use una evaluación inicial en paralelo para decidir qué actividades de prueba de aplicaciones puede asumir en su alcance: pruebas de flujos autenticados, investigación entre aplicaciones y API, y repetición de pruebas después de cambios. Mantenga la responsabilidad humana sobre el alcance, la intención de negocio, los hallazgos discutidos, las decisiones operativas y la aceptación de correcciones. Conserve las pruebas especializadas para las actividades fuera de la cobertura acordada. Use los hallazgos, la entrega, el costo y los requisitos de garantía para decidir qué parte de su evaluación manual actual puede sustituir Ostorlab.

¿Tenemos que proporcionar código fuente? Ostorlab admite compilaciones móviles, aplicaciones web, API y pruebas de código fuente. El caso de la credencial móvil partió del binario distribuido; los ejemplos de firma y registro de eventos utilizaron acceso al código fuente. Acuerde explícitamente el modo de evaluación. Una revisión solo del código fuente no puede demostrar el comportamiento real del backend, y una prueba exclusivamente en ejecución tiene una visibilidad distinta de una evaluación apoyada en código fuente.

¿Qué debe preparar nuestro equipo? Proporcione la compilación o las URL objetivo, los servicios autorizados, cuentas de prueba separadas por roles, datos de prueba representativos y documentación relevante de API o flujos de trabajo. Para los flujos con sesión iniciada, acuerde con el equipo de evaluación la configuración de prueba necesaria para la autenticación multifactor (MFA) o las contraseñas de un solo uso (OTP). Identifique un responsable de la aplicación, un operador y un contacto de ingeniería para reproducir hallazgos y repetir pruebas. Confirme el esfuerzo de preparación al definir el alcance.

¿Adónde irán nuestro código, credenciales y evidencia? Revise el Trust Center y las opciones de escaneo en las instalaciones con sus equipos de seguridad y compras. Confirme el despliegue elegido, el proveedor del modelo, los flujos de datos, la retención y los controles de acceso antes de suministrar material sensible; no suponga que todos los despliegues funcionan igual.

¿Cumplirá el informe un requisito externo de garantía? Revise un informe de ejemplo con la parte que solicita la evaluación. Confirme el alcance, la metodología, las cualificaciones o independencia del auditor, la revisión humana, los informes y la evidencia de nuevas pruebas exigidos antes de modificar una evaluación existente. Pida a Ostorlab que identifique la validación humana y la aprobación final incluidas en el servicio propuesto. Un hallazgo técnico, por sí solo, no garantiza la aceptación para todos los requisitos de garantía.

Comparar Ostorlab con su próximo pentest manual

La ventaja comunicada de Ostorlab sobre el pentesting manual consiste en más hallazgos críticos, menos tiempo de pruebas y menor costo de evaluación. Los casos muestran el trabajo técnico que puede realizar la plataforma: investigar credenciales entre API, encadenar debilidades de identidad y ejecución, y validar el impacto con pruebas registradas. Una comparación sobre su aplicación debe establecer si esas capacidades mejoran los resultados y la rentabilidad de su pentest actual.

Aporte una aplicación representativa, sus API conectadas y el alcance de su pentest manual actual. Use la conversación sobre el alcance para acordar:

1. Entradas: la compilación o las URL, cuentas y roles de prueba, acceso al código fuente si se incluye, documentación, permisos y exclusiones.
2. Entregables: un informe con hallazgos reproducidos y límites de la evidencia, acceso al registro de investigación, propuestas de corrección y una entrega acordada de limpieza y nuevas pruebas.
3. Criterios de éxito: hallazgos validados y coincidencias, plazo de entrega utilizable, costo total y esfuerzo de ingeniería, con las mismas definiciones para ambos proveedores.
4. Compromiso: alcance por escrito, plan operativo, fechas de entrega, presupuesto desglosado y responsables designados antes de comenzar las pruebas.

Reserve una PoC de Ostorlab frente a un pentest manual para acordar un alcance equivalente, criterios de éxito y condiciones comerciales para su aplicación. Comience con el informe de ejemplo web o el informe de ejemplo móvil si desea examinar primero el formato de la evidencia.

Evidencia técnica adicional

Las siguientes secciones documentan la autorización de inscripciones, la firma móvil, el registro de eventos móvil y una evaluación separada en un laboratorio de Active Directory. Cada una describe el método de prueba, el resultado observado y la validación aún necesaria.

Propiedad de la inscripción: lecturas y escrituras no autorizadas; la activación siguió bloqueada

En una evaluación de inscripción de autoservicio, Ostorlab siguió un flujo de trabajo de recuperación de registros y creación de contraseñas. Una sesión anónima podía recuperar un registro controlado por el auditor que pertenecía a otra identidad, obtener un token contra falsificación de solicitudes entre sitios (CSRF) utilizable y enviar solicitudes de creación de contraseña para esa inscripción. Las respuestas satisfactorias y los cambios persistidos en la versión del registro documentaron las escrituras no autorizadas.

El límite esperado. Un flujo de trabajo debe establecer que el solicitante puede actuar sobre la inscripción concreta que se modifica. Un token CSRF aborda una cuestión diferente: si una solicitud incluye el token esperado de la sesión del navegador. Poseer uno no demuestra la propiedad de un registro identificado en la solicitud.

La investigación. El agente comparó distintas identidades, incluida una sesión anónima de invitado, con registros creados para la prueba. Recuperó la inscripción ajena, obtuvo el token CSRF de la sesión, envió una solicitud de creación de contraseña dirigida a ese registro y volvió a leerlo para inspeccionar el estado resultante.

La validación CSRF y la autorización de registros responden a preguntas distintas. Una sesión de invitado con su propio token CSRF podía leer y modificar una inscripción de prueba ajena; la etapa de activación e inicio de sesión no se completó.

Secuencia HTTP ilustrativa · ambas identidades y la inscripción están controladas por el auditor.

# Session A does not own test enrollment B.
GET /example/enrollments/TEST_RECORD_B HTTP/1.1
Cookie: guest=FAKE_SESSION_A

# Obtain FAKE_CSRF_A through the public enrollment flow.
POST /example/enrollments/TEST_RECORD_B/password HTTP/1.1
Cookie: guest=FAKE_SESSION_A
X-CSRF-Token: FAKE_CSRF_A
Content-Type: application/json

{"password":"SYNTHETIC_TEST_PASSWORD"}

GET /example/enrollments/TEST_RECORD_B HTTP/1.1
Cookie: guest=FAKE_SESSION_A

# Article: write accepted; record version changed on readback.
# Final activation and login did not complete.

Paso	Evidencia	Límite evaluado
Leer una inscripción de prueba desde una sesión que no es propietaria	Respuesta satisfactoria con el registro	Confidencialidad del registro y comprobaciones de propiedad.
Obtener el token CSRF de la sesión de invitado	Token disponible mediante el flujo público	Disponibilidad de un token de solicitud válido para un solicitante anónimo.
Enviar una solicitud de creación de contraseña para el registro de prueba ajeno	Respuesta de creación satisfactoria	Autorización de una operación que modifica el estado.
Volver a leer el registro	Cambios de versión persistidos	Un efecto duradero más allá de la respuesta inicial.
Intentar la etapa final de activación e inicio de sesión	Esa etapa no se completó	Límite de la ruta de ataque demostrada.

Qué demuestra la evidencia. La evaluación estableció el acceso a registros entre identidades y la preparación de credenciales en una inscripción de prueba. También registró el punto donde se detuvo la cadena. La etapa final de activación e inicio de sesión permaneció bloqueada en el despliegue evaluado, por lo que el caso no afirma que se completara la toma de control de una cuenta de usuario activa.

Orientación para la corrección. Vincule cada operación de inscripción a la identidad autorizada o a una capacidad de inscripción diseñada expresamente con un alcance limitado. Compruebe ese vínculo tanto en lecturas como en escrituras. Valide las relaciones entre el registro, el solicitante y los campos de identidad modificados. Los casos de regresión deben incluir un propietario, otro usuario autenticado, una sesión anónima y un token CSRF válido asociado al registro incorrecto.

El defecto de inscripción era un fallo de autorización: la aplicación aceptaba solicitudes con un token CSRF válido sin verificar que la sesión pudiera acceder al registro especificado o modificarlo.

Firma móvil: clave recuperable; aceptación del backend sin probar

En una PoC de código fuente móvil, Ostorlab rastreó una clave de firma HMAC compartida por toda la aplicación, reconstruida a partir de dos matrices de bytes integradas. La firma cubría una marca de tiempo y un marcador fijo de la aplicación, mientras que el método, la ruta y el cuerpo de la solicitud quedaban fuera de la entrada firmada. Era un hallazgo a nivel de código fuente; demostrar que el backend aceptaba la firma todavía requería una prueba en ejecución.

El límite esperado. Una firma de solicitud solo puede establecer las propiedades representadas por su clave y su mensaje firmado. Por ello, la revisión examinó cómo obtenía el cliente su clave y exactamente qué componentes de la solicitud entraban en la operación de firma.

La investigación. El agente siguió la función de reconstrucción hasta el generador de solicitudes de API. Las dos matrices necesarias para recuperar el secreto compartido se distribuían con el cliente. La capa de API utilizaba después ese valor reconstruido para firmar la marca de tiempo y el marcador de la aplicación antes de colocar la firma en las cabeceras de la solicitud.

El cliente distribuido contenía el material necesario para reconstruir su clave compartida. La firma rastreada cubría una marca de tiempo y un marcador fijo; el método, la ruta y el cuerpo no formaban parte de la entrada firmada. El comportamiento del backend quedó sin probar.

Pseudocódigo ilustrativo · las funciones auxiliares de reconstrucción y HMAC representan la implementación original.

// Both embedded arrays are distributed with the client.
const sharedKey = reconstructKey(embeddedArrayA, embeddedArrayB);

// Simplified representation of the traced signing inputs.
const signedInput = timestamp + APP_MARKER;
const signature = hmac(sharedKey, signedInput);

headers["X-Example-Signature"] = signature;

// request.method is absent from signedInput.
// request.path is absent from signedInput.
// request.body is absent from signedInput.
// The reconstruction algorithm and header name are illustrative.
// Backend acceptance was not established by the source review.

Seguimiento del código fuente	Consecuencia de seguridad respaldada por el código
Ambas matrices de reconstrucción presentes en el cliente	La ofuscación no impedía recuperar la clave compartida.
Clave compartida utilizada por el generador de solicitudes	El mismo material de firma se reutilizaba en los puntos de llamada rastreados.
Marca de tiempo y marcador fijo suministrados a HMAC	Esos valores estaban cubiertos por la firma.
Método, ruta y cuerpo ausentes de la entrada firmada	La firma no vinculaba esos componentes de la solicitud.

Qué demuestra la evidencia. La revisión estableció que el material de firma era recuperable y determinó la composición del mensaje firmado. No demostró que pudiera eludirse la autenticación de portador ni todas las comprobaciones de propiedad del backend. El backend quedaba fuera de este archivo de código fuente, por lo que esas cuestiones correspondían a una evaluación posterior en ejecución.

Orientación para la corrección. Revise la confianza depositada en un secreto distribuido a cada instalación del cliente. Especifique el propósito de seguridad de la firma, la identidad que representa, el contenido de la solicitud que vincula y las comprobaciones de vigencia del servidor. Mantenga explícita en el servidor la autorización de usuarios y objetos. Rote el material de firma expuesto como parte de una migración adecuada, mientras corrige el diseño subyacente.

La evidencia del código fuente identifica el código de reconstrucción de la clave y los campos firmados. Aún se requieren pruebas en ejecución para determinar cómo valida el backend la firma y si otros controles impiden solicitudes no autorizadas.

Registro de eventos móvil: carencia de enmascaramiento reproducida; transmisión real sin verificar

En otra evaluación de Android, Ostorlab rastreó valores de autenticación desde un resultado de OpenID a través del registro de eventos de la aplicación, una función de enmascaramiento y la serialización de telemetría. La reproducción local mostró que los valores con formato de credenciales sobrevivían al filtro bajo nombres de campos y formatos de cadenas no reconocidos. El registro identificó la ruta de filtración y las comprobaciones pendientes en ejecución.

El límite esperado. El material de autenticación debe excluirse u ocultarse de forma segura antes de entrar en los logs. Un filtro debe manejar la serialización real que utiliza la aplicación, incluidos los campos estructurados y las representaciones en cadenas.

La investigación. El código fuente mostraba registros de eventos en la ruta de autenticación satisfactoria. Un punto de llamada serializaba un mapa de cabeceras que contenía el valor de una cookie; otro registraba un resultado de autenticación como cadena. La función de enmascaramiento reconocía un conjunto definido de campos en un formato concreto similar a JSON. Las cadenas con credenciales quedaban fuera de esos nombres o de ese formato.

La reproducción local incluyó controles positivos: se enmascararon los campos reconocidos de autorización y de token de actualización. Las cadenas problemáticas con cookies y códigos permanecieron. Esa distinción estableció una carencia concreta en un mecanismo de enmascaramiento que, por lo demás, funcionaba.

El mismo filtro enmascaraba los campos reconocidos de autorización y token de actualización, pero omitía las cadenas del mapa de cookies y del resultado de autenticación. El seguimiento del código llegó a la serialización de telemetría; no se observaron transmisión real ni reutilización de credenciales.

Ejemplo local ejecutable · credenciales sintéticas y una regla de enmascaramiento simplificada.

const mask = text => text.replace(
  /("(?:authorization|refresh_token)"\s*:\s*")[^"]*"/gi,
  '$1[REDACTED]"'
);

const known = '{"authorization":"FAKE_BEARER"}';
const refresh = '{"refresh_token":"FAKE_REFRESH"}';
const cookie = '{Cookie=FAKE_COOKIE}';
const result = 'AuthResult(code=FAKE_AUTH_CODE)';

if (mask(known).includes("FAKE_BEARER")) throw Error("control");
if (mask(refresh).includes("FAKE_REFRESH")) throw Error("control");
if (!mask(cookie).includes("FAKE_COOKIE")) throw Error("gap");
if (!mask(result).includes("FAKE_AUTH_CODE")) throw Error("gap");

// The known fields are masked; the cookie and code survive.
// This reproduces the failure class, not the original filter.

Ostorlab siguió después el mensaje resultante hasta la ruta de serialización del SDK de registro de eventos. La captura de tráfico en ejecución y la reutilización de credenciales seguían pendientes, por lo que el artículo no describe una exfiltración real observada de credenciales ni una toma de control de sesión completada.

Orientación para la corrección. Elimine las instrucciones de registro que contienen credenciales cuando sea posible y, después, aplique un ocultamiento coherente a atributos estructurados, cabeceras serializadas y representaciones de objetos en cadenas. Pruebe tanto las rutas de autenticación satisfactoria como los errores. Use secretos sintéticos en las pruebas de regresión y compruebe que no estén presentes ni en el evento de log en cola ni en su forma transmitida.

La evaluación identifica los puntos de registro de autenticación, los formatos omitidos por la regla de enmascaramiento y la ruta de serialización. Estas ubicaciones definen los cambios de código necesarios y las pruebas de regresión para ocultar credenciales.

Laboratorio de AD separado: cadena desde ACL hasta certificados y limpieza pendiente

En una evaluación de laboratorio de Active Directory, el agente partió de un usuario de dominio con pocos privilegios y enumeró la superficie de control de acceso del directorio. La revisión abarcó 3,002 filas de listas de control de acceso (ACL) entre usuarios, grupos, equipos y la raíz del dominio. Identificó una entrada de control de acceso (ACE) WriteOwner no heredada que permitía a un usuario ordinario tomar posesión de la cuenta de servicio de la autoridad de certificación (CA). Era la única ACE del conjunto que otorgaba a una identidad ajena a Tier-0 control sobre un objeto Tier-0.

La cuenta de servicio de la CA era miembro de Cert Publishers, tenía GenericAll sobre una plantilla de certificados y era vulnerable a Kerberoasting con RC4.

La concesión GenericAll sobre la plantilla de certificados constituía la condición ESC4: permitía al agente modificar la configuración de seguridad de la plantilla antes de solicitar un certificado como otra identidad. La ACE WriteOwner de la cuenta de servicio era el punto de entrada separado a esa ruta de control de la plantilla. La pertenencia a Cert Publishers y la exposición a Kerberoasting con RC4 suponían exposición adicional, no requisitos previos para el paso ESC4.

El límite esperado. Una cuenta de servicio de CA y sus plantillas de certificados son objetos Tier-0. Los usuarios ordinarios no deben ser sus propietarios, las ACL de las plantillas deben restringirse a los administradores de la CA y del directorio, y cada emisión debe registrarse y poder revocarse. Una ACE WriteOwner en la cuenta de la CA no es una delegación rutinaria.

La investigación. El agente tomó posesión de la cuenta de servicio, reescribió la DACL para otorgarse GenericAll y controló la cuenta. Modificó la plantilla para permitir la inscripción, solicitó un certificado como administrador, se autenticó con ese certificado y replicó krbtgt. Después falsificó un golden ticket. El certificado de administrador emitido indebidamente siguió sin revocarse.

Una ACE no heredada otorgó a un usuario ordinario la propiedad de la cuenta de servicio de la CA. El agente encadenó esa propiedad, a través de una plantilla ESC4, hasta un certificado y la replicación del dominio.

Pseudocódigo ilustrativo de ejecución · nombres sintéticos; no es sintaxis real de herramientas.

# Lab: ordinary user -> CA service account -> template -> certificate -> DCSync.
# Names and values are synthetic.

ace = read_ace(target="svc-ca", trustee="user-a")
# One non-inherited WriteOwner ACE in 3,002 ACL rows.

seize_owner(target="svc-ca", as="user-a")
grant_generic_all(target="svc-ca", to="user-a")
reset_secret(target="svc-ca")

template = modify_template("CorpAuthTemplate", enroll="svc-ca")
cert = request_certificate(template, subject="Administrator")
session = authenticate_with(cert)
replicate_krbtgt(session)
forge_golden_ticket()

# The misissued administrator certificate was not revoked.

Paso	Evidencia	Límite evaluado
Enumerar las ACL de todo el directorio	3,002 filas; una ACE WriteOwner no heredada para un usuario ordinario sobre la cuenta de servicio de la CA	Si los objetos Tier-0 estaban aislados de los usuarios ordinarios.
Tomar posesión y reescribir la DACL	Toma de posesión y concesión de GenericAll reproducidas en ejecución; escrituras revertidas con igualdad byte a byte	Si la ACE era explotable y no solo estaba presente.
Controlar la cuenta de servicio de la CA	La cuenta era miembro de Cert Publishers y tenía GenericAll sobre la plantilla	Si los derechos de la cuenta de servicio alcanzaban la emisión de certificados.
Modificar la plantilla y solicitar un certificado	Condición ESC4; se emitió un certificado de administrador	Si las ACL de la plantilla impedían la inscripción como una identidad privilegiada.
Autenticarse con el certificado y replicar krbtgt	Replicación del dominio y un golden ticket	Si la autenticación mediante certificados alcanzaba la autoridad del controlador de dominio.
Comprobar la revocación	El certificado de administrador emitido indebidamente seguía sin revocarse	Si la organización podía retirar la credencial.

Qué demuestra la evidencia. La toma de control mediante ACL se reprodujo en ejecución, y los derechos de la cuenta alcanzaban una plantilla que la CA utilizaría. La etapa de certificados y replicación se registra como la cadena crítica del agente; el certificado emitido indebidamente seguía sin revocarse al terminar la evaluación. Se trata de una evaluación de laboratorio, no de un resultado de cliente ni de un benchmark comparativo. El certificado sin revocar es una tarea de limpieza pendiente, no evidencia de una restauración completada. Una evaluación equivalente necesita un responsable designado para revocarlo y verificar el resultado antes de aceptar la limpieza como completa.

Resultado de la evaluación. El control de la cuenta de servicio de la CA proporcionó acceso a una plantilla de certificados que podía modificarse para solicitar un certificado de administrador. La secuencia registrada conectó la configuración incorrecta inicial de ACL con la autenticación mediante certificados y la replicación del dominio. El laboratorio no comparó el rendimiento de evaluaciones automatizadas y manuales.

Orientación para la corrección. Elimine la ACE y revise cada concesión no heredada sobre objetos Tier-0. Separe la cuenta de servicio de la CA de la administración ordinaria, restrinja las ACL de las plantillas a los administradores de la CA y del directorio, desactive RC4 para las cuentas de servicio, exija aprobación y registro para los cambios de plantillas y la emisión de certificados, revoque los certificados emitidos indebidamente y rote krbtgt dos veces. Las nuevas pruebas deben verificar que un usuario con pocos privilegios no pueda ser propietario de la cuenta de la CA ni modificar la plantilla, que DCSync falle y que los tickets falsificados sean rechazados tras la rotación.

Un informe de pruebas internas debe documentar la identidad inicial, las ACL afectadas, los permisos obtenidos, los resultados de validación, las pruebas sin éxito y los artefactos restantes. Los administradores necesitan esta información para reproducir el hallazgo, reparar la delegación y verificar la limpieza dentro del alcance autorizado.