Active Directory Ueberwachungsluecken: Display Specifiers, RODC, Manipulation der Default Domain Policy und PAM Shadow Principals

Active Directory Ueberwachungsluecken: Display Specifiers, RODC und zwei weitere

Active Directory Ueberwachungsluecken – Display Specifiers, RODC-Credential-Caching, Manipulation der Default Domain Policy und PAM Shadow Principals – tauchen in einem Standard-Security-Review selten auf, obwohl alle vier dokumentierte Microsoft-Mechanismen sind, über die ein Angreifer Persistenz oder privilegierten Zugriff erlangen kann, während die üblichen Dashboards (Mitgliedschaft in Domain Admins, DCSync-Rechte, ACL-Änderungen an Tier-0-Objekten) grün bleiben. Es sind blinde Flecken, weil niemand eine SACL oder eine Abfrage darauf richtet – nicht weil sie versteckt wären.

Dieser Beitrag behandelt jeden einzeln: was das Objekt oder der Mechanismus tatsächlich ist, wie er missbraucht wird oder driftet, worauf man achten sollte, um ihn zu erkennen, und wie man ihn behebt.

Display Specifiers: Eine UI-Erweiterung wird zur Persistenz-Backdoor

Der Mechanismus

Display Specifiers sind Objekte der Klasse displaySpecifier, gespeichert in gebietsschemaspezifischen Containern unter CN=DisplaySpecifiers,CN=Configuration,DC=<forest-root> – zum Beispiel CN=user-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration. Da sie im Configuration-Namenskontext liegen, replizieren sie zu jedem Domain Controller im Forest. Ihr dokumentierter Zweck, laut Microsofts Win32-AD-Programmierreferenz, ist vollkommen legitim: Sie speichern die Daten hinter Eigenschaftsseiten, Kontextmenüs, Symbolen und Erstellungsassistenten in MMC-basierten Tools wie Active Directory-Benutzer und -Computer (ADUC).

Die Attribute, die dies aus Sicherheitssicht interessant machen, sind adminContextMenu und adminPropertyPages (administrative Snap-ins) sowie ihre nicht-administrativen Gegenstücke contextMenu/shellContextMenu – alle dokumentiert in Microsofts [MS-ADTS]-Protokollspezifikation und der Schemaklassen-Referenz Display-Specifier. Jedes kann ein COM-Objekt oder eine Anwendung registrieren, die ausgeführt wird, wenn ein Administrator über ADUC mit einem Objekt interagiert. Sicherheitsforscher von Semperis und SDM Software haben den Missbrauchsfall direkt dokumentiert: Ein Angreifer mit Schreibzugriff auf einen Display Specifier kann einen gefälschten Kontextmenüeintrag hinzufügen – einer, der wie eine normale Aktion aussieht (etwa eine Option zum Passwort-Zurücksetzen) –, der tatsächlich ein Skript startet, wenn ein Helpdesk-Administrator mit der rechten Maustaste auf ein Benutzerobjekt klickt.

Erkennung

Änderungen an Verzeichnisobjekten erzeugen das Windows-Sicherheitsereignis mit der ID 5136 ("Ein Verzeichnisdienstobjekt wurde geändert"), aber nur, wenn beide Bedingungen erfüllt sind: Auf dem DC ist die erweiterte Überwachungsunterkategorie "Verzeichnisdienständerungen überwachen" aktiviert, und das Zielobjekt trägt eine SACL für die betreffenden Attribute. Standardmäßig ist keines von beidem für den DisplaySpecifiers-Container aktiv – genau deshalb existiert diese Überwachungslücke. Sobald die Überwachung eingerichtet ist, achten Sie auf 5136-Ereignisse, bei denen die Objektklasse displaySpecifier ist und das geänderte Attribut adminContextMenu, adminPropertyPages, contextMenu oder shellContextMenu lautet. Siehe Active Directory Monitoring: Die relevanten Security Event IDs für die grundlegende Audit-Policy-Baseline, von der diese Prüfungen ausgehen.

# Alle Display-Specifier-Objekte und ihre Menü-/Eigenschaftsseiten-Attribute auflisten
Get-ADObject -SearchBase "CN=DisplaySpecifiers,CN=Configuration,$((Get-ADRootDSE).configurationNamingContext)" `
  -Filter "objectClass -eq 'displaySpecifier'" `
  -Properties adminContextMenu, adminPropertyPages, contextMenu, shellContextMenu |
  Where-Object { $_.adminContextMenu -or $_.adminPropertyPages -or $_.contextMenu -or $_.shellContextMenu } |
  Select-Object Name, adminContextMenu, adminPropertyPages, contextMenu, shellContextMenu

Eine saubere Baseline für diese Abfrage ist in den meisten Domänen ein leeres Ergebnis – jeder Treffer verdient eine manuelle Überprüfung der referenzierten COM-CLSID oder des Anwendungspfads.

Manipulation der Default Domain Policy: Stille Änderungen an der Sicherheits-Baseline der Domäne

Der Mechanismus

Die Default Domain Policy trägt eine bekannte, forest-unabhängige GUID – {31B2F340-016D-11D2-945F-00C04FB984F9} – und erzwingt die domänenweite Baseline für Konten-, Passwort-, Kerberos- und Sperrrichtlinien, sofern sie nicht durch ein spezifischeres GPO überschrieben wird. Da diese GUID fest codiert und vorhersagbar ist und das GPO alt genug ist, dass die meisten Teams die Überprüfung nach der initialen Härtung eingestellt haben, bleiben Änderungen daran tendenziell unbemerkt. MITRE ATT&CK erfasst GPO-Manipulation als Sub-Technik T1484.001 (Domain or Tenant Policy Modification: Group Policy Modification) – Angreifer verändern GPOs, um Sperrschwellen für Konten abzuschwächen, die Passwortkomplexität zu deaktivieren oder eine geplante Aufgabe bzw. ein Anmeldeskript an jeden Computer zu verteilen, auf den die Richtlinie angewendet wird.

Erkennung

Zwei separate Event-IDs decken unterschiedliche Ebenen einer GPO-Änderung ab, und sie zu vermischen ist ein häufiger Fehler:

• Event-ID 5136 ("Ein Verzeichnisdienstobjekt wurde geändert") wird für das groupPolicyContainer-AD-Objekt selbst ausgelöst, wenn die Unterkategorie "Verzeichnisdienständerungen überwachen" und eine Objekt-SACL beide vorhanden sind. Sicherheitsinhalte aus Splunks Detection-Research und MITREs eigener Erkennungsanleitung weisen beide darauf hin, gezielt die Attribute gPCFileSysPath, gPCMachineExtensionNames und versionNumber zu beobachten – ein Versionssprung ohne dazugehörige SYSVOL-Änderungsanfrage ist selbst ein beachtenswertes Signal.
• Event-ID 4739 ("Die Domänenrichtlinie wurde geändert") wird ausgelöst, wenn sich die effektive Kontorichtlinie – Sperrschwelle, Passwortrichtlinie, Kerberos-Richtlinie – tatsächlich ändert, unabhängig davon, ob die Änderung über Gruppenrichtlinien oder die lokale Sicherheitsrichtlinie erfolgte. Es ist das aussagekräftigere Ereignis für die Frage "hat sich die Sicherheits-Baseline selbst verschoben" – es verrät aber nicht, welches GPO oder welcher Administrator die Änderung vorgenommen hat; kombinieren Sie es mit 5136 zur Attribution.

# Splunk-Erkennungsskizze: Änderung des Default-Domain-Policy-Objekts
index=wineventlog EventCode=5136 ObjectDN="*CN=Policies,CN=System,DC=*"
| search ObjectDN="*{31B2F340-016D-11D2-945F-00C04FB984F9}*"
| table _time, SubjectUserName, AttributeLDAPDisplayName, AttributeValue, OperationType

PAM Shadow Principals: Befristeter Admin-Zugriff, den Standardabfragen übersehen

Der Mechanismus

Die Privileged-Access-Management-Funktion (PAM) von Windows Server, aufgebaut auf Microsoft Identity Manager, gewährt zeitlich begrenzten privilegierten Zugriff, ohne ein Konto jemals dauerhaft einer Gruppe wie Domain Admins hinzuzufügen. Microsofts eigene PAM-Dokumentation beschreibt den Mechanismus: Ein Shadow Principal – ein Objekt der Klasse msDS-ShadowPrincipal, das ausschließlich im Standardcontainer CN=Shadow Principal Configuration unter CN=Services im Configuration-NC eines Bastion-Forests erstellt wird – trägt ein Attribut msDS-ShadowPrincipalSid, das es auf die SID einer privilegierten Gruppe im Produktions-Forest abbildet (z. B. Domain Admins). Die Mitgliedschaft in diesem Shadow Principal wird mit einer Lebensdauer (TTL) über die AD-Funktion Expiring Links (Windows Server 2016+) gewährt: Der KDC begrenzt jedes ausgestellte Kerberos-Ticket auf die verbleibende TTL des Links, sodass der Zugriff tatsächlich abläuft, statt sich darauf zu verlassen, dass jemand daran denkt, ihn zu entfernen.

Die Überwachungslücke: Ablaufende Gruppenverknüpfungen werden als gewöhnliche member-Attributwerte mit einem TTL-Flag gespeichert, aber diese TTL ist nur für eine Abfrage sichtbar, die explizit das erweiterte Steuerelement LDAP_SERVER_LINK_TTL (OID 1.2.840.113556.1.4.2309) übergibt, wie die Forschung von DSInternals zur tatsächlichen Funktionsweise von Expiring Links dokumentiert. Eine routinemäßige "Wer ist Mitglied dieser Gruppe"-Abfrage, die dieses Steuerelement nicht übergibt, sieht eine normal aussehende Mitgliedschaft – kein Ablauf, kein offensichtliches Zeitlimit-Flag –, was bedeutet, dass ein Administrator, der Shadow-Principal-Gruppen mit generischem AD-Auditing-Tooling durchsucht, übersehen kann, dass der Zugriff per Design befristet ist, oder kurzlebige Mitgliedschaftsänderungen komplett verpasst, wenn das Scan-Intervall länger ist als die TTL.

Erkennung

Shadow-Principal-Gruppen sind weiterhin Objekte der Klasse Sicherheitsgruppe, daher erzeugen Mitgliedschaftsänderungen dieselben Standard-AD-Gruppenmitgliedschaftsereignisse wie jede andere Gruppe, unterschieden nach Gruppentyp: 4728 (Mitglied zu einer globalen Sicherheitsgruppe hinzugefügt), 4732 (domänenlokal), 4756 (universell). Filtern Sie diese Ereignisse gezielt nach Objekten innerhalb von CN=Shadow Principal Configuration,CN=Services,CN=<config-NC>, um PAM-Aktivierungen von der routinemäßigen Gruppenverwaltung zu isolieren.

# Aktuelle Shadow Principals und ihre zugeordnete SID im Produktions-Forest auflisten
Get-ADObject -SearchBase "CN=Shadow Principal Configuration,CN=Services,$((Get-ADRootDSE).configurationNamingContext)" `
  -Filter "objectClass -eq 'msDS-ShadowPrincipal'" `
  -Properties 'msDS-ShadowPrincipalSid', member |
  Select-Object Name, 'msDS-ShadowPrincipalSid', @{N='MemberCount';E={$_.member.Count}}

RODC-Credential-Caching, kurz gefasst

Read-Only Domain Controller (RODCs) werden gezielt für Standorte mit geringem Vertrauen eingesetzt – Zweigstellen, physisch exponierte Standorte – unter der Annahme, dass bei einer Kompromittierung der Explosionsradius auf die Kontopasswörter begrenzt ist, die er zwischenspeichern durfte. Diese Grenze wird durch zwei Gruppenmitgliedschaften erzwungen: die Allowed RODC Password Replication Group (standardmäßig leer – ein RODC speichert nichts zwischen, bis es explizit erlaubt wird) und die Denied RODC Password Replication Group, die den von Microsoft dokumentierten Attributen msDS-RevealOnDemandGroup und msDS-NeverRevealGroup entsprechen. Was tatsächlich zwischengespeichert wurde, ist über msDS-RevealedList sichtbar; wer sich über den RODC authentifiziert hat, steht in msDS-AuthenticatedToAccountlist.

Dies ist die einzige Überwachungslücke in diesem Beitrag, bei der die Behebung eine Policy-Frage ist und keine Monitoring-Lücke, von der die meisten Teams noch nie gehört haben – EtcSec hat den vollständigen Erkennungs- und Behebungspfad für privilegiertes RODC-Caching bereits behandelt, einschließlich der genauen Fehlkonfigurationen der Password Replication Policy, durch die ein Tier-0-Credential dorthin repliziert wird, wo es niemals landen sollte. Siehe RODC Privileged Credential Caching: Read-Only Domain Controller speichert Domain-Admin-Hashes für die ausführliche Analyse; die Zusammenfassung hier ist bewusst kurz gehalten, um sie nicht zu duplizieren.

Erkennung: Worauf tatsächlich zu achten ist

Keiner dieser Punkte erfordert eine neue Logging-Pipeline – sie brauchen SACLs auf Objekten, die ohne sie ausgeliefert werden, und jemanden, der Attribute abfragt, die Standard-AD-Health-Check-Skripte nicht anfassen.

Behebung

Schritt für Schritt

1. Display Specifiers. Setzen Sie eine SACL für "Alle Eigenschaften schreiben" (oder gezielter für die spezifischen Menü-/Eigenschaftsseiten-Attribute) auf CN=DisplaySpecifiers,CN=Configuration,DC=<forest-root> und dessen untergeordnete Objekte. Erfassen Sie jetzt eine Baseline der aktuellen Werte von adminContextMenu/adminPropertyPages, da bereits eine kompromittierte Backdoor vorhanden sein könnte.
2. Default Domain Policy. Wenden Sie eine SACL auf das groupPolicyContainer-Objekt der Default Domain Policy und auf deren SYSVOL-Ordner an (\\<domain>\SYSVOL\<domain>\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}). Alarmieren Sie bei jedem 5136/4739-Paar, das keinem nachverfolgten Änderungsticket entspricht.
3. PAM Shadow Principals. Wenn PAM/MIM nicht bewusst eingesetzt wird, bestätigen Sie, dass der Container CN=Shadow Principal Configuration leer ist und leer bleibt. Falls es eingesetzt wird, überprüfen Sie die Shadow-Principal-Mitgliedschaft in einem Rhythmus, der TTLs berücksichtigt, die kürzer sind als Ihr Prüfintervall – eine Verknüpfung, die zwischen zwei wöchentlichen Scans abläuft, taucht in keinem der beiden auf, es sei denn, Sie vergleichen 4728/4732/4756-Ereignisse statt reiner Momentaufnahmen der Mitgliedschaft.
4. RODC-Credential-Caching. Bestätigen Sie, dass die Allowed RODC Password Replication Group keine Tier-0-Prinzipale enthält, weder direkt noch über verschachtelte Gruppenmitgliedschaft – siehe den oben verlinkten eigenen Beitrag für die vollständige Anleitung zur Behebung, einschließlich der spezifischen Prüfungen der Replikationsrichtlinie.
5. Speisen Sie alle fünf oben genannten Event-IDs (5136, 4739, 4728, 4732, 4756) in das SIEM ein, das bereits Ihre Baseline der Active-Directory-Auditrichtlinie verarbeitet – dies ist eine Erweiterung des bestehenden Account-Management- und Policy-Change-Auditings, keine neue Log-Kategorie, und es passt natürlich zu bestehenden Prozessen wie GPO-Monitoring und Überprüfung von privilegiertem Zugriff.

Wie EtcSec das erkennt

Die Advanced- und Computers-Detektoren von EtcSec markieren alle vier dieser Überwachungslücken automatisch bei jedem AD-Audit: DISPLAY_SPECIFIER_CHANGES erfasst kürzliche Änderungen an Display-Specifier-Objekten, DEFAULT_DOMAIN_POLICY_CHANGED meldet Änderungen an der Sicherheits-Baseline der Domäne, EPHEMERAL_ADMINS_PAM deckt PAM-Shadow-Principal-Aktivität auf (einschließlich kurzlebiger Mitgliedschaften, die eine manuelle Momentaufnahme übersehen würde), und RODC_PRIVILEGED_CACHING – als Kritisch eingestuft – erfasst Tier-0-Credentials, die auf einen RODC repliziert wurden.