Evasión de defensas en Azure: logs borrados y Defender
Configuraciones de diagnóstico borradas, exportación del Activity Log eliminada, planes de Defender en Free, bloqueos y NSG: detectar la evasión en Azure.
En resumen. En Azure, los atacantes no borran el Activity Log: no pueden, Azure no permite a nadie modificar ni eliminar sus entradas. Lo que hacen es cortar las tuberías: microsoft.insights/diagnosticSettings/delete en un Key Vault o una cuenta de almacenamiento (los logs de recursos se detienen), la misma operación a nivel de suscripción (la exportación del Activity Log se detiene), Microsoft.Security/pricings/write con pricingTier: Free (se desactiva un plan de Defender), Microsoft.Authorization/locks/delete, y reglas de NSG o del cortafuegos de almacenamiento abiertas. Cada una de esas acciones queda registrada a su vez en el Activity Log, que Azure conserva 90 días. El hueco que crean empieza en la marca de tiempo de la eliminación.
El evento más revelador de muchas intrusiones en Azure no es el robo, sino la limpieza. Una configuración de diagnóstico borrada a las 02:55 de un domingo por la misma entidad de servicio que leyó doce secretos a las 02:24 es lo más parecido a una confesión que ofrecen los logs en la nube.
Por qué sobrevive el Activity Log
Microsoft indica que las entradas del Activity Log las genera el sistema y que no se pueden modificar ni eliminar (registro de actividad en Azure Monitor). Siguen disponibles durante 90 días, sea cual sea la configuración de exportación. Lo que sí puede hacer un atacante:
| Objetivo | Operación | Efecto | Recuperación |
|---|---|---|---|
| Logs de recursos de un almacén, cuenta de almacenamiento, NSG… | microsoft.insights/diagnosticSettings/delete en el recurso | Los logs del plano de datos dejan de escribirse desde ese momento | Volver a crear la configuración; el hueco es permanente |
| Exportación del Activity Log (configuración de diagnóstico de la suscripción) | microsoft.insights/diagnosticSettings/delete a nivel de suscripción | Se detiene la copia a largo plazo (Log Analytics, almacenamiento, Event Hubs) | La copia de 90 días en Azure sigue ahí: expórtala ya |
| Mecanismo heredado de exportación del Activity Log | microsoft.insights/logProfiles/delete | Lo mismo, con el mecanismo heredado | Lo mismo |
| Microsoft Defender for Cloud | Microsoft.Security/pricings/write → nivel Free | Se detienen las detecciones propias del plan | Reactivar; las alertas del hueco se pierden |
| Bloqueos de recursos | Microsoft.Authorization/locks/delete | Los recursos protegidos pasan a poder eliminarse | Restaurar los bloqueos |
| Controles de red | Regla NSG que permite entrada desde * / Internet; almacenamiento con defaultAction: Allow | Rutas de acceso abiertas | Revertir |
Los blobs de logs ya existentes en una cuenta de almacenamiento sí puede borrarlos quien tenga permisos sobre esa cuenta. Eso aparece como StorageDelete en los propios logs de la cuenta, si estaban activados y se enviaban a otro sitio. Por eso el archivo de logs debería estar en una suscripción separada, con su propio control de acceso.
MITRE ATT&CK registra estas acciones como T1562.008 Disable or Modify Cloud Logs, T1562.001 Disable or Modify Tools y T1562.007 Disable or Modify Cloud Firewall.
Leer un evento diagnosticSettings/delete
El resourceId te dice qué se ha apagado:
…/providers/Microsoft.KeyVault/vaults/<vault>/providers/microsoft.insights/diagnosticSettings/<name>: un Key Vault dejó de enviarAuditEvent.…/providers/Microsoft.Storage/storageAccounts/<account>/…/diagnosticSettings/<name>: se detuvieron los logs de almacenamiento./subscriptions/<id>/providers/microsoft.insights/diagnosticSettings/<name>: sin grupo de recursos en la ruta, es la configuración de la suscripción, es decir, la exportación del Activity Log.
El nombre de la configuración suele ser descriptivo (kv-audit-to-storage, export-activity-to-sentinel) y ayuda a averiguar adónde iban los logs. Después:
- Anota la marca de tiempo exacta. Es el final de tu visibilidad del plano de datos de ese recurso.
- Mira qué hizo el mismo autor en la hora anterior. Borrar el registro suele ser el último paso, no el primero.
- Si la configuración se volvió a crear más tarde, tienes un hueco, no una ausencia. Descríbelo como tal.
Un diagnosticSettings/write también puede servir para la evasión: redirigir los logs a un área de trabajo controlada por el atacante o quitar una categoría degrada la recopilación en silencio. Revisa el cuerpo de la solicitud.
Planes de Defender for Cloud
Los planes de Defender for Cloud se configuran por suscripción mediante la API pricings. Volver a poner un plan en el nivel Free aparece como Microsoft.Security/pricings/write con "pricingTier": "Free" en el cuerpo de la solicitud. El nombre del recurso indica el plan (VirtualMachines, StorageAccounts, KeyVaults, Arm…). Una decisión de ahorro de costes produce el mismo evento, así que confírmalo con el responsable y después contrasta el momento con los demás hallazgos.
Las alertas de Defender generadas antes de desactivar el plan siguen en la API de alertas; expórtalas (guía de exportación). El analizador Azure Forensics lee esa exportación y convierte cada alerta en un hallazgo AZ-DEF-001, con la gravedad de la alerta.
Qué marca el analizador
| Regla | Detecta | Nivel |
|---|---|---|
AZ-DE-001 | Configuración de diagnóstico eliminada en un recurso (la ruta contiene un grupo de recursos) | Alto |
AZ-DE-002 | Exportación del Activity Log eliminada (configuración de diagnóstico de la suscripción o log profile heredado) | Alto |
AZ-DE-003 | Plan de Defender for Cloud pasado al nivel Free | Alto |
AZ-DE-004 | Bloqueo de recurso eliminado | Medio |
AZ-DE-005 | Regla NSG que permite tráfico entrante desde cualquier origen / Internet | Medio |
AZ-ST-004 | Cortafuegos del almacenamiento abierto a todas las redes | Medio |
AZ-KV-004 | Eliminación temporal o protección de purga desactivadas en un almacén, u objetos purgados | Alto |
Como el veredicto exige al menos dos hallazgos altos para «Comprometido», un AZ-DE-003 aislado por una decisión financiera te deja en «Sospechoso», que es la respuesta correcta hasta que alguien confirme el motivo.
Reconocer el hueco en tus propios datos
La evasión se nota en los datos que cargas, no solo en los eventos:
- Una fuente que se corta de golpe. El bloque de cobertura muestra el primer y el último evento de cada fuente. Un log de Key Vault que termina a las 02:55 mientras el Activity Log sigue hasta las 03:30 encaja con una eliminación a las 02:55.
- Blobs horarios que se interrumpen. En una exportación a almacenamiento, las carpetas
h=de ese recurso simplemente se acaban. - Duplicados que desaparecen. Si cargaste tanto la exportación a almacenamiento como una exportación reciente de
azCLI, la copia de la CLI continúa después del corte: es la copia de 90 días de Azure haciendo su trabajo.
En el ejemplo ficticio, la configuración de diagnóstico del Key Vault se elimina a las 02:55:12 y la exportación de la suscripción a las 02:55:40; el Activity Log exportado a almacenamiento termina ahí, y solo la exportación de la CLI muestra la eliminación de la propia exportación.
Remediación y bastionado
- Vuelve a crear las configuraciones de diagnóstico eliminadas y la exportación del Activity Log; comprueba que los datos vuelven a llegar.
- Reactiva los planes de Defender; revisa las alertas durante y después del hueco.
- Impón el registro con Azure Policy (deploy-if-not-exists para configuraciones de diagnóstico), de modo que las configuraciones que falten se marquen como no conformes y puedan volver a desplegarse con una tarea de corrección.
- Mantén el archivo de logs en una suscripción separada, con permisos de borrado en muy pocas identidades; valora el almacenamiento inmutable para el contenedor del archivo.
- Restaura los bloqueos de los recursos críticos y restringe
Microsoft.Authorization/locks/delete.