AdminSDHolder SDProp Backdoor Active Directory: il processo orario per un accesso privilegiato permanente

Cosa Sono AdminSDHolder e SDProp

AdminSDHolder SDProp backdoor Active Directory persistence è la tecnica che questa guida analizza in dettaglio: come gli attaccanti impiantano un accesso privilegiato permanente, come i difensori lo rilevano e come porvi rimedio prima che diventi un rischio permanente. AdminSDHolder è un oggetto contenitore che risiede in CN=AdminSDHolder,CN=System,DC=<dominio>,DC=<tld> in ogni dominio AD, e SDProp — il Security Descriptor Propagator — è il processo in background che copia la sua ACL su ogni oggetto che protegge, per impostazione predefinita una volta all'ora (Microsoft Learn — Appendix C: Protected Accounts and Groups in Active Directory).

SDProp viene eseguito ogni 60 minuti (per impostazione predefinita) sul controller di dominio che detiene il ruolo di PDC Emulator (PDCE). Confronta i permessi su AdminSDHolder con i permessi degli account e dei gruppi protetti del dominio — e dove differiscono, sovrascrive l'ACL dell'oggetto per farla corrispondere esattamente a quella di AdminSDHolder. L'intervallo è controllato dal valore DWORD AdminSDProtectFrequency sotto HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters sul PDCE, valido da 60 a 7200 secondi; la maggior parte degli ambienti non lo modifica mai e funziona semplicemente con il valore predefinito di 60 minuti.

I seguenti gruppi e account predefiniti sono protetti da AdminSDHolder/SDProp in ogni dominio AD:

Due effetti collaterali contraddistinguono ogni oggetto protetto: l'attributo adminCount viene impostato su 1, e l'ereditarietà dell'ACL dall'OU padre viene disabilitata permanentemente — finché qualcosa non la rimuove esplicitamente. Microsoft ha progettato SDProp per impedire che gli account privilegiati ereditino silenziosamente permessi più deboli se qualcuno li sposta all'interno della directory. È lo stesso meccanismo sottostante che gli attaccanti già sfruttano per l'abuso di ACL e il DCSync su singoli oggetti — questo backdoor sposta semplicemente l'abuso di un livello più in alto, sull'oggetto modello che alimenta contemporaneamente ogni account protetto.

AdminSDHolder SDProp Backdoor Active Directory, Passo per Passo

La tecnica non è nuova — Sean Metcalf l'ha documentata nel 2015 — e funziona ancora esattamente come descritto allora, perché sfrutta un meccanismo intenzionale e non un bug (AD Security — Sneaky Active Directory Persistence #15). A differenza di altri percorsi di attacco di Active Directory che concatenano più configurazioni errate per raggiungere Domain Admin, questo richiede una sola scrittura su un solo oggetto.

Passo 1 — Aggiungere una ACE Malevola ad AdminSDHolder

Un attaccante che può già scrivere su CN=AdminSDHolder,CN=System,DC=... — tipicamente perché è Domain Admin/Enterprise Admin, oppure ha ottenuto WriteDacl/GenericWrite su di esso tramite un precedente abuso di ACL — concede a un account a basso privilegio o usa-e-getta il Full Control (o GenericAll) direttamente sull'oggetto AdminSDHolder. Nell'articolo originale di Metcalf, a un normale account utente viene concesso il controllo completo sullo stesso AdminSDHolder. Nulla cambia riguardo a quell'account — non è ancora membro di alcun gruppo privilegiato, e resta insospettabile in una revisione di routine delle appartenenze ai gruppi.

Passo 2 — Attendere (o Forzare) la Propagazione da Parte di SDProp

Al ciclo successivo — fino a 60 minuti dopo — SDProp copia l'ACL di AdminSDHolder, ACE malevola inclusa, su ogni account e gruppo con adminCount=1: Domain Admins, Enterprise Admins, l'oggetto utente di ogni membro esistente, e qualsiasi account aggiunto successivamente a quei gruppi. L'account usa-e-getta non deve mai unirsi a Domain Admins; gli bastano diritti di modifica sugli oggetti che contano. Il ciclo può anche essere forzato immediatamente — da un amministratore che sta testando una modifica, o da un attaccante impaziente di confermare che il backdoor ha funzionato — tramite Ldp.exe, impostando l'attributo RunProtectAdminGroupsTask su 1 sul rootDSE (Microsoft Learn — Appendix C).

Passo 3 — Continuare a Usare Diritti che Non Compaiono Mai come Appartenenza a un Gruppo

Poiché la ACE risiede sull'oggetto modello anziché su un singolo account, ritorna ogni volta che SDProp viene eseguito — anche dopo che un difensore individua il permesso malevolo sull'oggetto utente di un Domain Admin e lo rimuove lì. A meno che la correzione non venga applicata allo stesso AdminSDHolder, il ciclo SDProp successivo la riapplica silenziosamente ovunque. Questo è ciò che rende questa tecnica una persistenza e non una semplice escalation di privilegi una tantum: le rotazioni delle password, la disattivazione dell'account o la rimozione dell'account dell'attaccante da Domain Admins non servono a nulla, perché quell'account non è mai stato membro — ha ottenuto i diritti tramite il modello di ACL. Questo è anche ciò che la distingue dal comune nesting pericoloso dei gruppi: il nesting si nasconde nell'appartenenza ai gruppi, questa tecnica si nasconde in una singola ACL che la maggior parte degli amministratori non pensa mai a controllare.

I difensori possono inventariare i target candidati e gli artefatti residui di questa tecnica con un'unica query LDAP:

Get-ADObject -LDAPFilter "(&(admincount=1)(|(objectcategory=person)(objectcategory=group)))" -Properties MemberOf,Created,Modified,AdminCount

Qualsiasi risultato il cui MemberOf non includa più un gruppo protetto, o i cui permessi effettivi sembrino non correlati al ruolo effettivo, merita ulteriori indagini prima di presumere che si tratti di debito di pulizia legittimo.

Rilevamento

Il meccanismo tocca un solo oggetto, quindi il rilevamento è ristretto ma affidabile — a condizione che la policy di controllo e la SACL corrette siano già in atto.

Due condizioni devono essere vere prima che l'evento 5136 si attivi: la sottocategoria Criteri di controllo avanzati → DS Access → Controllo modifiche servizio directory deve essere abilitata, e deve esistere una SACL che copra il descrittore di sicurezza (o "Write All Properties") sull'oggetto AdminSDHolder stesso. Nessuna delle due è attiva per impostazione predefinita nella maggior parte degli ambienti. La regola di rilevamento pubblicata da Elastic per questa tecnica specifica dipende da entrambe le condizioni per attivarsi — la sua query è event.code:5136 and host.os.type:"windows" and winlog.event_data.ObjectDN:CN=AdminSDHolder,CN=System*, mappata su MITRE ATT&CK T1098 (Account Manipulation) e T1078.002 (Valid Accounts: Domain Accounts), con severità alta (Elastic — AdminSDHolder Backdoor detection rule). La regola equivalente di Splunk Security Content conferma la stessa logica 5136/nTSecurityDescriptor e lo stesso prerequisito di SACL (Splunk Security Content — Windows AD AdminSDHolder ACL Modified).

Controllare l'ACL Direttamente

I log degli eventi aiutano solo una volta attivato l'auditing — una revisione puntuale dell'ACL funziona indipendentemente dalla policy di controllo ed è un primo controllo ragionevole in un ambiente che non ha mai abilitato l'auditing delle modifiche al servizio directory:

Get-Acl -Path "AD:\CN=AdminSDHolder,CN=System,DC=corp,DC=local" | Select-Object -ExpandProperty Access

Esaminare ogni voce del risultato confrontandola con la baseline nota nella sezione remediation più avanti. Qualsiasi elemento che non sia un principal predefinito noto merita di essere immediatamente escalato, indipendentemente dal fatto che il logging sia già attivo.

Remediation

Risposta Immediata

1. Controllare subito l'ACL di AdminSDHolder. Confrontare i suoi trustee con una baseline nota (Domain Admins, Enterprise Admins, Administrators, SYSTEM, e qualsiasi account di servizio esplicitamente delegato) e rimuovere qualsiasi elemento inatteso — come ha scritto Metcalf, "questi dovrebbero rimanere ai valori predefiniti".
2. Forzare SDProp a rieseguirsi immediatamente dopo la remediation, tramite Ldp.exe → RunProtectAdminGroupsTask=1 sul rootDSE, invece di attendere fino a 60 minuti per confermare che la correzione si sia propagata (Microsoft Learn — Appendix C).

Hardening Continuo

3. Abilitare l'auditing delle modifiche al servizio directory e impostare una SACL su AdminSDHolder affinché le future modifiche generino l'evento 5136, come descritto nella sezione rilevamento sopra.
4. Inventariare ogni oggetto con adminCount=1 con la query LDAP mostrata in precedenza e riconciliarlo con l'attuale appartenenza ai gruppi protetti. Per gli account confermati come non più appartenenti a un gruppo protetto, azzerare adminCount e riabilitare l'ereditarietà solo dopo aver confermato che l'appartenenza al gruppo è già scomparsa — azzerarlo per primo permetterebbe a SDProp di annullare la correzione alla sua esecuzione successiva. Questi account orfani costituiscono lo stesso debito di pulizia trattato in Account Obsoleti e Sovraprivilegiati.
5. Limitare chi può scrivere su AdminSDHolder. Per impostazione predefinita solo Domain Admins, Enterprise Admins e Administrators possono modificarlo o prenderne possesso — mantenere questa condizione. Qualsiasi GenericWrite o WriteDacl delegato sul container System, o su AdminSDHolder in particolare, è un rischio permanente e va trattato come Tier 0.

Come EtcSec Rileva Questo

L'audit Active Directory di EtcSec verifica ADMIN_SD_HOLDER_MODIFIED per trustee inattesi o diritti pericolosi (Full Control, GenericAll, WriteDacl, WriteOwner) sull'ACL dell'oggetto AdminSDHolder, ADMINSDHOLDER_BACKDOOR per il pattern specifico di un principal non privilegiato con quei diritti, e ADMIN_COUNT_ORPHANED per gli account ancora contrassegnati adminCount=1 dopo aver lasciato un gruppo protetto — debito di pulizia che sia nasconde backdoor genuini sia gonfia il conteggio degli account privilegiati. Questo backdoor raramente compare da solo: si trova spesso insieme a una deriva più ampia degli accessi privilegiati, quindi entrambi i controlli meritano di essere eseguiti insieme come parte di un audit di routine anziché trattati come riscontri isolati.