Ejemplo de cronología de un incidente en Okta (ficticio)
Una intrusión ficticia en Okta leída evento a evento: restablecimiento del helpdesk, factor del atacante, Super Admin, IdP malicioso, AWS y los hallazgos.
TL;DR. Todo en este artículo es ficticio: la organización, las personas, las direcciones IP (rangos de documentación), los números de AS (rango de documentación) y los dominios (.example). Es el ejemplo que carga el botón Probar un ejemplo del analizador: 160 eventos del System Log a lo largo de dos días en los que un atacante convence al helpdesk para que restablezca la contraseña y los factores de una administradora de TI, registra su propio Okta Verify desde un VPS, concede Super Administrator a una cuenta de servicio, añade un proveedor de identidad entrante y lo usa para llegar a AWS. El veredicto del analizador es Compromiso probable, con un hallazgo crítico y cinco altos. Este recorrido muestra cómo leerlo.
El escenario ficticio
«Northwind Logistics» (northwind.example) tiene una pequeña organización de Okta: doce cuentas, una red de oficina en Lyon, algunas personas en teletrabajo y aplicaciones como Slack, Salesforce, Google Workspace, Jira y AWS IAM Identity Center. Tres cuentas importan:
| Cuenta | Papel en la historia |
|---|---|
m.okafor@northwind.example | administradora de TI (Super Administrator), de baja por enfermedad la mañana del incidente |
h.lambert@northwind.example | agente del helpdesk |
svc-sync@northwind.example | cuenta de servicio de sincronización de directorio; nunca inicia sesión de forma interactiva |
Redes: la oficina (198.51.100.10, «Example Telecom», AS64496), la banda ancha doméstica (192.0.2.x, AS64497) y el VPS del atacante (203.0.113.77, «Example VPS Hosting Ltd», AS64511, Ámsterdam).
El 14 de septiembre y la mañana del 15 son jornadas normales: inicios de sesión con contraseña, push de Okta Verify, SSO a las aplicaciones, alguna contraseña mal escrita.
La intrusión, evento a evento (2026-09-15, UTC)
| Hora | eventType | Actor | Objetivo / detalle | Origen |
|---|---|---|---|---|
| 13:58:40 | user.session.access_admin_app | h.lambert | Okta Admin Console | oficina |
| 14:03:12 | user.account.reset_password | h.lambert | m.okafor | oficina |
| 14:03:40 | user.mfa.factor.reset_all | h.lambert | m.okafor | oficina |
| 14:09:05 | policy.evaluate_sign_on | m.okafor | riesgo HIGH, dispositivo nuevo / país nuevo | VPS |
| 14:09:09 | user.session.start | m.okafor | contraseña | VPS |
| 14:10:22 | user.mfa.factor.activate | m.okafor | Okta Verify registrado | VPS |
| 14:10:51 | user.authentication.auth_via_mfa | m.okafor | push de Okta Verify | VPS |
| 14:12:30 | user.session.access_admin_app | m.okafor | Okta Admin Console | VPS |
| 14:19:02 | user.account.privilege.grant | m.okafor | svc-sync, «Super administrator» | VPS |
| 14:26:47 | system.idp.lifecycle.create | m.okafor | IdP «Partner SSO» | VPS |
| 14:27:10 | system.idp.lifecycle.activate | m.okafor | IdP «Partner SSO» | VPS |
| 14:33:15 | user.authentication.auth_via_IDP | svc-sync | a través de «Partner SSO» | VPS |
| 14:33:16 | user.session.start | svc-sync | aserción de federación | VPS |
| 14:35:18 | user.authentication.sso | svc-sync | AWS IAM Identity Center | VPS |
| 14:36:02 | user.authentication.sso | m.okafor | AWS IAM Identity Center | VPS |
| 15:41:08 | user.session.start FAILURE | m.okafor | INVALID_CREDENTIALS | casa |
| 15:41:52 | user.session.start FAILURE | m.okafor | INVALID_CREDENTIALS | casa |
Léelo como una historia: a las 14:03 el helpdesk restablece la contraseña y los factores de Maya (alguien llamó haciéndose pasar por ella). Seis minutos después, «Maya» inicia sesión desde un VPS neerlandés que nunca había usado, registra un Okta Verify nuevo y en menos de diez minutos está en la Admin Console. Convierte una cuenta de servicio en Super Administrator, crea y activa un proveedor de identidad entrante e inicia sesión como la cuenta de servicio a través de él. Ambas identidades abren AWS. A las 15:41, la Maya real, ya conectada desde casa, no puede entrar: su contraseña ha cambiado.
Es el patrón descrito en el artículo sobre la ingeniería social al helpdesk y en el artículo sobre cross-tenant impersonation, comprimido en 33 minutos.
Qué informa el analizador
Veredicto: Compromiso probable. Estadísticas: 160 eventos, 12 usuarios, 5 direcciones IP, 24 sesiones, del 2026-09-14 07:56 al 2026-09-15 15:41 UTC.
| Gravedad | Hallazgo | Clave | Por qué se disparó |
|---|---|---|---|
| Crítica (agravado) | Restablecimiento por el helpdesk y nuevo factor registrado | m.okafor | restablecimiento por h.lambert y después user.mfa.factor.activate en 24 h, desde un proveedor de hosting / red nueva |
| Alta | Aplicación sensible abierta tras actividad sospechosa | m.okafor → Okta Admin Console | acceso a la Admin Console después del hallazgo crítico |
| Alta | Rol de Super administrador concedido | svc-sync | privilegeGranted = Super administrator |
| Alta | Nuevo proveedor de identidad (federación entrante) | Partner SSO | creación + activación |
| Alta | Aplicación sensible abierta tras actividad sospechosa | svc-sync → AWS IAM Identity Center | SSO de una cuenta implicada en un hallazgo alto; enlaza con AWS Forensics |
| Alta | Aplicación sensible abierta tras actividad sospechosa | m.okafor → AWS IAM Identity Center | lo mismo |
| Media | Inicio de sesión desde un proveedor de hosting | m.okafor | «Example VPS Hosting Ltd» coincide con la lista de hosting |
| Media | Inicio de sesión desde un proveedor de hosting | svc-sync | misma red |
| Baja | Contraseña o factores restablecidos por otro usuario | m.okafor | contexto informativo para la cronología |
El hallazgo crítico bastaría por sí solo para el veredicto Compromiso probable; cuatro reglas altas distintas lo hacen inequívoco.
Dos detalles que conviene notar:
- El inicio de sesión por IdP no es un hallazgo aparte.
user.authentication.auth_via_IDPes normal en organizaciones que usan federación. Aquí aflora a través de la regla de proveedor de hosting y de la regla de SSO tras actividad sospechosa, porquesvc-syncfue el objetivo de la concesión de Super Administrator. En un caso real, enumera a mano cadaauth_via_IDPa través de un IdP nuevo. - Los inicios de sesión fallidos de la víctima tampoco son un hallazgo. Dos fallos son ruido normal. Aun así aparecen en la cronología y, en un caso real, marcan el momento en que la usuaria se da cuenta; pregúntale cuándo llamó al helpdesk.
Trabajarlo en la interfaz
- Pestaña Hallazgos. Abre las pruebas del hallazgo crítico: tres eventos (restablecimiento de contraseña, restablecimiento de factores, activación del factor). El actor de los dos primeros es
h.lambert; el del tercero,m.okafordesde203.0.113.77. - Cronología del incidente. Las pruebas de cada hallazgo medio o superior, más las acciones de administración de las cuentas implicadas, en orden: básicamente la tabla de arriba, construida para ti.
- Entidades → direcciones IP.
203.0.113.77(AS64511, Países Bajos) tiene eventos de dos usuarios,m.okaforysvc-sync. Pulsa Eventos para ver todo lo que hizo esa IP. - Entidades → sesiones. La sesión del atacante para
m.okaforcontiene el registro del factor, el acceso a la Admin Console, la concesión y la creación del IdP: una sesión, todo el ataque. - Remediación. Conservar los registros; eliminar sesiones; revisar administradores; endurecer la verificación del helpdesk; restablecer factores y contraseña; investigar AWS y revocar allí las sesiones; revocar la concesión de Super Administrator; eliminar el IdP y revisar las reglas de enrutamiento; bloquear los proveedores de hosting en el inicio de sesión; contactar con la usuaria; escalar a respuesta a incidentes.
Qué haría después un equipo de respuesta
- Contener en Okta: eliminar «Partner SSO», revocar el rol de administración de
svc-sync, eliminar las sesiones de ambas cuentas y volver a registrar a Maya en persona. - Seguir en AWS: ambas identidades llegaron a AWS IAM Identity Center entre las 14:35 y las 14:36 desde
203.0.113.77. CloudTrail pasa a ser la fuente principal; AWS Forensics lo lee de la misma forma. - Cerrar el punto de entrada: averiguar cómo verificó el helpdesk a quien llamó a las 14:03 y cambiar el proceso para los restablecimientos de administradores.
Pruébalo tú
Abre el analizador, pulsa Probar un ejemplo y sigue los pasos anteriores. Después lee la guía de análisis paso a paso para hacer lo mismo con tu propia exportación, o la guía de investigación para el método.
El ejemplo lo genera un script del proyecto (scripts/make-samples.py) que sigue el esquema LogEvent del System Log de la documentación para desarrolladores de Okta y usa eventTypes del catálogo de event types. Sus direcciones IP provienen de los rangos de documentación de la RFC 5737 y sus números de AS del rango de documentación de la RFC 5398, así que nada apunta a una red real.