Missbrauch verwalteter Identitäten in Azure
Wie Angreifer Azure-Dienstprinzipale und verwaltete Identitäten missbrauchen: abgeflossene Geheimnisse, IMDS-Tokendiebstahl, Verbundanmeldeinformationen.
Kurz gesagt. Nicht-menschliche Identitäten sind die stille Mehrheit der Azure-Aufrufer – und die bevorzugte Tarnung von Eindringlingen. Drei Muster: ein Dienstprinzipal, dessen Geheimnis abgeflossen ist (CI/CD-Variablen, ein Repository, ein Laptop), wird von einer neuen IP verwendet; ein Token einer verwalteten Identität wird vom Instance Metadata Service der VM (169.254.169.254) abgegriffen und woanders wiederverwendet; und Persistenz über Verbundanmeldeinformationen, Automation-Runbooks, Logic Apps oder Functions, die als privilegierte Identität laufen. In den Logs kennzeichnet die Claim xms_mirid eine verwaltete Identität, und „dieselbe Identität, neue IP“ ist das stärkste Einzelsignal, das Sie haben.
Wenn ich ein kompromittiertes Abonnement prüfe, sind die menschlichen Konten meist einfach: wenige, mit vorhersehbaren Arbeitszeiten und MFA in den Claims. Schwierig sind die Dutzenden Anwendungsidentitäten, die den ganzen Tag Azure Resource Manager aufrufen. Dort tauchen Angreifer unter.
Dienstprinzipale und verwaltete Identitäten aus Sicht der Logs
| Identität | Was sie ist | Wie sie in den Claims des Activity Log erscheint |
|---|---|---|
| Dienstprinzipal (App-Registrierung) | Anwendungsidentität, authentifiziert mit geheimem Clientschlüssel, Zertifikat oder Verbundanmeldeinformation | appid + Objekt-ID, oft idtyp: app; caller ist eine GUID |
| Verwaltete Identität | Von Azure verwalteter Dienstprinzipal, an eine Ressource gebunden (systemseitig zugewiesen) oder eigenständig (benutzerseitig zugewiesen) | Dasselbe, plus xms_mirid = Ressourcen-ID der VM / App / Identität, zu der sie gehört |
| Benutzer | Menschliches Konto | UPN, Name, amr (z. B. pwd, mfa) |
Der Azure Forensics Analyzer klassifiziert Aufrufer auf diese Weise (zuerst Claims, dann principalType, dann GUID-förmige Aufrufer) und zeigt den Typ im Reiter Entitäten. In Key Vault- und Storage-Logs erscheinen dieselben Claims unter identity.claim und identity.requester.
Muster 1: ein abgeflossenes Dienstprinzipal-Geheimnis
Der Erstzugriff geschieht außerhalb von Azure: ein Geheimnis, das in ein Repository committet, in einem CI-Log ausgegeben oder vom Rechner eines Entwicklers gestohlen wurde. Microsoft Entra ID sieht die Anmeldung (Anmeldeprotokolle für Dienstprinzipale); Azure sieht, was folgt.
Signale in Azure-Logs:
- Der Dienstprinzipal ruft ARM von einer IP auf, die er nie genutzt hat. CI-Runner haben wenige stabile IPs oder einen bekannten Cloud-Bereich; der VPS eines Angreifers ist beides nicht.
- Der Dienstprinzipal tut etwas, das er nie getan hat: Rollenzuweisungen, Run Command,
listKeys, Änderungen an Zugriffsrichtlinien. - Der Zeitpunkt: Deployment-Prinzipale arbeiten, wenn Pipelines laufen. Eine Salve um 02:14 an einem Sonntag ohne Pipeline-Lauf spricht Bände.
MITRE ATT&CK: T1078.004 Cloud Accounts. Wie das Geheimnis abgeflossen ist und ob der Anwendung neue Geheimnisse hinzugefügt wurden (T1098.001 Additional Cloud Credentials), steht im Entra ID-Überwachungsprotokoll – ausgewertet vom Schwesterwerkzeug m365forensics.com.
Muster 2: Diebstahl von Tokens verwalteter Identitäten über IMDS
Jeder Prozess auf einer VM kann beim Instance Metadata Service ein Token der verwalteten Identität der VM anfordern:
GET http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/
Metadata: true
Microsoft benennt die Sicherheitsgrenze klar: Jeglicher Code und alle Skripte, die auf einem virtuellen Computer laufen, können Tokens für alle dort verfügbaren verwalteten Identitäten anfordern und abrufen (Verwaltete Identitäten auf einer VM zum Abrufen eines Zugriffstokens verwenden). Der Header Metadata ist eine SSRF-Abwehr, keine Autorisierungsprüfung.
So wird Codeausführung auf einer VM – über Run Command, eine Web Shell oder eine SSRF, die Header setzen kann – zu einer Cloud-Identität. Der Angreifer kopiert das Bearer-Token und nutzt es von seinem eigenen Rechner, bis es abläuft (T1528 Steal Application Access Token).
Das Signal ist einfach und stark: eine verwaltete Identität, die von einer IP verwendet wird, die nicht ihr Host ist. Die verwaltete Identität einer VM erreicht Key Vault und Storage normalerweise von der privaten IP der VM (über einen Dienst- oder privaten Endpunkt) oder von einer stabilen ausgehenden öffentlichen IP. Dieselbe Objekt-ID mit einer Privatanschluss- oder VPS-Adresse und einem curl-User-Agent ist Token-Wiederverwendung.
Muster 3: Persistenz über Identitäten
Mit einer privilegierten Identität in der Hand will ein Angreifer eine, die Passwortwechsel und Geheimnisrotation überlebt:
| Persistenz | Operation im Activity Log | MITRE |
|---|---|---|
| Verbundanmeldeinformation auf einer benutzerseitig zugewiesenen verwalteten Identität (erlaubt einem externen IdP, Tokens für sie zu erhalten) | Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/write | T1098.001 |
| Automation-Runbook oder -Webhook, der als Identität des Automation-Kontos läuft | Microsoft.Automation/automationAccounts/runbooks/write, …/webhooks/write, …/jobs/write | T1648 |
| Code einer Logic App oder Function geändert | Microsoft.Logic/workflows/write, Microsoft.Web/sites/functions/write, Funktionsschlüssel geschrieben | T1648 |
| Neues Geheimnis oder Zertifikat an einer App-Registrierung | Entra ID-Überwachungsprotokoll, nicht das Activity Log | T1098.001 |
Verbundanmeldeinformationen sind legitim und verbreitet (GitHub Actions, AKS-Workload-Identität). Die Frage ist immer: welcher Aussteller und welches Subjekt, von wem angelegt, und ist jemand dafür verantwortlich?
Was der Analyzer meldet
| Regel | Erkennt | Stufe |
|---|---|---|
AZ-ID-001 | Dienstprinzipal ruft ARM von einer IP auf, die im 72-stündigen Lernzeitraum nicht vorkam | Mittel |
AZ-ID-002 | Verwaltete Identität von einer neuen IP verwendet – Activity Log, Key Vault oder Storage | Hoch |
AZ-RBAC-002 | Dienstprinzipal oder verwaltete Identität erhält Owner, Contributor oder eine Zugriffsverwaltungsrolle | Hoch |
AZ-PER-001 | Automation-Runbook, -Webhook oder -Auftrag erstellt | Mittel |
AZ-PER-002 | Code einer Logic App oder Function geändert | Niedrig |
AZ-PER-003 | Verbundanmeldeinformation zu einer verwalteten Identität hinzugefügt | Hoch |
„Neue IP“-Regeln brauchen Verlauf: Mit weniger als 72 Stunden Logs vor der verdächtigen Aktivität können sie nicht laufen, und der Abdeckungsblock sagt das. Bekannte False Positives: CI-Runner mit wechselnden IPs, VMs, die mit neuer privater IP neu bereitgestellt wurden.
Checkliste zur Triage
- Listen Sie jede nicht-menschliche Identität mit einem Befund im Reiter Entitäten auf und öffnen Sie ihre Ereignisse.
- Legen Sie für jede die Referenz fest: übliche IPs, übliche Operationen, übliche Zeiten. Die erste Abweichung ist der Beginn Ihrer Zeitleiste.
- Bei einer verwalteten Identität: An welche Ressource ist sie gebunden (
xms_mirid)? Gab es kurz davor Codeausführung auf dieser Ressource (Run Command, Erweiterung, Bereitstellung)? - Bei einem Dienstprinzipal: Wann wurde die letzte Anmeldeinformation hinzugefügt und von wem? (Entra-Überwachungsprotokoll.)
- Was hat sie berührt? Key Vault-Lesezugriffe, Storage-Lesezugriffe, Rollenzuweisungen. Jeder davon ist ein neuer Zweig der Untersuchung.
Behebung
- Rotieren Sie Geheimnisse und Zertifikate kompromittierter Dienstprinzipale; entfernen Sie Anmeldeinformationen, für die niemand verantwortlich ist.
- Eine verwaltete Identität hat kein Geheimnis zum Rotieren. Dämmen Sie den Host ein (VM isolieren und neu aufbauen) und reduzieren Sie die Rollenzuweisungen der Identität. Bereits gestohlene Zugriffstoken bleiben bis zu ihrem Ablauf gültig; beobachten Sie die Aktivität der Identität von fremden IPs also noch eine Weile – und rotieren Sie die Secrets, die sie lesen konnte.
- Entfernen Sie unbekannte Verbundanmeldeinformationen, Runbooks und Webhooks.
- Reduzieren Sie Rechte: kein abonnementweites Contributor für die Identität einer Web-App.