Active Directory Privilegierte Konten: Protected Users, Delegation und Dienstkonto-Lücken

Was ist der Schutz für privilegierte Active-Directory-Konten (Protected Users und Delegation)

Domain Admins, Enterprise Admins und andere Tier-0-Konten sind die Konten, die ein Angreifer benötigt, um eine Domäne vollständig zu kompromittieren. Für privilegierte Active-Directory-Konten übernehmen drei integrierte, unabhängige Kontrollen den Großteil der eigentlichen Schutzarbeit: die Mitgliedschaft in der Sicherheitsgruppe Protected Users, das Delegation-Flag „Dieses Konto ist vertraulich und kann nicht delegiert werden" sowie die grundlegende Hygieneregel, dass Dienstkonten nicht in privilegierte Gruppen gehören. Zusätzlich kann das Attribut SID History – eigentlich für Domänenmigrationen gedacht – stillschweigend privilegierten Zugriff gewähren, wenn es nie überprüft wird.

Keines davon ist exotisch. Es handelt sich um Standard-AD-Funktionen. Die in diesem Artikel behandelte Lücke ist kein fehlender Patch und kein Zero-Day – es sind schlicht Kontrollen, die für die Konten, die sie benötigen, nicht aktiviert wurden. Deshalb taucht dies in Active-Directory-Sicherheitsbewertungen immer wieder als einer der Hauptübeltäter auf. Jede der folgenden Lücken ist unabhängig ausnutzbar, und keine erfordert speicherresidentes Tooling oder Process Injection: Es sind Fehlkonfigurationen auf Attributebene, sichtbar für jeden, der das Verzeichnis auf die richtige Weise abfragt.

Wie es funktioniert

Protected Users: vorhanden, aber ungenutzt

Die globale Sicherheitsgruppe Protected Users, eingeführt mit Windows Server 2012 R2, wendet nicht konfigurierbare Schutzmaßnahmen auf jedes Konto an, das ihr hinzugefügt wird. Laut Microsofts Dokumentation zu Protected Users können Mitglieder sich nicht per NTLM authentifizieren, können DES oder RC4 nicht für die Kerberos-Vorauthentifizierung verwenden, können nicht per constrained oder unconstrained Delegation delegiert werden und erhalten eine feste 4-Stunden-Kerberos-TGT-Lebensdauer ohne Verlängerung. Die Mitgliedschaft allein erledigt die Arbeit – es gibt keine Richtlinie, die falsch konfiguriert werden könnte, sobald ein Konto in der Gruppe ist.

Der Haken ist, dass die meisten Umgebungen sie nie befüllen. Domain Admins und andere Tier-0-Konten authentifizieren sich weiterhin mit veralteten Protokollen und cachen Anmeldeinformationen in LSASS, genau als ob die Gruppe nicht existierte – weil niemand sie hinzugefügt hat.

Das Flag „vertraulich und kann nicht delegiert werden"

Unabhängig von Protected Users besitzt jedes AD-Konto ein userAccountControl-Bit – NOT_DELEGATED (0x100000 / 1048576) –, das in der GUI als „Dieses Konto ist vertraulich und kann nicht delegiert werden" angezeigt wird. Ist es gesetzt, kann das Kerberos-Ticket des Kontos nicht an einen für Delegation konfigurierten Dienst weitergeleitet werden, selbst wenn dieser Dienst ansonsten für Delegation vertrauenswürdig ist. Laut der Sicherheitsbewertung von Microsoft Defender for Identity für diese Kontrolle bedeutet das Nichtsetzen dieses Flags bei privilegierten Konten, dass ein kompromittierter oder böswilliger, für Delegation vertrauenswürdiger Dienst das Ticket dieses Kontos anfordern und wiederverwenden kann, um es andernorts im Netzwerk zu imitieren – ein Eskalationspfad, unabhängig davon, ob das Konto in Protected Users ist.

Delegation-Exposition am Konto selbst

Über das Sensitive-Flag hinaus kann ein Konto direkt eine Delegation-Konfiguration tragen: TRUSTED_FOR_DELEGATION (unconstrained), msDS-AllowedToDelegateTo (constrained) oder Resource-Based Constrained Delegation über msDS-AllowedToActOnBehalfOfOtherIdentity. Jedes dieser Merkmale an einem Tier-0-Konto bedeutet, dass ein kompromittierter, für Delegation vertrauenswürdiger Dienst Tickets als dieses Konto anfordern kann. Die Ausnutzung dieser Mechanismen behandeln wir ausführlich in Kerberos Delegation Attacks: Von Unconstrained bis RBCD-Missbrauch – der Punkt für diesen Artikel ist enger gefasst: Ein vertrauliches Konto sollte von vornherein niemals Ziel einer Delegation sein, unabhängig von der gegen es eingesetzten Angriffstechnik.

Dienstkonten in privilegierten Gruppen

Ein Dienstkonto mit einem Service Principal Name (SPN) ist per Design kerberoastable – jeder authentifizierte Domänenbenutzer kann für es ein Service-Ticket anfordern und versuchen, das Ticket offline zu knacken (siehe unseren Kerberoasting-Leitfaden für diese Angriffskette). Dieses Risiko ist tolerierbar, solange das Konto nur Zugriff auf den Dienst hat, den es ausführt. Es hört auf, tolerierbar zu sein, sobald das Konto auch Mitglied von Domain Admins oder Enterprise Admins ist.

Microsofts Leitfaden zur Reduzierung der Mitgliedschaft in hochprivilegierten administrativen Gruppen ist eindeutig: Privilegierte Gruppen sollten leer gehalten oder auf eine kleine Zahl verantwortlicher Administratoren beschränkt werden, und Dienstkonten sollten enge, delegierte Berechtigungen erhalten statt pauschaler Domain-Admin-Rechte. Ein Dienstkonto in Domain Admins kombiniert ein knackbares Passwort mit domänenweiten Rechten – jeder, der SPNs abfragen kann, hat bereits einen Weg zur vollständigen Domänenkompromittierung.

SID History: der stille vierte Pfad

Das Attribut sIDHistory existiert, um den Zugriff während Migrationen zwischen Domänen zu erhalten – ein migrierter Benutzer behält die SID seines alten Kontos, angehängt an sein Token, sodass bestehende Berechtigungen weiter funktionieren. Laut MITRE ATT&CK T1134.005 kann ein Angreifer mit Domain-Admin-äquivalenten Rechten (oder DCSync-Fähigkeit) eine erbeutete oder bekannte privilegierte SID – etwa die der Enterprise Admins – in die SID History eines niedrig privilegierten Kontos einfügen. Das Token dieses Kontos trägt dann Enterprise-Admin-Rechte, ohne jemals als Mitglied der Gruppe Enterprise Admins zu erscheinen – genau das macht es gefährlich: Eine Überprüfung der Gruppenmitgliedschaft übersieht es vollständig.

Warum Angreifer diese Lücken verketten

Keine dieser vier Schwachstellen muss für sich allein nützlich sein, und in der Praxis stehen sie selten allein. Ein privilegiertes Konto ohne das Sensitive-Flag ist ein taugliches Delegation-Ziel; dasselbe Konto außerhalb von Protected Users kann sich weiterhin per NTLM authentifizieren, sodass ein Angreifer mit einem gerelayten Hash nicht einmal Kerberos benötigt. Wenn dieselbe Umgebung zusätzlich ein Dienstkonto in Domain Admins hat, erhält ein Angreifer, der es kerberoastet und sein Passwort knackt, einen zweiten, unabhängigen Weg zur selben Berechtigungsstufe – kein Delegation-Missbrauch nötig. Und SID History bietet eine Persistenzoption, die eine Rotation der Anmeldedaten des ursprünglichen privilegierten Kontos vollständig überlebt, da die eingeschleuste SID auf einer völlig anderen, niedrig privilegierten Identität mitreist.

Das ist auch der Grund, warum sich diese Lücke von veralteten privilegierten Konten unterscheidet (nicht deaktivierte, ruhende Anmeldedaten – siehe Veraltete privilegierte Konten: verstecktes Risiko in Active Directory) und von Privileged-Access-Drift (zurückkriechende Rechte nach einer Bereinigung – siehe Privileged Access Drift in Active Directory). Dort geht es um Konten, die keinen Zugriff mehr haben sollten, oder um Zugriff, der zurückgekrochen ist. Hier geht es um Konten, die heute korrekt privilegiert sind, aber ohne die Schutzmaßnahmen auf Attributebene, die Active Directory bereits mitbringt, um sie einzudämmen.

Erkennung

Fragen Sie das Verzeichnis direkt für jede Lücke ab – nichts davon erfordert Drittanbieter-Tooling.

# Privilegierte Konten NICHT in Protected Users
$protected = (Get-ADGroupMember "Protected Users" -Recursive).SamAccountName
Get-ADGroupMember "Domain Admins" -Recursive |
    Where-Object { $_.SamAccountName -notin $protected } |
    Select-Object SamAccountName

# Privilegierte Konten ohne das Flag "vertraulich, kann nicht delegiert werden" (Bit 0x100000)
Get-ADGroupMember "Domain Admins" -Recursive |
    Get-ADUser -Properties userAccountControl |
    Where-Object { -not ($_.userAccountControl -band 1048576) } |
    Select-Object SamAccountName

# Konten, die weiterhin für unconstrained/constrained Delegation vertrauenswürdig sind
Get-ADUser -Filter 'TrustedForDelegation -eq $true -or msDS-AllowedToDelegateTo -like "*"' `
    -Properties TrustedForDelegation, msDS-AllowedToDelegateTo

# Dienstkonten (SPN gesetzt) in privilegierten Gruppen
Get-ADGroupMember "Domain Admins","Enterprise Admins" -Recursive |
    Get-ADUser -Properties ServicePrincipalNames |
    Where-Object { $_.ServicePrincipalNames.Count -gt 0 }

# Jedes Konto mit SID History
Get-ADUser -Filter * -Properties SIDHistory |
    Where-Object { $_.SIDHistory.Count -gt 0 } |
    Select-Object SamAccountName, SIDHistory

Für eine umfassendere Übersicht darüber, welche Event-IDs im übrigen AD-Bestand relevant sind, siehe Active Directory Monitoring: Die Security Event IDs, auf die es ankommt.

Remediation

1. Befüllen Sie Protected Users ausschließlich mit menschlichen Tier-0-Konten. Testen Sie zuerst in einer Pilotgruppe – Protected Users bricht NTLM-abhängige Apps, gecachte/Offline-Anmeldung und jeden Workflow, der auf eine Kerberos-Ticket-Verlängerung über 4 Stunden hinaus angewiesen ist. Fügen Sie niemals Dienst- oder Computerkonten hinzu.
2. Setzen Sie das Sensitive-Flag bei jedem privilegierten menschlichen Konto:

   Get-ADUser -Identity "jdoe" | Set-ADAccountControl -AccountNotDelegated:$true
   

   Tun Sie dies auch bei Konten, die bereits in Protected Users sind – die Delegation-Sperre von Protected Users wird bei der Authentifizierung erzwungen, aber ein explizites Sensitive-Flag ist Defense in Depth und zählt sofort für jedes Konto, das noch nicht vollständig in die Gruppe migriert wurde.
3. Entfernen Sie Delegation-Vertrauen von Tier-0-Konten. Löschen Sie TrustedForDelegation und msDS-AllowedToDelegateTo bei jedem privilegierten Konto; privilegierte Konten sollten niemals Delegation-Ziele sein. Unser Leitfaden Kerberos Delegation Attacks erklärt, wie Sie die Delegation-Konfiguration domänenweit prüfen, bevor Sie mit dem Entfernen beginnen.
4. Entfernen Sie Dienstkonten aus privilegierten Gruppen. Ersetzen Sie die Domain-Admin-Mitgliedschaft durch ein Group Managed Service Account (gMSA) mit eng delegierten Berechtigungen auf die spezifische OU oder Ressource, die der Dienst tatsächlich benötigt. Wenn der Dienst wirklich domänenweite Rechte braucht, ist das ein Signal, den Dienst neu zu gestalten – nicht, ein kerberoastbares Konto mit vollen Domänenrechten zu belassen.
5. Prüfen und bereinigen Sie veraltete SID History. Führen Sie die obige Erkennungsabfrage aus; jeder sIDHistory-Wert, der nicht mit einer dokumentierten, noch relevanten Domänenmigration verbunden ist, sollte untersucht und mit Set-ADUser -Clear sIDHistory entfernt werden, nachdem bestätigt wurde, dass kein legitimer Zugriff davon abhängt. Aktivieren Sie für Cross-Forest- und externe Trusts die SID-Filterung (Quarantäne), damit auf der anderen Seite des Trusts eingeschleuste SIDs entfernt werden, bevor sie Ihre Domäne erreichen – siehe Active Directory Trust Attacks: Von der Unterdomäne zur Gesamtstruktur-Root dafür, wie Lücken bei der SID-Filterung über Trusts hinweg ausgenutzt werden.

Wie EtcSec das erkennt

Das Active-Directory-Audit von EtcSec prüft bei jedem Scan alle vier Lücken: NOT_IN_PROTECTED_USERS markiert privilegierte Konten, die in der Protected-Users-Gruppe fehlen, SENSITIVE_DELEGATION erfasst privilegierte Konten ohne das Flag „kann nicht delegiert werden", SERVICE_ACCOUNT_PRIVILEGED findet SPN-tragende Konten in Domain Admins/Enterprise Admins, und SID_HISTORY deckt jedes Konto mit einer nicht leeren sIDHistory zur Überprüfung auf.