Leistungsstarke erweiterte LDAP-Steuerelemente: Anti-Remediation und unsichtbare Aufklärung in AD

In einer Zwei-DC-Laborumgebung demonstriert cloud.lab (Windows Server 2022, Gesamtstrukturfunktionsebene 2016). Nur für Labor- und autorisierte Forschungszwecke.

Fund 1 - FORCE_UPDATE: Gewinnende Replikationskonflikte durch einen einzelnen LDAP-Schreibvorgang

Die Idee in einfacher Sprache

Wenn Sie die AD-Replikation bereits genau kennen, können Sie weiterspringen. Andernfalls hier eine Analogie.

Stellen Sie sich ein Unternehmen mit zwei identischen Aktenschränken in zwei verschiedenen Büros vor. Dies sind die beiden Domänencontroller (DCs). Um synchron zu bleiben, wird jede Änderung, die an einem vorgenommen wird, auf den anderen kopiert. Dieses Kopieren ist die Replikation.

Was passiert, wenn zwei Personen dieselbe Datei zur gleichen Zeit in verschiedenen Büros bearbeiten, bevor die Kopie aktualisiert wird? Die Schränke sind uneinig, und AD braucht eine Regel, wer gewinnt:

1. Wer auch immer die höhere Versionsnummer hat, gewinnt. Jedes Feld merkt sich, wie oft es geändert wurde, und diese Anzahl ist seine "Version."
2. Nur wenn die Versionen gleich sind, schaut AD, wer zuletzt bearbeitet hat (Zeitstempel).
3. Wenn das auch unentschieden ist, wird das Unentschieden durch die ID des Schranks gebrochen.

Der Trick: normalerweise, wenn Sie ein Feld „bearbeiten“, indem Sie den genauen Wert, den es bereits hatte, zurückschreiben, zuckt AD mit den Schultern, sagt „nichts geändert“ und die Version bleibt bestehen. FORCE_UPDATE ist ein Flag, das sagt „zähle das trotzdem als echte Änderung.“ Also können Sie Bob in ein Feld schreiben, das bereits Bob sechs Mal sagt, und die Version steigt auf 6, obwohl sich der Wert nie geändert hat.

Ein Angreifer nimmt also eine bösartige Änderung an einem Feld vor, das er bearbeiten kann, führt mehrmals FORCE_UPDATE aus, um die Version auf 6 zu erhöhen, und wartet. Wenn ein Verteidiger es im anderen Cabinet (beliebiger anderer DC) behebt, ist es eine neue, spätere Bearbeitung, aber die erste Änderung dort, also Version 1. Die Cabinets synchronisieren sich, AD vergleicht 6 vs 1, und 6 gewinnt: Der Wert des Angreifers wird zurückgesetzt und die Korrektur des Verteidigers verschwindet stillschweigend. Der Angreifer hat eine Änderung erzwungen, die eine neuere, legitime übertrumpft.

Zwei ehrliche Hinweise: es funktioniert nur bei Feldern, die Sie bereits bearbeiten konnten (es ist Persistenz, keine Eskalation), und es ist nicht unsichtbar. Es hinterlässt ein Feld, dessen Version ohne Wertänderung gesprungen ist. Der wirklich neue Teil ist der „Eintrittspreis“: der berühmte DCShadow Angriff macht denselben „meine Version gewinnt“-Zug, benötigt aber fast gottgleiche Domänenrechte (vortäuschend ein DC zu sein); dies benötigt einen normalen Schreibzugriff und die Berechtigung für ein Feld.

Hintergrund: Wie AD entscheidet, wer gewinnt

Active Directory ist Multi-Master, was bedeutet, dass jeder beschreibbare DC Änderungen akzeptiert, die nach außen repliziert werden. Zwei DCs können angewiesen werden, das gleiche Attribut desselben Objekts zu ändern, bevor die Replikation abgeglichen wird. Für einen attributbezogenen Konflikt ist die Reihenfolge der Entscheidungsfindung:

1. Version - ein pro-Attribut-Zähler, der bei jedem ursprünglichen Schreibvorgang erhöht wird.
2. Zeitstempel - wird nur verwendet, wenn die Versionen gleich sind.
3. Server (DSA) GUID - wird nur verwendet, wenn die Version und beim Zeitstempel gleich sind.

Diese Metadaten sind pro Attribut und sichtbar über repadmin /showobjmeta oder msDS-replAttributeMetaData. Die entscheidende Eigenschaft: eine niedrigere Version verliert immer gegen eine höhere Version, egal wie viel neuer sie ist. Und ein MODIFY, das den vorhandenen Wert eines Attributs schreibt, ist normalerweise eine No-Op (AD erhöht die Version nicht). Normalerweise kann man die Version nicht erhöhen, indem man denselben Wert neu schreibt.

Die Steuerung: LDAP_SERVER_FORCE_UPDATE (1.2.840.113556.1.4.1974)

FORCE_UPDATE ist eine dokumentierte, durch den Rahmen harmlose Steuerung: Laut MS-ADTS weist sie den DC an, die Änderung zu verarbeiten, auch wenn sie sonst eine No-Op wäre („aktualisieren, auch wenn die neuen Daten identisch sind“). Die Java-Bibliothek ldaptive liefert eine ForceUpdateControl, die genau dies tut, ohne Angriffsrahmen. Der wichtige Nebeneffekt: Da der erzwungene Schreibvorgang als echte Ursprungs-Schreiboperation zählt, erhöht sie die Versionsnummer pro Attribut ohne Wertänderung. Das ist die Brücke. Der Versionsstempel gilt konventionell als für einen LDAP-Client unerreichbar (weshalb DCShadow ihn über das Replikationsprotokoll als bösartiger DC manipuliert); FORCE_UPDATE macht ihn von einer gewöhnlichen authentifizierten LDAP-MODIFY.

Die Technik

1. Wählen Sie ein Zielattribut das der Principal bereits schreiben kann (eine WriteProperty ACE).
2. Setzen Sie den bösartigen Wert auf DC-A.
3. Version aufblähen: sende N zusätzliche gleiche MODIFYs, jeweils mit FORCE_UPDATE, die jeweils die Version ohne sichtbare Änderung erhöhen.
4. Warten: Ein Verteidiger korrigiert den Wert, natürlich auf dem DC, mit dem er verbunden ist (DC-B). Seine einzelne Korrektur erhöht die Version um eins (auf aktuell+1). Solange der Angreifer darüber hinaus aufgeblasen hat, hat der Angreifer immer noch den höheren Rang. (Im Labor landete der Verteidiger bei Version 1, nur weil das Attribut zuvor nicht gesetzt war; im Allgemeinen muss der Angreifer nur die Version der Korrektur überbieten, was kostenlos ist.)
5. Konvergenz: AD vergleicht Versionen; die aufgeblähte Version des Angreifers übertrumpft die spätere, aber niedrigere Korrektur des Verteidigers. Der Wert des Angreifers gewinnt auf beiden DCs.

Der Verteidiger sieht, dass seine Änderung „nicht hält“: Er behebt es, es sieht behoben aus, und Minuten später wird es zurückgesetzt.

Privilegienmodell vs DCShadow: Der neue Teil

Die nicht offensichtliche Erkenntnis: LDAP kann den versionsstempel pro Attribut überhaupt erreichen. FORCE_UPDATE durchbricht stillschweigend die Annahme „Sie müssen das Replikationsprotokoll als DC sprechen“ von der Client-Oberfläche aus.

Demonstration (Zwei-DC-Labor)

Angreifer = svc-research, ein einfacher Domänenbenutzer mit der Delegation nur WP;Beschreibung (keine Replikationsrechte). Die Aktionen des Angreifers laufen unter seiner eigenen NTLM-Bindung; der Admin-Kontext wird ausschließlich für die Labor-Orchestrierung verwendet (Delegation, Replikationspause/-fortsetzung, Simulation des Verteidigers).

      Step 1 — low-priv writer bumps the version:
  baseline:                      description  version 1
  attacker no-op FORCE_UPDATE -> description  version 2   (no value change)

Step 2 — stage and win the conflict (replication paused):
  DC01:  description='ATTACKER-OWNED'            version 6  @ 19:58:34  (attacker, FORCE_UPDATE x3)
  DC-02: description='defender-remediation-LATER' version 1 @ 19:58:36  (defender, LATER, lower version)
  => CONVERGED: DC01 = DC-02 = 'ATTACKER-OWNED'   (defender's later fix reverted)
      

Die gesamte offensive Zutat ist ein MODIFY mit dem angehängten Kontrollmechanismus:

      var m = new ModifyRequest(dn, DirectoryAttributeOperation.Replace, "description", value);
m.Controls.Add(new DirectoryControl("1.2.840.113556.1.4.1974", null, true, true)); // FORCE_UPDATE, critical
connection.SendRequest(m);   // same-value write now bumps the per-attribute version
      

Auswirkungen, Umfang und Einschränkungen

Ein Anti-Remediation-/Persistenz Primitive: macht einen Angreiferwert hartnäckig gegen Bereinigung für jedes Attribut, das der Angreifer bereits schreiben kann, z. B. msDS-AllowedToActOnBehalfOfOtherIdentity (RBCD-Backdoor), servicePrincipalName (erneutes Festlegen eines Kerberoast-Ziels), scriptPath / gPLink (dauerhafter Halt).

• Geltungsbereich (getestet): linked Attribute (member / memberOf) sind nicht betroffen. Sie replizieren über Linked-Value Replication mit pro Wert Metadaten; ein No-Op FORCE_UPDATE zum erneuten Hinzufügen eines bestehenden Mitglieds gelingt, erhöht aber nicht die Versionsnummer des Verknüpfungswerts. Daher kann die Gruppenmitgliedschaft auf diese Weise nicht festgelegt werden, nur einzelne und mehrfach belegte nicht verknüpfte Attribute.
• Erfordert bestehenden Schreibzugriff (keine Eskalation), und der Verteidiger muss auf einem anderen DC (oder Vor-Konvergenz) korrigieren, damit der Konflikt besteht.
• Nicht unauffällig: es hinterlässt einen abnormalen Versionssprung ohne Wertänderung und einen Wert, der nach der Behebung „zurückkommt“ (harmj0y, Hunting With AD Replication Metadata, 2017).

Neuheit: Eine mehrfache Vorprüfung des Standes der Technik sowie eine authentifizierte GitHub-native Code-Suche (~1.000+ OID-Treffer) fanden keine Veröffentlichung dieses spezifischen Primitives. Fast jeder Treffer ist inert (SDK-Header, Sprachbindungen, Dissektoren, CTF-supportedControl-Dumps). Die nächsten Nachbarn sind DCShadow (gleiche Wirkung, DA/EA über einen bösartigen DC), LDAPAngel/RIFM (ein Tool zur Wiederherstellung von Forests, das sendet FORCE_UPDATE, aber nicht kritisch für seinen operativen FSMO/GC-Zweck, nicht zur Versionsaufblähung), ldaptives harmloses ForceUpdateControl und Tenables objektbezogenes "Conflicting Objects"-Rennen. Keines von ihnen verwendet diese Technik. Abwesenheit von Beweisen ist kein Beweis, aber der Konflikt-Sieg / die Anti-Remediation-Anwendung scheint unveröffentlicht.

Fund 2 - OBJECT_SECURITY DirSync: Aufzählung von Active Directory ohne Protokollspur

Die Idee in einfacher Sprache

Ein normaler Benutzer kann bereits die meisten Dinge im Active Directory nachschlagen: Namen, Gruppenmitgliedschaften, sogar die Berechtigungslisten (ACLs) für Objekte, die er lesen kann. Normalerweise werden diese Abfragen können vom Abfragelog des DC aufgezeichnet werden. DirSync ist eine Synchronisierungsfunktion, die für Tools wie Entra Connect gedacht ist, um Änderungen abzurufen. Eine seiner Optionen, OBJECT_SECURITY, erlaubt es einem normalen Benutzer, sie auszuführen, um alles aus Active Directory zu lesen, was er mit seinen Berechtigungen bereits lesen darf, aber da sie die Replikation verwendet anstelle des normalen Such-Pfads, zeichnet der DC nichts auf. Es sind dieselben Daten, die ein Benutzer bereits sammeln könnte, aber ohne Spur. Diese Methode bietet auch ein "Lesezeichen" (Cookie), um später nur die Änderungen in AD abzurufen.

Der Mechanismus

DirSync (LDAP_SERVER_DIRSYNC_OID, .841) hat zwei Modi:

• flags=0 verwendet vollständige Replikationssemantik und erfordert das Replikationsrecht Get-Changes. Dies ist der privilegierte, DCSync-nahe Pfad, und er wird über Ereignis 4662 protokolliert.
• OBJECT_SECURITY (Flag 0x1) ist der nicht privilegierte Pfad, der für normale Aufrufer dokumentiert ist: er erfordert keine Replikationsrechte und keine Berechtigungsänderung, nur Domain Users, und beschränkt die Ergebnisse auf Daten, die der Aufrufer bereits lesen kann. (Dies ist der Pfad, den Simon Décosse, simondotsh, 2022 dokumentiert hat. Mein Beitrag ist die validierte Erkennung Folge.)

Da OBJECT_SECURITY no Get-Changes right ausübt, erzeugt es no Event 4662replication code path rather than the search path, erzeugt es no Event 1644. Es liegt vollständig zwischen den beiden Host-Log-Quellen.

Das DirSync-Cookie, das es zurückgibt, ermöglicht es Ihnen auch, später erneut eine Verbindung herzustellen und nur die Änderungen seit dem letzten Mal abzurufen, sodass es auch als geräuscharmer Änderungsmonitor dient.

Warum es eine heimliche Gelegenheit ist

Es ist eine echte Gelegenheit für die Recon / Aufzählungs Phase:

• Kein spezieller Zugriff: Jedes kompromittierte Domänenkonto funktioniert. Es gibt kein Replikationsrecht anzufordern, keine Änderung an schema/searchFlags, nichts, was an sich verdächtig aussieht.
• Keine Spuren: Massenhafte Objekt- und Mitgliedschaftserfassung mit kostenlosem Protokollpfad sowie integrierter Delta-Synchronisierung für kontinuierliche Überwachung.

Dies ist verdeckt, kein neuer Zugriff. Es liefert einem Angreifer keine Daten, die er sonst nicht lesen könnte. Es beschränkt sich auf den effektiven Lesezugriff des Anrufers und gibt genau das zurück, was eine gewöhnliche LDAP-Suche liefern würde. Wichtig ist, dass es nicht umgeht das Tor für vertrauliche Attribute (searchFlags 0x80): Ein vertrauliches Attribut wird nur zurückgegeben, wenn der Anrufer tatsächlich berechtigt ist, es zu lesen (besitzt das CONTROL_ACCESS-Recht). Dieses Umgehen gehört zum anderen DirSync-Modus, flags=0, der Replikationssemantik verwendet, um vertrauliche Attribute an jeden mit dem Get-Changes-Recht weiterzugeben (Thema des begleitenden Beitrags über Erkennungsblindstellen). OBJECT_SECURITY kann auch keine Geheimnisse lesen (es ist kein DCSync, also kein Passwortmaterial). Was anders ist, ist rein die Umgehung: Ein gewöhnlicher SD_FLAGS-Durchlauf würde Ereignis 1644-Einträge hinterlassen, wo immer die LDAP-Abfrageprotokollierung aktiviert ist; die OBJECT_SECURITY-DirSync-Version hinterlässt in keinem der Protokolle Einträge. Der Wert für einen Angreifer ist eine geräuscharme Sammlung, die die LDAP-Suchtelemetrie, auf die Verteidiger angewiesen sind, außer Kraft setzt, weshalb es sich lohnt, davon zu wissen, obwohl es keine neuen Privilegien gewährt.

Erkennung und Abwehr

Beide Erkenntnisse haben ein gemeinsames Thema: die offensichtliche Erkennungs-Idee funktioniert nicht, und Host-Protokolle sind blinder, als Verteidiger annehmen. Alles Folgende wurde durch Ausführen der Techniken im Labor validiert.

FORCE_UPDATE (Feststellung 1)

• Primär - Replikations-Metadaten-Suche: Snapshot msDS-replAttributeMetaData (oder repadmin /showobjmeta) für sensible Attribute und Alarm, wenn eine pro-Attribut Version steigt, während der Wert-Hash unverändert bleibt. Im Labor hat dies den Angriff sauber erkannt (Beschreibung Version 28 → 29, Wert unverändert). Ein zweites Symptom: ein Wert, der nach der Behebung wieder auftaucht.
• Ereignis 1644 ist blind dafür: FORCE_UPDATE nutzt ein MODIFY; Ereignis 1644 protokolliert nur Suchvorgänge, daher erzeugt das Modify kein 1644-Ereignis. Eine Regel, die auf der .1974 OID in Abfrageprotokollen basiert, wird nie ausgelöst. Die Draht-Erkennung benötigt PCAP/ETW, und die Kontrolle erfordert ein signed bind (ein einfacher/Basic bind wird abgelehnt), was die Sichtbarkeit von cleartext-389 einschränkt.
• Härtung: Minimieren Sie WriteProperty bei sensiblen Attributen (die gesamte Voraussetzung); beheben Sie es auf demselben DC (wenn möglich) und überprüfen Sie anschließend die Version.

OBJECT_SECURITY DirSync (Feststellung 2)

• Host-Protokolle sehen es nicht: Kein 4662 (kein Get-Changes-Recht) und kein 1644 (Replikationspfad), daher gibt es keine Ereignisregel zum Schreiben; dies ist die blinde Stelle.
• Was tatsächlich funktioniert, ist begrenzt: Der realistische Fang ist network / ETW capture der DirSync-Steuerung im Netzwerk (vorbehaltlich LDAPS) plus Basislinie der DirSync-Nutzung und Alarmierung darüber von jeder Nicht-Sync-Quelle. Ein SACL-read-Canary ist kein zuverlässiger Rückhalt hier: Im Test löste ein ReadProperty-Audit-ACE das Ereignis 4662 nicht für eine gewöhnliche Attributlesung aus. Die Host-Leseprüfung von AD ist unzuverlässig, und die Replikationspfad-Lesung von DirSync ändert das nicht. (SACL-Canaries sind zuverlässig gegen das FORCE_UPDATE-write und gegen Replikationsrechte DirSync/DCSync, nur nicht gegen dieses heimliche Lesen.)
• Beachte auch den ADWS-Winkel: Die PowerShell AD-Cmdlets (Get-ADUser und Co.) sprechen nicht direkt LDAP. Stattdessen laufen sie über Active Directory Web Services (ADWS, TCP 9389), die die Abfrage lokal an den DC weiterleiten. Daher zeichnet Ereignis 1644 den Client als 127.0.0.1 (den DC selbst) auf, nicht die echte Adresse des Operators.
  • Warum das wichtig ist: Jede 1644-Regel muss 127.0.0.1 ausschließen. Da die internen Suchvorgänge des DC konstantes Loopback-Rauschen erzeugen, schließt derselbe Ausschluss auch alle Aktivitäten aus, die ein Angreifer über ADWS weiterleitet. Nur die Netzwerk-/ETW-Sichtbarkeit erkennt die wahre Quelle.

SACL-Canaries: Was sie sind und wo sie helfen

Mehrere der obigen Empfehlungen basieren auf SACL-Canaries, also sprechen wir darüber. Der Sicherheitsdeskriptor jedes AD-Objekts enthält zwei Zugriffskontrolllisten:

• DACL: entscheidet wer was tun kann (Berechtigungen)
• SACL: (System ACL) bestimmt was geprüft wird

Ein SACL-Audit-ACE besagt: „Wenn auf dieses Objekt oder Attribut zugegriffen wird, wird das Windows-Sicherheitsereignis Event 4662 ausgelöst.“ Ein canary ist eine absichtlich platzierte „Honeytoken-ähnliche“ Falle an einem wertvollen Objekt, das legitime Aktivitäten selten berühren, sodass jeder Zugriff es auslöst. Da es auf der Objektszugriffsebene (nicht der Kontroll- oder Protokollebene) ausgewertet wird, löst es unabhängig davon aus, welcher LDAP-Steuerung oder welches Transportprotokoll verwendet wurde.

Zum Bereitstellen:

• Aktivieren Sie Audit Directory Service Access (Erfolg) und fügen Sie einen Audit-ACE für den Zugriff hinzu, der Ihnen bei Ihren Kronjuwelen wichtig ist (z. B. das RBCD-Attribut msDS-AllowedToActOnBehalfOfOtherIdentity, privilegiertes Gruppenmitglied member, AdminSDHolder).

Der Haken: Stark bei Schreibvorgängen, schwach bei Lesevorgängen (validiert).

Diese beiden Befunde scheitern an unterschiedlichen Abwehrmechanismen, daher hilft der Canary ungleichmäßig:

• FORCE_UPDATE ist ein write: ein SACL write-Canary auf dem Zielattribut, das zuverlässig 4662 bei der böswilligen Änderung auslöst und die Replikations-Metadaten-Suche es trotzdem erkennt. (Ein SACL-Audit auf einem Kontroll-access right erkennt ebenso zuverlässig Replikationsrechte DirSync/DCSync über Get-Changes 4662.)
• OBJECT_SECURITY DirSync ist eine Lesevorgang: Die Leseüberwachung des AD-Hosts ist unzuverlässig. In meinen Tests hat ein ReadProperty-Audit-ACE nicht einmal für eine gewöhnliche Attributlesung das Ereignis 4662 ausgelöst. Daher erkennt ein SACL-Canary diese heimliche Leseoperation nicht zuverlässig. Stattdessen ist die Netzwerk-/ETW-Erfassung und das DirSync-Baselining zuständig.

Die einfache Version: Audit Canaries sind dein bester Alarm für die Schreib-seite und Missbrauch von Replikationsrechten, aber das heimliche Lesen braucht Augen auf der Leitung.

Werkzeuge

Ich habe zwei Proof-of-Concept-Tools für Red Team und Blue Team entwickelt, um LDAP Extended Controls zu erkunden und zu verteidigen: LDAP Extended Controls Toolkit.

Was jedes Tool macht

red/ — ldapctl (beleidigend)

Drei Unterbefehle, die jeweils eine validierte erweiterte Kontrolltechnik operationalisieren. Vollständige Flags, Berechtigungen und Ausgabeformate befinden sich in red/README.md.

blau/ — AdLdapDefense (defensiv)

Ein PowerShell-Modul mit fünf exportierten Funktionen, die vier Erkennungs-/Härtungsfunktionen abdecken. Parameter und Beispielausgabe befinden sich in blue/README.md. Erfordert PowerShell 5.1+ und RSAT (ActiveDirectory), auszuführen von einem Admin-Arbeitsplatz, der den DC erreichen kann.

Referenzen

• MS-ADTS, LDAP_SERVER_FORCE_UPDATE_OID. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/3c5e87db-4728-4f29-b164-01dd7d7391ea
• MS-ADTS / MS-DRSR. Replikationskonfliktauflösung (Version → Zeitstempel → DSA GUID); DirSync (LDAP_SERVER_DIRSYNC_OID) und Replikationssemantik
• DCShadow, Delpy & Le Toux, BlueHat IL 2018. https://www.dcshadow.com/
• harmj0y, Jagd mit Active Directory-Replikationsmetadaten (2017). https://blog.harmj0y.net/defense/hunting-with-active-directory-replication-metadata/
• simondotsh, Verstehen und Ausnutzen von DirSync (2022). https://simondotsh.com/infosec/2022/07/11/dirsync.html
• Tenable, Verwendung von widersprüchlichen Objekten in Active Directory zum Erlangen von Rechten (2024). https://medium.com/tenable-techblog/using-conflicting-objects-in-active-directory-to-gain-privileges-243ef6a27928