Análisis del Activity Log de Azure, paso a paso
Análisis paso a paso del Activity Log de Azure con el analizador gratuito Azure Forensics: carga exportaciones, lee veredicto, hallazgos, cronología, entidades.
En resumen. Exporta el Activity Log (y Key Vault, almacenamiento y flow logs si los tienes), abre el analizador Azure Forensics, suelta los archivos o un ZIP y lee en este orden: cobertura → veredicto → hallazgos → cronología → entidades → remediación. Todo se ejecuta en local como WebAssembly dentro de un Web Worker; nada sale del navegador. Calcula 30 minutos para una primera pasada sobre una suscripción típica.
Este es el procedimiento que sigo cuando alguien me entrega una carpeta de exportaciones de Azure y pregunta «¿nos han atacado?». La herramienta da una primera respuesta rápida; los pasos siguientes sirven para leerla con ojo crítico.
Antes de empezar: qué cargar
El analizador lee estas fuentes y reconoce cada formato automáticamente:
| Fuente | Formatos aceptados |
|---|---|
| Activity Log | JSON de az CLI / REST, exportación a cuenta de almacenamiento o Event Hubs (insights-activity-logs, JSON Lines o {"records": […]}), AzureActivity de Log Analytics (CSV o JSON), «Download as CSV» del portal (en la medida de lo posible) |
| Key Vault | AuditEvent de la exportación a almacenamiento, o AzureDiagnostics |
| Almacenamiento | StorageRead / StorageWrite / StorageDelete, o StorageBlobLogs |
| Red | Flow logs de NSG v1 y v2, flow logs de VNet |
| Defender for Cloud | Exportación REST {"value": […]}, o SecurityAlert |
Archivos sueltos, carpetas completas (los árboles resourceId=/…/PT1H.json), ZIP y archivos .gz funcionan tal cual. Si todavía no tienes exportaciones, exportar el Activity Log de Azure y los logs de recursos recoge los comandos.
Incluye al menos una semana antes del inicio sospechado. Varias reglas son de «primera aparición» y aprenden qué es normal durante las primeras 72 horas de datos; sin ese historial no pueden ejecutarse.
Paso 1: cargar los archivos
Abre el analizador. Suelta los archivos en la zona de carga, o usa Elegir archivos / Elegir una carpeta. Los ZIP se descomprimen en el navegador. Cada archivo se lee en bloques de 4 MB y se envía en flujo al analizador en Rust, así que una exportación de varios gigabytes no necesita caber dos veces en memoria.
Para ver primero cómo es un resultado, pulsa Probar un ejemplo. Carga una exportación sintética de una empresa ficticia (Kestrel Freight), señalada como tal en pantalla. El caso ficticio paso a paso explica ese ejemplo hallazgo por hallazgo.
Paso 2: revisar la cobertura antes del veredicto
El bloque Cobertura es lo más importante de la página y lo que más se pasa por alto. Enumera, por fuente (Activity Log, Key Vault, almacenamiento, flow logs de NSG / VNet, Defender for Cloud), el número de eventos y el intervalo temporal, o «no proporcionado».
Debajo, la herramienta enumera las detecciones que no pudieron ejecutarse, con el motivo:
- origen de logs no proporcionado: por ejemplo, todas las reglas de Key Vault cuando no se cargó ningún log
AuditEvent; - necesita más de 72 h de historial: las reglas de primera aparición sobre una exportación corta.
Un veredicto «Limpio» con Key Vault y almacenamiento marcados como «no proporcionado» significa «el plano de control parece limpio»; no dice nada del acceso a los datos. El artículo sobre los límites lo trata a fondo.
Mira también la pestaña Archivos: cada archivo descartado tiene su explicación (vacío, no es un log, Avro, Parquet, UTF-16, ZIP ilegible), y los duplicados entre exportaciones se cuentan y fusionan.
Paso 3: leer el veredicto y los hallazgos
El veredicto es deliberadamente sencillo y está documentado:
| Veredicto | Regla |
|---|---|
| Comprometido | Al menos dos hallazgos de gravedad alta, o uno crítico |
| Sospechoso | Al menos un hallazgo medio o alto |
| Limpio | Nada por encima de «bajo», en los logs aportados |
Por qué enumera los identificadores de regla que sostienen el veredicto. Cada hallazgo muestra después:
- el título y la gravedad de la regla, y un identificador estable (
AZ-RBAC-003,AZ-VM-001…) que puedes citar en un informe; - cuántas acciones distintas coincidieron, primera y última aparición;
- las entidades, IP y recursos implicados;
- grupos para las reglas de umbral (por ejemplo, un autor que lee 12 secretos distintos en menos de una hora);
- flujos de red para las reglas de flujo;
- técnicas de MITRE ATT&CK, con enlace.
Lee las pruebas de cada hallazgo alto. Una regla es una heurística: un equipo de plataforma que asigna Owner, o una copia de seguridad que lee cientos de blobs, pueden coincidir. La tabla de detecciones de la página de la herramienta enumera todas las reglas, y el propio archivo de reglas documenta los falsos positivos conocidos de cada una.
Paso 4: recorrer la cronología
La pestaña Cronología enumera cada evento ligado a un hallazgo medio, alto o crítico, en orden cronológico. Ahí es donde una cadena de ataque se vuelve legible: asignación de rol, luego Run Command, luego un token de identidad administrada usado desde fuera, luego lectura de secretos, luego una SAS generada, luego el registro eliminado.
Haz clic en un evento para ver los campos normalizados (operación, autor, tipo de autor, application ID, object ID, IP, recurso, user agent, correlation ID, archivo de origen) y el registro original tal como se exportó. Alterna entre UTC y Local con el selector; redacta los informes en UTC.
El correlationId importa: el Activity Log escribe varios eventos para una misma operación (Started, Accepted, Succeeded). El analizador cuenta acciones distintas, pero cuando cites un evento en un informe, cita también su correlation ID.
Paso 5: pivotar sobre entidades, IP y recursos
La pestaña Entidades es la tabla dinámica de la investigación:
- Entidades de seguridad: usuarios, entidades de servicio, identidades administradas, tokens SAS (identificados por un hash) y accesos anónimos, con primera y última aparición y número de hallazgos.
- Direcciones IP: públicas o privadas, con los totales enviados y recibidos cuando se cargaron flow logs.
- Recursos: filtrables por Key Vault, cuentas de almacenamiento, VM y red.
- Suscripciones.
Haz clic en cualquier fila para filtrar la tabla Eventos. La pregunta que hay que hacerle a una IP atacante es «¿qué más hizo?». La que hay que hacerle a una identidad comprometida, «¿cuándo empezó a comportarse de otra manera?».
La tabla de eventos admite además filtrado de texto libre (operación, entidad, IP, recurso, regla), filtros por fuente y resultado, y un interruptor Solo marcados.
Paso 6: remediación y exportación
La pestaña Remediación convierte los hallazgos en una lista ordenada: rotar credenciales, eliminar asignaciones de roles, aislar VM, rotar secretos de Key Vault y claves de almacenamiento, restaurar el registro y los planes de Defender, bloquear IP, investigar la parte de identidad en Entra ID. Las casillas marcadas solo se guardan en la página.
Para el expediente:
- CSV exporta la tabla de eventos (con protección frente a inyección de fórmulas en hojas de cálculo);
- Informe JSON exporta el resultado completo: veredicto, hallazgos, cronología, entidades, cobertura.
Lo que la herramienta no hará por ti
- No ve nada que no hayas exportado. Ninguna llamada a API, ningún acceso a tu tenant.
- No analiza inicios de sesión de Entra ID ni credenciales de aplicaciones; eso corresponde a la herramienta hermana m365forensics.com.
- No demuestra ausencias. Un atacante cuidadoso puede quedarse por debajo de un umbral.
Para el proceso que rodea a la herramienta (qué preservar primero, cómo contener), empieza por la guía de respuesta a incidentes.