La query deriva accessi privilegiati active directory indica un problema concreto: lo scarto tra il modello di privilegi che l’organizzazione pensa di avere e i diritti effettivi che esistono davvero nella directory oggi. La deriva può iniziare con un’appartenenza temporanea a un gruppo, una delega helpdesk per sbloccare un’operazione, un account di servizio aggiunto durante un incidente o una ACL che nessuno rivede dopo la fine di un progetto. Nel tempo, questi piccoli cambiamenti possono ricreare percorsi di attacco che un audit precedente aveva già rimosso.
Questo articolo è limitato ad Active Directory on-premises. Non presenta Microsoft Entra Privileged Identity Management come controllo sostitutivo e non riduce la deriva ai soli account amministrativi obsoleti. In AD, l’accesso privilegiato può riapparire tramite gruppi annidati, ACL di directory, diritti di replica, modifiche ad AdminSDHolder, riutilizzo dell’account Administrator integrato, account di servizio ed eccezioni di emergenza. La rilevazione richiede correlazione tra baseline attesa, diritti effettivi correnti, cambiamenti recenti e telemetria di sicurezza.
Deriva accessi privilegiati active directory: cosa copre
La deriva degli accessi privilegiati è l’accumulo di diritti amministrativi effettivi che non corrispondono più al modello previsto per il dominio. Una revisione degli accessi pulita può concludere che solo gruppi amministrativi nominati controllano gli asset Tier 0. Poche settimane dopo, un operatore può aggiungere un membro temporaneo a Domain Admins, annidare un gruppo di supporto in un gruppo privilegiato, delegare WriteDACL su una OU o concedere diritti di replica a un account di migrazione. Se la modifica non viene rimossa e rimisurata, il risultato della revisione diventa obsoleto.
Il punto importante è che il privilegio in Active Directory non è memorizzato in un unico posto. L’appartenenza ai gruppi è il livello visibile, ma è solo una parte del piano di controllo. Un principal può diventare pericoloso perché è membro diretto di un gruppo privilegiato, perché ci arriva tramite annidamento, perché può modificare l’appartenenza del gruppo, perché può riscrivere il security descriptor di un oggetto, perché ha diritti di replica compatibili con DCSync o perché può influenzare account protetti da AdminSDHolder. Per questo un articolo sugli account obsoleti e sovraprivilegiati è utile, ma non basta per coprire tutta la deriva degli accessi privilegiati.
Una revisione della deriva deve quindi rispondere a una domanda precisa: chi può influenzare identità privilegiate, gruppi privilegiati, domain controller, permessi sulla root del dominio, Group Policy, servizi certificati e altre superfici di controllo Tier 0 in questo momento? La risposta deve includere amministratori diretti, amministratori indiretti, operatori delegati, account di servizio e principal con percorsi ACL pericolosi.
Perché le revisioni annuali non vedono la deriva AD
Le revisioni annuali o trimestrali sono istantanee. Sono utili per la governance, ma deboli nel rilevare una directory che cambia ogni settimana. Le modifiche di appartenenza ai gruppi Active Directory sono auditabili, e Microsoft documenta eventi di gestione dei gruppi di sicurezza, inclusi eventi di membri aggiunti e rimossi in gruppi globali, locali e universali. Anche le modifiche agli oggetti di directory possono essere auditate tramite eventi di modifica del directory service, e l’accesso agli oggetti può esporre operazioni sensibili quando auditing e SACL sono configurati. Questi log mostrano che AD non è statico.
Il problema pratico è che molte revisioni lavorano ancora con esportazioni. Un foglio di calcolo dei Domain Admins del mese scorso non mostra che ieri è stato aggiunto un gruppo annidato. Una lista di utenti privilegiati non mostra che un gruppo helpdesk può modificare l’appartenenza di un gruppo admin. Una revisione manuale degli account disabilitati non mostra che un account di servizio conserva ancora DS-Replication-Get-Changes e DS-Replication-Get-Changes-All sul naming context del dominio.
Per questo contano anche gli audit ricorrenti di Active Directory. Se gli stessi controlli vengono eseguiti una volta l’anno, l’organizzazione sa cosa era sbagliato alla data dell’audit. Se i controlli vengono rieseguiti dopo modifiche e bonifiche, l’organizzazione può vedere se il modello privilegiato resta pulito o torna a derivare.
Come nasce la deriva degli accessi privilegiati
L’appartenenza temporanea diventa permanente
Incident response, migrazioni, configurazione dei backup e supporto applicativo urgente possono richiedere diritti elevati. Il rischio non è l’eccezione in sé; il rischio è un’eccezione senza owner, senza scadenza e senza rivalidazione. Active Directory continuerà a rispettare l’appartenenza finché qualcuno non la rimuove.
L’annidamento dei gruppi nasconde il privilegio effettivo
Un gruppo può sembrare innocuo isolatamente e diventare privilegiato quando viene annidato in Account Operators, Backup Operators, Domain Admins, Enterprise Admins o un altro gruppo sensibile. L’accesso annidato rende anche più difficili le revisioni, perché i membri effettivi non sono visibili dalla prima schermata del gruppo. Un gruppo privilegiato deve essere rivisto per appartenenza effettiva, non solo per membri diretti.
La deriva ACL crea percorsi di controllo
L’autorizzazione Active Directory dipende molto dalle discretionary access control lists. GenericAll, WriteDACL, WriteOwner, AddMember, Self-Membership e diritti simili possono trasformare un principal non amministratore in un amministratore pratico su oggetti specifici. In una revisione dei percorsi di attacco, la domanda non è solo chi è in Domain Admins. È chi può cambiare un principal, un gruppo, una GPO, un computer, una OU o una ACL che porta al Tier 0. La stessa logica vale quando si rivedono abuso ACL e percorsi DCSync.
I diritti di replica ampliano l’esposizione delle credenziali
MITRE documenta DCSync in OS Credential Dumping perché un avversario con diritti sufficienti di replica della directory può imitare il comportamento di replica di un domain controller per ottenere materiale di credenziali. I difensori devono rivedere i principal con DS-Replication-Get-Changes e DS-Replication-Get-Changes-All, oltre a qualsiasi diritto di replica specifico dell’ambiente applicabile ai segreti protetti.
Le modifiche ad AdminSDHolder sono sensibili per la persistenza
Le Microsoft Open Specifications descrivono AdminSDHolder come l’oggetto usato dal sistema per gestire i security descriptor degli oggetti amministrativi protetti. Se il security descriptor di AdminSDHolder viene modificato, l’impatto può propagarsi ad account e gruppi protetti tramite il meccanismo SDProp. Questo rende AdminSDHolder un oggetto sensibile per la persistenza, non un normale contenitore amministrativo.
Account di servizio e account integrato aggiungono rischio duraturo
Un account di servizio in un gruppo privilegiato può essere più difficile da ruotare, più difficile da collegare a un owner umano e più facile da dimenticare. L’account Administrator integrato con RID 500 non dovrebbe diventare l’identità amministrativa quotidiana. Se è stato usato di recente, trattatelo come un’eccezione da spiegare, non come prova autonoma di compromissione.
Percorsi di attacco creati dalla deriva dei privilegi
La deriva dei privilegi conta perché crea percorsi, non solo liste di accesso disordinate. Un account admin extra è un target di credenziali. Un gruppo di supporto annidato può diventare una rotta nascosta verso Domain Admins. Un permesso WriteDACL può permettere a un principal di concedersi diritti più forti. Un permesso WriteOwner può permettere a un principal di prendere ownership e poi cambiare la ACL. Diritti AddMember su un gruppo privilegiato possono bastare per aggiungere un account controllato a quel gruppo.
La deriva compatibile con DCSync è particolarmente sensibile. Se un principal che non è un domain controller ha diritti di replica che permettono comportamento DCSync, i reset password dei singoli utenti non bastano. L’organizzazione deve rimuovere i diritti di replica, investigare se materiale di credenziali è stato esposto e ruotare i segreti interessati secondo lo scope di incident response.
Delegation e infrastruttura di identità possono ampliare l’effetto. Un account computer privilegiato, un account di servizio sovradelegato o un percorso di delega Kerberos mal gestito può collegare la deriva dei privilegi al lateral movement. Per questo l’analisi della deriva deve essere correlata con i rischi di delega Kerberos, la gestione delle password amministratore locali come Windows LAPS e i percorsi di attacco AD CS quando i servizi certificati sono nello scope.
| Superficie di deriva | Domanda pratica | Evidenza di validazione |
|---|---|---|
| Gruppi privilegiati | Chi è membro diretto o annidato effettivo? | Owner approvato, ticket, scadenza e appartenenza effettiva corrente |
| ACL di directory | Chi può modificare oggetti privilegiati o i loro security descriptor? | Diff ACL, revisione del trustee, fonte di ereditarietà e business owner |
| Diritti di replica | Chi può eseguire operazioni di replica del dominio? | Solo DC attesi e principal di replica approvati |
| AdminSDHolder | Chi può influenzare oggetti amministrativi protetti? | Security descriptor atteso e nessuna ACE non autorizzata |
Rilevazione
Nessun singolo evento Windows prova la deriva degli accessi privilegiati. La rilevazione deve combinare una baseline degli accessi privilegiati attesi, lo stato corrente della directory, l’analisi delle ACL e la telemetria delle modifiche recenti.
Inventariare prima il privilegio effettivo
Iniziate con un inventario effettivo degli accessi privilegiati. Enumerate appartenenze dirette e annidate dei gruppi privilegiati. Includete gruppi privilegiati integrati, gruppi amministrativi del dominio, gruppi che amministrano domain controller, gruppi operativi backup o server che possono incidere su asset Tier 0 e qualsiasi gruppo admin specifico dell’organizzazione. Confrontate il risultato con una baseline approvata con owner nominati.
Rivedere i permessi fuori dall’appartenenza ai gruppi
Poi ispezionate i permessi, non solo le appartenenze. Rivedete ACL sulla root del dominio, AdminSDHolder, domain controller, gruppi privilegiati, utenti privilegiati, OU sensibili, GPO e account di servizio ad alto impatto. Prestate attenzione ai diritti che permettono a un principal di modificare appartenenze o security descriptor, inclusi GenericAll, WriteDACL, WriteOwner, AddMember, Self-Membership, Write Property e Control Access. Per la replica, rivedete DS-Replication-Get-Changes e DS-Replication-Get-Changes-All sul naming context del dominio.
Correlare gli eventi senza sovrainterpretare
Microsoft documenta la categoria Audit Security Group Management e i singoli eventi usati per aggiunte e rimozioni di membri. Gli eventi 4728 e 4729 coprono modifiche di membri nei gruppi globali di sicurezza, 4732 e 4733 coprono gruppi locali di sicurezza, e 4756 e 4757 coprono gruppi universali di sicurezza. Questi eventi sono utili quando il gruppo privilegiato o annidato è nello scope.
Per le modifiche di directory, l’evento 5136 registra modifiche agli oggetti del directory service quando l’audit corretto è abilitato. Può aiutare a identificare attributi modificati come appartenenza a gruppi o security descriptor, a seconda di ciò che viene auditato. L’evento 4662 può aiutare con accesso auditato agli oggetti e operazioni sensibili di directory, inclusi contesti Write Property, Control Access, WRITE_DAC e WRITE_OWNER quando le SACL sono configurate. Trattate questi eventi come evidenza di correlazione, non come verdetti autonomi.
Infine, collegate la telemetria all’intenzione. Una modifica a un gruppo privilegiato eseguita tramite richiesta di accesso documentata può essere attesa. La stessa modifica fuori da una finestra di manutenzione, eseguita da un operatore insolito o seguita da nuova attività di autenticazione sui domain controller merita investigazione. Per una mappatura più ampia, usate una guida di monitoraggio come eventi chiave di sicurezza AD per mantenere espliciti nomi, scope e limiti degli eventi.
Remediation e bonifica operativa
La bonifica deve rimuovere il percorso e correggere il processo che gli ha permesso di tornare.
Rimuovere percorsi di gruppo e documentare eccezioni
Per la deriva di appartenenza ai gruppi, rimuovete membri diretti non approvati e sciogliete annidamenti pericolosi. Fatelo sull’appartenenza effettiva, non solo su quella diretta. Se un gruppo annidato resta necessario, documentate owner, scopo, percorso di approvazione e cadenza di revisione. Evitate di lasciare principal ampi come Authenticated Users o gruppi operativi troppo grandi dentro gruppi privilegiati.
Rimuovere ACL pericolose con cautela
Per la deriva ACL, non cancellate permessi alla cieca. Identificate prima oggetto, trustee, diritto, fonte di ereditarietà e business owner. Poi rimuovete diritti che creano controllo amministrativo senza scopo documentato. Prioritizzate GenericAll, WriteDACL, WriteOwner, AddMember, Self-Membership, diritti Write Property eccessivi e diritti Control Access su oggetti Tier 0. Dopo la rimozione, verificate che la delega operativa funzioni ancora per attività legittime.
Revocare percorsi di replica e persistenza
Per principal compatibili con DCSync, rimuovete diritti di replica da qualsiasi account o gruppo non esplicitamente approvato per quel ruolo. I domain controller hanno bisogno di replica. Alcuni scenari di identità, migrazione o backup possono richiedere diritti strettamente delimitati, ma queste eccezioni devono essere rare, avere un owner, essere monitorate e riviste. Se esisteva capacità DCSync sospetta, trattate la pulizia come una questione di esposizione di credenziali, non solo come pulizia ACL.
Per la deriva di AdminSDHolder, confrontate il security descriptor con la baseline attesa e investigate come è cambiato. Poiché AdminSDHolder influenza oggetti amministrativi protetti, trattate permessi inattesi come sensibili per la persistenza. Rimuovete voci non autorizzate e poi validate i permessi degli account protetti dopo che SDProp ha avuto tempo di riapplicare il descriptor previsto.
Ridurre l’esposizione permanente delle identità privilegiate
Per le identità privilegiate, riducete lo standing access. Separate gli account utente quotidiani dagli account amministrativi. Rivedete gli account di servizio privilegiati e rimuoveteli dai gruppi admin dove possibile. Riservate l’account Administrator RID 500 a scenari break-glass o di emergenza e investigate l’uso routinario recente. Considerate il gruppo Protected Users per account umani privilegiati adatti, ma testate prima la compatibilità perché Microsoft documenta cambiamenti e limitazioni del comportamento di autenticazione per i membri.
Per la deriva di processo, richiedete scadenza e ownership per le eccezioni. Un AD pulito dopo la bonifica tornerà a derivare se l’accesso temporaneo non ha un meccanismo di rimozione. Il controllo deve rispondere a chi ha approvato il privilegio, perché esiste, quando scade e quale evidenza prova che è stato rimosso.
Validazione dopo la pulizia
La validazione è dove molti sforzi di bonifica falliscono. Rimuovere un membro visibile da Domain Admins non basta se rimane un gruppo annidato, una ACL o un diritto di replica.
Ricalcolare l’appartenenza effettiva
Dopo la pulizia, rieseguite l’inventario dell’appartenenza effettiva. Confermate che i gruppi privilegiati abbiano solo membri diretti e indiretti approvati. Confermate che nessun principal ampio sia presente in un gruppo privilegiato. Confermate che account privilegiati creati di recente e modifiche recenti a gruppi privilegiati corrispondano a ticket o record di incidente approvati.
Ricontrollare ACL e percorsi di replica
Poi rieseguite la revisione ACL. Confermate che GenericAll, WriteDACL, WriteOwner, AddMember, Self-Membership e diritti di replica rimossi non siano riapparsi tramite ereditarietà, annidamento di gruppi o processi di template. Confermate che AdminSDHolder non contenga più voci inattese e che gli oggetti protetti riflettano il security descriptor previsto.
Validare la telemetria dopo la bonifica
Infine, validate la telemetria. Cercate nuove modifiche di appartenenza ai gruppi dopo la pulizia. Rivedete modifiche agli oggetti di directory su oggetti sensibili. Confermate che ogni eccezione consentita abbia owner e data di revisione. L’obiettivo non è provare che nessuna modifica futura possa avvenire. L’obiettivo è provare che i diritti effettivi correnti corrispondano alla baseline e che le modifiche future saranno visibili.
Se state costruendo un programma di audit più ampio, allineate questa validazione con come auditare la sicurezza di Active Directory per misurare la deriva privilegiata insieme ad autenticazione, delega, AD CS, GPO, password e controlli di monitoraggio.
Come EtcSec rileva la deriva degli accessi privilegiati
EtcSec identifica e rimisura condizioni di deriva degli accessi privilegiati nella postura AD corrente. I controlli rilevanti del catalogo coprono account privilegiati, gruppi, ACL, diritti di replica e AdminSDHolder invece di trattare la deriva come un unico sintomo.
Per deriva di account e utilizzo, EtcSec controlla condizioni come PRIVILEGED_ACCOUNT_STALE, ADMIN_NATIVE_RECENT_LOGON, EXCESSIVE_PRIVILEGED_ACCOUNTS e RECENT_PRIVILEGED_CREATION. Soglie come 90 giorni per account privilegiati inattivi, 30 giorni per uso recente dell’account Administrator integrato, 10 giorni per account privilegiati creati di recente o 7 giorni per modifiche recenti a gruppi privilegiati sono soglie di policy del catalogo. Non devono essere descritte come standard Microsoft.
Per deriva dei gruppi, EtcSec controlla GROUP_EVERYONE_IN_PRIVILEGED, GROUP_AUTHENTICATED_USERS_PRIVILEGED, DANGEROUS_GROUP_NESTING e PRIVILEGED_GROUP_MEMBER_CHANGES. Questi findings aiutano a distinguere una lista di membri diretti apparentemente pulita da un percorso di privilegio effettivo creato da principal ampi o gruppi annidati.
Per deriva ACL e replica, EtcSec controlla DCSYNC_CAPABLE, ACL_GENERICALL, ACL_WRITEDACL, ACL_WRITEOWNER, ACL_SELF_MEMBERSHIP, ACL_ADD_MEMBER, ADMIN_SD_HOLDER_MODIFIED e ADMINSDHOLDER_BACKDOOR. Questi findings mappano le superfici di controllo che i difensori devono rimisurare dopo la pulizia: diritti di replica, diritti di modifica gruppi, controllo dei security descriptor e persistenza sugli admin protetti.
EtcSec non sostituisce investigazione SIEM o incident response. Il suo ruolo in questo workflow è misurare la postura: identificare la condizione rischiosa, spiegare perché conta, tracciare la bonifica e misurare se la condizione torna dopo la prossima modifica di directory.
Controlli correlati
La deriva degli accessi privilegiati è più facile da controllare quando viene trattata come problema ricorrente di postura. Una revisione di accesso una tantum può rimuovere account admin evidenti; un workflow ricorrente può rilevare quando gli stessi diritti tornano.
Usate igiene degli account privilegiati per ridurre il numero di identità che possono diventare target di credenziali ad alto valore. Usate revisione ACL e DCSync per trovare percorsi che non compaiono nei report di appartenenza ai gruppi. Usate eventi di monitoraggio per validare quando sono avvenute le modifiche e chi le ha eseguite. Usate controlli di password amministratore locale come Windows LAPS per ridurre l’impatto di credenziali admin locali riutilizzate mentre lavorate sui percorsi di privilegio del dominio.
L’obiettivo operativo è semplice: ogni percorso privilegiato deve essere intenzionale, avere un owner, essere minimo e rivalidato. Tutto il resto è deriva.
Riferimenti primari
- Microsoft Learn: Audit Security Group Management
- Microsoft Learn: Event 4728 - A member was added to a security-enabled global group
- Microsoft Learn: Event 4729 - A member was removed from a security-enabled global group
- Microsoft Learn: Event 4732 - A member was added to a security-enabled local group
- Microsoft Learn: Event 4733 - A member was removed from a security-enabled local group
- Microsoft Learn: Event 4756 - A member was added to a security-enabled universal group
- Microsoft Learn: Event 4757 - A member was removed from a security-enabled universal group
- Microsoft Learn: Event 5136 - A directory service object was modified
- Microsoft Learn: Event 4662 - An operation was performed on an object
- Microsoft Open Specifications: AdminSDHolder
- Microsoft Learn: Protected Users security group
- MITRE ATT&CK: Account Manipulation T1098
- MITRE ATT&CK: DCSync T1003.006
- Catalogo locale EtcSec: Active Directory vulnerability catalogue - docs/vulnerabilities/active-directory/AD_VULNERABILITY_CATALOG.md
