Active Directory: 5 Controlli Anti-Breach

L’Active Directory (AD) è il cuore pulsante di quasi ogni infrastruttura IT aziendale, agendo come il principale sistema di autenticazione e autorizzazione. La sua compromissione può avere conseguenze devastanti, portando a interruzioni di servizio, esfiltrazione di dati sensibili e danni reputazionali. Gli attaccanti lo sanno bene e l’AD è spesso il loro primo bersaglio, con statistiche che indicano come una quota rilevante dei breach (circa il 74% nelle PMI fonte: Verizon Data Breach Investigations Report 2024) abbia origine proprio da exploit o abusi legati all’Active Directory. Rilevare una compromissione in corso non è solo una questione di patching, ma di monitoraggio proattivo e comprensione dei segnali che l’AD stessa ci fornisce.

Quando si gestiscono ambienti complessi, con migliaia di workstation e centinaia di server, la quantità di eventi generati può essere schiacciante. Eppure, tra il rumore di fondo, ci sono pattern specifici e Event ID che fungono da campanelli d’allarme precoci. Ignorarli significa dare agli attaccanti il tempo necessario per stabilire la persistenza, elevare i privilegi e muoversi lateralmente nella rete. L’obiettivo non è solo prevenire l’attacco, ma ridurne il più possibile il tempo medio di rilevamento (MTTD) e il tempo medio di risposta (MTTR). In questo articolo, esploreremo cinque controlli fondamentali, testati sul campo, che ogni IT pro dovrebbe implementare per individuare tempestivamente una compromissione dell’Active Directory.

Testato su: Windows Server 2022 Domain Controller · Windows 10/11 Client · Agosto 2026

Prerequisiti / Ambiente di test

Per implementare e testare questi controlli, è necessario avere accesso con privilegi di amministratore al Domain Controller (DC) e al sistema di centralizzazione log (SIEM/EDR) utilizzato nell’ambiente. È fondamentale che l’audit policy di Active Directory sia configurata correttamente per registrare gli eventi di sicurezza rilevanti. In un ambiente di test, ho utilizzato un Domain Controller virtuale con Windows Server 2022 e diverse macchine client Windows 10/11, monitorando i log tramite un’istanza di Wazuh. Assicurati che l’audit policy sia abilitata per ‘Audit Account Logon Events’, ‘Audit Account Management’, ‘Audit Directory Service Access’ e ‘Audit Policy Change’.

1. Monitoraggio dei Log di Sicurezza Critici

Il monitoraggio continuo dei log di sicurezza è la prima linea di difesa. Eventi specifici possono indicare attività sospette come tentativi di accesso non autorizzati, escalation di privilegi o modifiche alla configurazione di sicurezza. È essenziale non solo raccogliere questi log, ma anche analizzarli attivamente, magari tramite un SIEM che possa correlare gli eventi e generare alert in tempo reale. I log vanno centralizzati e conservati per un periodo adeguato, in conformità con le normative come la NIS2 art. 21 Leggi anche: NIS2 Sanità: Registro Trattamenti Tecnico.

Event ID da monitorare prioritariamente:

4624 (An account was successfully logged on): Un login riuscito. Di per sé non è un problema, ma un gran numero di login da un singolo account da diverse posizioni geografiche in un breve lasso di tempo, o login da account di servizio in orari non lavorativi, sono altamente sospetti.
4625 (An account failed to log on): Un tentativo di login fallito. Un alto volume di questi eventi per un singolo account o da un singolo IP può indicare un attacco di ‘brute-force’ o ‘password spraying’.
4720 (A user account was created): Creazione di un nuovo account utente. Se non autorizzato, potrebbe essere un account backdoor.
4732 (A member was added to a security-enabled global group): Un utente è stato aggiunto a un gruppo di sicurezza privilegiato (es. Domain Admins). Questo è un segnale di escalation di privilegi.
4740 (A user account was locked out): Un account utente è stato bloccato. Spesso conseguenza di attacchi ‘brute-force’.
4768/4769 (A Kerberos authentication ticket (TGT/Service Ticket) was requested): Richieste di ticket Kerberos. Possono indicare attacchi ‘Golden Ticket’ o ‘Silver Ticket’ se i pattern sono anomali.

Per filtrare questi eventi su un Domain Controller, puoi usare PowerShell:

Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4624,4625,4720,4732,4740,4768,4769} | Format-Table -AutoSize

Questo comando ti darà una panoramica immediata degli eventi più recenti. Per un monitoraggio continuo, è indispensabile un SIEM.

2. Audit degli Account Privilegiati

Gli account con privilegi elevati (come Domain Admins, Enterprise Admins, Schema Admins e account di servizio con permessi elevati) sono i bersagli principali degli attaccanti. Un controllo rigoroso del loro utilizzo è cruciale. Ogni attività da questi account deve essere giustificata e monitorata. Idealmente, questi account dovrebbero essere usati solo per compiti amministrativi specifici e non per attività quotidiane.

Controlli da effettuare:

Principio del minimo privilegio: Assicurarsi che nessun utente o servizio abbia più permessi di quanto strettamente necessario per le proprie funzioni.
Separazione dei compiti: Implementare la separazione dei compiti per ridurre il rischio che un singolo utente possa compromettere l’intero sistema.
Monitoraggio dell’uso: Tracciare ogni login e ogni azione intrapresa da account privilegiati. Strumenti come LAPS (Local Administrator Password Solution) aiutano a gestire le password degli amministratori locali in modo sicuro. Leggi anche: Honeypot Agosto: 7 Giorni, 1.200 Attacchi SSH

Per elencare i membri del gruppo ‘Domain Admins’:

Get-ADGroupMember -Identity "Domain Admins" -Recursive | Select-Object Name, SamAccountName

Questa lista dovrebbe essere revisionata regolarmente. Qualsiasi account sconosciuto o non autorizzato è un segnale di allarme.

3. Robustezza delle Password Policy e Monitoraggio del ‘Password Spraying’

Password deboli o policy insufficienti sono un punto di ingresso comune per gli attaccanti. La policy delle password dovrebbe essere complessa, con requisiti di lunghezza, complessità e rotazione adeguati. Tuttavia, anche con policy robuste, attacchi come il ‘password spraying’ (tentativo di accedere a molti account con una singola password comune) possono avere successo.

Azioni preventive e di monitoraggio:

Policy di blocco account: Implementare una policy di blocco account (Account Lockout Policy) per prevenire attacchi ‘brute-force’ mirati. Attenzione però, può essere usata per attacchi DoS (Denial of Service) se non configurata con cura.
MFA per accessi privilegiati: L’autenticazione a più fattori (MFA) dovrebbe essere obbligatoria per tutti gli account amministrativi e per gli accessi da remoto.
Monitoraggio Event ID 4625: Un numero elevato di 4625 con diversi account ma la stessa password sorgente può indicare un attacco di ‘password spraying’.

Per visualizzare la policy di blocco account:

Get-ADDefaultDomainPasswordPolicy | Format-List LockoutThreshold, LockoutDuration, ResetLockoutCount

Questi parametri devono essere bilanciati per prevenire attacchi senza bloccare eccessivamente gli utenti legittimi.

4. Controllo della Replica di Active Directory

La replica di Active Directory è fondamentale per la coerenza dei dati tra i Domain Controller. Anomalie nella replica possono indicare problemi di connettività, ma anche tentativi di manipolazione da parte di un attaccante che cerca di compromettere un DC senza che le modifiche vengano propagate (o che vengano propagate modifiche malevole). Un DC compromesso può essere usato come punto di appoggio per attacchi successivi.

Strumenti e controlli:

repadmin /showrepl: Questo comando mostra lo stato della replica tra i DC. Errori persistenti o latenze anomale devono essere indagate.
dcdiag: Un tool diagnostico che verifica lo stato di salute generale dei DC, inclusa la replica.

Esempio di utilizzo di repadmin:

repadmin /showrepl

Un output pulito indica una replica sana. Errori come ‘Access Denied’ o ‘RPC server is unavailable’ potrebbero essere più gravi di un semplice problema di rete.

5. Monitoraggio dei Cambiamenti alle Group Policy Objects (GPO)

Le Group Policy Objects (GPO) sono il mezzo principale per configurare la sicurezza e il comportamento degli utenti e dei computer in un dominio AD. Modifiche non autorizzate alle GPO possono essere usate dagli attaccanti per disabilitare controlli di sicurezza, creare nuove eccezioni firewall o distribuire malware. Il monitoraggio di queste modifiche è quindi un controllo critico.

Event ID da monitorare:

4662 (An operation was performed on an object): Questo evento è generato quando un oggetto AD viene modificato. Filtrando per il tipo di oggetto ‘Group-Policy-Container’ e ‘Group-Policy-Template’, è possibile identificare le modifiche alle GPO.
5136 (A directory service object was modified): Simile al 4662, fornisce dettagli sulle modifiche agli oggetti del servizio directory, incluse le GPO.

Per un monitoraggio efficace, è consigliabile utilizzare strumenti specifici per la gestione e il versioning delle GPO, oltre al monitoraggio degli Event ID. Qualsiasi modifica non pianificata o non approvata a una GPO deve innescare un alert immediato.

Errori comuni e troubleshooting

Sovraccarico di log: Senza un SIEM o una strategia di filtraggio, il volume di log può essere insostenibile. Utilizza filtri specifici e configura l’audit policy per registrare solo gli eventi più rilevanti.
Falsi positivi: Alert eccessivi possono portare a ‘fatica da alert’. Affina le regole di correlazione nel tuo SIEM e crea baseline di comportamento normale per ridurre i falsi positivi.
Mancanza di contesto: Un singolo Event ID raramente fornisce il quadro completo. Correlare eventi da diverse fonti (AD, firewall, EDR) è fondamentale per capire la natura dell’attacco.
Mancanza di automazione: Eseguire questi controlli manualmente è impraticabile in ambienti enterprise. L’automazione tramite script PowerShell, SIEM o EDR è indispensabile.

FAQ — Domande Frequenti

Con quale frequenza dovrei revisionare i membri dei gruppi privilegiati?

Idealmente, dovresti revisionare i membri dei gruppi privilegiati almeno trimestralmente. Per ambienti ad alta sicurezza o con elevato turnover, una revisione mensile o anche più frequente è raccomandata. Inoltre, ogni volta che un amministratore lascia l’organizzazione, i suoi account devono essere disabilitati immediatamente e rimossi da tutti i gruppi privilegiati.

È sufficiente monitorare solo gli Event ID?

No, il monitoraggio degli Event ID è un ottimo punto di partenza, ma non è sufficiente da solo. Gli Event ID forniscono un pezzo del puzzle. È fondamentale correlarli con altri dati di sicurezza (es. traffico di rete, attività endpoint da un EDR) e avere un contesto sulla baseline comportamentale normale del tuo ambiente. Un SIEM è essenziale per questa correlazione.

Qual è l’impatto delle policy di audit sui Domain Controller?

Le policy di audit, se configurate in modo eccessivo, possono generare un volume molto elevato di log, consumando spazio su disco e risorse CPU sul Domain Controller. È importante bilanciare la granularità dell’audit con le prestazioni del DC. Concentrati sugli eventi di sicurezza critici e disabilita l’audit per eventi di basso valore che non contribuiscono al rilevamento di minacce.

Gli account di servizio dovrebbero avere password che scadono?

Generalmente, per gli account di servizio, è preferibile utilizzare password lunghe, complesse e generate casualmente che non scadono, piuttosto che forzarne la scadenza. Le password che scadono per gli account di servizio spesso portano a interruzioni di servizio e all’uso di password deboli per comodità. È più importante monitorare attentamente l’attività di questi account e proteggerli con il principio del minimo privilegio e, se possibile, con Managed Service Accounts (MSA) o Group Managed Service Accounts (gMSA).

Conclusioni con takeaway operativi

La sicurezza dell’Active Directory non è un progetto ‘set-and-forget’. Richiede un approccio proattivo, basato sul monitoraggio continuo e sulla comprensione dei segnali di allarme. I cinque controlli discussi — monitoraggio dei log critici, audit degli account privilegiati, robustezza delle password policy, controllo della replica AD e monitoraggio delle GPO — formano una base solida per rilevare tempestivamente una compromissione. Implementare un SIEM efficace, automatizzare i controlli e formare il personale sui rischi legati all’AD sono passaggi operativi essenziali. Ricorda, il tempo è un fattore critico: ogni minuto risparmiato nel rilevamento di un attacco può significare la differenza tra un incidente gestibile e un disastro totale.

Fonti

Aggiornato: agosto 2026