CVE-2025-55241 Entra ID Actor Token Impersonation: Konnte Jeden Global Admin Kompromittieren

Was war CVE-2025-55241: der Entra-ID-Actor-Token-Impersonation-Fehler

CVE-2025-55241 ist eine Elevation-of-Privilege-Schwachstelle in Microsoft Entra ID, die auf Entra-ID-Actor-Token-Impersonation beruht, entdeckt vom unabhängigen Sicherheitsforscher Dirk-jan Mollema und am 14. Juli 2025 an das Microsoft Security Response Center (MSRC) gemeldet. Microsofts eigene Common-Vulnerabilities-and-Exposures(CVE)-Bewertung stufte sie mit CVSS 10.0 (Kritisch) ein; die unabhängige Neuberechnung der NVD ergab 9.8 (Kritisch), mit einer Klassifizierung als CWE-287 (Improper Authentication). Microsoft vergab die CVE am 4. September 2025 und erklärte, dass keine Kundenmaßnahme erforderlich sei, da der Fix bereits mandantenweit ausgerollt worden war.

Der Fehler kombinierte zwei Dinge: einen undokumentierten, Microsoft-internen Token-Typ namens „Actor Token" und eine Lücke bei der Mandantenvalidierung in der veralteten Azure-AD-Graph-API (graph.windows.net). Zusammen erlaubten sie es dem Inhaber eines Actor Tokens aus dem eigenen (angreiferkontrollierten) Mandanten, sich als beliebiger Benutzer — einschließlich Global Administrators — in jedem anderen Entra-ID-Mandanten zu authentifizieren, ohne dessen Zugangsdaten zu benötigen, ohne MFA auszulösen und ohne die Audit-Spur zu erzeugen, auf die sich Verteidiger normalerweise verlassen. Mollema beschrieb die Exposition als fähig, „jeden Entra-ID-Mandanten weltweit" zu kompromittieren — mit Ausnahme nationaler/souveräner Clouds.

🚨 Gefahr: Weder Microsoft noch Mollema haben Hinweise auf eine Ausnutzung in freier Wildbahn gefunden. Dies ist eine retrospektive Erklärung einer Schwachstelle, die Microsoft bereits global behoben hat — keine aktive Bedrohung, die heute Notfallmaßnahmen erfordert.

Offenlegungszeitleiste

• 14. Juli 2025 — Mollema meldet das Problem an MSRC; MSRC eröffnet noch am selben Tag einen Fall.
• 17. Juli 2025 — Microsoft rollt einen Produktions-Fix für die Mandantenvalidierungslücke in der Azure-AD-Graph-API aus.
• 23. Juli 2025 — MSRC bestätigt Mollema, dass das Kernproblem behoben ist.
• 6. August 2025 — Microsoft liefert weitere Abhilfemaßnahmen, die die Ausstellung von Actor Tokens für die Azure-AD-Graph-API auf Microsoft-interne Dienste beschränken.
• 4. September 2025 — Microsoft vergibt formal CVE-2025-55241 und erklärt, dass keine Kundenmaßnahme erforderlich ist.
• 17. September 2025 — Mollema veröffentlicht den vollständigen technischen Bericht inklusive Erkennungshinweisen.

Wie die Actor-Token-Umgehung funktionierte

Actor Tokens werden von Microsofts Access Control Service (ACS) für die Service-zu-Service-Delegation ausgestellt — dem Mechanismus, der es First-Party-Backends wie Exchange Online erlaubt, beim Aufruf anderer Microsoft-Dienste im Namen eines Benutzers „als" dieser Benutzer zu agieren. Laut Mollemas Analyse tragen Actor Tokens einen trustedfordelegation-Claim und erlauben, einmal ausgestellt, effektiv bis zu 24 Stunden lang die Impersonation jedes Benutzers in einem Mandanten. Dies ist ein legitimer, seit Langem bestehender interner Mechanismus — die Schwachstelle lag darin, wie ein veralteter Konsument dieser Tokens sie validierte, nicht in der Existenz des Mechanismus selbst.

Zwei Design-Lücken machten dies über Mandantengrenzen hinweg ausnutzbar:

Unvalidierte Mandantenherkunft

Die veraltete Azure-AD-Graph-API prüfte nicht ordnungsgemäß, ob die in den Impersonation-Claims eines Actor Tokens eingebettete Mandanten-ID mit dem tatsächlich abgefragten Mandanten übereinstimmte. Da die Impersonation-Payload in einem unsignierten JWT transportiert wurde, konnte ein Angreifer eine Ziel-Mandanten-ID gegen seine eigene austauschen, ohne die Signatur des Tokens ungültig zu machen — es gab keine zu brechen. Das erlaubte es, ein für den eigenen Mandanten des Angreifers ausgestelltes Token so wiederzuverwenden, als stamme es von jedem beliebigen anderen Mandanten der Welt.

Vorhersagbare Benutzerkennungen (netId)

Das Impersonation-Ziel innerhalb des Zielmandanten wurde über netId aufgelöst, eine veraltete Microsoft-Passport-Kennung, die in manchen Entra-Interna noch vorhanden ist. Anders als eine Entra-Objekt-ID (eine zufällige GUID) erhöhen sich netId-Werte vorhersagbar. Mollema fand heraus, dass sie sich für einen Zielmandanten in „Minuten bis Stunden" per Brute-Force ermitteln ließen, und dass sie auch direkt aus den alternativeSecurityIds-Attributen von Gastbenutzern in B2B-Vertrauensstellungen oder aus in Logs, Support-Tickets und öffentlichen Screenshots durchgesickerten Tokens gewonnen werden konnten.

Zusammengefasst: Ein Angreifer, der ein Actor Token von jedem beliebigen von ihm kontrollierten Mandanten anfordern konnte — auch von einem kostenlosen oder Testmandanten —, konnte die Ziel-Mandanten-ID umschreiben, sie mit einer aufgelösten netId kombinieren, und die veraltete Azure-AD-Graph-API akzeptierte die resultierende Impersonation. Das verschaffte Lese- und Schreibzugriff auf Verzeichnisdaten, die Möglichkeit, Service Principals zu erstellen, Rollenzuweisungen zu ändern und Conditional-Access-Richtlinien zu ändern — als der Benutzer, für den sich das Token ausgab, bis hin zu einem Global Administrator.

Warum MFA, Conditional Access und Logging es nicht erkennen konnten

Das ist der Teil, der den Fehler kritisch statt nur schwerwiegend machte: Die Umgehung lag unterhalb der Kontrollen, auf die sich Mandanten normalerweise verlassen, um eine Kontokompromittierung zu erkennen.

• MFA und Conditional Access greifen nicht. Actor Tokens sind ein Service-zu-Service-Delegationsmechanismus, keine interaktive Anmeldung — sie durchlaufen die Conditional-Access-Policy-Engine überhaupt nicht, sodass Pro-Benutzer-MFA, Sign-in-Risiko und Geräte-Compliance-Anforderungen schlicht nicht ausgewertet werden. Eine Erinnerung daran, dass MFA allein nie eine vollständige Kontrolle war — es deckt nur die Authentifizierungspfade ab, in die es tatsächlich eingebunden ist.
• Das Anfordern des Tokens erzeugt kein Log. Laut Mollemas Bericht erzeugt das Beziehen eines Actor Tokens keinen für den Mandanten sichtbaren Log-Eintrag — ein Angreifer konnte den Angriff mit null Fußabdruck im Zielmandanten vorbereiten.
• Die veraltete Graph-API protokolliert zu wenig. graph.windows.net stammt aus der Zeit vor der Protokollierungstiefe, die Microsoft Graph und Entras moderne Audit-Pipeline bieten, sodass selbst mit dem Impersonation-Token durchgeführte Aktionen nur teilweise erfasst wurden.
• Das Token war innerhalb seines Gültigkeitsfensters faktisch nicht widerrufbar. Als unsigniertes, in sich geschlossenes JWT mit bis zu 24 Stunden Gültigkeit konnte ein durchgesickertes oder gefälschtes Actor Token nicht mitten im Flug ungültig gemacht werden, wie es bei einem kompromittierten Session-Token möglich ist.

Erkennung: Worauf zu achten ist

Da Microsofts Fix den zugrunde liegenden Zugriffspfad geschlossen hat, ist die Erkennung hier retrospektiv — eine Überprüfung der Entra-Audit-Historie auf Anzeichen, dass die Technik vor dem Patch gegen den eigenen Mandanten eingesetzt wurde —, statt eine Live-Überwachungskontrolle. Mollema veröffentlichte genau dafür eine KQL-Abfrage: Durch Actor Token getriebene Änderungen tauchen weiterhin in AuditLogs auf, aber mit einer verräterischen Diskrepanz zwischen dem Anzeigenamen des ausführenden Dienstes und dem tatsächlichen initiierenden Kontext.

AuditLogs
| where not(OperationName has "group")
| where not(OperationName == "Set directory feature on tenant")
| where InitiatedBy has "user"
| where InitiatedBy.user.displayName has_any (
    "Office 365 Exchange Online", "Skype for Business Online", "Dataverse",
    "Office 365 SharePoint Online", "Microsoft Dynamics ERP")

Was die Abfrage nicht erfasst

Diese aus Mollemas veröffentlichtem Bericht übernommene Abfrage markiert Verzeichnis-Änderungen, die per Actor-Token-Impersonation vorgenommen wurden. Sie erfasst keine reine Aufklärung — Benutzer- oder Gruppenaufzählung, das Abgreifen von Secrets, Richtlinienüberprüfung —, die die veraltete API nicht detailliert genug protokollierte, um sie im Nachhinein zu rekonstruieren. Ein sauberes Ergebnis dieser Abfrage ist ein Beleg dafür, dass über diesen Pfad keine Schreib-Aktivität gefunden wurde — nicht ein Beweis dafür, dass der Mandant nie gelesen wurde.

Behebung

Microsofts eigener Fix erforderte keine Kundenmaßnahme: MSRC bestätigte, dass das Mandantenvalidierungsproblem bis zum 23. Juli 2025 behoben war, und schränkte bis zum 6. August 2025 die Ausstellung von Actor Tokens für die Azure-AD-Graph-API weiter auf Microsoft-interne Dienste ein. Das schließt diese konkrete Kette. Die dauerhafte Abhilfe für Mandanten besteht darin, die Abhängigkeit von der veralteten Oberfläche und den Rechte-Mustern zu reduzieren, die dieser Fehler ausnutzte:

1. Abhängigkeiten von Azure AD Graph zurückbauen. Prüfen Sie Ihre App-Registrierungen und Service Principals auf verbleibende Aufrufe von Azure AD Graph und migrieren Sie diese zu Microsoft Graph; jede entfernte Abhängigkeit ist eine Angriffsfläche weniger, die dem nächsten Validierungsfehler einer veralteten API ausgesetzt ist.
2. Dauerhafte Global-Administrator-Zuweisungen eliminieren. Der schlimmste Fall dieses Fehlers war die vollständige Impersonation eines Global Admin. Die Verlagerung von Admin-Rollen auf Just-in-Time-Aktivierung über Privileged Identity Management (PIM) verringert die Zahl der Konten, die eine erfolgreiche Impersonation tatsächlich sinnvoll nutzen könnte.
3. Phishing-resistente MFA für jede privilegierte Rolle verlangen, nicht nur für die interaktive Anmeldung im Allgemeinen — das stoppt keine Service-zu-Service-Token-Umgehung wie Actor Tokens, schließt aber den weitaus häufigeren Pfad, über den Angreifer tatsächlich Admin-Konten erreichen.
4. Legacy-Authentifizierung mandantenweit blockieren über Conditional Access. Legacy-Auth unterstützt weder moderne Token-Validierung noch Conditional-Access-Durchsetzung, und Mandanten, die weiterhin Legacy-Auth erlauben oder Lücken im Conditional Access offenlassen, vergrößern dieselbe Klasse von Exposition, die diese Schwachstelle so schwerwiegend machte: Authentifizierungspfade, die die moderne Kontrollebene nicht sehen kann.
5. Aufbewahrung und Alarmierung der Entra-AuditLogs für das oben beschriebene anomale-Initiator-Muster überprüfen, damit jede zukünftige First-Party-Dienst-Impersonation-Umgehung einen Alarm statt Stille erzeugt. Ein umfassenderes Entra-ID-Sicherheitsaudit deckt dies zusammen mit dem Rest der Mandantenlage ab, einschließlich der Standardeinstellungen, mit denen neue Mandanten ausgeliefert werden.

Warum die veraltete API über diese CVE hinaus wichtig war

Microsoft zieht graph.windows.net seit der Deprecation-Ankündigung 2019 stufenweise zurück: Neue Anwendungen wurden ab dem 31. August 2024 bei der ersten Nutzung blockiert, und seit dem 1. Februar 2025 ist mandantenweit ein Extended-Access-Opt-in erforderlich, wobei Apps ohne Opt-in den Zugriff vollständig verlieren. Microsoft hat klargestellt, dass es über Sicherheitsfixes hinaus keine weiteren Investitionen in Azure AD Graph tätigt und dass jede neue Fähigkeit in Microsoft Graph einfließt. CVE-2025-55241 ist eine konkrete Veranschaulichung dafür, warum diese Migration über die Compliance-Checkbox hinaus wichtig ist: Eine veraltete, unzureichend protokollierte, unzureichend gepflegte API-Oberfläche ist genau der Ort, an dem eine Validierungslücke wie diese am längsten unbemerkt bleibt.

Wie EtcSec dies erkennt

EtcSecs Entra-ID-Audit hat keine Sicht auf Microsofts interne Actor-Token-Infrastruktur — diese Kontrollebene liegt vollständig innerhalb von Microsofts Infrastruktur und war nie etwas, das ein mandantenseitiges Audit direkt beobachten oder beheben konnte. Was EtcSec kontinuierlich prüft, ist die Menge mandantenseitiger Bedingungen, die bestimmen, wie viel Schaden jede Impersonation-Klasse-Umgehung (diese oder die nächste) anrichten kann: dauerhafte Global-Administrator-Zuweisungen (PA_TOO_MANY_GLOBAL_ADMINS, PA_PERMANENT_ADMIN_ASSIGNMENTS), Admin-Konten ohne starke MFA (PA_GLOBAL_ADMIN_NOT_MFA) und Mandanten, die weiterhin Legacy-Authentifizierungspfade außerhalb der Conditional-Access-Durchsetzung zulassen (CA_NO_LEGACY_AUTH_BLOCK).