Modifica di AdminSDHolder – Come funziona e strategie di difesa

Cos'è la modifica di AdminSDHolder?

AdminSDHolder è un contenitore speciale in AD (CN=AdminSDHolder,CN=System,DC=...) che contiene un descrittore di sicurezza utilizzato per proteggere account e gruppi privilegiati. Il processo SDProp copia periodicamente quel descrittore agli oggetti il cui attributo adminCount è uguale a 1, assicurando che questi oggetti mantengano un ACL rinforzato e non siano indeboliti dall'ereditarietà normale dell'ACL. Un attaccante che riesce a modificare l'ACL di AdminSDHolder — o a creare un oggetto privilegiato con ACL manipolate o adminCount — può avere quella modifica applicata automaticamente a molti account privilegiati tramite SDProp.

Come funziona la modifica di AdminSDHolder?

Di seguito è illustrata una tipica catena di attacco che mostra come gli avversari abusano di AdminSDHolder e comportamenti correlati.

1. Ottenere una posizione iniziale

L'attaccante ottiene l'accesso nel dominio — ad esempio: un utente del dominio con privilegi ridotti, un account di servizio compromesso, un amministratore delegato (Operatori Account, Admin Schema, ecc.), o una credenziale di automazione configurata in modo errato. Potrebbero anche sfruttare un'interfaccia di gestione esposta o un host vulnerabile.

2. Riconoscere la protezione di AD e le ACL

Dalla posizione iniziale, l'attaccante enumera gli oggetti della directory per scoprire l'oggetto AdminSDHolder e la sua ACL, chi ha i permessi di Scrittura/Modifica su AdminSDHolder e CN=System, l'insieme di account con adminCount=1 e l'appartenenza a gruppi privilegiati. Strumenti: PowerShell Get-ACL, query LDAP, script ADSI.

3. Identificare un percorso di modifica

L'attaccante cerca un percorso che consenta di modificare gli ACL su AdminSDHolder (ad esempio, un utente delegato in modo errato o un gruppo troppo permissivo come gli Operatori di account o un account di servizio con diritti di scrittura DS). Gli account di automazione/servizio con elevati diritti di scrittura AD o gli account abbandonati con permessi residui sono obiettivi attraenti.

4. Modificare AdminSDHolder o ACL di oggetti protetti

Se permesso, l'attaccante modifica il descrittore di sicurezza AdminSDHolder per aggiungere un ACE che concede a un soggetto scelto diritti potenti (WriteDacl, FullControl, WriteProperty). In alternativa, possono cambiare gli ACL su un account protetto individuale o impostare adminCount=1 su un account backdoor. Metodi: Set-ACL, LDIF, ldapmodify, API native di Windows.

5. Attendere la propagazione di SDProp

SDProp viene eseguito periodicamente sui controller di dominio e propaga il descrittore AdminSDHolder a tutti gli oggetti dove adminCount=1. Una volta avvenuta la propagazione, l'ACE malevolo viene applicato agli account protetti — spesso agli Amministratori di Dominio — concedendo all'attaccante un accesso elevato persistente.

6. Utilizzare diritti elevati per persistere e spostarsi lateralmente

Con i nuovi ACL, l'attaccante può prendere il controllo degli account di amministratore di dominio (se consentito), leggere/modificare la configurazione sensibile (GPO, trust), creare principali di servizio aggiuntivi o account di amministratore ombra e mantenere la persistenza che sopravvive a semplici rimedi se i cambiamenti degli ACL non vengono rilevati.

✱ Variante: Modifica diretta dell'adminCount o SD di un singolo oggetto

Un attaccante con la capacità di modificare oggetti singoli può impostare adminCount=1 su un account scelto, rendendolo un bersaglio per SDProp, o sostituire direttamente il descrittore di sicurezza di un account di alto valore. Entrambe le varianti possono garantire un accesso privilegiato duraturo.

Diagramma del flusso di attacco

Esempio: Prospettiva dell'organizzazione

Un attaccante compromette un account di servizio utilizzato da uno strumento di backup legacy. Quell'account di servizio ha il permesso di scrittura delegato su un sottoalbero sotto CN=System. L'attaccante scrive un ACE che concede al loro account attaccante il controllo completo su AdminSDHolder, attende SDProp e poi utilizza i privilegi elevati risultanti per prendere il controllo degli account amministratore di dominio ed esportare i segreti di dominio.

Esempi (modelli del mondo reale)

Conseguenze della modifica di AdminSDHolder

Modificare il descrittore AdminSDHolder o gli oggetti protetti può avere effetti devastanti:

Conseguenze finanziarie

Il compromesso di account privilegiati può portare al furto di proprietà intellettuale, registrazioni finanziarie o PII dei clienti, seguito da multe normative, costi di risposta agli incidenti, spese legali e possibili richieste di riscatto.

Interruzione operativa

Un compromesso di dominio mina l'autenticazione e l'autorizzazione in tutto l'ambiente. I servizi possono essere disabilitati, AD potrebbe richiedere una attenta bonifica o ricostruzione, e le operazioni aziendali possono fermarsi durante il recupero.

Danno reputazionale

La prova di compromissione del dominio indica significativi fallimenti della sicurezza e può danneggiare la fiducia dei clienti, le relazioni con i partner e la reputazione pubblica.

Impatto Legale e Normativo

L'esposizione di dati regolamentati può innescare azioni di conformità, indagini e multe relative al GDPR, HIPAA o specifiche del settore.

Obiettivi comuni: Chi è a rischio?

Account protetti da AdminSDHolder

Domain Admins, Enterprise Admins, Schema Admins, Administrators

Account di servizio e principali non umani delegati

Account di servizio a cui sono stati concessi accidentalmente diritti di scrittura sui contenitori di sistema

Automazione legacy

Strumenti di backup, agenti di monitoraggio, script DevOps con capacità di scrittura AD

Grandi ambienti AD scarsamente auditati

Molti permessi delegati e account inattivi

Valutazione dei rischi

Come prevenire la modifica di AdminSDHolder

La prevenzione richiede di ridurre chi può modificare AdminSDHolder e migliorare il rilevamento & la governance.

Igiene di ACL & Delega

Limitare i permessi su CN=AdminSDHolder: solo un set minimo di principali ad alta privilegio fidati dovrebbero avere WriteDacl, WriteOwner o FullControl. Verificare i permessi delegati sotto CN=System e revocare i diritti eccessivi. Evitare di concedere la scrittura AD a account di servizio non privilegiati; utilizzare identità privilegiate dedicate e controllate per l'automazione.

Privileged Access Management (PAM)

Utilizzare l'accesso JIT/just-enough per le attività di amministrazione piuttosto che privilegi permanenti. Utilizzare account di servizio gestiti (gMSA) e certificati/segreti a breve termine per i servizi dove possibile.

Rafforzamento e Controllo degli Account

Rafforzare l'accesso di emergenza / gli account break-glass, disabilitare o rimuovere gli account di servizio obsoleti/inutilizzati e imporre la gestione del ciclo di vita.

Controllo delle modifiche & Separazione dei compiti

Richiedere l'approvazione di più persone per modifiche agli oggetti AD critici (AdminSDHolder, ACL radice del dominio). Registrare e rivedere i ticket di modifica legati ai cambiamenti delle ACL.

Controlli di base e di integrità

Mantenere una copia di base del descrittore di sicurezza di AdminSDHolder e confrontarlo periodicamente con l'oggetto attivo; allertare in caso di modifiche. Scansionare regolarmente gli oggetti con adminCount=1 e gli account inaspettati nei gruppi privilegiati.

Strategie di rilevamento, mitigazione e risposta

Detection

• Esegui audit e allerta su scritture su CN=AdminSDHolder: abilita l'auditing del servizio di directory (DS Access) per catturare le modifiche ad AdminSDHolder e generare allerte per modifiche agli attributi nTSecurityDescriptor o DACL.
• Monitorare i cambiamenti in adminCount: allerta quando adminCount è impostato a 1 per account insoliti.
• Ricevi un avviso quando vengono concessi nuovi ACE che danno agli utenti non amministratori diritti elevati su oggetti protetti.
• Fate attenzione ai picchi nelle modifiche agli account protetti (reimpostazioni password, modifiche ACL).
• Monitora le modifiche dell'appartenenza ai gruppi privilegiati e le aggiunte inaspettate.

Risposta

1. Rimuovi immediatamente le ACE dannose e ripristina AdminSDHolder all'ultimo descrittore di sicurezza noto come valido (o da un backup verificato).
2. Revoca l'accesso dell'attaccante: disabilita gli account, cambia le credenziali, revoca i certificati/segreti degli account di servizio che sono stati utilizzati.
3. Invalidare le sessioni di autenticazione dove possibile (forzare l'eliminazione del ticket Kerberos, imporre la riautenticazione).
4. Eseguire una valutazione dell'integrità del dominio e dell'impatto: elencare dove è stata propagata l'ACE dannosa, identificare gli account privilegiati compromessi e cercare artefatti laterali.
5. Eseguire il reset delle credenziali per gli account privilegiati interessati e ruotare i segreti dei servizi.
6. Caccia alla persistenza: verifica la creazione di principali servizi, attività pianificate, GPO con script maligni o voci di delega modificate.

Mitigazione

• Limita l'esposizione futura rimuovendo deleghe di scrittura non necessarie, rafforzando i controlli e implementando Privileged Access Management/JIT per le attività di amministrazione.
• Migliora l'audit e integra gli allarmi nei playbook di risposta agli incidenti per accelerare il rilevamento e il contenimento.

Come Netwrix può aiutare

Netwrix Threat Prevention aiuta a fermare l'abuso di AdminSDHolder rilevando e bloccando in tempo reale le modifiche non autorizzate agli oggetti AD critici. Crea un tracciato di audit completo e a prova di manomissione per le modifiche agli oggetti e agli attributi, e può automaticamente allertare o prevenire azioni rischiose come le modifiche a DACL e le modifiche ai gruppi privilegiati o alle GPO, riducendo il tempo di persistenza e il rischio di takeover del dominio. I team possono personalizzare le politiche per bloccare i contenitori sensibili e imporre una risposta immediata quando AdminSDHolder o account protetti vengono toccati, rafforzando la data security that starts with identity.

Impatto specifico del settore

Evoluzione degli attacchi & tendenze future

• L'automazione del riconoscimento delle ACL — gli aggressori stanno automatizzando le ricerche di contenitori di sistema scrivibili e permessi delegati in grandi patrimoni AD.
• La combinazione con altri attacchi AD — L'abuso di AdminSDHolder è combinato con catene di abuso Golden Ticket / DCSync / ACL per una persistenza robusta.
• L'esposizione della supply-chain e DevOps — le credenziali di automazione trapelate nei pipeline continuano a emergere come vettori per le modifiche delegate delle ACL.
• Meno azioni appariscenti, più furtività — gli aggressori preferiscono le manipolazioni di ACL/DACL perché si confondono con le attività amministrative legittime.

Statistiche chiave & Telemetria (controlli suggeriti)

• Percentuale di domini con permessi di scrittura non standard su CN=System o AdminSDHolder (misurazione dell'igiene).

• Numero di account con adminCount=1 e nessuna recente attività amministrativa legittima.

• Numero di account di servizio con privilegi di scrittura AD nell'ambiente.

Considerazioni Finali

La modifica di AdminSDHolder è una tecnica ad alto impatto e furtiva: attaccando il meccanismo che AD utilizza per proteggere gli account privilegiati, gli aggressori possono ottenere un'escalation di privilegi duratura e su scala di dominio che sopravvive a molti semplici passi di rimedio. Difendersi richiede una rigorosa governance delle ACL, delega basata sul principio del minimo privilegio, controlli di accesso privilegiati efficaci (Privileged Access Management/JIT), audit continui di AdminSDHolder e oggetti adminCount, e playbook di risposta esercitati per rimuovere rapidamente ACE maligni e ruotare le credenziali impattate.