Investigación de un compromiso en Okta: guía práctica
Cómo investigar un posible compromiso de Okta desde el System Log: alcance, eventTypes clave, la cadena de ataque paso a paso y qué contener primero.
TL;DR. Un compromiso de Okta casi siempre deja un rastro legible en el System Log: un restablecimiento o una avalancha de solicitudes MFA, un inicio de sesión desde una red que el usuario nunca había usado, un factor nuevo y, después, acciones de administración (roles, tokens de API, proveedores de identidad) y SSO hacia las aplicaciones importantes. Exporta como mínimo los 90 días de retención, léelos como una secuencia y no como alertas sueltas, contén en el orden sesiones → factores → privilegios de administración → tokens e IdP → aplicaciones posteriores, e investiga cada aplicación que abrió el atacante en sus propios registros. El analizador gratuito Okta Forensics hace la correlación en tu navegador sin subir nada.
He leído muchas cronologías de incidentes de identidad y el patrón es casi aburrido de tan constante: el atacante no explota ningún fallo del proveedor de identidad. Consigue que una persona, o un agente del servicio de ayuda, le abra la puerta, y luego usa las funciones de administración exactamente como fueron diseñadas. Es una buena noticia para quien responde al incidente, porque lo diseñado queda registrado. Esta guía es el método que sigo; el resto de la serie «Investigar un tenant de Okta» profundiza en cada paso.
Paso 0: plantea las preguntas
Escríbelas antes de abrir una sola línea de log. Una investigación de compromiso tiene que responder a cinco cosas:
- Acceso inicial. ¿Qué cuenta cayó primero, cuándo y cómo (adivinación de contraseña, fatiga MFA, restablecimiento por el helpdesk, sesión robada)?
- Privilegios. ¿Llegó el atacante a un administrador o se otorgó derechos de administración?
- Persistencia. ¿Qué dejó atrás: administradores adicionales, tokens de API, un nuevo proveedor de identidad, políticas debilitadas?
- Alcance. ¿Qué aplicaciones posteriores abrió mediante SSO?
- Estado de la contención. ¿Sigue activo ahora mismo algo de lo anterior?
Todo lo que viene a continuación responde a una de estas preguntas.
Paso 1: consigue el registro completo, no una vista filtrada
La API del System Log solo devuelve 90 días de datos, como documenta la guía de consultas del System Log de Okta. Empieza la exportación ya, antes de que caduquen las pruebas, y toma toda la organización en lugar de una búsqueda sobre un usuario: la mayoría de las correlaciones útiles (un restablecimiento hecho por otra persona, un rol de administración concedido a otra cuenta) están en eventos donde tu sospechoso es el objetivo, no el actor.
La guía de exportación del System Log cubre la API, el CSV de la Admin Console, el Log Streaming y las exportaciones de SIEM, incluida la trampa de paginación que pierde eventos sin avisar.
Paso 2: conoce la cadena de ataque que buscas
Esta cadena no es teórica. En agosto de 2023, Okta Security describió atacantes que llamaban a servicios de ayuda de TI para que restablecieran los factores de usuarios privilegiados, usaban el acceso de Super Administrator obtenido para conceder privilegios a otras cuentas y configuraban un segundo proveedor de identidad para iniciar sesión como otros usuarios (Okta Security, cross-tenant impersonation). El aviso conjunto de CISA y el FBI sobre Scattered Spider describe las mismas familias de técnicas, como la suplantación ante el helpdesk y las solicitudes MFA repetidas (CISA AA23-320A).
Cada paso tiene una lista corta de eventTypes:
| Paso | Qué ocurre | eventTypes clave | Para profundizar |
|---|---|---|---|
| Acceso inicial | Ráfaga de push, restablecimiento por el helpdesk, spraying, cookie robada | system.push.send_factor_verify_push, user.mfa.okta_verify.deny_push, user.mfa.factor.reset_all, user.session.start (FAILURE) | fatiga MFA, restablecimientos del helpdesk, spraying, secuestro de sesión |
| Punto de apoyo | El atacante registra su propio factor | user.mfa.factor.activate | restablecimientos del helpdesk |
| Acceso de administración | Apertura de la Admin Console | user.session.access_admin_app | abuso de administración |
| Privilegios y persistencia | Roles, tokens, políticas | user.account.privilege.grant, group.privilege.grant, system.api_token.create, policy.lifecycle.deactivate | abuso de administración |
| Puerta trasera de federación | Nuevo IdP entrante, inicio de sesión a través de él | system.idp.lifecycle.create, user.authentication.auth_via_IDP | cross-tenant impersonation |
| Alcance | SSO a AWS, Microsoft 365, GitHub… | user.authentication.sso | esta guía, paso 6 |
La tabla completa está en los eventTypes que realmente usan los equipos de respuesta.
Paso 3: encuentra al paciente cero
Trabaja desde las señales más fuertes hacia abajo:
- Restablecimientos hechos por otra persona. Filtra
user.mfa.factor.reset_all,user.mfa.factor.deactivateyuser.account.reset_passwordcuando el actor sea distinto del objetivo. Busca después unuser.mfa.factor.activatedel objetivo poco después. Si ese registro llega desde una red que el usuario no había usado nunca, probablemente tienes el punto de entrada. - Ráfagas de push. Varias solicitudes push o rechazos para un usuario en pocos minutos, sobre todo si al final se acepta una.
- Inicios de sesión fallidos en muchos usuarios desde una misma IP, seguidos de un éxito.
- Una sesión, varias redes. El mismo externalSessionId visto desde dos ASN es el rastro clásico de una cookie de sesión reutilizada.
- De dónde vino el inicio de sesión.
securityContext.asOrg,securityContext.isProxyydebugContext.debugData.tunnelsindican si el origen es un proveedor de hosting, un proxy o Tor. Los empleados rara vez inician sesión desde un VPS.
Paso 4: sigue el rastro de administración
Cuando conozcas la cuenta comprometida, pivota sobre ella como actor. Enumera todo lo que hizo como administrador entre su primer inicio de sesión sospechoso y ahora: concesiones de roles (debugContext.debugData.privilegeGranted indica cuál), tokens de API, proveedores de identidad, reglas de enrutamiento, cambios de políticas y autenticadores, ediciones de zonas de red, ajustes de ThreatInsight. Repite después el pivote con cada cuenta que tocó: un administrador recién ascendido o una cuenta de servicio que inicia sesión a través de un IdP nuevo es la segunda identidad del atacante que no se te puede escapar.
Paso 5: construye la cronología
Una cronología defendible tiene una fila por evento, en UTC, con actor, objetivo, IP de origen y ASN, sesión y resultado. Conserva el uuid original de cada evento para que cualquiera pueda contrastar tu lectura con el registro original. El recorrido por un incidente ficticio muestra cómo queda sobre una intrusión completa, aunque inventada.
Paso 6: sigue al atacante dentro de las aplicaciones
user.authentication.sso te dice qué aplicaciones se abrieron, cuándo y desde dónde, pero nada de lo que se hizo dentro. El registro de auditoría de la propia aplicación es la siguiente parada. Las sesiones en esas aplicaciones además sobreviven a la sesión de Okta, así que cerrar la sesión de Okta no expulsa al atacante de ellas. Para AWS la fuente es CloudTrail; la herramienta hermana AWS Forensics lo lee igual que este sitio lee el System Log. Para Microsoft 365 y Entra ID, M365 Forensics hace lo mismo.
Paso 7: contén en el orden correcto
El orden importa porque algunos puntos de apoyo del atacante sobreviven a la eliminación de otros:
- Conserva la exportación antes de cambiar nada.
- Elimina las sesiones de los usuarios afectados y revoca sus tokens.
- Restablece factores y contraseñas, y vuelve a registrar al usuario real por un canal verificado.
- Retira los roles de administración inesperados, empezando por Super Administrator.
- Revoca los tokens de API creados durante el incidente: un token de API lleva los permisos de quien lo creó y no depende de su contraseña.
- Desactiva los proveedores de identidad desconocidos y revisa las reglas de enrutamiento.
- Restaura las políticas, los autenticadores y los ajustes de seguridad.
- Revoca las sesiones en las aplicaciones posteriores e investígalas.
Las recomendaciones de Okta para la campaña de 2023 añaden refuerzos que deben ir al plan posterior al incidente: autenticadores resistentes al phishing, una verificación más estricta en el helpdesk y reautenticación para las acciones de administración sensibles (Okta Security).
Hacerlo con el analizador
Todo lo anterior puede hacerse a mano en un SIEM o en una hoja de cálculo. El analizador Okta Forensics automatiza la correlación: suelta la exportación y aplica 25 reglas de detección (umbrales, secuencias y condiciones de seguimiento) a cada evento, con un veredicto (Sin indicios de compromiso, Actividad sospechosa o Compromiso probable) y sus motivos, una cronología, un pivote por entidades y una lista de remediación ordenada por urgencia. Todo se ejecuta en local con WebAssembly; los registros nunca salen de tu equipo. La guía paso a paso muestra cada pantalla.
FAQ
¿Hasta dónde puedo remontarme en Okta?
La API del System Log devuelve 90 días de eventos. Lo anterior solo existe si se envió por streaming o se exportó a un SIEM o a un almacenamiento antes de caducar.
¿Qué cuenta debo revisar primero?
Los administradores, después cualquier cuenta cuya contraseña o factores haya restablecido otra persona, y después las cuentas que iniciaron sesión desde un proveedor de hosting o un anonimizador. Ese orden sigue la progresión de los ataques de identidad recientes.
¿Un resultado limpio demuestra que el tenant está a salvo?
No. Solo cubre los eventos de la exportación. Comprueba el periodo, comprueba que la exportación no estaba filtrada y confírmalo con las personas implicadas. La guía de límites y ajuste enumera los puntos ciegos.