Le falle di sicurezza che troviamo nel 90% degli assessment e come mitigarle oggi
In oltre dieci anni di 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.
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 crittografato con l'hash NTLM della password dell'account. 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
Conclusione
Queste vulnerabilità sono la porta d'ingresso per il 90% degli attacchi 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? Contatta il team Nexsys per un Assessment dedicato e trasforma il tuo "debito tecnico" in una difesa impenetrabile.