¿Suscripción de Azure comprometida? Guía de respuesta
¿Tu suscripción de Azure está comprometida? Qué logs preservar primero, las operaciones que delatan a un atacante y cómo pasar del Activity Log a un veredicto.
En resumen. Trata la pregunta «¿nos han comprometido la suscripción de Azure?» como tres preguntas: qué identidad actuó, qué hizo en el plano de control (Activity Log) y qué datos tocó (Key Vault, almacenamiento y flow logs). Exporta todo antes de que la retención te alcance: el Activity Log se conserva 90 días. Busca primero una lista corta de operaciones: roleAssignments/write, elevateAccess/action, runCommand/action, listAccountSas/action, accessPolicies/write, diagnosticSettings/delete. Si hoy solo puedes hacer una cosa, exporta el Activity Log de cada suscripción implicada y cárgalo en el analizador Azure Forensics, que se ejecuta en tu navegador.
Casi todos los incidentes de Azure que veo empiezan igual: alguien detecta un pico de costes, una alerta de Defender for Cloud o una asignación de roles que nadie recuerda haber creado. La tentación es abrir el portal y ponerse a hacer clic. Aguanta diez minutos. Hacer clic no preserva pruebas, y las vistas del portal vienen filtradas por defecto. Esta guía recoge el orden de trabajo que sigo.
Qué significa «comprometida» en Azure
Una suscripción de Azure tiene dos planos, y los atacantes usan ambos.
| Plano | Qué ocurre ahí | Dónde se registra | ¿Registrado por defecto? |
|---|---|---|---|
| Plano de control (Azure Resource Manager) | Crear, modificar y eliminar recursos; asignar roles; ejecutar comandos en VM; generar tokens SAS | Activity Log | Sí, 90 días |
| Plano de datos | Leer un secreto, descargar un blob, abrir una conexión TCP | Logs de recursos (Key Vault AuditEvent, StorageRead), flow logs de NSG / VNet | No: necesita una configuración de diagnóstico |
| Identidad | Inicios de sesión, MFA, nuevos secretos de aplicación, consentimientos | Logs de Microsoft Entra ID | Sí, la retención depende de la licencia |
Microsoft Learn es explícito con esta separación: el Activity Log registra operaciones del plano de control, mientras que los logs de recursos capturan el plano de datos y no se recopilan por defecto. Si el registro de Key Vault nunca se activó, nadie podrá decirte qué secretos se leyeron. Es el primer límite honesto de cualquier investigación en Azure; el artículo sobre los límites profundiza en ello.
Paso 1: preservar antes de investigar
Dos cosas destruyen las pruebas en Azure: el tiempo y el atacante.
- El tiempo. Azure conserva los eventos del Activity Log 90 días y después los elimina. Si la intrusión empezó hace 80 días, te quedan diez.
- El atacante. Eliminar una configuración de diagnóstico hace que un recurso deje de enviar sus logs desde ese momento. Es de lo primero que hace un intruso cuidadoso (evasión de defensas en Azure).
Así que, antes que nada:
- Exporta el Activity Log de cada suscripción afectada para el periodo sospechoso más al menos una semana antes. Esa semana es la referencia que separa lo normal de lo anómalo.
- Copia los contenedores de la cuenta de almacenamiento a los que escriben las configuraciones de diagnóstico:
insights-activity-logs,insights-logs-auditevent,insights-logs-storageread,insights-logs-networksecuritygroupflowevent,insights-logs-flowlogflowevent. - Exporta las tablas de Log Analytics si existen:
AzureActivity,AzureDiagnostics(Key Vault),StorageBlobLogs. - Exporta también el log de nivel de tenant (Directory Activity):
elevateAccessaparece ahí, no en el log de la suscripción.
Los comandos exactos, incluido el valor por defecto de az monitor activity-log list que devuelve en silencio solo 50 eventos, están en exportar el Activity Log de Azure y los logs de recursos.
Paso 2: encontrar las operaciones que importan
El Activity Log de una suscripción con actividad son sobre todo despliegues y escrituras de etiquetas. La actividad maliciosa se esconde en un puñado de nombres de operación. Estas son las que usan las reglas del analizador, agrupadas según lo que busca el atacante:
| Objetivo | Operación (Activity Log salvo indicación) | MITRE ATT&CK | Más información |
|---|---|---|---|
| Escalar privilegios | Microsoft.Authorization/roleAssignments/write (Owner, User Access Administrator, Contributor a una identidad no humana) | T1098.003 | Abuso de asignaciones de roles |
| Escalar a todas las suscripciones | Microsoft.Authorization/elevateAccess/action | T1078.004 | ídem |
| Ejecutar código en VM | Microsoft.Compute/virtualMachines/runCommand/action, extensions/write (Custom Script) | T1651 | Ataques con Run Command |
| Robar secretos | accessPolicies/write y luego SecretGet (log de Key Vault) | T1555.006 | Logs de auditoría de Key Vault |
| Robar datos | listAccountSas/action, listKeys/action y luego GetBlob (log de almacenamiento) | T1530 | SAS y exfiltración |
| Copiar discos | disks/beginGetAccess/action, snapshots/write | T1537 | Ataques con Run Command |
| Esconderse | diagnosticSettings/delete, Microsoft.Security/pricings/write (nivel Free), locks/delete | T1562.008 | Evasión de defensas |
| Persistir | Runbooks y webhooks de Automation, credenciales federadas en identidades administradas | T1098.001 | Abuso de identidades administradas |
| Minar | VM en regiones nunca usadas, flujos salientes a puertos de pools de minería | T1496 | Flow logs |
Ninguna es maliciosa por sí sola. Un equipo de plataforma asigna roles cada semana. Lo que las vuelve sospechosas es quién (una entidad de servicio que normalmente despliega una aplicación web), desde dónde (una IP nunca vista en el periodo de referencia), cuándo (a las 02:14 UTC de un domingo) y qué viene después (un Run Command tres minutos más tarde).
No es teoría. El análisis de Microsoft sobre el ransomware en la nube de Storm-0501 cita elevateAccess/action, roleAssignments/write, listkeys/action y locks/delete entre las operaciones usadas antes de exfiltrar datos y eliminar recursos.
Paso 3: pivotar sobre la identidad
Cada evento del Activity Log incluye el autor de la llamada y, en las exportaciones JSON, las claims del token: object ID, application ID y, en una identidad administrada, una claim xms_mirid que apunta a la VM o aplicación a la que pertenece. En cuanto encuentres un evento sospechoso, pivota:
- Todos los eventos del mismo autor, en todas las suscripciones, durante toda la ventana de retención. La primera aparición importa más que el evento más ruidoso.
- Todos los eventos desde la misma dirección IP, sea cual sea el autor. Los atacantes reutilizan infraestructura entre identidades robadas.
- La misma identidad en los logs de Key Vault y de almacenamiento, donde aparece como object ID o, en accesos SAS, como hash del token.
- La misma IP en los flow logs, donde una VM comprometida vuelve a contactarla.
La identidad en sí (cómo se filtró el secreto de una entidad de servicio, quién consintió qué) es una cuestión de Entra ID. Esa investigación corresponde a la herramienta hermana m365forensics.com, que cubre inicios de sesión, registros de auditoría y credenciales de aplicaciones.
Paso 4: contener en el orden correcto
En Azure, la contención es sobre todo trabajo de identidades. La lista de remediación del analizador la ordena más o menos así:
- Credenciales. Rota los secretos y certificados de las entidades de servicio implicadas; revoca las sesiones de los usuarios. Un secreto rotado no invalida un token de acceso ya emitido, así que espera una breve cola de actividad.
- Asignaciones de roles. Elimina todas las creadas durante el incidente, y la asignación de User Access Administrator en el ámbito raíz (
/) si se usóelevateAccess. - VM. Aíslalas con un NSG que lo deniegue todo, haz snapshots de los discos para el análisis forense y reconstrúyelas desde una imagen fiable. Borrar el script no «limpia» una VM que ejecutó código de un atacante.
- Secretos y claves. Rota todo lo leído en los almacenes afectados y las dos claves de las cuentas de almacenamiento (lo que invalida las SAS de cuenta y de servicio).
- Registro. Restaura las configuraciones de diagnóstico y los planes de Defender eliminados, y protégelos con un bloqueo o Azure Policy.
La información general sobre la respuesta a incidentes en Azure de Microsoft es la referencia oficial para el proceso completo.
Paso 5: obtener un primer veredicto rápido
Un primer triaje debería llevar minutos, no una semana de KQL. El analizador Azure Forensics lee exportaciones del Activity Log (CSV del portal, JSON de az CLI / REST, Log Analytics, exportación a cuenta de almacenamiento), Key Vault AuditEvent, StorageBlobLogs, flow logs de NSG y VNet y alertas de Defender for Cloud. Aplica 35 reglas documentadas y devuelve un veredicto:
- 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», lo que solo significa que nada coincidió en los logs que aportaste.
Todo se ejecuta en WebAssembly dentro de un Web Worker: no se sube nada. La guía paso a paso muestra cómo leer los hallazgos, la cronología y el pivote por entidades, y el caso ficticio paso a paso muestra una cadena completa con datos sintéticos.
FAQ
¿Qué es lo primero que hay que hacer cuando una suscripción de Azure está comprometida?
Preservar los logs antes de que caduquen (el Activity Log se conserva 90 días) y después contener: rotar las credenciales de las entidades implicadas, eliminar las asignaciones de roles que hayan creado y aislar las VM afectadas. La investigación va en paralelo, no después.
¿El Activity Log muestra quién leyó mis secretos de Key Vault o mis blobs?
No. El Activity Log registra operaciones del plano de control a través de Azure Resource Manager. Leer un secreto o descargar un blob son operaciones del plano de datos, que solo quedan en los logs de recursos de Key Vault y Storage, y solo si había una configuración de diagnóstico activa antes del incidente.
¿Dónde investigo cómo consiguió el atacante las credenciales?
En Microsoft Entra ID: registros de inicio de sesión, registros de auditoría, nuevos secretos de aplicación y consentimientos. Los logs de recursos de Azure muestran qué hizo la identidad con su acceso, no cómo lo obtuvo.
Lecturas recomendadas
- Registro de actividad en Azure Monitor: retención, exportación, eventos de nivel de tenant.
- Información general sobre la respuesta a incidentes en Azure: el proceso según Microsoft.
- Azure Threat Research Matrix: el catálogo de Microsoft de técnicas de ataque en Azure.
- Storm-0501's evolving techniques lead to cloud-based ransomware: Microsoft Threat Intelligence (en inglés).