Account AD disabilitati, scaduti, bloccati gruppi privilegiati: perché i diritti da admin persistono

Account AD disabilitati, scaduti, bloccati gruppi privilegiati è esattamente il punto cieco che questo articolo copre: un account il cui stesso stato — disabilitato, scaduto o bloccato — indica che non dovrebbe avere accesso, ma che è ancora formalmente membro di Domain Admins, Enterprise Admins o di un altro gruppo Tier 0. Un account admin disabilitato è quasi sempre un passaggio di offboarding dimenticato. Uno scaduto è un accesso concesso per un periodo limitato che nessuno ha rimosso dal gruppo una volta scaduto il termine. Uno bloccato può essere solo un ticket dell'helpdesk — oppure la coda di un attacco di password spraying ancora in corso. Questo articolo copre tutti e tre gli stati, oltre al loro stretto parente, il flag adminCount orfano, e spiega come individuarli e correggerli.

Account AD disabilitati, scaduti, bloccati gruppi privilegiati: i quattro stati

Ognuna di queste quattro condizioni ha una definizione precisa a livello di attributo, e ognuna ha un proprio modo di finire silenziosamente in un gruppo privilegiato senza che nessuno abbia deciso che dovesse accadere.

L'account disabilitato

Il bit ACCOUNTDISABLE (0x2) è impostato in userAccountControl; l'account non può accedere in modo interattivo. (Microsoft Learn: UserAccountControl property flags) Gli account disabilitati si accumulano perché le checklist di offboarding di solito si fermano a «disabilita l'account». Questo blocca l'accesso, ma non cambia nulla nell'appartenenza ai gruppi — il SID resta in Domain Admins. Qualsiasi strumento di mappatura dei percorsi di attacco che calcola «chi potrebbe diventare domain admin» — BloodHound, PingCastle o EtcSec inclusi — lo conta comunque, perché quei grafi sono costruiti sull'appartenenza ai gruppi, non su userAccountControl. Se l'account viene mai riabilitato — per errore, per un ticket ITSM in ritardo, o da un attaccante che ha ottenuto i diritti per invertire un solo bit — il suo vecchio privilegio torna immediatamente attivo, senza ulteriore lavoro necessario.

L'account scaduto

accountExpires contiene un valore diverso da 0 o dalla sentinella «non scade mai» 9223372036854775807, e quel valore (un FILETIME di Windows) è nel passato. (Microsoft Learn: Account-Expires attribute) Questo attributo è usato spesso per account di collaboratori esterni o di elevazione temporanea con una data di fine pianificata. Il KDC rifiuta di emettere un ticket-granting ticket oltre quella data, quindi l'account smette di funzionare per l'accesso interattivo o di rete — ma accountExpires non tocca nemmeno l'appartenenza ai gruppi. Se l'intento reale era «l'accesso da admin di questa persona termina in questa data», impostare una data di scadenza senza rimuovere anche l'appartenenza al gruppo blocca solo la porta d'ingresso.

L'account bloccato

lockoutTime è diverso da zero e la durata del blocco dell'account non è ancora trascorsa. Windows non imposta mai un bit UF_LOCKOUT nel valore memorizzato di userAccountControl; lo stato bloccato/sbloccato in tempo reale è esposto tramite l'attributo costruito msDS-User-Account-Control-Computed. (MS-ADLS: lockoutTime, MS-ADTS: msDS-User-Account-Control-Computed) A differenza della disabilitazione o della scadenza, il blocco non è una decisione amministrativa — è un effetto collaterale di tentativi di accesso falliti che raggiungono la policy di blocco account. Un account privilegiato può essere bloccato perché qualcuno ha digitato male la password, oppure perché è attualmente sotto attacco: una campagna di password spraying o brute-force che raggiunge un account privilegiato ed è sul punto di riuscire può produrre esattamente la stessa firma appena prima dell'autenticazione.

Il flag adminCount orfano

adminCount=1 contrassegna i membri dei gruppi protetti da AdminSDHolder, ma un account può conservarlo pur non appartenendo più ad alcun gruppo protetto — il caso inverso: non un privilegio vivo su un account morto, ma un marcatore morto rimasto da un privilegio già rimosso. Il meccanismo dietro a questo è il processo SDProp, che viene eseguito sul controller di dominio che detiene il ruolo PDC Emulator (di default circa una volta all'ora), scorre l'appartenenza dei gruppi protetti, imposta adminCount=1 su ogni membro, copia l'ACL di AdminSDHolder sull'oggetto, e disabilita l'ereditarietà delle ACL. (Microsoft Community Hub: Five common questions about AdminSDHolder and SDProp) Quando l'account viene successivamente rimosso dal gruppo protetto, SDProp smette semplicemente di toccarlo — non ripristina adminCount a 0 né ripristina l'ereditarietà. Il flag e l'ACL scollegata restano come un marcatore silenzioso, dall'aspetto permanente, di un privilegio che l'account non ha più.

Rilevamento

Attributi e query PowerShell

Le query dirette sull'appartenenza tramite il modulo PowerShell di AD fanno emergere rapidamente tutte e quattro le condizioni:

# Account disabilitati ancora in un gruppo privilegiato
Get-ADGroupMember -Identity "Domain Admins" -Recursive |
    Get-ADUser -Properties Enabled, userAccountControl |
    Where-Object { -not $_.Enabled }

# Account scaduti (accountExpires impostato e nel passato — 0 e la
# sentinella int64 massima significano entrambi "non scade mai")
Get-ADGroupMember -Identity "Domain Admins" -Recursive |
    Get-ADUser -Properties accountExpires |
    Where-Object {
        $_.accountExpires -gt 0 -and
        $_.accountExpires -lt 9223372036854775807 -and
        [datetime]::FromFileTime($_.accountExpires) -lt (Get-Date)
    }

# Account attualmente bloccati, incrociati con i gruppi privilegiati
Search-ADAccount -LockedOut -UsersOnly |
    Where-Object { (Get-ADPrincipalGroupMembership $_.SamAccountName).Name -contains "Domain Admins" }

# adminCount=1 senza appartenenza attuale a un gruppo protetto (flag orfano)
Get-ADUser -LDAPFilter "(adminCount=1)" -Properties adminCount, memberOf, Enabled

Filtro LDAP per strumenti a bind diretto

Per gli strumenti che non passano dal modulo PowerShell di AD, il controllo del bit di disabilitazione usa l'OID LDAP_MATCHING_RULE_BIT_AND su userAccountControl:

(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2))

Questo corrisponde alla semantica AND bit a bit propria di AD: la clausola è soddisfatta solo se il secondo bit (0x2, ACCOUNTDISABLE) è impostato sul valore memorizzato. (MS-ADTS: LDAP_MATCHING_RULE_BIT_AND)

Event ID di Windows da correlare

Questi eventi vengono registrati sui controller di dominio nell'ambito dell'audit Account Management — vedi il riferimento completo agli Event ID di monitoraggio di Active Directory per la configurazione di logging più ampia:

Fonti: Event ID 4725, Event ID 4740, Event ID 4767, Event ID 4738, Event ID 4728, Event ID 4756.

Remediation

Per gli account disabilitati e scaduti

1. Rendete il controllo ricorrente, non solo parte dell'offboarding. Un processo di uscita che disabilita l'account quando qualcuno lascia l'azienda non intercetterà una data di scadenza già trascorsa da sei mesi. Pianificate l'esecuzione regolare delle query sopra, o di una regola SIEM/EASM equivalente.
2. Collegate l'offboarding alla rimozione dal gruppo, non solo alla disabilitazione dell'account. Disabilitare blocca l'accesso; non revoca l'appartenenza al gruppo che i grafi dei percorsi di attacco, i diritti delegati e parte della logica di autorizzazione applicativa continuano a leggere. Quando l'accesso deve terminare, rimuovete esplicitamente l'account dal gruppo privilegiato.
3. Trattate le date di scadenza come un trigger per la revisione dell'appartenenza, non come un sostituto. Se un account è stato inserito in un gruppo privilegiato per un periodo limitato, impostate un promemoria corrispondente per rimuovere l'appartenenza entro la data di scadenza — non affidatevi solo ad accountExpires per rappresentare «questa persona non è più admin».

Per gli account privilegiati bloccati

Poiché sbloccare un account è un'operazione economica, rapida e delegabile — un permesso AD distinto dal reset della password — un account Tier 0 bloccato è a un solo sblocco dall'essere di nuovo pienamente utilizzabile. Instradate l'Event ID 4740 sui membri dei gruppi protetti verso un proprio percorso di alert, separato dal rumore di routine dei blocchi helpdesk, e confermate che lo sblocco (Event ID 4767) provenga da un amministratore atteso prima di considerare l'incidente chiuso.

Per i flag adminCount orfani

Per ogni account con adminCount=1 ma senza appartenenza attuale a un gruppo protetto, confermate che non sia davvero più privilegiato — controllate le appartenenze annidate, non solo quelle dirette, poiché una rimozione da un gruppo assegnato direttamente può comunque lasciare un privilegio indiretto in essere. Una volta confermata la pulizia, reimpostate adminCount e riattivate l'ereditarietà delle ACL invece di lasciare in essere il flag obsoleto e l'ACL scollegata; lasciarli offusca ogni futuro audit dei permessi su quell'oggetto.

Come EtcSec rileva tutto questo

EtcSec controlla tutte e quattro le condizioni a ogni audit di Active Directory: DISABLED_ACCOUNT_IN_ADMIN_GROUP e EXPIRED_ACCOUNT_IN_ADMIN_GROUP segnalano i membri di gruppi privilegiati il cui stesso stato dell'account avrebbe già dovuto bloccarne l'accesso, LOCKED_ACCOUNT_ADMIN fa emergere gli account privilegiati attualmente bloccati per lo scenario di password spraying descritto sopra, e ADMIN_COUNT_ORPHANED cattura il caso inverso — il marcatore residuo adminCount=1 rimasto dopo la rimozione di un'appartenenza protetta.