Azure Run Command-Angriffe: Ausführung auf VMs untersuchen

Kurz gesagt. Mit Run Command kann jeder, der Microsoft.Compute/virtualMachines/runCommand/action besitzt, über den VM-Agenten ein Skript auf einer VM ausführen – unter Windows als SYSTEM, unter Linux als Benutzer mit erhöhten Rechten – ganz ohne Netzwerkpfad zur VM. Das Activity Log erfasst wer, wann, von wo und auf welcher VM, in der Regel aber nicht das Skript. Das Skript liegt auf der VM: C:\Packages\Plugins\Microsoft.CPlat.Core.RunCommandWindows\<version>\Downloads\ unter Windows, /var/lib/waagent/run-command/download/ unter Linux. Die Custom Script Extension (extensions/write) folgt derselben Idee mit einem Download-Schritt. Korrelieren Sie mit ausgehenden Verbindungen der VM in den Minuten danach.

Run Command ist die Azure-Funktion, die ich als Administrator am meisten vermissen und als Verteidiger am meisten fürchten würde. Sie verwandelt eine Berechtigung der Steuerungsebene in Codeausführung im Gastsystem – und genau deshalb setzen Eindringlinge, die Contributor auf einem Abonnement erlangen, sie binnen Minuten ein.

Warum Angreifer Run Command mögen

Microsoft beschreibt Run Command als Möglichkeit, Skripte über den VM-Agenten innerhalb einer VM auszuführen – nützlich, wenn RDP oder SSH geschlossen sind (Windows, Linux). Aus Sicht eines Angreifers:

Die typische Abfolge: RunShellScript oder RunPowerShellScript mit einem Einzeiler, der eine zweite Stufe nachlädt, Anmeldeinformationen abgreift oder beim Instance Metadata Service das Token der verwalteten Identität der VM abruft. Letzteres macht aus der Ausführung auf der VM eine neue Cloud-Identität (Missbrauch verwalteter Identitäten).

MITRE ATT&CK führt dies als T1651 Cloud Administration Command. Microsofts Azure Threat Research Matrix listet es als AZT301.1.

Was das Activity Log zeigt

Jeder Run Command erzeugt typischerweise ein Started-, ein Accepted- und ein Succeeded-Ereignis mit derselben correlationId. Sie erhalten Aufrufer, Claims, IP des Aufrufers und Ziel-VM. Was Sie in der Regel nicht erhalten, ist das Skript. Mandiants Azure Run Command for Dummies stellt klar, dass das Activity Log die Aktion zeigt, nicht aber den Skriptinhalt; dafür braucht man die VM.

Wo das Skript auf der VM liegt

Nach Mandiants Recherche und Microsofts Hinweisen zur Problembehandlung:

Unter Windows hinterlässt RunPowerShellScript außerdem PowerShell-Telemetrie (Script Block Logging, Ereignis 4104), sofern aktiviert. Sichern Sie diese Dateien, bevor Sie die VM neu aufbauen: Snapshot des Betriebssystemdatenträgers, dann Image erstellen oder schreibgeschützt einbinden.

Die Variante Custom Script Extension

Die Custom Script Extension lädt Dateien aus fileUris herunter und führt commandToExecute aus. Sie wird mit Microsoft.Compute/virtualMachines/extensions/write installiert; Herausgeber und Typ sind Microsoft.Compute / CustomScriptExtension unter Windows und Microsoft.Azure.Extensions / CustomScript unter Linux (Windows, Linux).

Forensische Hinweise:

• Der Befehl kann in settings (im Klartext im Anforderungstext) oder in protectedSettings (für die VM verschlüsselt) stehen. Angreifer, die das wissen, verwenden geschützte Einstellungen.
• Unter Windows läuft sie als LocalSystem; Downloads landen in C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.*\Downloads\<n>, Logs in C:\WindowsAzure\Logs\Plugins\Microsoft.Compute.CustomScriptExtension.
• Unter Linux landen Downloads sowie stdout und stderr in /var/lib/waagent/custom-script/download/<n>/, das Handler-Log ist /var/log/azure/custom-script/handler.log.
• az vm extension list zeigt die aktuellen öffentlichen Einstellungen, einschließlich commandToExecute, sofern nicht geschützt. Nur den aktuellen Stand, keine Historie.

Was der Analyzer meldet

AZ-VM-001 ist in Umgebungen, die Run Command zur Administration nutzen, laut. Das ist in Ordnung: Ziel ist, jede Ausführung mit Aufrufer und IP einem Menschen vorzulegen, und die Zeitleiste des Azure Forensics Analyzer zeigt, was unmittelbar danach geschah.

Checkliste zur Triage

1. Wer hat ihn ausgeführt? Ein menschlicher Administrator aus dem Firmen-IP-Bereich während der Arbeitszeit oder ein Dienstprinzipal, der normalerweise Web-Apps bereitstellt?
2. Ist die IP des Aufrufers neu? AZ-ID-001 meldet Dienstprinzipale, die von nie gesehenen IPs verwendet werden.
3. Was tat die VM danach? Suchen Sie in VNet- oder NSG-Flow-Logs nach ausgehenden Verbindungen von der privaten IP der VM zu einer öffentlichen IP in den folgenden Minuten. Im fiktiven Beispiel verbindet sich die VM etwa 25 Sekunden nach dem Start des Run Command über Port 80 mit der Angreifer-IP.
4. Tauchte die verwaltete Identität der VM anderswo auf? Ein Token einer verwalteten Identität, das von einer anderen IP als der der VM verwendet wird, ist die Signatur von Token-Diebstahl über IMDS (AZ-ID-002).
5. Beschaffen Sie das Skript aus dem Datenträger-Snapshot unter den obigen Pfaden.
6. Prüfen Sie Datenträgerexporte. beginGetAccess auf einem Datenträger oder Snapshot liefert eine Download-URL für den gesamten Datenträger (MITRE T1537).

Behebung

• Isolieren Sie die VM (NSG, die alles verweigert), erstellen Sie Snapshots ihrer Datenträger für die Forensik und bauen Sie sie aus einem vertrauenswürdigen Image neu auf.
• Entfernen Sie unbekannte Erweiterungen und verwaltete Run Commands; entfernen Sie die RunCommand-Erweiterung, wenn Sie sie nicht nutzen.
• Rotieren Sie Anmeldeinformationen, die auf der VM lagen oder für ihre verwaltete Identität erreichbar waren.
• Beschränken Sie runCommand/action mit benutzerdefinierten Rollen; Virtual Machine Contributor gewährt es.

Verwandte Artikel

• Missbrauch verwalteter Identitäten in Azure
• NSG- und VNet-Flow-Logs analysieren: Exfiltration erkennen
• Missbrauch von Azure-Rollenzuweisungen und elevateAccess