Az - Exchange Hybrid Impersonation (ACS Actor Tokens)

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstütze HackTricks

Grundlegende Informationen

In alten Exchange Hybrid-Designs konnte die on‑prem Exchange‑Installation sich als dieselbe Entra‑Anwendungsidentität authentifizieren, die von Exchange Online verwendet wurde. Wenn ein Angreifer den Exchange‑Server kompromittierte, den privaten Schlüssel des Hybrid‑Zertifikats extrahierte und einen OAuth client-credentials flow ausführte, konnte er first-party tokens mit Exchange Online‑Berechtigungskontext erhalten.

Das praktische Risiko beschränkte sich nicht auf den Zugriff auf Postfächer. Da Exchange Online umfangreiche Back‑End‑Vertrauensbeziehungen hatte, konnte sich diese Identität mit zusätzlichen Microsoft 365‑Diensten interagieren und in älterem Verhalten für tiefere Tenant‑Kompromittierungen genutzt werden.

Angriffswege und technischer Ablauf

Federation-Konfiguration über Exchange ändern

Exchange‑Tokens hatten historisch Berechtigungen, Domain-/Federation‑Einstellungen zu schreiben. Aus Angreifersicht erlaubte das die direkte Manipulation von Trust‑Daten federierter Domains, einschließlich token-signing certificate lists und Konfigurationsflags, die die Akzeptanz von MFA‑Claims aus der on‑prem Federation‑Infrastruktur steuerten.

Das bedeutet, dass ein kompromittierter Exchange Hybrid‑Server verwendet werden konnte, um ADFS‑artige Impersonation vorzubereiten oder zu verstärken, indem die Federation‑Konfiguration von der Cloud‑Seite geändert wurde, selbst wenn der Angreifer nur mit einer on‑prem Exchange‑Kompromittierung begonnen hatte.

ACS Actor Tokens und Service‑zu‑Service‑Impersonation

Der Hybrid‑Auth‑Pfad von Exchange nutzte Access Control Service (ACS) actor tokens mit trustedfordelegation=true. Diese actor tokens wurden dann in ein zweites, nicht signiertes Service‑Token eingebettet, das die Zielbenutzeridentität in einem vom Angreifer kontrollierten Abschnitt trug. Da das äußere Token nicht signiert war und das actor token weitreichend delegierte, konnte der Aufrufer Zielbenutzer tauschen, ohne sich neu zu authentifizieren.

Praktisch hatte der Angreifer, sobald er das actor token erlangt hatte, eine langlebige Impersonation‑Primitive (typischerweise etwa 24 Stunden), die schwer mittendrin zu widerrufen war. Das ermöglichte Benutzer‑Impersonation über Exchange Online sowie SharePoint/OneDrive‑APIs und damit auch die Exfiltration hoch wertvoller Daten.

Historisch funktionierte dasselbe Muster auch gegen graph.windows.net, indem ein Impersonation‑Token mit dem Opfer‑netId gebaut wurde. Das erlaubte direkte Entra‑Administrative Aktionen als beliebige Benutzer und ermöglichte vollständige Tenant‑Übernahme‑Workflows (z. B. Erstellung eines neuen Global Administrator‑Kontos).

Was nicht mehr funktioniert

Der graph.windows.net‑Impersonationsweg über Exchange Hybrid actor tokens wurde behoben. Die alte Kette “Exchange to arbitrary Entra admin over Graph” sollte für diese spezifische Token‑Route als entfernt betrachtet werden.

Das ist die wichtigste Korrektur bei der Dokumentation des Angriffs: Trenne das Exchange/SharePoint‑Impersonationsrisiko von der inzwischen gepatchten Graph‑Impersonation‑Eskalation.

Was in der Praxis weiterhin relevant sein kann

Wenn eine Organisation noch eine alte oder unvollständige Hybrid‑Konfiguration mit geteilter Trust‑Beziehung und exponiertem Zertifikatmaterial betreibt, kann die Auswirkung der Exchange/SharePoint‑Impersonation weiterhin schwerwiegend sein. Der Missbrauch der Federation‑Konfiguration kann je nach Tenant‑Setup und Migrationszustand ebenfalls relevant bleiben.

Microsofts langfristige Maßnahme besteht darin, die on‑prem und Exchange Online Identitäten zu trennen, sodass der gemeinsame Service‑Principal‑Trustpfad nicht mehr existiert. Umgebungen, die diese Migration abgeschlossen haben, reduzieren diese Angriffsfläche erheblich.

Hinweise zur Erkennung

Wenn diese Technik missbraucht wird, können Audit‑Events Identitäts‑Mismatch anzeigen, bei denen der user principal name einem impersonierten Benutzer entspricht, während der Anzeige-/Source‑Kontext auf Exchange Online‑Aktivität hinweist. Dieses gemischte Identitätsmuster ist ein hochwertiges Hunting‑Signal; Verteidiger sollten jedoch legitime Exchange‑Admin‑Workflows baselinen, um False Positives zu reduzieren.

Referenzen

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstütze HackTricks