DCShadow-Angriff: Rogue-Domänencontroller erklärt

Der DCShadow Angriff Rogue Domain Controller Registrierung – öffentlich vorgestellt von Benjamin Delpy und Vincent Le Toux (den Machern von Mimikatz) auf der BlueHat IL im Januar 2018 – erlaubt es einem Angreifer mit ausreichenden Rechten, eine kompromittierte Maschine vorübergehend als Domänencontroller zu registrieren und Änderungen an Active-Directory-Objekten über das normale Replikationsprotokoll an den Rest der Domäne zu pushen – statt über eine Standard-Schreib-API. MITRE ATT&CK katalogisiert dies als T1207 — Rogue Domain Controller.

Dieser Artikel behandelt den Mechanismus, warum er die Protokollierung umgeht, die normalerweise privilegierte AD-Änderungen erfasst, sowie konkrete Erkennungs- und Behebungsschritte. Zur häufigeren Replikations-Missbrauchstechnik – dem Auslesen von Geheimnissen statt dem Schreiben von Änderungen – siehe ACL-Missbrauch und DCSync: Wie stille Rechte Domain Admin öffnen und AD Sicherheitsüberwachung: Event IDs und SIEM für die umfassendere Baseline der Replikationsüberwachung, die diese Technik zu umgehen versucht.

Der DCShadow Angriff Rogue Domain Controller Registrierung erklärt

Jeder Domänencontroller in Active Directory wird im Verzeichnis selbst repräsentiert: ein Server-Objekt und ein untergeordnetes nTDSDSA-Objekt im Konfigurations-Namenskontext (CN=Sites) – dieselbe Objektklasse, die bei jeder Beförderung eines echten DC erzeugt wird. DCShadow missbraucht die Tatsache, dass jeder Principal mit den passenden replikationsbezogenen Rechten dieses gleiche Objektpaar auf einer Maschine erzeugen kann, die tatsächlich kein Domänencontroller ist – und anschließend das legitime Directory-Replication-Service-(DRS)-RPC-Protokoll nutzt, damit der Rest der Domäne „Änderungen" von ihr abruft, als wäre sie ein vertrauenswürdiger Peer.

⚠️

⚠️ Warnung: Da die Änderung per Replikation eintrifft und nicht über LDAP-Schreibvorgänge oder das lokale Security-Eventlog eines DC, erzeugt DCShadow nicht die Events, auf die Sicherheitsteams normalerweise angewiesen sind, um privilegierte AD-Manipulation zu erkennen – kein 4738 (Benutzerkonto geändert), kein 5136 (Verzeichnisdienstobjekt geändert), das mit der eigentlichen Änderung verknüpft ist.

DCShadow unterscheidet sich von DCSync. DCSync (DS-Replication-Get-Changes) missbraucht Replikationsrechte, um Geheimnisse auszulesen – meist um Passwort-Hashes aus der Perspektive eines legitimen DC zu extrahieren. DCShadow missbraucht eine andere, angrenzende Gruppe von Replikationsrechten zum Schreiben – es fälscht eine Rogue-Replikationsquelle und schleust Änderungen ins Verzeichnis ein. Beide werden häufig verwechselt, da sie dieselbe zugrunde liegende Protokollfamilie (MS-DRSR) und dieselbe Klasse von „Wer hat DCSync-nahe Rechte"-Audit-Fragen teilen, sind aber getrennte Angriffsprimitive mit getrennten Erkennungsflächen.

Wie es funktioniert

Schritt 1 — Rechte beschaffen

Laut unabhängiger Minimalrechte-Recherche, veröffentlicht von Lab of a Penetration Tester im April 2018, erfordert DCShadow nicht zwingend eine Mitgliedschaft in Domain Admins oder Enterprise Admins – das ist der übliche Weg, aber die Technik funktioniert auch mit einer engeren Gruppe von Berechtigungen direkt am Domänenobjekt: den erweiterten Rechten DS-Install-Replica ({9923a32a-3607-11d2-b9be-0000f87a36b2}, laut Microsofts ADSchema-Referenz), DS-Replication-Manage-Topology und DS-Replication-Synchronize ({1131f6ab-9c07-11d1-f79f-00c04fc2dcd2}, laut Microsofts ADSchema-Referenz) – plus genug WriteProperty auf dem eigenen Computerobjekt der angreifenden Maschine (siehe Active Directory Computerobjekte Angriffsfläche: Das Maschinenidentitäts-Risiko, das niemand auditiert zur breiteren Risikoklasse), um dessen Service Principal Names zu setzen. Deshalb erfasst der Katalog von EtcSec, wer Server-Trust-Account-Rechte besitzt, als eigenständigen, kritischen Befund: Das ist die Voraussetzung, die eine Rogue-DC-Registrierung überhaupt erst ermöglicht – unabhängig davon, ob dieses Konto auch Domain Admin ist.

Schritt 2 — Den Rogue-DC registrieren

Mit dem Modul lsadump::dcshadow setzt Mimikatz (mit SYSTEM-Rechten auf der angreifenden Maschine ausgeführt) zwei Service Principal Names auf dem kompromittierten Computerkonto und erzeugt anschließend die Server- und nTDSDSA-Objekte in der Konfigurationspartition. Laut MITRE's DET0276-Erkennungsstrategie sind die verwendeten SPNs der Global-Catalog-SPN (GC/<hostname>/<domain>) und der Directory-Replication-Service-Interface-SPN (E3514235-4B06-11D1-AB04-00C04FC2DCD2/<guid>/<domain>) – dieselben SPN-Klassen, die ein legitimer DC trägt, was genau der Maschine erlaubt, für Replikationszwecke einen DC zu imitieren.

Schritt 3 — Die Änderung pushen

Mit registriertem Rogue-DC und gesetzten SPNs löst ein zweiter Befehl lsadump::dcshadow /push ein ausgehendes Replikationsereignis aus: Die gefälschte Objekt- oder Attributänderung (eine ACL-Umschreibung, eine Gruppenmitgliedschaft, ein msDS-KeyCredentialLink, ein Schema-Attribut – DCShadow kann im Prinzip jede beschreibbare AD-Dateneinheit anvisieren) wird per IDL_DRSReplicaAdd/GetNCChanges von der Maschine des Angreifers zu einem echten DC repliziert – exakt so, als käme sie von einem Peer-DC.

Schritt 4 — Deregistrieren und verschwinden

Der Angreifer entfernt das Rogue-Server- und nTDSDSA-Objekt, stellt die ursprünglichen SPNs wieder her, und die Maschine erscheint wieder wie ein gewöhnlicher domänengebundener Computer. Die bösartige Änderung ist jedoch bereits auf jeden echten DC in der Domäne repliziert worden und bleibt im Verzeichnis bestehen.

Erkennung

Die Registrierungs- und Deregistrierungsschritte sind das erkennbare Zeitfenster – die gepushte Änderung selbst sieht, einmal repliziert, wie jedes andere Verzeichnisattribut aus.

Indikator	Event-ID	Quelle	Beschreibung
Replikationsquelle als Namenskontext etabliert	4928	DC — Subkategorie „Detaillierte Verzeichnisdienstreplikation prüfen"	Laut Microsofts Event-Referenz ausgelöst, wenn ein DC beginnt, eine Quelle als Replikationspartner zu behandeln. Bei einem legitimen DC korreliert dies mit bekannten Beförderungen; eine unerwartete Source DRA ist das Signal.
Replikationsquelle als Namenskontext entfernt	4929	DC — dieselbe Subkategorie	Laut Microsofts Event-Referenz ausgelöst bei der Deregistrierung – DCShadows Aufräumschritt. Ein 4928/4929-Paar in kurzem Abstand von einem Host, der kein bekannter DC ist, ist ein starkes Signal.
Computerkonto geändert	4742	DC — „Computerkontoverwaltung prüfen"	Laut Microsofts Event-Referenz ausgelöst, wenn die SPNs der angreifenden Maschine gesetzt werden. Gleichen Sie das Subject (das die Änderung durchführende Konto) mit Ihrer Liste bekannter Domain-Admin-/Server-Trust-Account-Inhaber ab.
nTDSDSA-/Server-Objekterstellung im Konfigurations-NC	—	Directory Service Changes (5137), erfordert eine SACL auf `CN=Sites,CN=Configuration`	Active Directory prüft die Konfigurationspartition nicht standardmäßig. Eine SACL auf dem Sites-Container ist erforderlich, damit dieses Signal überhaupt existiert – dies entspricht direkt der Korrelation „unerwartete nTDSDSA-/Server-Objekte" gemäß MITRE's DET0276-Leitfaden.
Unerwartete DRS-SPN-Nutzung	—	Kerberos-Authentifizierung / SIEM-Korrelation	Laut MITRE DET0276: Kerberos-Authentifizierung mit den SPN-Klassen `GC/` oder `E3514235-4B06-11D1-AB04-00C04FC2DCD2` von einem Host außerhalb der bekannten DC-Liste.

💡

💡 Tipp: Keines der oben genannten Konfigurationspartitions-Signale wird standardmäßig erfasst. Wenn Ihre einzige Sichtbarkeit in die Replikation die Standard-Audit-Richtlinie der Domänen-NC ist, sehen Sie eine DCShadow-Rogue-Domänencontroller-Registrierung nicht. Genau das ist die Lücke, die diese Technik gezielt ausnutzt – Tooling (SentinelOnes Analyse) empfiehlt, das 4928/4929-Paar und Konfigurations-NC-SACLs als Basis zu behandeln, nicht als optionale Ergänzung.

Remediation

1. Prüfen, wer Server-Trust-Account- und Replikations-Schreibrechte besitzt

Die Voraussetzung für einen DCShadow-Angriff ist ein Principal mit DS-Install-Replica, DS-Replication-Manage-Topology und DS-Replication-Synchronize am Domänenobjekt – oder umfassenderen Rechten, um die SPNs eines Computerkontos zu setzen. Erfassen Sie dies genauso wie DCSync-fähige Konten, aber für die schreibseitigen erweiterten Rechte:

# Nicht-Standard-Principals mit Replikations-Extended-Rights am Domänenobjekt auflisten
$domainDN = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:\$domainDN"
$acl.Access |
  Where-Object { $_.ActiveDirectoryRights -match "ExtendedRight" } |
  Select-Object IdentityReference, ActiveDirectoryRights, ObjectType

Gleichen Sie jedes Ergebnis mit Ihrer erwarteten Domain-Admin-/Enterprise-Admin-Mitgliedschaft ab – alles andere ist eine undokumentierte Berechtigung, die es zu untersuchen lohnt.

2. Konfigurationspartitions-Auditing aktivieren

Änderungen an der Konfigurations-NC werden standardmäßig nicht geprüft. Wenden Sie eine SACL auf CN=Sites,CN=Configuration,DC=<domain> an (idealerweise auch auf die Konfigurations-NC-Wurzel), damit die Erstellung/Löschung von nTDSDSA- und Server-Objekten Directory-Service-Changes-Events (5136/5137) erzeugt, und aktivieren Sie die Subkategorie „Detaillierte Verzeichnisdienstreplikation prüfen" domänenweit, damit 4928/4929 erfasst werden.

3. Privilegierten Zugriff minimieren und staffeln

💡

💡 Quick Win: Behandeln Sie „Wer kann sich als DC registrieren" als Tier-0-Frage, nicht nur als „Wer ist Domain Admin".

Folgen Sie einem gestaffelten Administrationsmodell – siehe Active Directory härten: Was Sie zuerst absichern und wie Sie es validieren –, damit die Konten, die Replikations-Schreibrechte besitzen können, dieselbe kleine, überwachte Gruppe sind, die Sie bereits als Tier 0 behandeln, ohne ständige Mitgliedschaft über das aktiv Benötigte hinaus. Dieselbe Disziplin verhindert auch privilegierten Zugriffsdrift im weiteren Sinne.

4. Bei bekannten DCs korreliertes 4928/4929-Paar alarmieren

Erstellen Sie eine Erkennungsregel, die jedes 4928 (und sein gepaartes 4929) markiert, dessen Source DRA nicht mit Ihrem gepflegten Inventar legitimer Domänencontroller übereinstimmt. Da ein DCShadow-Registrierungsfenster typischerweise kurz ist, zählt Near-Realtime-Log-Forwarding hier stärker als bei den meisten AD-Erkennungen – eine tägliche Batch-Überprüfung läuft meist erst, nachdem der Rogue-DC sich bereits deregistriert hat.

Wie EtcSec dies erkennt

Der AD-Schwachstellenkatalog von EtcSec kennzeichnet diese Gefährdung über zwei Prüfungen: DCSHADOW_EVIDENCE, die nach direkten Hinweisen auf eine bereits erfolgte DCShadow-Rogue-Domänencontroller-Registrierung sucht, und SERVER_TRUST_ACCOUNT_RIGHT, die Konten und Gruppen markiert, die die Rechte besitzen, ein Server-Trust-Account zu setzen – die Voraussetzung, die die Technik unabhängig davon praktikabel macht, ob dieses Konto auch Domain Admin ist. Umgebungen, die ihre DCSync-fähigen Konten bereits geprüft haben, sollten dies als begleitendes Audit behandeln: Die Lese- und Schreibpfad-Replikationsrechte entstehen meist aus denselben Delegationsfehlern, werden aber selten gemeinsam überprüft.

ℹ️

ℹ️ Hinweis: EtcSec prüft bei jedem AD-Audit automatisch auf DCShadow-Hinweise und Server-Trust-Account-Rechte. Führen Sie ein kostenloses Audit durch, um zu prüfen, ob Ihre Umgebung diese Gefährdung aufweist.

DCShadow Angriff Rogue Domain Controller Registrierung: Wie sie die AD-Änderungsprüfung umgeht