Auditare la sicurezza di Active Directory

Per auditare la sicurezza di Active Directory in modo solido, bisogna partire dalle evidenze e non da una checklist generica. Un audit di Active Directory difendibile deve mostrare quali identità possono controllare la directory, quali permessi possono replicare segreti o riscrivere confini di trust, quali impostazioni di protocollo o di certificato continuano a creare percorsi di attacco brevi e quali prove verranno conservate per validare in seguito la remediation.

Questa guida resta focalizzata su Active Directory on-prem. Se operatori, ruoli privilegiati o workflow di recovery dipendono anche da Microsoft Entra, questa revisione deve essere eseguita in parallelo con una valutazione separata di Entra, invece di fondere i due perimetri in un unico report vago. L’obiettivo qui è più ristretto: mostrare cosa deve coprire per prima cosa un audit AD, quali finding meritano remediation anticipata e come dimostrare che una correzione ha davvero modificato il control plane.

Un audit AD utile deve produrre cinque risultati:

un inventario delimitato delle superfici della directory che contano davvero
un elenco di identità e permessi che possono controllare asset privilegiati o replicare segreti
un elenco più corto di attack path che richiedono remediation immediata
evidenze del fatto che i controlli di hardening siano realmente applicati in produzione
un pacchetto di validazione confrontabile con il ciclo di revisione successivo

Auditare la sicurezza di Active Directory: cosa significa davvero?

Un audit di Active Directory non è solo un controllo della password policy e non è nemmeno un health report una tantum. È una revisione basata su evidenze di identità, permessi, servizi, policy e telemetria che determinano chi può controllare la directory e con quale rapidità quel controllo potrebbe essere abusato.

Questo significa che l’output dell’audit deve rispondere a domande concrete:

Quali utenti, gruppi, account di servizio o computer hanno controllo sull’intero dominio o quasi?
Quali diritti possono replicare dati sensibili della directory o riscrivere confini di trust?
Quali impostazioni di protocollo e delega riducono il costo di attacco per un avversario?
Quali finding sono solo deriva di configurazione e quali aprono percorsi diretti di escalation?
Quali export, log e snapshot di stato dimostrano che una correzione è reale?

Se la revisione non riesce a rispondere a queste domande, resta una checklist, non un audit. Questa distinzione conta perché un ambiente può sembrare accettabile in un foglio di conformità e continuare comunque a esporre percorsi brevi verso Domain Admin tramite diritti di replica, delega, account privilegiati obsoleti o abuso di certificati.

Definire il perimetro prima di rivedere i finding

Il modo più rapido per perdere tempo è iniziare a rivedere i finding prima di avere definito il perimetro.

Decisioni di scope obbligatorie

Per prima cosa bisogna decidere quali superfici della directory sono realmente in gioco:

il dominio o la foresta revisionati
i domain controller e i gruppi amministrativi privilegiati
i gruppi di amministrazione delegata e gli account di servizio ad alto impatto
i diritti di replica, gli oggetti sensibili dal punto di vista ACL e i confini di ereditarietà
la delega Kerberos e l’esposizione dei service principal
Group Policy, postura LDAP, Windows LAPS e audit policy
AD CS, ma solo se esiste nella foresta

Il perimetro deve restare onesto. Se AD CS non è distribuito, va detto esplicitamente che è fuori scope e si può andare oltre. Se un team PKI separato lo gestisce ma AD CS esiste nella foresta, rientra comunque nell’audit perché l’emissione di certificati può ancora modificare l’esposizione privilegiata. La stessa regola vale per l’identità ibrida: se Microsoft Entra influenza operatori privilegiati, percorsi di recovery o amministrazione applicativa, questa dipendenza va dichiarata, ma non bisogna sostenere che una review Entra sostituisca una review AD.

Requisiti di evidenza prima del primo export

Questo è anche il momento in cui decidere quali prove verranno conservate tra i cicli. Se l’audit dovrà poi dimostrare che un gruppo privilegiato è stato ripulito o che un diritto pericoloso è stato rimosso, questo requisito deve essere fissato prima del primo export.

Rivedere prima l’accesso privilegiato e il Tier 0

Si parte dal control plane della directory, spesso descritto operativamente come Tier 0. Questo significa rivedere le identità e i percorsi amministrativi che possono modificare direttamente il dominio, i domain controller, i confini di trust o gli oggetti che li proteggono.

Cosa controllare nel primo passaggio

Bisogna rivedere almeno:

gruppi privilegiati built-in e personalizzati
gruppi di amministrazione delegata e catene di annidamento dei gruppi
account privilegiati obsoleti e vecchi account di eccezione
account di servizio privilegiati che mantengono ancora accesso permanente
separazione amministrativa tra identità utente normali e identità amministrative

Questo è il punto di partenza corretto perché pratiche amministrative deboli e segmentazione insufficiente sono esattamente dove i compromessi reali di AD si consolidano. La guida ANSSI 2023 sull’amministrazione sicura dei sistemi basati su AD afferma esplicitamente che i compromessi AD derivano da cattive pratiche amministrative e segmentazione insufficiente, poi descrive come gli attaccanti usino movimento laterale ed escalation di privilegi per ottenere il controllo completo della directory.

Cosa deve dimostrare questa sezione

Il test pratico è semplice: riuscite a spiegare chi amministra la directory, da dove, con quale tipo di account e perché quell’accesso esiste ancora? Se la risposta è no, l’audit deve fermarsi qui per prima cosa. Una directory con password policy pulita ma con un disegno debole dell’accesso privilegiato resta una directory debole.

Per i pattern di deriva correlati, usate Privileged Access Drift Active Directory: How Admin Rights Creep Back After Audits e Stale Privileged Accounts: Hidden Risk in Active Directory come review complementari.

Auditare diritti di replica, abuso ACL e percorsi di attacco brevi

Dopo i gruppi privilegiati, bisogna rivedere i permessi che possono aggirarli in silenzio. Un audit AD serio deve includere principal capaci di replicare segreti e di avere controllo ampio su oggetti sensibili.

Diritti che meritano revisione immediata

Microsoft documenta DS-Replication-Get-Changes-All come un control access right che consente la replica di dati segreti del dominio. Questo basta per rendere i diritti di replica un tema di audit di primo livello, non un edge case avanzato. Se non sapete esattamente quali principal hanno diritti legati alla replica, l’audit è incompleto.

Lo stesso vale per il controllo degli oggetti. Non si tratta solo di trovare membership evidenti in gruppi admin. Si tratta di identificare percorsi di scrittura, gestione dei permessi o presa di ownership su oggetti di alto valore come:

la root del dominio
gruppi privilegiati
AdminSDHolder
OU che ospitano admin sensibili, server o GPO
contenitori collegati a GPO che possono cambiare la postura di sicurezza su larga scala

Quale telemetria aiuta a validare i cambiamenti

Il logging conta qui, ma deve essere descritto con precisione. Event 5136 viene generato quando un oggetto del servizio directory viene modificato, ma solo se l’oggetto ha la SACL pertinente. Event 4662 registra operazioni eseguite su un oggetto AD, ma di nuovo solo quando la SACL appropriata esiste e l’operazione la attiva. Nessuno di questi eventi è un detector magico. Sono punti di evidenza utili per validare modifiche ad alto valore e monitorare oggetti specifici una volta definito correttamente il perimetro.

Per questo conta ragionare in termini di attack path. La domanda non è solo se un diritto esiste. La vera domanda è se quel diritto crea un percorso breve verso il controllo della directory. Per una review più profonda, affiancate l’audit con ACL Abuse and DCSync: The Silent Paths to Domain Admin e Active Directory Attack Paths to Domain Admin.

Rivedere Kerberos, delega ed esposizione degli account di servizio

Kerberos resta centrale nell’esposizione AD, soprattutto attraverso account di servizio e impostazioni di delega.

Account e impostazioni da rivedere per primi

Bisogna rivedere almeno:

account utente o di servizio con SPN
account privilegiati che espongono anch’essi SPN
unconstrained delegation
constrained delegation e resource-based constrained delegation quando sono usate
account di servizio senza owner chiaro, senza review recente o con privilegi eccessivi

Perché l’esposizione degli account di servizio appartiene al nucleo dell’audit

Gli account con SPN rientrano nello scope perché Kerberoasting dipende dai service ticket richiesti per quegli SPN, ed è per questo che MITRE ATT&CK T1558.003 resta un riferimento utile di contesto detection per un audit tecnico. L’audit non ha bisogno di un walkthrough di exploit. Deve però mostrare quali account di servizio espongono opportunità di cracking offline e se alcuni di essi sono anche privilegiati.

La delega richiede lo stesso livello di precisione. Microsoft descrive constrained delegation come una forma più restrittiva di delega rispetto a unconstrained delegation, perché limita i servizi verso cui un server può agire per conto di un utente. Questo non rende constrained delegation automaticamente sicura. Significa solo che deve essere rivista nel suo contesto: quali servizi front-end sono autorizzati, quali servizi back-end si fidano di essi e se il bisogno di business esiste ancora.

Se volete l’analisi specifica della delega, usate Kerberos Delegation Attacks: From Unconstrained to RBCD Abuse. Nell’audit stesso, mantenete il focus su ownership, privilegio e percorsi di abuso raggiungibili.

Includere AD CS se esiste nella foresta

Se Active Directory Certificate Services è distribuito in qualunque punto della foresta, va incluso. Microsoft documenta AD CS come un ruolo Windows Server per emettere e gestire certificati PKI usati in protocolli di autenticazione e comunicazione sicura. Questo basta per trattarlo come infrastruttura di identità, non come un tema secondario da rinviare a una futura review PKI.

Cosa deve coprire la parte AD CS

Un audit AD utile dovrebbe quindi rivedere:

Enterprise CA che emettono certificati rilevanti per l’autenticazione
template di certificato pubblicati
chi può eseguire l’enrollment e chi può modificare i permessi dei template
se l’emissione di certificati amplia l’esposizione privilegiata
se i percorsi basati su certificati creano escalation che aggirano il lavoro già fatto su gruppi e delega

Non bisogna assumere che ogni ambiente AD disponga di AD CS. Ma se AD CS esiste, non deve restare fuori dall’audit. L’emissione di certificati e i permessi dei template possono cambiare materialmente chi può autenticarsi e come chi. Per il dettaglio tecnico specifico sui certificati, vedere ADCS Certificate Attacks: How ESC1 to ESC8 Lead to Domain Admin.

Verificare GPO, LDAP, LAPS e controlli di logging

Una volta compresi i percorsi privilegiati e i meccanismi di escalation, bisogna rivedere i controlli che dovrebbero hardenizzare l’ambiente e generare la telemetria su cui il team fa affidamento.

Controlli da validare direttamente

Per LDAP, Microsoft afferma che LDAP signing firma crittograficamente le comunicazioni LDAP per verificarne autenticità e integrità, mentre channel binding collega la sicurezza del livello applicativo alla sessione TLS sottostante. In pratica, l’audit deve confermare la policy effettiva sui domain controller, non soltanto lo standard desiderato. Questo conta ancora di più oggi perché Microsoft documenta chiaramente i confini di versione: i nuovi deployment di Active Directory su Windows Server 2025 richiedono LDAP signing per impostazione predefinita, mentre gli ambienti aggiornati mantengono la policy esistente. Questo significa che va auditata la postura effettiva, e non va assunto un default. Per i dettagli di configurazione e validazione, usare LDAP Signing Disabled: How Unsigned Binds Expose Active Directory.

Per Windows LAPS, Microsoft documenta che la funzionalità gestisce automaticamente e salva le password dell’amministratore locale e può anche salvare la password DSRM dei domain controller di Active Directory. Un audit AD deve quindi verificare non solo se LAPS è presente, ma se la popolazione prevista è coperta, dove vengono salvate le password, chi può leggerle e se la protezione DSRM è configurata dove serve. Per il gap operativo, vedere Windows LAPS Not Deployed: Why Shared Local Admin Passwords Still Matter.

Il logging che prova i cambiamenti di controllo

Per il logging, la formulazione deve restare precisa:

Audit Security Group Management copre modifiche come creazione, eliminazione e aggiunta o rimozione di membri dai gruppi.
Event 5136 aiuta a validare modifiche a oggetti quando esiste la SACL corretta.
Event 4662 aiuta a monitorare operazioni su oggetti AD sensibili quando directory service access auditing e le SACL sono configurati correttamente.

Microsoft afferma inoltre che gli advanced audit policy settings possono essere gestiti tramite Group Policy, così che le organizzazioni possano modificare, testare e distribuire un auditing più granulare per utenti e gruppi che contano davvero. Questa è la postura operativa corretta: testare la policy, confermare volume e retention degli eventi e verificare che il team analizzi davvero le evidenze prodotte. Per gli eventi che contano di più dopo il rollout, vedere Active Directory Monitoring: Security Event IDs That Matter.

Evidenze da conservare tra i cicli di audit

Un audit AD utile lascia un pacchetto di evidenze riutilizzabile, non solo un deck di slide.

Pacchetto minimo di evidenze

Area di revisione	Evidenze da conservare	Perché è importante
Accesso privilegiato	Export di gruppi admin built-in, gruppi di amministrazione delegata e gruppi annidati ad alto impatto	Dimostra se il privilegio permanente è davvero cambiato tra i cicli
Replica ed esposizione ACL	Principal con diritti legati alla replica, più export ACL della root del dominio, `AdminSDHolder`, OU chiave e gruppi privilegiati	Mostra se i percorsi di replica dei segreti o di controllo degli oggetti sono stati davvero rimossi
Kerberos e delega	Account con SPN, impostazioni di delega e inventario degli account di servizio privilegiati	Conferma se il rischio legato a account di servizio e delega si è ridotto davvero
AD CS	Inventario delle CA, template pubblicati e snapshot dei permessi dei template quando AD CS esiste	Evita che l’esposizione da certificati scompaia in una review separata
Hardening e telemetria	Stato di LDAP signing, copertura Windows LAPS, export GPO e audit policy, più metadati di esecuzione dell’audit	Dimostra che i controlli di hardening e monitoraggio sono reali e ripetibili

Conservate data, perimetro, fonte e owner con ogni artefatto. Se il ciclo successivo non può confrontare export equivalenti, il team passerà tempo a discutere se un finding è nuovo invece di dimostrare che un percorso è scomparso.

Dare priorità alla remediation in base all’impatto sull’identità

Non bisogna eseguire remediation in una coda piatta. Occorre iniziare da ciò che cambia più direttamente la portata di un attaccante.

Correzioni che di solito vengono per prime

Le remediation di prima priorità di solito includono:

diritti legati alla replica che espongono dati segreti del dominio
percorsi ACL o di ereditarietà che creano vie brevi verso oggetti privilegiati
unconstrained delegation e account di servizio privilegiati fortemente esposti
misconfigurazioni AD CS che creano abuso di autenticazione o enrollment

Controlli che rafforzano il ciclo successivo

Poi vengono i controlli che riducono la libertà dell’attaccante e migliorano la validazione futura:

postura di LDAP signing e channel binding
copertura Windows LAPS e igiene delle password privilegiate
lacune di audit policy che lasciano oggetti ad alto valore di fatto non monitorati

Solo dopo ha senso spendere energia in attività di pulizia che migliorano la governance ma non accorciano materialmente un attack path da sole. È anche per questo che una review ripetibile conta più di un report statico. Recurring AD Audit Workflow: Why Annual Audits Drift and How Continuous Posture Monitoring Works copre il modello operativo, mentre Active Directory Security Audit Tools: What to Compare Before You Choose tratta il tema del tooling.

Validazione dopo la remediation

Un finding non è chiuso perché un ticket dice che è chiuso. Bisogna validarlo dalla stessa superficie di controllo che ha esposto il problema.

Dopo una pulizia dell’accesso privilegiato, rieseguite gli export di gruppi e amministrazione delegata e confermate che l’identità non possiede più il percorso effettivo. Dopo la pulizia dei diritti di replica, confermate che il principal non compare più nel set di review della replica. Dopo hardening LDAP, verificate la policy effettiva e validate che i bind non firmati vengano rifiutati come previsto. Dopo un rollout di Windows LAPS, confermate l’applicazione della policy e lo stato del backup delle password sulla popolazione target. Dopo una correzione AD CS, verificate che il template rischioso, lo scope di enrollment o il percorso di permesso siano davvero scomparsi.

Cosa deve contenere un finding chiuso

Anche la telemetria deve essere validata. Se vi aspettate che cambiamenti futuri su oggetti sensibili producano evidenza 5136 o 4662, bisogna dimostrare che il modello SACL e la audit policy generano davvero gli eventi su cui intendete fare affidamento. Se le modifiche ai gruppi sono importanti, bisogna dimostrare che gli eventi corrispondenti sono presenti nel percorso di logging e conservati abbastanza a lungo da essere utili.

Il pacchetto finale di chiusura deve includere:

lo stato prima e dopo
l’owner del cambiamento
il metodo di validazione
l’eventuale eccezione residua
la data in cui il finding verrà ricontrollato

Questo è ciò che trasforma un audit AD in un controllo ripetibile invece che in un documento che invecchia non appena arriva il successivo cambiamento di delega.

Come EtcSec aiuta a strutturare un audit AD ripetibile

EtcSec deve inserirsi in questo workflow, non sostituirlo con linguaggio di marketing. La parte utile è la ripetibilità.

Dove il prodotto si inserisce, e dove no

Un audit AD ripetibile ha bisogno di rieseguire gli stessi controlli sulle stesse superfici di controllo per mostrare se un percorso privilegiato è nuovo, invariato o davvero remediated. EtcSec aiuta a strutturarlo mantenendo la review ancorata a finding concreti come EXCESSIVE_PRIVILEGED_ACCOUNTS, DCSYNC_CAPABLE, KERBEROASTING_RISK, UNCONSTRAINED_DELEGATION, ESC1_VULNERABLE_TEMPLATE, PATH_ACL_TO_DA, LDAP_SIGNING_DISABLED e LAPS_NOT_DEPLOYED.

L’attuale modello di deployment supporta inoltre la raccolta locale, invece di forzare l’audit a partire come esercizio puramente SaaS. Questo è importante dal punto di vista operativo, perché l’evidenza AD è migliore quando il percorso di raccolta resta stabile, quando gli stessi controlli vengono rimisurati dopo la remediation e quando gli output possono essere conservati tra i cicli.

Il valore pratico resta quindi stretto e verificabile: strutturare l’audit, mantenere misurabile il set di finding e rendere più difendibili i rerun. Se la domanda riguarda la scelta dello strumento e non il metodo di audit, usate Active Directory Security Audit Tools: What to Compare Before You Choose.

Auditare la sicurezza di Active Directory: cosa verificare per prima e come dimostrare la remediation