Controlli estesi LDAP avanzati: Anti-remediation e ricognizione invisibile in AD

Dimostrato in un laboratorio a due DC cloud.lab (Windows Server 2022, livello di funzionalità della foresta 2016). Solo in contesto di laboratorio e ricerca autorizzata.

Rilevamento 1 - FORCE_UPDATE: Conflitti di replica vincenti da una singola scrittura LDAP

L'idea in linguaggio semplice

Se conosci già bene la replica di AD, puoi saltare avanti. Altrimenti, ecco un’analogia.

Immagina un'azienda con due armadi archivio identici in due uffici diversi. Questi sono i due controller di dominio (DC). Per rimanere sincronizzati, ogni modifica fatta a uno viene copiata sull'altro. Questa copia è la replica.

Cosa succede se due persone modificano lo stesso file allo stesso tempo in uffici diversi, prima che la copia venga aggiornata? Gli armadi non sono d'accordo, e AD ha bisogno di una regola per decidere chi vince:

1. Vince chi ha il numero di versione più alto. Ogni campo ricorda quante volte è stato modificato e quel conteggio è la sua "versione."
2. Solo se le versioni sono in parità, AD guarda chi ha modificato più recentemente (timestamp).
3. Se anche questo è in parità, si decide in base all'ID dell'armadio.

Il trucco: normalmente, se “modifichi” un campo riscrivendo il valore esatto che aveva già, AD scrolla le spalle, dice “niente è cambiato” e la versione rimane invariata. FORCE_UPDATE è un flag che dice “considera comunque questo come un cambiamento reale.” Quindi puoi scrivere Bob su un campo che già dice Bob sei volte, e la versione sale a 6 anche se il valore non è mai cambiato.

Quindi un attaccante effettua una modifica dannosa a un campo che può modificare, lo colpisce con FORCE_UPDATE alcune volte per portare la versione a 6 e aspetta. Quando un difensore la corregge nell'altro cabinet (qualsiasi altro DC), è una modifica nuova e successiva, ma il primo cambiamento lì, quindi la versione è 1. I cabinet si sincronizzano, AD confronta 6 contro 1, e 6 vince: il valore dell'attaccante ritorna e la correzione del difensore scompare silenziosamente. L'attaccante ha forzato una modifica che supera una più nuova e legittima.

Due avvertenze oneste: funziona solo su campi che potresti già modificare (è persistenza, non escalation), e non è invisibile. Lascia un campo la cui versione è aumentata senza cambiamento di valore. La parte veramente nuova è il “prezzo d'ingresso”: il famoso attacco DCShadow fa la stessa mossa “la mia versione vince” ma necessita di poteri quasi divini di dominio (fingendo di essere un DC); questo richiede una scrittura ordinaria e il permesso su un campo.

Contesto: Come AD decide chi vince

Active Directory è multi-master, il che significa che ogni DC scrivibile accetta modifiche che si replicano verso l'esterno. A due DC può essere chiesto di modificare lo stesso attributo dello stesso oggetto prima che la replica riconcili. Per un conflitto per attributo l'ordine di spareggio è:

1. Versione - un contatore per attributo incrementato a ogni scrittura di origine.
2. Timestamp - usato solo se le versioni sono uguali.
3. Server (DSA) GUID - usato solo se la versione e hanno un pareggio nel timestamp.

Questi metadati sono per attributo, visibili tramite repadmin /showobjmeta o msDS-replAttributeMetaData. La proprietà cruciale: una versione inferiore perde sempre contro una versione superiore, indipendentemente da quanto sia più recente. E una MODIFY che scrive il valore esistente di un attributo è normalmente un'operazione nulla (AD non incrementa la versione). Normalmente non puoi aumentare la versione riscrivendo lo stesso valore.

Il controllo: LDAP_SERVER_FORCE_UPDATE (1.2.840.113556.1.4.1974)

FORCE_UPDATE è un controllo documentato e benigno per inquadramento: secondo MS-ADTS, dice al DC di processare la modifica anche quando sarebbe altrimenti un'operazione nulla (“aggiornare anche se i nuovi dati sono identici”). La libreria Java ldaptive fornisce un ForceUpdateControl che fa esattamente questo, senza inquadramento di attacco. L'effetto collaterale importante: poiché la scrittura forzata conta come una scrittura originaria reale, incrementa la versione per attributo senza cambiamento di valore. Questo è il ponte. Il timbro di versione è convenzionalmente considerato irraggiungibile da un client LDAP (motivo per cui DCShadow lo manipola tramite il protocollo di replica come DC rogue); FORCE_UPDATE lo rende raggiungibile da una MODIFICA LDAP.

La tecnica

1. Seleziona un attributo di destinazione che il principale può già scrivere (un WriteProperty ACE).
2. Imposta il valore dannoso su DC-A.
3. Gonfia la versione: invia N ulteriori MODIFY con lo stesso valore, ciascuno con FORCE_UPDATE, ognuno che incrementa la versione senza alcun cambiamento visibile.
4. Aspetta: Un difensore corregge il valore, naturalmente su qualsiasi DC a cui sia connesso (DC-B). La loro singola correzione incrementa la versione di uno (a corrente+1). Finché l'attaccante ha gonfiato sopra quello, l'attaccante ha ancora un rango superiore. (Nel laboratorio, il difensore è arrivato alla versione 1 solo perché l'attributo non era stato impostato precedentemente; in generale, l'attaccante deve solo superare la versione della correzione, che è gratuita.)
5. Convergenza: AD confronta le versioni; la versione gonfiata dell'attaccante supera la correzione successiva ma inferiore del difensore. Il valore dell'attaccante vince su entrambi i DC.

Il difensore vede che la sua modifica “non si mantiene”: la corregge, sembra sistemata e pochi minuti dopo torna indietro.

Modello di privilegi vs DCShadow: La parte nuova

L'intuizione non ovvia: LDAP può raggiungere il timbro di versione per attributo. FORCE_UPDATE rompe silenziosamente l'assunzione "devi parlare il protocollo di replica come un DC" dalla superficie del client.

Dimostrazione (laboratorio a due DC)

Attaccante = svc-research, un utente di dominio semplice delegato solo WP;descrizione (nessun diritto di replica). Le azioni dell'attaccante vengono eseguite sotto il proprio bind NTLM; il contesto amministrativo è usato esclusivamente per l'orchestrazione del laboratorio (delegazione, pausa/ripresa della replica, simulazione del difensore).

      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)
      

L'intero ingrediente offensivo è un MODIFY con il controllo allegato:

      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
      

Impatto, ambito e limitazioni

Un primitivo anti-rimediamento / persistenza: rendere un valore dell'attaccante ostinato contro la pulizia per qualsiasi attributo che l'attaccante può già scrivere, ad esempio msDS-AllowedToActOnBehalfOfOtherIdentity (backdoor RBCD), servicePrincipalName (ri-assegnare un obiettivo Kerberoast), scriptPath / gPLink (appiglio persistente).

• Confine dell'ambito (testato): linked attributi (member / memberOf) non sono interessati. Si replicano tramite Linked-Value Replication con metadati per valore; un FORCE_UPDATE no-op che riaggiunge un membro esistente ha successo ma non incrementa la versione del valore del collegamento. Quindi l'appartenenza al gruppo non può essere fissata in questo modo, solo attributi non collegati a valore singolo e multiplo.
• Richiede accesso in scrittura esistente (non escalation), e il difensore deve correggere su un DC diverso (o pre-convergenza) affinché il conflitto esista.
• Non furtivo: lascia un salto anomalo di versione senza cambiamento di valore, e un valore che “torna” dopo la rimedio (harmj0y, Hunting With AD Replication Metadata, 2017).

Novità: Una revisione multi-sweep dell'arte precedente più una ricerca autenticata di codice nativo GitHub (~1.000+ risultati OID) non ha trovato pubblicazioni di questo specifico primitivo. Quasi tutti i risultati sono inattivi (header SDK, binding linguistici, dissector, dump CTF supportedControl). I vicini più prossimi sono DCShadow (stesso effetto, DA/EA tramite un DC rogue), LDAPAngel/RIFM (uno strumento di recupero foresta che invia FORCE_UPDATE, ma non in modo critico per il suo scopo operativo FSMO/GC, non per gonfiare le versioni), il benigno ForceUpdateControl di ldaptive, e la corsa a livello oggetto "Conflicting Objects" di Tenable. Nessuno di loro usa questa tecnica. L'assenza di prove non è una prova, ma la vittoria nel conflitto / l'applicazione anti-rimedi sembra non pubblicata.

Rilevamento 2 - OBJECT_SECURITY DirSync: Enumerazione di Active Directory senza traccia di log

L'idea in linguaggio semplice

Un utente normale può già cercare la maggior parte delle cose in Active Directory: nomi, appartenenze a gruppi, persino le liste di permessi (ACL) sugli oggetti che può leggere. Normalmente, queste ricerche possono essere registrate dal registro delle query del DC. DirSync è una funzione di sincronizzazione pensata per strumenti come Entra Connect per estrarre le modifiche. Una delle sue opzioni, OBJECT_SECURITY, permette a un utente ordinario di eseguirla per leggere tutto da Active Directory che è già autorizzato a leggere con i propri permessi, ma poiché sfrutta la replicazione invece del normale percorso di ricerca, il DC non registra nulla. Sono gli stessi dati che un utente potrebbe già raccogliere, ma senza traccia. Questo metodo fornisce anche un "segnalibro" (cookie) per tornare più tardi solo per ciò che è cambiato in AD.

Il meccanismo

DirSync (LDAP_SERVER_DIRSYNC_OID, .841) ha due modalità:

• flags=0 utilizza la semantica completa della replica e richiede il diritto di replica Get-Changes. Questo è il percorso privilegiato, adiacente a DCSync, e viene registrato tramite Evento 4662.
• OBJECT_SECURITY (flag 0x1) è il percorso non privilegiato documentato per chiamanti ordinari: richiede nessun diritto di replica e nessuna modifica dei permessi, solo Domain Users, e limita i risultati ai dati che il chiamante può già leggere. (Questo è il percorso che Simon Décosse, simondotsh, ha documentato nel 2022. Il mio contributo è la conseguenza validata della rilevazione.)

Poiché OBJECT_SECURITY esercita no Get-Changes right, produce no Event 4662; e poiché DirSync utilizza il replication code path rather than the search path, produce no Event 1644. Cade completamente tra le due fonti di log host.

Il cookie DirSync che restituisce consente anche di riconnettersi in seguito e recuperare solo le modifiche dall'ultima volta, quindi funge anche da monitor di modifiche a basso rumore.

Perché è un'opportunità furtiva

È una vera opportunità per la fase di ricognizione / enumerazione:

• Nessun accesso speciale: Qualsiasi account di dominio compromesso funziona. Non c'è il diritto di replica da richiedere, nessuna modifica a schema/searchFlags, nulla che sembri sospetto di per sé.
• Nessuna traccia: Raccolta massiva di oggetti e appartenenze con tracciamento dei log gratuito, più una sincronizzazione delta integrata per il monitoraggio continuo.

Questo è stealth, non un nuovo accesso. Non fornisce all'attaccante dati che non potrebbe leggere altrimenti. Si limita all'accesso in lettura effettivo, restituendo esattamente ciò che una normale ricerca LDAP restituirebbe. Fondamentalmente, non bypassa la porta degli attributi riservati (searchFlags 0x80): un attributo riservato viene restituito solo se il chiamante ha effettivamente diritto di leggerlo (possiede il diritto CONTROL_ACCESS). Quel bypass appartiene all'altro modalità DirSync, flags=0, che usa la semantica di replica per divulgare attributi riservati a chiunque abbia il diritto Get-Changes (argomento del post complementare su punti ciechi di rilevamento). OBJECT_SECURITY non può nemmeno leggere i segreti (non è DCSync, quindi nessun materiale di password). Ciò che cambia è puramente l'evasione: una normale scansione SD_FLAGS lascierebbe registri Evento 1644 ovunque sia attivo il logging delle query LDAP; la versione DirSync di OBJECT_SECURITY non ne lascia alcuno in nessun registro. Il valore per un attaccante è una raccolta a basso rumore che sconfigge la telemetria di ricerca LDAP su cui si affidano i difensori, motivo per cui vale la pena conoscerla anche se non concede nuovi privilegi.

Rilevamento e difesa

Entrambe le scoperte condividono un tema: l'ovvia idea di rilevamento non funziona, e i log dell'host sono più ciechi di quanto gli difensori presumano. Tutto quanto segue è stato convalidato eseguendo le tecniche in laboratorio.

FORCE_UPDATE (Rilevamento 1)

• Primario - ricerca dei metadati di replica: Snapshot msDS-replAttributeMetaData (o repadmin /showobjmeta) per attributi sensibili e avviso quando la versione per attributo aumenta mentre l'hash del valore rimane invariato. In laboratorio questo ha segnalato chiaramente l'attacco (descrizione versione 28 → 29, valore invariato). Un secondo sintomo: un valore che riappare dopo la rimedio.
• L'evento 1644 non lo rileva: FORCE_UPDATE utilizza un MODIFY; l'evento 1644 registra solo ricerche, quindi la modifica non produce nessun evento 1644. Quindi, una regola basata sul .1974 OID nei log delle query non si attiva mai. Il rilevamento via cavo necessita di PCAP/ETW, e il controllo richiede un signed bind (un simple/Basic bind viene rifiutato), limitando la visibilità cleartext-389.
• Indurimento: Minimizza WriteProperty sugli attributi sensibili (l'intero prerequisito); correggi sullo stesso DC (quando possibile) e verifica la versione successivamente.

OBJECT_SECURITY DirSync (Rilevamento 2)

• I log dell'host non lo vedranno: Nessun 4662 (nessun diritto Get-Changes) e nessun 1644 (percorso di replica), quindi non c'è alcuna regola evento da scrivere; questo è il punto cieco.
• Ciò che funziona realmente è limitato: La cattura realistica è network / ETW capture del controllo DirSync sulla rete (soggetto a LDAPS) più baselining dell'uso di DirSync e l'invio di avvisi da qualsiasi fonte non di sincronizzazione. Un SACL read-canary non è affidabile come ultima risorsa qui: nei test, un ACE di audit ReadProperty non ha generato l'Evento 4662 per una lettura ordinaria dell'attributo. L'audit di lettura host di AD non è affidabile, e la lettura del percorso di replica di DirSync non cambia questo. (I canarini SACL sono affidabili contro la scrittura FORCE_UPDATE write e contro i diritti di replica DirSync/DCSync, ma non contro questa lettura furtiva.)
• Guarda anche l'angolo ADWS: I cmdlet PowerShell AD (Get-ADUser e simili) non parlano LDAP direttamente. Invece, passano attraverso Active Directory Web Services (ADWS, TCP 9389), che inoltra la query al DC localmente. Quindi, l'Evento 1644 registra il client come 127.0.0.1 (lo stesso DC), non l'indirizzo reale dell'operatore.
  • Perché è importante: Ogni regola 1644 deve escludere 127.0.0.1. Poiché le ricerche interne del DC generano un rumore di loopback costante, quella stessa esclusione elimina anche qualsiasi attività che un attaccante inoltra tramite ADWS. Solo la visibilità di rete/ETW vede la vera fonte.

Canarini SACL: cosa sono e dove aiutano

Diverse raccomandazioni sopra si basano sui canarini SACL, quindi parliamone. Il descrittore di sicurezza di ogni oggetto AD contiene due liste di controllo degli accessi:

• DACL: decide chi può fare cosa (permessi)
• SACL: (System ACL) decide cosa viene controllato

Un ACE di audit SACL dice “quando questo oggetto o attributo viene accesso, emetti l'Evento di Sicurezza di Windows Event 4662.” Un canary è un tripwire posizionato deliberatamente in stile “honeytoken” su un oggetto di alto valore che l'attività legittima tocca raramente, quindi qualsiasi accesso lo attiva. Poiché viene valutato al livello di accesso all'oggetto (non al livello di controllo o log), si attiva indipendentemente da quale controllo o trasporto LDAP sia stato utilizzato.

Per distribuire:

• Abilita Audit Directory Service Access (Success) e aggiungi un ACE di audit per l'accesso che ti interessa sui tuoi gioielli della corona (ad esempio l'attributo RBCD msDS-AllowedToActOnBehalfOfOtherIdentity, membro del gruppo privilegiato member, AdminSDHolder).

Il problema: forte per le scritture, debole per le letture (convalidato).

Questi due risultati falliscono difese diverse, quindi il canarino aiuta in modo non uniforme:

• FORCE_UPDATE è un write: un SACL write-canary sull'attributo target che attiva in modo affidabile l'evento 4662 sulla modifica dannosa e la ricerca dei metadati di replica lo rileva comunque. (Un audit SACL su un controllo di access right cattura inoltre in modo affidabile i diritti di replica DirSync/DCSync tramite il Get-Changes 4662.)
• OBJECT_SECURITY DirSync è una lettura: L'auditing della lettura dell'host di AD non è affidabile. Nei miei test, un ACE di auditing ReadProperty non ha generato l'evento 4662 nemmeno per una lettura ordinaria dell'attributo. Quindi un canarino SACL non cattura in modo affidabile questa lettura furtiva. Spetta invece alla cattura di rete/ETW e al baselining di DirSync.

La versione diretta: gli audit canaries sono il tuo miglior sistema di allarme per il lato scrittura e l'abuso dei diritti di replica, ma la furtiva lettura ha bisogno di occhi sul filo.

Strumenti

Ho creato due strumenti proof-of-concept per Red Team e Blue Team per esplorare e difendere i controlli estesi LDAP: LDAP Extended Controls Toolkit.

Cosa fa ogni strumento

red/ — ldapctl (offensivo)

Tre sottocomandi, ciascuno che opera una tecnica di controllo esteso validata. Le flag complete, i privilegi e i formati di output sono in red/README.md.

blu/ — AdLdapDefense (difensivo)

Un modulo PowerShell con cinque funzioni esportate che coprono quattro capacità di rilevamento/rafforzamento. I parametri e l'output di esempio sono in blue/README.md. Richiede PowerShell 5.1+ e RSAT (ActiveDirectory), eseguito da una workstation amministrativa che può raggiungere il DC.

Riferimenti

• 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. Risoluzione dei conflitti di replica (versione → timestamp → DSA GUID); DirSync (LDAP_SERVER_DIRSYNC_OID) e semantica della replica
• DCShadow, Delpy & Le Toux, BlueHat IL 2018. https://www.dcshadow.com/
• harmj0y, Caccia con i metadati di replica di Active Directory (2017). https://blog.harmj0y.net/defense/hunting-with-active-directory-replication-metadata/
• simondotsh, Comprendere e abusare di DirSync (2022). https://simondotsh.com/infosec/2022/07/11/dirsync.html
• Tenable, Utilizzo di oggetti in conflitto in Active Directory per ottenere privilegi (2024). https://medium.com/tenable-techblog/using-conflicting-objects-in-active-directory-to-gain-privileges-243ef6a27928