Verificare la sicurezza del proprio Active Directory
I controlli che contano di più in un dominio Active Directory (account privilegiati, krbtgt, deleghe, Kerberos, LAPS, NTLMv1, firma LDAP), come verificarli da soli, poi come seguirli nel tempo
Un attaccante che entra in una rete Windows punta per prima cosa ad Active Directory: chi lo controlla controlla tutte le macchine del dominio. Questa guida elenca i punti da verificare, in ordine di peso, con i comandi PowerShell che danno la risposta.
Servono il modulo ActiveDirectory (strumenti RSAT) e un account che legge la directory. I comandi di questa guida si limitano a leggere.
1. Gli account privilegiati
Cominciate contando le persone che possono fare tutto. I gruppi da esaminare sono Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Backup Operators e Server Operators. Il loro nome cambia con la lingua del dominio, il loro identificatore di sicurezza (SID) no.
$sid = "$((Get-ADDomain).DomainSID)-512"
Get-ADGroupMember -Identity $sid -Recursive | Select-Object Name, SamAccountNameChe cosa guardare:
- il numero: oltre una decina di amministratori attivi, la maggior parte non ne ha bisogno ogni giorno;
- gli account di servizio membri di un gruppo privilegiato, la cui password è spesso vecchia e condivisa tra colleghi;
- gli account nominativi usati anche per leggere la posta e navigare: un amministratore ha un account separato per l'amministrazione;
- gli amministratori fuori dal gruppo Protected Users e senza l'opzione «L'account è sensibile e non può essere delegato».
Un account che è stato membro di un gruppo protetto conserva adminCount = 1 dopo esserne uscito. Questi account restano a parte nella directory e meritano una verifica.
Get-ADUser -Filter 'adminCount -eq 1' -Properties adminCount | Select-Object SamAccountName, Enabled2. L'account krbtgt
La password di krbtgt serve a firmare tutti i ticket Kerberos del dominio. Chi la conosce può fabbricare un ticket valido per qualsiasi account («golden ticket»). In molti domini non è cambiata dalla creazione.
Get-ADUser krbtgt -Properties PasswordLastSet | Select-Object PasswordLastSetCambiatela a intervalli regolari, e dopo ogni incidente in cui un controller di dominio può essere stato compromesso. La procedura richiede due cambi: uno solo lascia valida la vecchia password. Tra i due, lasciate che la replica raggiunga tutti i controller e attendete almeno la durata massima di un ticket (10 ore per impostazione predefinita). Due cambi troppo ravvicinati interrompono le sessioni in corso.
3. Le deleghe e gli attacchi Kerberos
- Delega non vincolata. Una macchina che ne beneficia tiene in memoria i ticket degli account che vi si collegano. Fuori dai controller di dominio non ha ragione di esistere.
- Account senza preautenticazione Kerberos. Chiunque può chiedere un ticket per loro e tentare di decifrare la password offline (AS-REP roasting).
- Account utente con un SPN. I loro ticket di servizio si richiedono liberamente e si decifrano offline (Kerberoasting). Una password lunga e rinnovata, o un account di servizio gestito (gMSA), risolve la questione.
Get-ADComputer -Filter 'TrustedForDelegation -eq $true' | Select-Object Name
Get-ADUser -Filter 'DoesNotRequirePreAuth -eq $true' | Select-Object SamAccountName
Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties PasswordLastSet | Select-Object SamAccountName, PasswordLastSetIl primo comando elenca anche i controller di dominio. Per loro la delega non vincolata è normale.
4. LAPS, NTLMv1 e firma LDAP
LAPS. Senza LAPS né Windows LAPS, l'account amministratore locale ha spesso la stessa password su tutte le postazioni: una postazione compromessa apre tutte le altre. Misurate la quota di macchine la cui password locale è gestita. Con Windows LAPS, l'attributo msLAPS-PasswordExpirationTime è valorizzato sull'oggetto computer.
NTLMv1. Questo protocollo è obsoleto, e basta uno scambio intercettato per ritrovare il segreto dell'account. I controller di dominio registrano la versione di NTLM in ogni evento di accesso 4624.
$xpath = "*[System[EventID=4624] and EventData[Data[@Name='LmPackageName']='NTLM V1']]"
Get-WinEvent -LogName Security -FilterXPath $xpath -MaxEvents 200 | Select-Object TimeCreated, @{n='Account';e={$_.Properties[5].Value}}Una volta corrette le applicazioni coinvolte, impostate LmCompatibilityLevel a 5 sui controller di dominio: viene allora accettato solo NTLMv2.
Firma LDAP. Senza firma obbligatoria, una connessione LDAP può essere inoltrata o alterata lungo il percorso. Il valore LDAPServerIntegrity a 2, sotto HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters, la rende obbligatoria. Prima di imporla, guardate l'evento 2887 del registro Directory Service: conta ogni giorno i bind non firmati, quindi i client ancora da correggere.
5. Gli account dimenticati
Account attivi senza accesso da mesi, password che non scadono, macchine sparite dalla rete, sistemi fuori supporto: ognuno è una porta che nessuno sorveglia.
Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 -UsersOnly | Where-Object Enabled | Select-Object SamAccountName, LastLogonDateLastLogonDate viene replicato con un ritardo che può arrivare a 14 giorni. Un account indicato come inattivo da 80 giorni può quindi essersi collegato la settimana scorsa.
6. Una verifica puntuale non basta
Un audit scatta una fotografia. Tra due audit gli scostamenti ritornano: un fornitore aggiunto a Domain Admins per un intervento e poi dimenticato, una delega impostata per un test. Due abitudini cambiano la situazione:
- rileggere ogni trimestre i membri dei gruppi sensibili, con una decisione scritta per ciascuno;
- essere avvisati appena un gruppo privilegiato cambia, invece di scoprirlo al prossimo audit.
Strumenti pubblici fanno un quadro puntuale, per esempio ORADAD, pubblicato dall'ANSSI (l'agenzia francese per la cybersicurezza), o PingCastle.
Che cosa segue FirstSI
Aprite SI-Tracer → Active Directory (#/sitracer/ad). I punti di questa guida formano il Punteggio di postura, un voto su 100 ricalcolato ogni giorno e tracciato su 180 giorni.
| Punto di questa guida | Controllo di FirstSI |
|---|---|
| Account privilegiati | 10 amministratori attivi al massimo, amministratori fuori da «Protected Users», adminCount orfani |
| krbtgt | password cambiata meno di 180 giorni fa |
| Deleghe e Kerberos | delega non vincolata fuori dai controller, account senza preautenticazione, account di servizio con password vecchia |
| LAPS, NTLMv1, LDAP | copertura LAPS di almeno il 90 %, 0 autenticazioni NTLMv1 in 7 giorni, firma LDAP obbligatoria, livello 5 |
| Account dimenticati | account inattivi da 90 giorni, password che non scadono, sistemi a fine vita |
Punti da trattare ordina gli scostamenti per gravità, e Mostra i … elementi elenca gli account o le macchine coinvolti.
I gesti pericolosi vengono segnalati in tempo reale: aggiunta a un gruppo privilegiato, delega impostata, Kerberoasting, DCSync, criterio di gruppo modificato, registro di sicurezza cancellato. Le 14 regole sono attive per impostazione predefinita e aprono i loro incidenti nel SIEM.
La scheda Revisione accessi prepara la revisione trimestrale e la esporta in CSV, con l'autore e la data di ogni decisione. FirstSI non modifica nulla nella directory: ogni correzione resta a carico dei vostri amministratori.
L'agente deve girare su ogni controller di dominio, con il modulo SI-Tracer. L'audit Accesso al servizio directory resta da attivare a cura vostra, altrimenti il rilevamento DCSync resta muto. Vedere Active Directory: sicurezza e stato di salute.
Per approfondire
- Active Directory: sicurezza e stato di salute: le 14 regole di avviso e le loro soglie.
- Revisione degli accessi: la prova da presentare durante un audit.
- SI-Tracer: autenticazioni Windows: chi si è collegato dove, in Kerberos o in NTLM.
- Scheda account e scheda di un indirizzo IP: la cronologia di un account e l'origine dei suoi blocchi.
- Rafforzare i propri server Windows: il passo successivo, sui server membri.
Presentazione: Sicurezza Active Directory: monitoraggio e audit
Fonte: · Docs FirstSI · aggiornato il 11/10/2026