Exchange-Privilegieneskalation WriteDacl Domain Active Directory: Wie eine zehn Jahre alte Installation noch immer Domain-Admin-Rechte verteilt

Was ist Exchange-Privilegieneskalation WriteDacl Domain Active Directory

Fehlkonfigurationen der Exchange-Privilegieneskalation WriteDacl Domain Active Directory zählen zu den folgenreichsten Standardeinstellungen, die in Umgebungen, die irgendwann im letzten Jahrzehnt On-Premises-Exchange-Server installiert haben, bis heute unangetastet bestehen. Wird Exchange Server 2013, 2016 oder 2019 mit Microsofts Standardmodell der geteilten Berechtigungen (shared permissions) eingerichtet, erhält die Sicherheitsgruppe Exchange Windows Permissions das Recht WriteDacl — also die Berechtigung, die Discretionary Access Control List (DACL) zu ändern — direkt auf dem Domänenobjekt an der Wurzel von Active Directory. Dieser eine Zugriffssteuerungseintrag (Access Control Entry, ACE), wenige Schritte weiter in einer kurzen Kette, genügt, um einem Angreifer Domain-Admin-äquivalenten Zugriff auf die gesamte Gesamtstruktur (Forest) zu verschaffen — nicht nur auf die Exchange-Organisation.

Die Gruppe Exchange Trusted Subsystem — die Dienstidentität, mit der jeder Exchange-Server über das rollenbasierte Zugriffssteuerungsmodell (RBAC) von Exchange im Namen der Endbenutzer in AD handelt — ist standardmäßig selbst in Exchange Windows Permissions verschachtelt (Microsoft Learn, „Split permissions in Exchange Server"). Wer ein Konto zu Exchange Trusted Subsystem hinzufügen kann oder einen Exchange-Server direkt kompromittiert, erbt damit das WriteDacl-Recht auf dem Domänenobjekt.

Warum das nicht „nur" CVE-2019-1166 ist

Dabei handelt es sich nicht um eine einzelne, patchbare CVE: Microsofts eigene Split-Permissions-Dokumentation beschreibt dies als architektonischen Standard des Shared-Permissions-Modells, nicht als Schwachstelle mit einem Fix-Release. Diese Unterscheidung ist wichtig, denn Katalogtexte zu diesem Finding werden mitunter fälschlich mit CVE-2019-1166 in Verbindung gebracht — einer echten CVE, die jedoch einen unabhängigen NTLM-Message-Integrity-Check-(MIC)-Bypass betrifft („Drop the MIC 2", entdeckt vom Preempt Research Team und von Microsoft im Oktober-2019-Patch-Tuesday behoben, laut Praetorians Advisory). Dieser Patch und sein Pendant CVE-2019-1040 vom Juni 2019 haben die NTLM-Relay-Abwehr allgemein gehärtet; keiner der beiden hat den WriteDacl-ACE angerührt, den Exchange auf dem Domänenobjekt hinterlässt. Organisationen, die beide Patches installiert, aber nie Split Permissions eingeführt haben, sind bis heute exponiert — und ein vollständig gepatchter Domain Controller sagt nichts darüber aus, ob dieser ACE noch vorhanden ist. Siehe dazu unsere ausführlichere Analyse zu ACL-Missbrauch und DCSync-Pfaden zu Domain Admin dafür, wie sich solche Zugriffsrechte mit anderen Active-Directory-Fehlkonfigurationen summieren.

Wie es funktioniert: Von Exchange Windows Permissions zu DCSync

Die Standard-Rechtekette

Die Kette von einer überprivilegierten (oder schlicht kompromittierten) Exchange-Identität bis zur vollständigen Domänenkompromittierung ist kurz:

1. Exchange Windows Permissions besitzt eine WriteDacl-ACE auf dem Domänenobjekt.
2. Exchange Trusted Subsystem ist standardmäßig Mitglied von Exchange Windows Permissions.
3. Mitglieder der RBAC-Rollengruppe Organization Management können die Mitgliedschaft anderer Exchange-Sicherheitsgruppen ändern, einschließlich Exchange Trusted Subsystem (ADSecurity.org, „Mitigating Exchange Permission Paths to Domain Admins in Active Directory"; Trimarc Security).
4. Jeder in dieser Kette — oder wer das Computerkonto eines Exchange-Servers direkt kompromittiert — kann das WriteDacl-Recht nutzen, um eine neue ACE auf das Domänenobjekt zu schreiben, die DS-Replication-Get-Changes und DS-Replication-Get-Changes-All gewährt, die beiden erweiterten Rechte, von denen DCSync abhängt.
5. Von dort aus zieht eine Replikationsanfrage sämtliche Passwort-Hashes der Domäne, einschließlich krbtgt. Es handelt sich um denselben Missbrauch von Replikationsrechten, den wir in unserem Audit-Leitfaden zu ACL-, DPAPI-, Tombstone- und Schema-Berechtigungen behandeln — Exchange ist lediglich die häufigste Quelle dieser Rechtevergabe, nicht die einzige.

# Nur lesende Enumeration: Hält Exchange Windows Permissions (oder eine verschachtelte Gruppe)
# noch immer WriteDacl auf dem Domänenobjekt?
dsacls "DC=corp,DC=local" | Select-String "Exchange Windows Permissions|WRITE DAC"

Die PrivExchange-Verstärkung von 2019

Im Januar 2019 zeigte der Forscher Dirk-jan Mollema, dass dieser Standard nicht einmal einen bestehenden Fuß in einer Exchange-Gruppe voraussetzte. Die Funktion PushSubscription von Exchange ließ sich missbrauchen, um das eigene Computerkonto eines Exchange-Servers zu zwingen, sich per HTTP bei einem vom Angreifer kontrollierten Endpunkt zu authentifizieren. Da NTLM über HTTP standardmäßig kein Signing-Required-Flag setzt, konnte diese Authentifizierung an LDAP weitergeleitet und mit dem WriteDacl-Recht des Servers kombiniert werden, um dem Angreifer DCSync-Rechte zu verschaffen — auslösbar durch jeden Postfachbenutzer (dirkjanm.io, „Abusing Exchange: one API call away from Domain Admin"). Microsofts kumulative Exchange-Updates vom Februar 2019 adressierten dies aus zwei Richtungen: KB4490060 änderte den Authentifizierungsvertrag der Exchange-Web-Services-Push-Benachrichtigungen, sodass Abonnements keine Anmeldeinformationen mehr übertragen, die zu einer ausgehenden Authentifizierung gezwungen werden könnten, und KB4490059 dokumentierte, wie sich Exchanges Standard-Active-Directory-Berechtigungen künftig reduzieren lassen — doch weder dieser Fix noch die späteren Patches für den NTLM-MIC-Bypass entfernen eine ACE, die Jahre zuvor bereits auf ein Domänenobjekt geschrieben wurde.

Eine in der Praxis häufige Variante verschärft das noch: Organisationen, die ihre Postfächer zu Exchange Online migriert haben, behalten oft einen einzigen On-Premises-Exchange-Server ausschließlich für die AD-Attributverwaltung, weil Microsofts Hybrid-Empfehlungen historisch davon abraten, den letzten On-Premises-Server vollständig zu entfernen. Dieser beibehaltene Server und die dahinterliegenden AD-Gruppen tragen die gleiche WriteDacl-Vergabe unbegrenzt weiter — genau so endet eine zehn Jahre alte Installation damit, Domain-Admin-Rechte in einer Umgebung zu verteilen, in der niemand mehr Exchange als „im Scope" betrachtet, lange nachdem die Postfächer selbst in die Cloud umgezogen sind.

Erkennung

Die Überwachung von Directory Service Access und Directory Service Changes ist auf Domänencontrollern standardmäßig nicht aktiviert, und selbst wenn sie es ist, löst Event-ID 4662 nur für Objekte mit einer passenden SACL aus. Beide Lücken müssen geschlossen werden, bevor einer der folgenden Indikatoren tatsächlich in Ihren Protokollen erscheint (Altered Security, „A primer on DCSync attack and detection"). Unser Leitfaden zur Active-Directory-Überwachung mit den relevanten Event-IDs behandelt die Voraussetzungen der Audit-Richtlinie für all dies ausführlicher.

Protokollbasierte Erkennung

Proaktive Enumeration

Da die ACE selbst Jahre alt und still sein kann — sie erzeugt kein neues Ereignis, nur weil sie existiert —, sollte die Protokollüberwachung mit periodischer proaktiver Enumeration kombiniert werden: dsacls oder Get-Acl "AD:\<Domänen-DN>" gegen das Domänenobjekt, oder eine BloodHound-Erhebung, die gezielt nach einer WriteDacl-Kante prüft, die auf dem Domänenknoten landet. Behandeln Sie dies genauso wie Privilegierten-Zugriffs-Drift: Ein punktueller Audit beweist nur, dass die ACE am Tag der Prüfung nicht vorhanden war, nicht, dass sie danach dauerhaft verschwunden bleibt.

Remediation

Sofortige kompensierende Kontrollen

1. Enumerieren. Führen Sie dsacls oder Get-Acl gegen das Domänenobjekt aus und prüfen Sie, ob Exchange Windows Permissions / Exchange Trusted Subsystem WriteDACL besitzt; gleichen Sie dies mit einer BloodHound-Erhebung für dieselbe Kante ab.
2. Reduzieren Sie den unmittelbaren Wirkungsradius, falls eine vollständige Migration zu geteilten Berechtigungen noch nicht machbar ist: Entfernen Sie Exchange Trusted Subsystem aus Exchange Windows Permissions und verlangen Sie für jede künftige Aufnahme in Organization Management, Exchange Windows Permissions oder Exchange Trusted Subsystem einen change-kontrollierten, protokollierten Prozess (Trimarc Security).

Die dauerhafte Lösung

3. Übernehmen Sie Microsofts Modell der geteilten Berechtigungen. RBAC Split Permissions ist Microsofts empfohlener Standard; Active Directory Split Permissions sorgt für eine vollständige Trennung zwischen Exchange- und AD-Administration. Beides erfordert einen erneuten Setup-Lauf mit /PrepareAD /ActiveDirectorySplitPermissions:true, zuzüglich /PrepareAllDomains (oder ein /PrepareDomain pro Domäne) in Multi-Domain-Gesamtstrukturen (Microsoft Learn, „Split permissions in Exchange Server"). Das ist es, was die Exchange-Windows-Permissions-ACEs tatsächlich vom Domänenobjekt entfernt — nicht ein Windows- oder Exchange-Sicherheitspatch.
4. Sauber außer Betrieb nehmen. Wurde Exchange bereits in die Cloud migriert oder stillgelegt, bestätigen Sie, dass die ACE des Domänenobjekts als Teil dieses Prozesses entfernt wurde. Das Deprovisioning von Exchange entfernt eine frühere WriteDacl-Vergabe nicht automatisch rückwirkend — genau so verteilt eine zehn Jahre alte Installation weiterhin Domain-Admin-Rechte, lange nachdem der letzte Exchange-Server abgeschaltet wurde.
5. Verifizieren. Wiederholen Sie die Enumeration aus Schritt 1 nach der Behebung und bestätigen Sie, dass die Rechte DS-Replication-Get-Changes(-All) auf dem Domänenobjekt ausschließlich auf Domänencontroller und explizit autorisierte Replikationskonten beschränkt sind. Integrieren Sie diese Prüfung in einen wiederkehrenden Audit-Workflow statt in eine einmalige Bereinigung, denn das erneute Aktivieren geteilter Berechtigungen oder das erneute Hinzufügen von Exchange Trusted Subsystem zu Exchange Windows Permissions stellt die ACE still wieder her, ohne ein offensichtliches Warnsignal.

Wie EtcSec dies erkennt

Der Active-Directory-Audit von EtcSec markiert dieses Muster direkt über den Check Exchange Privilege Escalation Risk (EXCHANGE_PRIV_ESC_PATH), der die ACL des Domänenobjekts auf die WriteDacl-Vergabe von Exchange Windows Permissions prüft und die Gruppenverschachtelung bis dorthin zurückverfolgt. Er wird mit den umfassenderen Checks ACL WriteDACL (ACL_WRITEDACL) und DS-Replication-Get-Changes Rights (DCSync) (ACL_DS_REPLICATION_GET_CHANGES) sowie dem allgemeinen Rollup DCSync Capable (DCSYNC_CAPABLE) korreliert, sodass ein vollständiger Angriffspfad von Exchange zu DCSync als ein einziger priorisierter Befund erscheint statt als vier unverbundene ACL-Einträge — unabhängig davon, ob er von einem aktiven Exchange-Server stammt oder von einem zehn Jahre alten Relikt, dessen Außerbetriebnahme niemand mehr auf dem Schirm hatte.