Missbrauch von Azure-Rollenzuweisungen und elevateAccess

Kurz gesagt. Rechteausweitung in Azure ist vor allem eine Operation: Microsoft.Authorization/roleAssignments/write. Verdächtig wird sie durch die Rolle (Owner, User Access Administrator, Role Based Access Control Administrator oder Contributor für eine nicht-menschliche Identität), den Aufrufer (ein Dienstprinzipal oder ein Prinzipal, der sich selbst eine Rolle zuweist) und den Bereich (Abonnement oder Stamm). Die nukleare Variante ist Microsoft.Authorization/elevateAccess/action: Ein Globaler Administrator verschafft sich User Access Administrator im Stammbereich /, über alle Abonnements hinweg. Dieses Ereignis wird im mandantenweiten Log geschrieben – ein Abonnement-Export zeigt es nicht.

Rollenzuweisungen sind das Rückgrat der Autorisierung in Azure und damit das Erste, was ein Eindringling mit gewissen Rechten auszuweiten versucht. Sie sind aber auch Routineverwaltung, weshalb eine bloße Liste von roleAssignments/write-Ereignissen nutzlos ist. In diesem Artikel geht es darum, beides zu unterscheiden.

Wie Rechteausweitung über Azure RBAC funktioniert

Eine Rollenzuweisung verbindet drei Dinge: einen Prinzipal, eine Rollendefinition und einen Bereich. Wer Microsoft.Authorization/roleAssignments/write in einem Bereich besitzt, kann dort Zuweisungen erstellen. Unter den integrierten Rollen sind das Owner, User Access Administrator und Role Based Access Control Administrator.

Typische Eskalationspfade, die ich sehe:

Ausgangspunkt	Ausweitung	Warum es funktioniert
Abgeflossenes Geheimnis eines CI/CD-Dienstprinzipals, dem man User Access Administrator gab, „um Rollenzuweisungen bereitzustellen“	Weist sich Contributor oder Owner auf dem Abonnement zu	Überprivilegierte Automatisierung
Kompromittierter Globaler Administrator in Entra ID	`elevateAccess` → User Access Administrator auf `/` → Owner auf jedem Abonnement	Entra und Azure RBAC sind getrennt, Globale Administratoren können die Brücke schlagen
Contributor auf einem Key Vault mit Zugriffsrichtlinien	Trägt sich selbst in die Zugriffsrichtlinie ein	Kein RBAC, aber dieselbe Idee – siehe den Key Vault-Artikel
Owner eines Automation-Kontos oder einer VM mit privilegierter verwalteter Identität	Führt Code als diese Identität aus	Behandelt in Missbrauch verwalteter Identitäten

MITRE ATT&CK führt die Vergabe als T1098.003 Additional Cloud Roles und die Nutzung legitimer Cloud-Identitäten als T1078.004 Cloud Accounts.

Was elevateAccess ist und wo es protokolliert wird

Die Zugriffserhöhung ist eine dokumentierte, legitime Funktion: Ein Globaler Administrator in Microsoft Entra ID kann „Access management for Azure resources“ aktivieren und erhält die Rolle User Access Administrator im Stammbereich /. Von dort kann er sich jede Rolle in jedem Abonnement und jeder Verwaltungsgruppe des Mandanten zuweisen. Microsoft empfiehlt, diesen Zugriff nach Erledigung der Aufgabe wieder zu entfernen (Zugriff zum Verwalten aller Azure-Abonnements erhöhen).

Die forensische Falle liegt darin, wo protokolliert wird. Laut derselben Seite erscheinen Einträge zur Zugriffserhöhung in den Verzeichnis-Überwachungsprotokollen von Microsoft Entra (Dienst „Azure RBAC (Elevated Access)“, zum Zeitpunkt des Schreibens in der Vorschau) und in der Ansicht Directory Activity des Activity Log – also im mandantenweiten Log. Die Operation ist Microsoft.Authorization/elevateAccess/action mit dem Bereich /providers/Microsoft.Authorization. Ein az monitor activity-log list pro Abonnement liefert sie nicht. Exportieren Sie die Mandantenebene mit az rest, wie im Exportleitfaden gezeigt.

Das ist kein exotischer Pfad. Microsofts Analyse zu Storm-0501 beschreibt, wie der Akteur mit elevateAccess/action User Access Administrator erlangte und dann mit roleAssignments/write Owner über die Abonnements hinweg übernahm.

Ein roleAssignments/write-Ereignis lesen

Im REST-/CLI-Schema sind die benötigten Details zwischen Ereignis und Anforderungstext verteilt:

Feld	Wo	Warum es wichtig ist
`caller` und `claims`	Ereignis	Wer die Zuweisung erstellt hat. Ein GUID-Aufrufer mit `appid`-Claim ist ein Dienstprinzipal; eine `xms_mirid`-Claim bedeutet verwaltete Identität
`httpRequest.clientIpAddress`	Ereignis	Woher der Aufruf kam
`properties.requestbody` → `PrincipalId`, `RoleDefinitionId`, `Scope`	Anforderungstext	Wer welche Rolle wo erhalten hat
`authorization.evidence.role`	Schema der Ressourcenlogs	Welche Rolle es dem Aufrufer erlaubt hat
`status.value`	Ereignis	Started / Succeeded / Failed – auch Fehlschläge sind interessant

RoleDefinitionId ist eine GUID. Die IDs der integrierten Rollen sind fest und in Integrierte Azure-Rollen dokumentiert; Owner ist zum Beispiel 8e3af657-a8ff-443c-a75c-2fe8c4bcb635, Contributor b24988ac-6180-42a0-ab88-20f7382dd24c und User Access Administrator 18d7d88d-d35e-4fb5-a5c3-7773c20a72d9.

Zwei günstige, aber starke Signale:

Der Aufrufer weist sich selbst eine Rolle zu. Vergleichen Sie die Objekt-ID des Aufrufers mit PrincipalId im Anforderungstext. Legitime Bootstrap-Skripte tun das gelegentlich, Angreifer ständig.
Der Empfänger ist nicht menschlich und die Rolle ist weitreichend. Ein Dienstprinzipal oder eine verwaltete Identität, die Owner oder Contributor auf einem ganzen Abonnement erhält, verdient einen Verantwortlichen und eine Ticketnummer.

Was der Analyzer meldet

Der Azure Forensics Analyzer implementiert vier RBAC-Regeln, alle auf dem Activity Log:

Regel	Erkennt	Stufe
`AZ-RBAC-001`	Owner, User Access Administrator oder Role Based Access Control Administrator zugewiesen	Mittel
`AZ-RBAC-002`	Dienstprinzipal oder verwaltete Identität erhält Owner, Contributor oder eine Zugriffsverwaltungsrolle	Hoch
`AZ-RBAC-003`	Prinzipal weist sich selbst eine Rolle zu (Objekt-ID des Aufrufers = Empfänger)	Hoch
`AZ-RBAC-004`	`elevateAccess/action` – Globaler Administrator erhöht auf den Stammbereich	Hoch

Kombinieren Sie sie mit AZ-ID-001 (Dienstprinzipal von neuer IP verwendet), und die Kette liest sich meist von selbst: neue IP → Selbstzuweisung → was danach kam.

Checkliste zur Triage

Für jede gemeldete Zuweisung:

Gibt es ein Change-Ticket? Fragen Sie das Plattformteam, bevor Sie etwas annehmen; viele „verdächtige“ Zuweisungen sind Freitagabend-Korrekturen.
Wer ist der Aufrufer, und ist das sein übliches Verhalten? Pivotieren Sie im Reiter Entitäten auf den Aufrufer. Ein Deployment-Prinzipal, der noch nie Rollen vergeben hat, ist ein starkes Signal.
Von welcher IP? Vergleichen Sie mit den Referenz-IPs des Aufrufers. CI-Runner wechseln die IP; Angreifer wechseln IP und Uhrzeit.
Was geschah danach mit den neuen Rechten? Sehen Sie sich die nächste Stunde an Ereignissen des Empfängers an. Eine Rolle, die niemand nutzt, ist ein Fehler; eine Rolle, die binnen Minuten für Befehle oder Secret-Zugriffe genutzt wird, ist ein Angriff.
Wurde sie wieder entfernt? Angreifer räumen manchmal mit roleAssignments/delete auf. Auch das Löschen wird protokolliert.
Bei elevateAccess: Welcher Globale Administrator, von welcher Anmeldung? Das ist eine Entra ID-Frage für m365forensics.com.

Behebung

Entfernen Sie während des Vorfalls erstellte Zuweisungen (az role assignment delete) und prüfen Sie, wer in jedem Bereich Owner und User Access Administrator hat.
Entfernen Sie die durch die Zugriffserhöhung entstandene User Access Administrator-Zuweisung auf /; Microsoft dokumentiert sowohl den Schalter im Portal als auch das Entfernen per CLI / REST.
Rotieren Sie die Anmeldeinformationen jedes Dienstprinzipals, der eine verdächtige Zuweisung erstellt oder erhalten hat.
Reduzieren Sie dauerhafte Rechte: kein User Access Administrator für CI/CD-Identitäten; für Menschen Privileged Identity Management erwägen.