Límites de la forense de logs de Azure: retención y huecos
El Activity Log de Azure se conserva 90 días y los logs de recursos vienen desactivados. Qué no puede decirte cada log y cómo redactar una conclusión honesta.
En resumen. Azure conserva el Activity Log 90 días y después lo elimina. Los logs de recursos (Key Vault, almacenamiento y la mayor parte de la actividad del plano de datos) vienen desactivados por defecto y solo existen desde el momento en que se creó una configuración de diagnóstico. Los flow logs hay que activarlos por NSG o por VNet. Los eventos de nivel de tenant, como elevateAccess, no están en las exportaciones de suscripción. Las reglas son heurísticas con umbrales y periodos de aprendizaje. Nada de esto hace inútil la forense en Azure; obliga a dejar por escrito exactamente con qué contabas y a formular las conclusiones en consecuencia.
Cada informe de Azure que escribo tiene una sección llamada «Alcance y limitaciones». No es relleno. Es donde el lector descubre si «no hay pruebas de acceso a los datos» significa «lo comprobamos y no pasó nada» o «no había nada que comprobar».
Retención: la cuenta atrás de 90 días
Microsoft indica que Azure conserva los eventos del registro de actividad durante 90 días y después los elimina (registro de actividad en Azure Monitor). La API REST exige que los dos extremos del intervalo estén dentro de esa ventana. Consecuencias:
- Una intrusión descubierta el día 100 ha perdido sus diez primeros días de historial del plano de control, salvo que una configuración de diagnóstico exportara el Activity Log a Log Analytics (retención configurable, hasta 12 años según Microsoft), a una cuenta de almacenamiento o a Event Hubs.
- El creador de un recurso solo se registra en el Activity Log. Pasados 90 días sin exportación, «¿quién creó esta VM?» puede quedarse sin respuesta.
- Exportar pronto es la acción más valiosa de la primera hora (guía de exportación).
Los logs de recursos no tienen retención de plataforma: viven donde los envíe la configuración de diagnóstico, con la retención de ese destino.
Fuentes que faltan: registro que nunca estuvo activo
| Pregunta | Log necesario | ¿Activo por defecto? | Si estaba desactivado |
|---|---|---|---|
| ¿Quién cambió qué en Azure? | Activity Log | Sí (90 días) | — |
| ¿Quién leyó qué secreto de Key Vault? | Key Vault AuditEvent | No | Sin respuesta; rotar todos los secretos alcanzables |
| ¿Qué blobs se descargaron? | StorageRead / StorageBlobLogs | No | Sin respuesta desde Azure; dar por expuesto el contenido de la cuenta |
| ¿Habló una VM con el atacante? | Flow logs de NSG / VNet | No | Mirar la propia VM, logs de cortafuegos o de proxy |
| ¿Cómo se comprometió la identidad? | Registros de inicio de sesión y auditoría de Entra ID | Sí (retención según licencia) | Investigación aparte (m365forensics.com) |
| ¿Qué se ejecutó en la VM? | Logs del SO invitado, disco | Depende de la VM | Forense del disco |
El bloque de cobertura del analizador lo deja explícito: fuentes «no proporcionado», reglas que «no pudieron ejecutarse» y por qué. Cópialo en tu informe.
Huecos creados por el atacante
Las configuraciones de diagnóstico eliminadas crean un hueco desde la marca de tiempo de la eliminación; los planes de Defender desactivados detienen las detecciones; los blobs de logs borrados eliminan historial de un archivo. Es distinto de «nunca estuvo activo»: la eliminación en sí es una prueba, registrada en el Activity Log. Ver evasión de defensas.
Puntos ciegos de los propios logs
Incluso con todos los logs activados:
- El contenido de los scripts de Run Command no suele estar en el Activity Log (ataques con Run Command).
- La creación de una SAS firmada en el cliente no se registra en ningún sitio; Microsoft indica que no es posible auditar la generación de tokens SAS (información general de SAS).
- Los flow logs no llevan cargas útiles y no ven a clientes de Internet que hablan directamente con endpoints PaaS (flow logs).
- Las operaciones de lectura en el plano de control (listar recursos, leer configuración) no suelen estar en el Activity Log, así que el reconocimiento es casi invisible.
- Los eventos de nivel de tenant, como
elevateAccess, están en el log de nivel de tenant, no en las exportaciones de suscripción. - La latencia. Microsoft habla de 3 a 20 minutos para la disponibilidad del Activity Log y de hasta 10 minutos para los logs de Key Vault; una exportación hecha durante un incidente activo puede perder los últimos minutos.
- Diferencias de mayúsculas en Log Analytics. Microsoft señala que los valores de
AzureActivitypueden variar en mayúsculas y minúsculas; las comparaciones de cadenas deben ignorarlas.
Límites del analizador
Seamos honestos también con la herramienta:
- Solo ve lo que cargas. Sin acceso por API a tu tenant, por diseño.
- Las reglas de primera aparición necesitan más de 72 horas de historial antes de la actividad sospechosa. Con una exportación corta,
AZ-KV-001,AZ-ID-001,AZ-ID-002yAZ-VM-004no pueden ejecutarse. - Los umbrales se pueden esquivar. La descarga masiva exige 50 blobs distintos en una hora desde una misma identidad e IP; la enumeración de secretos, 8 objetos distintos en una hora. Un atacante paciente se queda por debajo.
- La automatización legítima dispara reglas. Cada regla documenta sus falsos positivos conocidos.
- Formatos. Avro (Event Hubs Capture) y Parquet no se leen; el CSV del portal se trata en la medida de lo posible; el UTF-16 hay que convertirlo.
- Límite de visualización. Más allá de 100 000 eventos la tabla deja de listarlos, pero todos se analizan y cuentan igualmente.
- Entra ID queda fuera del alcance. La identidad corresponde a m365forensics.com.
Redactar la conclusión
Formulaciones que uso según lo que había disponible:
| Situación | Formulación defendible |
|---|---|
| Logs de Key Vault presentes durante todo el periodo, sin lecturas sospechosas | «No hay pruebas de acceso a secretos por parte de la identidad comprometida en los logs de auditoría de Key Vault que cubren <periodo>.» |
| Logs de Key Vault ausentes | «El registro de auditoría de Key Vault no estaba activado; no puede determinarse el acceso a secretos. Todos los secretos accesibles para la identidad se consideran expuestos.» |
| Logs eliminados en mitad del incidente | «El atacante desactivó el registro de Key Vault a las <hora>; no puede determinarse la actividad posterior.» |
| Veredicto Limpio, cobertura completa | «Ninguna detección coincidió en <fuentes> durante <periodo>. Esto no excluye actividad por debajo de los umbrales de detección.» |
El veredicto de cualquier herramienta automática es el comienzo de ese párrafo, no su conclusión.
FAQ
¿Cuánto tiempo conserva Azure el Activity Log?
90 días. Después, Azure elimina los eventos. Para una retención más larga hace falta una configuración de diagnóstico que envíe el Activity Log a un área de trabajo de Log Analytics, una cuenta de almacenamiento o Event Hubs.
¿Puedo obtener logs de acceso de Key Vault o de almacenamiento de un periodo en el que el registro estaba desactivado?
No. Los logs de recursos solo se escriben mientras una configuración de diagnóstico los envía a algún sitio. Activar una ahora no rellena el pasado.
¿Un veredicto Limpio significa que la suscripción no estaba comprometida?
No. Significa que ninguna regla de detección coincidió en los logs aportados. Comprueba qué fuentes había, qué reglas no pudieron ejecutarse y si la ventana de retención cubre el periodo sospechoso.