Análisis del System Log de Okta paso a paso (gratis)
Analiza una exportación del System Log de Okta en tu navegador: carga los ficheros, lee el veredicto y los hallazgos, pivota por usuario, IP y sesión.
TL;DR. Abre el analizador Okta Forensics, suelta tu exportación del System Log (JSON, JSON Lines, CSV, gzip, ZIP o una carpeta entera) y lee el veredicto: Sin indicios de compromiso, Actividad sospechosa o Compromiso probable, con los hallazgos que lo motivan. Después recorre cinco pestañas: Hallazgos (qué se disparó y sobre qué eventos), Cronología del incidente, Entidades (usuarios, IP, sesiones, factores, aplicaciones, administradores), Todos los eventos (filtrables y exportables) y Remediación (una lista ordenada por urgencia). No se sube nada: el analizador está escrito en Rust compilado a WebAssembly y se ejecuta en tu navegador.
Este es el artículo de «qué botón pulso». Para el método (qué buscar y por qué), lee antes la guía de investigación de un compromiso en Okta.
Antes de empezar
Necesitas una exportación del System Log de Okta. La guía de exportación explica las opciones; en resumen: toda la organización, el periodo más largo que tengas y JSON original de la API siempre que sea posible.
¿No tienes una exportación a mano? Pulsa Probar un ejemplo en la página principal. Carga una exportación sintética de un incidente ficticio (160 eventos, organización inventada, direcciones IP de rangos de documentación) para que aprendas la interfaz con algo que seguro dispara detecciones. El recorrido por el incidente ficticio explica cada hallazgo que produce.
Paso 1: carga los ficheros
Suelta los ficheros en la zona de carga o usa Elegir ficheros / Elegir una carpeta. Qué se acepta:
| Entrada | Notas |
|---|---|
Array JSON de /api/v1/logs | varias páginas en un fichero, sin problema |
| JSON Lines, líneas con prefijo syslog | un evento por línea |
| Exportaciones de EventBridge, Elastic, Splunk | sobres detail, _source, result / _raw desempaquetados |
| CSV | cabeceras con rutas de LogEvent (actor.alternateId, target[0].displayName…) o columna _raw; separador coma, punto y coma o tabulador |
.gz, .zip, carpetas | descomprimidos y recorridos en el navegador, ZIP anidados incluidos |
Los ficheros se leen en bloques de 4 MB y se envían en flujo al analizador, así que funcionan exportaciones de varios gigabytes; el límite real es la memoria que ocupan los propios eventos. En exportaciones muy grandes (más de 200.000 eventos), las detecciones siguen ejecutándose sobre todos los eventos, pero la tabla muestra todas las pruebas más los eventos más recientes.
Paso 2: comprueba qué se ha leído realmente
Antes de fiarte de un veredicto, abre Ficheros analizados. Cada fichero muestra su número de eventos, formato y tamaño, además de notas: duplicados eliminados, registros que no son eventos del System Log, JSON no válido, eventos sin marca de tiempo legible o un fichero que termina a mitad de un evento (una exportación truncada). Ficheros no analizados explica cada rechazo: fichero vacío, no es un log de Okta, una hoja de cálculo en lugar de un CSV, un gzip o ZIP dañado.
Mira luego la fila de estadísticas: eventos, usuarios, direcciones IP, sesiones y el Periodo (UTC). Si el periodo no coincide con lo que exportaste, detente y corrige la exportación.
Paso 3: lee el veredicto
La lógica del veredicto es deliberadamente sencilla y visible:
| Veredicto | Regla |
|---|---|
| Compromiso probable | algún hallazgo crítico, o hallazgos altos de dos reglas distintas |
| Actividad sospechosa | cualquier otro hallazgo alto o medio |
| Sin indicios de compromiso | nada por encima de bajo (los hallazgos bajos son informativos) |
Bajo Por qué aparecen los hallazgos que determinaron el veredicto. Un veredicto limpio significa que ninguna de las 25 reglas de detección coincidió con estos eventos. No es un certificado; el artículo sobre límites explica lo que puede pasar desapercibido.
Paso 4: revisa los hallazgos
Cada tarjeta de hallazgo muestra una gravedad (crítica, alta, media, baja), una etiqueta agravado cuando una condición de seguimiento la elevó (por ejemplo, una ráfaga de push seguida de un push aceptado), una frase construida a partir de las pruebas, las marcas de tiempo inicial y final, los usuarios e IP implicados, las técnicas de MITRE ATT&CK y Ver los eventos para abrir las pruebas en la tabla de eventos.
Cada familia se explica en su propio artículo:
- Solicitudes MFA y restablecimientos: fatiga MFA, ingeniería social al helpdesk
- Sesiones: secuestro de sesión
- Administración y persistencia: roles y tokens de API, proveedores de identidad
- Ataques al inicio de sesión: password spraying
Cuando se abrió una aplicación sensible (AWS, Microsoft 365, Google Workspace, GitHub, plataformas Kubernetes…) tras una actividad sospechosa, el hallazgo enlaza con la herramienta hermana que lee los registros de esa plataforma, por ejemplo AWS Forensics para CloudTrail.
Paso 5: recorre la cronología del incidente
La pestaña Cronología del incidente ordena en el tiempo las pruebas de cada hallazgo medio, alto y crítico, más las acciones de administración de las cuentas implicadas. Es el borrador de la cronología de tu informe. Cambia entre UTC y Local con el selector; usa UTC para todo lo que compartas.
Paso 6: pivota sobre las entidades
La pestaña Entidades enumera usuarios, direcciones IP (con ASN y país), sesiones, factores, aplicaciones y administradores, cada uno con su número de eventos y fallos, primera y última aparición, y los hallazgos en los que figura. Pulsa Eventos en cualquier fila y la tabla de eventos se filtra por esa entidad. Así respondes a «¿qué más hizo esta IP?» o «¿qué pasó en esta sesión?» sin escribir una consulta.
Paso 7: filtra y exporta los eventos
Todos los eventos combina un filtro de texto libre (usuario, IP, eventType, aplicación, sesión, fecha), un filtro por categoría (autenticación, MFA, sesiones, administración e IdP, políticas, acceso a aplicaciones…), un filtro por resultado y Solo en un hallazgo. Pulsa una fila para ver cada campo relevante: mensaje, resultado, actor, objetivos, cliente, red, sesión, factor, privilegio concedido, riesgo, comportamientos, túnel de anonimización, indicador de ThreatInsight, URI de la petición, transacción y uuid.
CSV y JSON exportan lo que está filtrado en ese momento. El CSV está protegido contra la inyección de fórmulas, así que se puede abrir con seguridad en una hoja de cálculo.
Paso 8: remedia
La pestaña Remediación convierte los hallazgos en una lista ordenada por urgencia: conservar los registros, eliminar sesiones, restablecer factores y contraseñas, revisar y revocar roles de administración, revocar tokens de API, eliminar proveedores de identidad desconocidos, restaurar políticas, investigar las aplicaciones posteriores. Marca las casillas a medida que avanzas (el estado solo se queda en la página). El bloque Qué hacer ahora remite a la documentación de seguridad de Okta.
Privacidad, en breve
Los registros contienen datos personales. Por eso el analizador no tiene ningún punto de subida: los ficheros se leen en local en un Web Worker, WebAssembly los analiza y los resultados viven en la página. Al cerrar la pestaña, desaparecen.