DCSync-Rechte in Active Directory finden und entfernen

DCSync ist kein Exploit. Es ist das Verzeichnisreplikationsprotokoll (MS-DRSR), das genau das tut, wofür es gebaut wurde – angefragt von jemandem, der nicht fragen sollte. Jedes Prinzipal mit zwei bestimmten erweiterten Rechten auf dem Domänennamenskontext kann von einem DC über das Netzwerk Kennwortdaten für jedes Konto anfordern, einschließlich krbtgt. Werkzeuge wie Mimikatz und secretsdump aus Impacket machen daraus einen Einzeiler, und auf dem DC bleibt keine Datei zurück.

Wer diese Rechte besitzt, ist daher eine der wichtigsten ACL-Fragen jeder Domäne – und eine der am seltensten geprüften. Der ACL-Grundlagenleitfaden zeigt die Basisabfrage. Dieser Leitfaden behandelt das vollständige Audit: jedes Recht, das DCSync gleichkommt, die zu erwartenden Standardwerte, das sichere Entfernen aller übrigen und die Erkennung der Nutzung jener Rechte, die bleiben müssen.

Die Rechte, die zusammen DCSync ergeben

Replikationsberechtigungen sind erweiterte Rechte (Control Access Rights), die auf dem Kopf des Namenskontexts gewährt werden, also auf dem Domänenobjekt selbst (zum Beispiel DC=corp,DC=example,DC=com):

DCSync von Geheimnissen erfordert Get-Changes plus Get-Changes-All. Sie müssen aber auch Rechte mitzählen, die diese gewähren oder implizieren können:

• GenericAll auf dem Domänenobjekt umfasst alle erweiterten Rechte.
• AllExtendedRights, ein ExtendedRight-ACE mit leerem ObjectType, deckt jedes Control Access Right ab.
• WriteDACL oder WriteOwner auf dem Domänenobjekt erlaubt es dem Inhaber, sich die beiden Rechte jederzeit selbst zu gewähren.
• Gruppenmitgliedschaft in jeder Gruppe, die eines der oben genannten Rechte besitzt, einschließlich verschachtelter Mitgliedschaft.

Ein Audit, das nur nach den beiden GUIDs sucht, übersieht die letzten vier. Angriffspfad-Werkzeuge modellieren sie alle als eine einzige DCSync-Kante.

Messen: jedes replikationsfähige Prinzipal auflisten

Die rightsGuid-Werte sind in jeder Gesamtstruktur identisch und können daher fest codiert werden. Markieren Sie jeden ACE, der DCSync gewährt oder ermöglichen kann:

Import-Module ActiveDirectory
$domainDN = (Get-ADDomain).DistinguishedName
$acl      = Get-Acl -Path "AD:\$domainDN"

$getChanges    = [guid]'1131f6aa-9c07-11d1-f79f-00c04fc2dcd2'
$getChangesAll = [guid]'1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'
$filteredSet   = [guid]'89e95b76-444d-4c62-991a-0facbeda640c'
$empty         = [guid]::Empty

$findings = foreach ($ace in ($acl.Access | Where-Object { $_.AccessControlType -eq 'Allow' })) {
    $r = $ace.ActiveDirectoryRights
    $why = switch ($true) {
        { $r.HasFlag([System.DirectoryServices.ActiveDirectoryRights]::GenericAll) } { 'GenericAll'; break }
        { $r.HasFlag([System.DirectoryServices.ActiveDirectoryRights]::WriteDacl) }  { 'WriteDACL'; break }
        { $r.HasFlag([System.DirectoryServices.ActiveDirectoryRights]::WriteOwner) } { 'WriteOwner'; break }
        { $r.HasFlag([System.DirectoryServices.ActiveDirectoryRights]::ExtendedRight) -and $ace.ObjectType -eq $empty } { 'AllExtendedRights'; break }
        { $ace.ObjectType -eq $getChangesAll } { 'Get-Changes-All'; break }
        { $ace.ObjectType -eq $getChanges }    { 'Get-Changes'; break }
        { $ace.ObjectType -eq $filteredSet }   { 'Get-Changes-In-Filtered-Set'; break }
    }
    if ($why) { [PSCustomObject]@{ Principal = $ace.IdentityReference.Value; Right = $why; Inherited = $ace.IsInherited } }
}
$findings | Sort-Object Principal, Right | Format-Table -AutoSize

Lösen Sie anschließend Gruppenprinzipale in ihre effektiven Mitglieder auf, denn ein ACE für „IT-Sync-Operators“ ist nur so sicher wie die Mitgliedschaft dieser Gruppe:

$findings.Principal | Sort-Object -Unique | Where-Object { $_ -notmatch '^(NT AUTHORITY|BUILTIN)\\' } |
    ForEach-Object {
        $name = $_.Split('\')[-1]
        $obj = Get-ADObject -Filter "sAMAccountName -eq '$name'" -Properties objectClass
        if ($obj.objectClass -eq 'group') {
            Get-ADGroupMember $obj -Recursive | Select-Object @{n='ViaGroup';e={$name}}, SamAccountName, objectClass
        }
    }

Führen Sie dieselbe Abfrage für jede Domäne der Gesamtstruktur aus. Jede Domäne hat ihren eigenen Namenskontext und ihre eigene ACL.

Auditieren: mit dem erwarteten Satz vergleichen

In einer Standarddomäne besitzen folgende Prinzipale Replikationsrechte auf dem Domänenobjekt:

• Domain Controllers und Enterprise Domain Controllers: die DCs selbst.
• Enterprise Read-only Domain Controllers: nur Get-Changes. RODCs erhalten kein Get-Changes-All.
• Administrators (integriert), worüber Domain Admins und Enterprise Admins das Recht erhalten, dazu die weitreichenden Standardrechte dieser Gruppen auf dem Domänenobjekt.
• SYSTEM.

Alles andere braucht einen Verantwortlichen und eine Begründung. Häufige Funde und wie Sie damit umgehen:

Andere Namenskontexte, Domänen und Gesamtstrukturen

Im Domänennamenskontext liegen die Kennwortgeheimnisse, dort ist DCSync also am relevantesten. Die Partitionen Configuration und Schema haben ebenfalls eigene Replikations-ACLs. Dort liegen keine Kennwort-Hashes, doch Schreibrechte auf Configuration können sich auf jede Domäne der Gesamtstruktur auswirken (Standorte, AD-CS-Objekte, Exchange-Konfiguration). Führen Sie dieselbe Abfrage gegen (Get-ADRootDSE).configurationNamingContext aus und prüfen Sie alles, was keine integrierte Admin-Gruppe und kein DC ist.

Wiederholen Sie das Audit in einer Gesamtstruktur mit mehreren Domänen in jeder Domäne. Eine Berechtigung in einer untergeordneten Domäne legt die Konten dieser Domäne offen, und Enterprise Admins aus der Stammdomäne erreichen ohnehin alles. Über Gesamtstruktur-Vertrauensstellungen hinweg überschreiten Replikationsrechte die Grenze nicht, es sei denn, jemand hat einem fremden Prinzipal ausdrücklich einen ACE gewährt. Eine solche Berechtigung erscheint in Ihrer Ausgabe als nicht aufgelöste SID oder als Foreign Security Principal und sollte immer untersucht werden.

Prüfen Sie whenChanged am Domänenobjekt und Ihren Verlauf von Ereignis 5136, um festzustellen, wann ein unerwarteter ACE aufgetaucht ist. Eine nicht standardmäßige Replikationsberechtigung ohne Änderungsnachweis ist eine klassische Persistenztechnik.

Durchsetzen: entfernen, was keinen Verantwortlichen hat

Entfernen Sie einzelne ACEs, nicht ganze Prinzipale, damit Sie nicht versehentlich andere Rechte entziehen. Sichern Sie zuerst den vollständigen Sicherheitsdeskriptor:

$domainDN = (Get-ADDomain).DistinguishedName
(Get-Acl "AD:\$domainDN").Sddl | Out-File "C:\Tier0\Backup\domain-root-$(Get-Date -f yyyyMMdd).sddl"

$acl    = Get-Acl "AD:\$domainDN"
$target = 'CORP\svc-oldaudit'
$acl.Access | Where-Object {
    $_.IdentityReference.Value -eq $target -and -not $_.IsInherited -and
    $_.ObjectType -in @([guid]'1131f6aa-9c07-11d1-f79f-00c04fc2dcd2', [guid]'1131f6ad-9c07-11d1-f79f-00c04fc2dcd2')
} | ForEach-Object { [void]$acl.RemoveAccessRule($_) }
Set-Acl -Path "AD:\$domainDN" -AclObject $acl

Finden Sie eine Berechtigung, die niemand erklären kann – vor allem eine kürzlich hinzugefügte oder eine, die ein niedrig privilegierter Benutzer besitzt –, löschen Sie sie nicht einfach und machen weiter. Behandeln Sie sie als mögliche Kompromittierung. Sichern Sie die Beweise (die SDDL-Sicherung, die Ereignisse 5136 und 4662, den Anmeldeverlauf des Kontos), gehen Sie davon aus, dass jeder Hash der Domäne kopiert worden sein könnte, und planen Sie das Zurücksetzen der Anmeldeinformationen von oben nach unten: krbtgt zweimal mit Replikation dazwischen, Tier-0-Konten, Dienstkonten, dann alle anderen. Das Entfernen des ACE verhindert die künftige Nutzung. An bereits abgegriffenen Hashes ändert es nichts.

Für Konten, die die Rechte behalten müssen:

• Nehmen Sie sie in das Tier-0-Verwaltungsmodell auf. Sie melden sich nur an Tier-0-Systemen an, haben lange zufällige oder verwaltete Kennwörter und sind von der Delegierung ausgeschlossen.
• Wenn das Produkt es unterstützt, gewähren Sie nur Get-Changes und testen Sie, ob die von Geheimnissen abhängige Funktion wirklich genutzt wird.
• Bevorzugen Sie pro Produkt eine dedizierte Gruppe (zum Beispiel T0-Repl-EntraConnect), die den ACE besitzt, damit Mitgliedschaftsänderungen in der Überwachung von Gruppenänderungen sichtbar werden.

Überprüfen und erkennen

Führen Sie das Messskript erneut aus und vergleichen Sie das Ergebnis mit Ihrer genehmigten Liste. Die Ausgabe sollte nun genau dem erwarteten Satz entsprechen. Planen Sie das Skript wöchentlich ein und alarmieren Sie bei jeder Abweichung.

Aktivieren Sie zur Erkennung auf den DCs Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > DS Access > Audit Directory Service Access (Erfolg) und stellen Sie sicher, dass das Domänenobjekt eine SACL besitzt, die Everyone für die Replikations-Control-Access-Rights überwacht. Alarmieren Sie dann bei:

• Ereignis 4662, wenn das Objekt das Domänenobjekt ist, die Zugriffsmaske 0x100 (Control Access) lautet, die Eigenschaften {1131f6ad-9c07-11d1-f79f-00c04fc2dcd2} oder {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2} enthalten und der Antragsteller kein DC-Computerkonto ist. Nehmen Sie das Entra-Connect-Konto namentlich in die Ausnahmeliste auf – und nur von seinem Server aus.
• Ereignis 5136 am Domänenobjekt, wenn nTSecurityDescriptor geändert wird. Jeder, der Replikationsrechte hinzufügt, erscheint hier. Die Referenz der Ereignis-IDs enthält Details auf Feldebene zu beiden Ereignissen.

Testen Sie den Alarm im Labor: Gewähren Sie einem dedizierten Testkonto die beiden Replikationsrechte, fordern Sie damit die Replikation der Geheimnisse eines einzelnen Laborbenutzers an (zum Beispiel mit einem autorisierten DCSync-Werkzeug wie Impacket secretsdump) und bestätigen Sie, dass ein 4662-Alarm mit dem Testkonto ausgelöst wird. Normale Replikation zwischen DCs im selben Zeitraum darf keinen Alarm auslösen. Entfernen Sie die Berechtigung anschließend wieder.

Was dabei kaputtgeht

• Die Kennwort-Hash-Synchronisierung stoppt, wenn Sie dem Entra-Connect-Connector-Konto die Rechte entziehen. Behalten Sie diese Rechte und härten Sie stattdessen das Konto.
• Kennwortprüfungs- und ITDR-Werkzeuge, die Hashes mit Listen kompromittierter Kennwörter vergleichen, benötigen Get-Changes-All. Ohne dieses Recht fällt die Funktion weg. Entscheiden Sie bewusst, ob der Nutzen eine weitere Tier-0-Anmeldeinformation rechtfertigt.
• Die Vorbereitung älterer Exchange-Versionen kann WriteDACL wieder hinzufügen, wenn jemand ein altes /PrepareAD erneut ausführt. Halten Sie den Fix in Ihrem Exchange-Runbook fest.
• Eigene Synchronisierungsskripte auf Basis von DirSync-Steuerelementen benötigen Get-Changes. Ohne dieses Recht schlagen sie mit „Zugriff verweigert“ fehl. Stellen Sie sie nach Möglichkeit auf eingegrenzte LDAP-Lesezugriffe um.

Weiterführende Lektüre: der ACL-Grundlagenleitfaden, AdminSDHolder und SDProp bereinigen für die andere ACL, die privilegierte Objekte steuert, und krbtgt-Rotation, falls eine unerklärliche DCSync-Berechtigung darauf hindeutet, dass die Hashes das Haus bereits verlassen haben.