Ataques con Azure Run Command: investigar ejecución en VM

En resumen. Run Command permite a cualquiera con Microsoft.Compute/virtualMachines/runCommand/action ejecutar un script en una VM a través del agente de VM (como SYSTEM en Windows, como usuario con privilegios elevados en Linux) sin ningún camino de red hacia la VM. El Activity Log registra quién, cuándo, desde dónde y en qué VM, pero por lo general no el script. El script está en la VM: C:\Packages\Plugins\Microsoft.CPlat.Core.RunCommandWindows\<version>\Downloads\ en Windows, /var/lib/waagent/run-command/download/ en Linux. La Custom Script Extension (extensions/write) es la misma idea con un paso de descarga. Correlaciona con los flujos salientes de la VM en los minutos siguientes.

Run Command es la función de Azure que más echaría de menos como administrador y la que más temo como defensor. Convierte un permiso del plano de control en ejecución de código en el sistema invitado, y precisamente por eso los intrusos que consiguen Contributor en una suscripción la usan en cuestión de minutos.

Por qué a los atacantes les gusta Run Command

Microsoft describe Run Command como una forma de ejecutar scripts dentro de una VM mediante el agente de VM, útil cuando RDP o SSH están cerrados (Windows, Linux). Desde el punto de vista de un atacante:

La secuencia típica: ejecutar RunShellScript o RunPowerShellScript con una línea que descarga una segunda fase, vuelca credenciales o consulta el Instance Metadata Service para obtener el token de la identidad administrada de la VM. Esto último convierte la ejecución en la VM en una nueva identidad cloud (abuso de identidades administradas).

MITRE ATT&CK lo registra como T1651 Cloud Administration Command. La Azure Threat Research Matrix de Microsoft lo incluye como AZT301.1.

Qué muestra el Activity Log

Cada Run Command suele producir un evento Started, uno Accepted y uno Succeeded que comparten correlationId. Obtienes el autor, las claims, la IP del autor y la VM objetivo. Lo que normalmente no obtienes es el script. El artículo de Mandiant Azure Run Command for Dummies deja claro que el Activity Log muestra la acción pero no el contenido del script; recuperarlo exige la VM.

Dónde está el script en la VM

Según la investigación de Mandiant y las notas de solución de problemas de Microsoft:

En Windows, RunPowerShellScript deja también telemetría de PowerShell (script block logging, evento 4104) si estaba activada. Recoge estos archivos antes de reconstruir la VM: snapshot del disco del SO y después imagen o montaje de solo lectura.

La variante Custom Script Extension

La Custom Script Extension descarga archivos desde fileUris y ejecuta commandToExecute. Se instala con Microsoft.Compute/virtualMachines/extensions/write; el publicador y el tipo son Microsoft.Compute / CustomScriptExtension en Windows y Microsoft.Azure.Extensions / CustomScript en Linux (Windows, Linux).

Notas forenses:

• El comando puede ir en settings (en claro en el cuerpo de la solicitud) o en protectedSettings (cifrado para la VM). Los atacantes que lo saben usan la configuración protegida.
• En Windows se ejecuta como LocalSystem; las descargas van a C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.*\Downloads\<n> y los logs a C:\WindowsAzure\Logs\Plugins\Microsoft.Compute.CustomScriptExtension.
• En Linux, las descargas, stdout y stderr van a /var/lib/waagent/custom-script/download/<n>/, y el log del handler es /var/log/azure/custom-script/handler.log.
• az vm extension list muestra la configuración pública actual, incluido commandToExecute si no estaba protegido. Solo el estado actual, no el historial.

Qué marca el analizador

AZ-VM-001 es ruidoso en entornos que usan Run Command para administrar. No pasa nada: la idea es poner cada ejecución delante de una persona, con su autor y su IP, y la cronología del analizador Azure Forensics muestra lo que ocurrió justo después.

Lista de triaje

1. ¿Quién lo ejecutó? ¿Un administrador humano desde el rango de IP de la empresa en horario laboral, o una entidad de servicio que normalmente despliega aplicaciones web?
2. ¿Es nueva la IP del autor? AZ-ID-001 marca las entidades de servicio usadas desde IP nunca vistas.
3. ¿Qué hizo la VM a continuación? En los flow logs de VNet o NSG, busca conexiones salientes desde la IP privada de la VM hacia una IP pública en los minutos siguientes. En el ejemplo ficticio, la VM conecta con la IP del atacante por el puerto 80 unos 25 segundos después de que empiece el Run Command.
4. ¿Apareció la identidad administrada de la VM en otro sitio? Un token de identidad administrada usado desde una IP distinta de la de la VM es la firma del robo de tokens vía IMDS (AZ-ID-002).
5. Consigue el script a partir del snapshot del disco, en las rutas anteriores.
6. Comprueba la exportación de discos. beginGetAccess sobre un disco o snapshot devuelve una URL de descarga del disco completo (MITRE T1537).

Remediación

• Aísla la VM (NSG que lo deniegue todo), haz snapshots de sus discos para el análisis y reconstrúyela desde una imagen fiable.
• Elimina extensiones desconocidas y run commands administrados; quita la extensión RunCommand si no la usas.
• Rota las credenciales que estuvieran en la VM o al alcance de su identidad administrada.
• Limita runCommand/action con roles personalizados; Virtual Machine Contributor lo concede.

Artículos relacionados

• Abuso de identidades administradas en Azure
• Análisis de flow logs de NSG y VNet para exfiltración
• Abuso de asignaciones de roles en Azure y elevateAccess