Le vulnerabilità Active Directory che incontriamo più spesso negli assessment e come mitigarle
Negli assessment di Active Directory, abbiamo notato un pattern costante: indipendentemente dalla dimensione dell'azienda, dal settore o dal livello di maturità del team IT, ci sono otto vulnerabilità che ricorrono praticamente ovunque. Non sono bug complessi, non sono zero-day, non sono esoteriche ma errori di configurazione che si accumulano nel tempo, trasformandosi in rischi di sicurezza critici.
Questa guida elenca le falle in ordine di frequenza e impatto, spiega come vengono sfruttate e indica le contromisure pratiche per sysadmin, blue team e responsabili IT. Per il resto dell'infrastruttura, cioè server, rete e servizi esposti, il punto di partenza è un vulnerability assessment.
Una nota importante: queste vulnerabilità sono tutte rilevabili con tool gratuiti (BloodHound, PingCastle, Purple Knight) in poche ore. La domanda non è "esistono nel mio dominio?" – molto probabilmente sì – ma "quanto sono critiche e con che priorità le correggo?".
Il tuo dominio è al sicuro? Molte di queste vulnerabilità sono invisibili senza un'analisi professionale. Scopri il servizio di Assessment Hardening AD di Nexsys.
Kerberoasting: Account privilegiati con SPN
Il Kerberoasting è presente in quasi ogni dominio. Ogni account di servizio con un Service Principal Name (SPN) registrato è un bersaglio potenziale. Un utente autenticato può richiedere un Ticket-Granting Service (TGS) per quel servizio, ottenendo un blob cifrato con una chiave derivata dalla password dell'account (l'hash NT se è ammesso RC4). Da lì, può tentare il cracking della password offline, senza generare alert.
Perché è grave
Se l'account di servizio ha privilegi elevati (Domain Admin, accesso a SQL critici, account di backup), il cracking della password equivale alla compromissione del dominio. Le password degli account di servizio sono spesso vecchie, riutilizzate, o create con criteri deboli perché "tanto è solo un servizio".
Come rilevarlo
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName, MemberOf | Where-Object {$_.MemberOf -match "Admins"}
Oppure con BloodHound: cerca il pattern "Kerberoastable Users" e incrocia con i percorsi verso Domain Admins.
Come correggerlo
- Migrare gli account di servizio a Group Managed Service Account (gMSA) con password gestite automaticamente
- Per gli account che non possono essere migrati: password lunghe (25+ caratteri) e generate casualmente
- Aggiungere gli account di servizio critici al gruppo Protected Users (attenzione alle implicazioni applicative)
- Configurare AES-only encryption nei tipi di crittografia Kerberos supportati
AS-REP Roasting e Pre-autenticazione Kerberos
Questa vulnerabilità colpisce gli account con il flag "Do not require Kerberos preauthentication" attivo. Un attaccante può raccogliere dati crittografici senza nemmeno autenticarsi, semplicemente conoscendo il nome utente.
Perché è grave
Un attaccante che ottiene credenziali di basso livello (o anche solo accesso anonimo a un Domain Controller in alcuni scenari) può raccogliere AS-REP per tutti gli account vulnerabili e attaccarli offline. Questi flag sono spesso impostati su account legacy o per "compatibilità" con vecchie applicazioni e poi dimenticati.
Come rilevarlo
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth
Come correggerlo
- Rimuovere il flag DONT_REQ_PREAUTH ovunque non sia strettamente necessario
- Verificare con il vendor dell'applicazione legacy se esistono alternative aggiornate
- Per gli account che devono mantenerlo, applicare password molto lunghe e monitoring dedicato
ACL pericolose: i permessi invisibili
Le permission ACL su oggetti AD sono spesso trascurate. Anni di deleghe ad-hoc creano percorsi di privilege escalation che permettono a un utente comune di diventare amministratore in pochi passaggi.
Perché è grave
Un attaccante con permessi GenericAll su un account privilegiato può modificarne la password. Con WriteDACL può aggiungersi qualsiasi permesso. Con WriteOwner può prendere ownership e diventare di fatto admin di quell'oggetto. BloodHound rivela questi percorsi in pochi minuti.
Come rilevarlo
BloodHound è il tool d'elezione: importa i dati raccolti con SharpHound e cerca query come "Find Shortest Paths to Domain Admins" o "Find Principals with DCSync Rights".
Come correggerlo
- Audit completo delle ACL su AdminSDHolder e gruppi privilegiati
- Rimozione delle deleghe non documentate
- Implementazione del Tier Model (o Enterprise Access Model) per separare ambiti amministrativi
- Documentazione obbligatoria di qualsiasi nuova delega di permessi
Assenza di Tier Model (Segregazione degli accessi)
Il Tier Model (oggi evoluto in Enterprise Access Model) separa i Domain Controller dai server applicativi e dalle workstation. Senza questa separazione, le credenziali dei Domain Admin finiscono memorizzate su macchine vulnerabili.
Perché è grave
Nella maggior parte degli ambienti che incontriamo, gli admin di dominio si autenticano dalle proprie workstation Tier 2, lasciano credenziali in cache su server Tier 1 e quelle stesse credenziali sono recuperabili con Mimikatz da qualsiasi macchina compromessa. Un singolo endpoint compromesso = potenziale escalation a Domain Admin.
Come correggerlo
- Implementare Privileged Access Workstation (PAW) per gli account Tier 0
- Restrizioni di logon via GPO: i Domain Admin non possono autenticarsi su Tier 1/2
- Authentication Silos e Authentication Policies per limitare la propagazione delle credenziali
- Aggiungere gli account Tier 0 al gruppo Protected Users
NTLM attivo e vulnerabilità di Relay
NTLM è un protocollo deprecato ma ancora onnipresente. È vulnerabile a relay attacks e Pass-the-Hash, permettendo a un attaccante di impersonare utenti legittimi nella rete.
Perché è grave
Un attaccante con accesso alla rete (anche a livello di un singolo client compromesso) può forzare relay NTLM verso servizi non firmati e impersonare utenti legittimi. È uno degli attack path più sfruttati in scenari di lateral movement reali.
Come rilevarlo
GPO "Audit: Audit NTLM authentication in this domain" attiva sui Domain Controller, poi analisi degli eventi 8001-8004 nel log Microsoft-Windows-NTLM/Operational. PingCastle riporta direttamente il livello di esposizione NTLM.
Come correggerlo
- Audit del traffico NTLM per identificare le applicazioni che lo usano
- Migrazione progressiva a Kerberos delle applicazioni che lo supportano
- Restrict NTLM via GPO con eccezioni controllate per i servizi legacy residui
- SMB Signing Required ovunque
- Disabilitare NTLMv1 a livello di GPO Network security: LAN Manager authentication level = "Send NTLMv2 response only. Refuse LM & NTLM"
LDAP non firmato (Simple Bind)
Trasmettere credenziali LDAP in chiaro espone l'azienda ad attacchi Man-in-the-Middle. Sebbene Microsoft raccomandi la firma LDAP dal 2019, molti ambienti sono ancora scoperti.
Perché è grave
Un attaccante in grado di intercettare traffico di rete o eseguire MITM può catturare credenziali in transito o eseguire relay attacks verso i Domain Controller per modificare oggetti AD.
Come correggerlo
- Abilitare LDAP Signing e Channel Binding sui Domain Controller via GPO
- Audit del traffico LDAP unsigned: registry key LDAPServerIntegrity in modalità audit prima di enforcement
- Migrare le applicazioni a LDAPS (porta 636) con certificato valido
- Bloccare LDAP simple bind per gli account privilegiati
Igiene di Dominio: Account e computer obsoleti
Account dormienti da oltre un anno o computer dismessi ma ancora presenti in Active Directory sono "porte di servizio" ideali per i cybercriminali.
Perché è grave
Account dormienti spesso hanno password deboli (impostate inizialmente e mai cambiate). Computer object stantii possono avere password riutilizzabili tramite tecniche di silver ticket. Account "service" con password mai scadute sono bersagli ideali per Kerberoasting.
Come rilevarlo
# Account inattivi da > 180 giorni Search-ADAccount -AccountInactive -TimeSpan 180 -UsersOnly # Computer non autenticati da > 90 giorni Search-ADAccount -AccountInactive -TimeSpan 90 -ComputersOnly # Password che non scadono mai Get-ADUser -Filter {PasswordNeverExpires -eq $true -and Enabled -eq $true}
Come correggerlo
- Processo di lifecycle management: disabilitazione automatica account inattivi >90gg, eliminazione dopo conservazione legale
- Eliminazione computer object orfani
- Rimozione del flag PasswordNeverExpires ovunque possibile, alternativa con gMSA
- Audit periodico (trimestrale) di account e computer dormienti
Logging e Detection inadeguati
L'ultima vulnerabilità riguarda la mancanza di visibilità. Senza un logging avanzato sui Domain Controller, attacchi come il DCSync o la creazione di Golden Ticket passano totalmente inosservati.
Perché è grave
Senza logging avanzato sui Domain Controller e forwarding centralizzato, le tecniche di attacco più comuni (Kerberoasting, DCSync, modifiche ACL, creazione Golden Ticket) passano completamente inosservate. L'attaccante può rimanere persistente per mesi, esfiltrare dati con calma, preparare il ransomware deployment.
Cosa configurare al minimo
- Advanced Audit Policy completa sui Domain Controller (Account Logon, Account Management, DS Access, Logon/Logoff, Object Access)
- Sysmon con configurazione SwiftOnSecurity o Olaf Hartong sui DC e sui server critici
- Windows Event Forwarding verso un collector centralizzato
- Forwarding al SIEM con regole di correlazione per le TTP MITRE ATT&CK più rilevanti
- Microsoft Defender for Identity per detection comportamentale automatica
- Honeypot account come canary per rilevare reconnaissance attiva
Le misure che seguono sono il piano di hardening che applichiamo dopo l'assessment: ogni voce è verificabile sul dominio e ha un impatto misurabile sulla superficie di attacco.
Kerberos e AES: eliminare RC4
- Impostare msDS-SupportedEncryptionTypes a 0x18 (AES128 + AES256) su utenti, computer e trust, dopo aver verificato che nessuna applicazione richieda ancora RC4.
- Configurare la GPO "Sicurezza di rete: configura i tipi di crittografia consentiti per Kerberos" lasciando solo AES128_HMAC_SHA1, AES256_HMAC_SHA1 e i tipi futuri.
- Resettare la password degli account di servizio dopo il cambio: le chiavi AES vengono generate solo al successivo cambio password.
- Monitorare gli eventi 4768 e 4769 sui Domain Controller filtrando il Ticket Encryption Type 0x17 per scoprire chi usa ancora RC4.
SMB Signing: chiudere la strada al relay
- Richiedere la firma SMB lato server e lato client su tutti i sistemi, non solo sui Domain Controller.
- Rimuovere SMBv1 e i client legacy prima di forzare la firma, per non interrompere dispositivi e apparati non aggiornati.
- Abilitare la crittografia SMB sulle share che trasportano dati sensibili.
- Senza firma SMB un NTLM relay verso file server e Domain Controller resta sfruttabile: è la contromisura diretta, non un opzionale.
LAPS: la password dell'amministratore locale
- Passare a Windows LAPS e dismettere Microsoft LAPS Legacy, evitando la coesistenza delle due policy sugli stessi client.
- Randomizzare e ruotare la password dell'amministratore locale su tutte le workstation e su tutti i member server, con backup della password DSRM per i Domain Controller.
- Restringere la lettura dell'attributo in AD ai soli gruppi di supporto e attivare l'audit degli accessi in lettura.
- Forzare la rotazione subito dopo ogni intervento che ha esposto la password (helpdesk, imaging, troubleshooting).
AD CS: i template che regalano il dominio
- Censire i template abilitati e disattivare quelli che permettono al richiedente di specificare il subject (ESC1) o l'EKU (ESC2) senza approvazione.
- Rimuovere ENROLLEE_SUPPLIES_SUBJECT dove non indispensabile e richiedere l'approvazione del certificate manager sui template privilegiati.
- Disabilitare l'enrollment web o proteggerlo con EPA e disattivare NTLM verso la CA, per chiudere il relay verso il servizio di certificazione (ESC8).
- Applicare lo strong certificate mapping della KB5014754 e leggere i log della CA prima di passare in Full Enforcement.
GPO: baseline e deleghe sotto controllo
- Partire dalle Microsoft Security Baseline e applicarle con LGPO in un ambiente di test prima della produzione.
- Verificare chi ha diritto di modifica e di link sulle GPO: una delega dimenticata su una OU di Tier 0 equivale a una escalation di privilegi.
- Cercare e rimuovere le credenziali nelle Group Policy Preferences (cpassword, MS14-025) e le GPO orfane rimaste in SYSVOL.
- Attivare l'audit delle modifiche alle GPO ed esportare un backup periodico con Backup-GPO.
Service account e gMSA
- Migrare a gMSA gli account di servizio con SPN: la password è generata e ruotata da Active Directory, per default ogni 30 giorni.
- Negare il logon interattivo agli account di servizio e non inserirli nei gruppi privilegiati: se serve un privilegio, si delega quello puntuale.
- Eliminare la delega Kerberos non vincolata e passare a constrained delegation o a RBCD.
- Per gli account che non possono diventare gMSA, imporre password lunghe (25 caratteri o più) e rotazione documentata; gli account amministrativi umani vanno in Protected Users.
Rotazione della password KRBTGT
- Ruotare la password di KRBTGT due volte, con almeno 10 ore fra le due rotazioni: è il lifetime massimo dei ticket, e rotazioni ravvicinate invalidano i ticket legittimi.
- Verificare la replica su tutti i Domain Controller fra la prima e la seconda rotazione.
- Pianificare la rotazione periodica (ogni 180 giorni) e quella immediata dopo ogni sospetto Golden Ticket o DCSync.
- Dopo un incidente ruotare anche le chiavi dei trust fra domini e forest.
Backup e forest recovery
- Mantenere backup offline del system state di almeno due Domain Controller per dominio, non raggiungibili con credenziali di dominio.
- Non ripristinare un Domain Controller da snapshot di VM: si rischia un USN rollback. Usare IFM o il ripristino autorevole.
- Scrivere un piano di forest recovery con tempi, ordine dei ruoli FSMO e ambiente di ripristino isolato.
- Provare il restore almeno una volta l'anno: un backup non verificato non è un backup.
Conclusione
Queste vulnerabilità ricorrono spesso nelle catene di attacco che portano al ransomware. La domanda non è se esistano nel tuo dominio, ma con quale priorità intendi correggerle.
Vuoi un supporto esperto per l'Hardening della tua Active Directory?
Scopri il servizio di Assessment e Hardening AD oppure richiedi una consulenza cybersecurity completa per definire roadmap e priorità della tua azienda