🏢Active DirectoryPasswordAccountsConfig

Sicurezza delle Password in Active Directory: errori critici

Politiche di password deboli, password che non scadono mai e archiviazione delle credenziali in testo chiaro sono tra le configurazioni errate piu sfruttate in Active Directory.

ES
EtcSec Security Team
9 min read
Sicurezza delle Password in Active Directory: errori critici

Cos'e la sicurezza delle password in Active Directory?

La sicurezza delle password in Active Directory non riguarda soltanto la lunghezza minima. Riguarda tutti i controlli che determinano come un segreto viene scelto, conservato, derivato, trasportato e rinnovato nel dominio.

In pratica, gli errori davvero pericolosi ricadono quasi sempre in sei famiglie:

  • password che non scadono mai
  • policy password troppo deboli
  • account con PasswordNotRequired
  • password scritte in campi descrittivi
  • WDigest ancora capace di esporre credenziali in chiaro in LSASS
  • NTLMv1 ancora consentito

Il motivo per cui questi errori sono cosi utili a un attaccante e semplice: si combinano bene con quasi tutte le tecniche di accesso iniziale o di espansione dei privilegi. Un segreto vecchio o esposto rende molto piu efficace Kerberoasting, AS-REP Roasting, password spraying, dump LSASS e riuso di credenziali locali o di servizio.

Il modello tecnico corretto

In un dominio AD i controlli sulle password arrivano da piu livelli:

  • Default Domain Password Policy
  • Fine-Grained Password Policies (FGPP)
  • flag di account dentro userAccountControl
  • configurazioni di autenticazione legacy sugli host e sui domain controller
  • cattive pratiche operative, come salvare una password in description

Il problema vero quindi non e semplicemente "una password debole". Il problema e la combinazione tra:

  • un segreto facile da indovinare, estrarre o riutilizzare
  • un account che ha accesso utile
  • una durata eccessiva del segreto
  • un protocollo o un meccanismo di caching che aiuta l'attaccante

Se questi elementi si sovrappongono, il costo dell'attacco scende molto piu di quanto suggerirebbe la sola policy password vista in GPO.

Le sei configurazioni errate che contano davvero

1. PasswordNeverExpires

Un account con PasswordNeverExpires = True puo restare sfruttabile per anni se nessuno ruota il segreto. Questo e particolarmente pericoloso per:

  • account di servizio
  • account tecnici usati da processi batch o scheduler
  • account privilegiati lasciati fuori dal ciclo normale di review

Non e solo un problema di hygiene. E un acceleratore di persistenza.

2. Policy password troppo debole

Microsoft supporta sia la policy di dominio sia le FGPP. Se la lunghezza minima, la history o la scadenza sono troppo permissive, l'attaccante ottiene due vantaggi concreti:

  • maggiore probabilita di successo per spray e guessing
  • costi piu bassi nel cracking offline di materiale raccolto altrove

Le FGPP complicano la lettura reale della postura: il dominio puo sembrare ragionevole, mentre alcuni gruppi sensibili ereditano una policy piu debole.

3. PasswordNotRequired

Microsoft documenta il flag PASSWD_NOTREQD tra le proprieta di userAccountControl. E un segnale da trattare come deviazione seria, non come semplice stranezza. Anche quando il contesto rende l'exploit meno immediato, la presenza del flag su un account merita una review tecnica.

4. Password nei campi descrittivi

E uno degli errori piu evitabili e piu utili per un attaccante. Se una password viene copiata in description o in un altro attributo testuale, l'annuario diventa un contenitore di credenziali.

5. WDigest ancora attivo

L'advisory Microsoft 2871997 esiste proprio perche WDigest puo esporre credenziali in memoria in modo molto piu favorevole all'attaccante. Se UseLogonCredential e attivo, un dump di LSASS puo tornare a produrre materiale molto piu facilmente riutilizzabile.

6. NTLMv1 ancora consentito

Microsoft documenta da anni LmCompatibilityLevel. Se l'ambiente continua a permettere livelli legacy, conserva un protocollo di autenticazione piu debole che aumenta il valore offensivo di vecchi client, relay e cattive pratiche storiche.

Come leggere correttamente FGPP e flag di account

Un errore comune nei team AD e guardare solo la policy di dominio e concludere che la postura password sia coerente. In realta le FGPP cambiano completamente la lettura, perche possono assegnare criteri diversi a utenti o gruppi specifici.

Get-ADFineGrainedPasswordPolicy -Filter * |
  Select-Object Name, Precedence, MinPasswordLength, MaxPasswordAge, PasswordHistoryCount

Get-ADUserResultantPasswordPolicy -Identity svc_sql

Questa seconda query e fondamentale: restituisce la policy risultante per un account specifico. E l'unico modo affidabile per capire se un account tecnico o privilegiato stia ereditando un criterio troppo permissivo nonostante la policy di dominio appaia corretta.

Allo stesso modo, userAccountControl non va letto come un unico interruttore. Va spezzato in flag rilevanti:

  • PASSWD_NOTREQD
  • DONT_EXPIRE_PASSWORD
  • eventuali combinazioni che descrivono account tecnici, di trust o legacy

Se il team non sa quali account hanno questi flag e perche li hanno, non sta facendo password security: sta solo sperando che la baseline GPO basti.

Account di servizio, gMSA e segreti dimenticati

Molti ambienti sembrano avere una policy password decente e poi crollano appena si guardano gli account di servizio. Microsoft raccomanda i group managed service accounts (gMSA) proprio per ridurre dipendenza da password manuali, deboli o mai ruotate.

Se un servizio supporta gMSA ma continua a usare un normale utente di dominio, il problema non e solo operativo. E una esposizione diretta verso:

  • Kerberoasting
  • riuso di credenziali
  • password condivise tra team
  • incapacita di dimostrare ownership e rotazione reale

In una review tecnica la domanda giusta non e "questo servizio funziona?". La domanda giusta e "questo servizio usa ancora un segreto umano che puo restare valido per anni?".

Come un attaccante collega questi errori

Fase 1 - Inventario degli account deboli

Get-ADUser -Filter {PasswordNeverExpires -eq $true} -Properties PasswordNeverExpires, PasswordLastSet |
    Select-Object SamAccountName, PasswordLastSet

Get-ADUser -Filter {PasswordNotRequired -eq $true} -Properties PasswordNotRequired |
    Select-Object SamAccountName

Get-ADUser -Filter * -Properties Description |
    Where-Object {$_.Description -match "pass|pwd|password|chiave"} |
    Select-Object SamAccountName, Description

Fase 2 - Verifica dei punti di esposizione memoria o protocollo

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' -Name UseLogonCredential
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel

Fase 3 - Sfruttamento secondo il caso

A seconda di cio che trova, l'attaccante puo:

  • effettuare dump di LSASS per cercare materiale in chiaro o facilmente riutilizzabile
  • eseguire password spraying su account vecchi o deboli
  • crackare offline materiale raccolto via Kerberoasting o AS-REP Roasting
  • riutilizzare password locali o di servizio che non ruotano mai

Il punto importante e che una cattiva postura sulle password raramente resta isolata. Alimenta altre tecniche.

Detection

Cosa osservare lato AD

I log di dominio aiutano, ma da soli non bastano. Conviene correlare segnali di postura e attivita.

Gli eventi piu utili da tenere in considerazione sono:

  • 4738 per modifiche di account, inclusi flag sensibili
  • 4723 e 4724 per cambi e reset password
  • 4771 per errori di pre-auth Kerberos che possono indicare spraying
  • 4624 quando si vuole individuare ancora uso di NTLMv1 o pattern di accesso anomali

Cosa misurare come postura continua

La parte piu redditizia resta un inventario periodico di:

  • account con PasswordNeverExpires
  • account con PasswordNotRequired
  • account con password molto vecchie
  • presenza di UseLogonCredential
  • valore effettivo di LmCompatibilityLevel
  • attributi testuali che contengono possibili credenziali
  • account di servizio non migrati a gMSA quando il software li supporta

Query utile per tracce NTLMv1

event.code: "4624" AND
winlog.event_data.LmPackageName: "NTLM V1"

La lettura corretta non e "vedo un solo evento e ho la prova". La lettura corretta e: quali account deboli esistono, quali protocolli deboli restano, e su quali sistemi o identita questo diventa davvero critico.

Remediation

1. Rafforzare policy di dominio e FGPP

Set-ADDefaultDomainPasswordPolicy -Identity corp.local \
    -MinPasswordLength 14 \
    -ComplexityEnabled $true \
    -MaxPasswordAge (New-TimeSpan -Days 90) \
    -MinPasswordAge (New-TimeSpan -Days 1) \
    -PasswordHistoryCount 24

I valori precisi dipendono dal contesto, ma la direzione e chiara: aumentare il costo del guessing e del cracking, e ridurre il riuso del segreto.

2. Correggere PasswordNeverExpires

Get-ADUser -Filter {PasswordNeverExpires -eq $true -and Enabled -eq $true} |
    Set-ADUser -PasswordNeverExpires $false

Per gli account di servizio non basta toccare il flag. Serve una strategia di rotazione reale o la migrazione verso gMSA quando possibile.

3. Correggere PasswordNotRequired

Get-ADUser -Filter {PasswordNotRequired -eq $true} | ForEach-Object {
    Set-ADAccountControl -Identity $_ -PasswordNotRequired $false
}

4. Bonificare subito i campi descrittivi con segreti

Get-ADUser -Filter * -Properties Description |
    Where-Object {$_.Description -match "pass|pwd|password"} |
    ForEach-Object {
        Set-ADUser -Identity $_ -Description ""
    }

Se una password e stata scritta in un attributo, bisogna considerarla esposta e ruotarla, non limitarsi a cancellare il testo.

5. Disabilitare WDigest esposto

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' \
    -Name UseLogonCredential -Value 0

6. Forzare NTLMv2 soltanto

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' \
    -Name LmCompatibilityLevel -Value 5

Prima del change e necessario individuare eventuali sistemi o applicazioni che ancora dipendono da comportamenti legacy.

Validazione dopo la correzione

Una chiusura seria del tema richiede di dimostrare:

  1. quali account mantengono ancora eccezioni e perche
  2. che i segreti trovati in attributi testuali sono stati ruotati, non solo rimossi dal campo
  3. che UseLogonCredential non espone piu credenziali dove non dovrebbe
  4. che l'ambiente non accetta piu NTLMv1
  5. che gli account di servizio vecchi hanno un piano di rotazione o migrazione credibile
  6. che la policy risultante degli account sensibili e stata verificata via FGPP, non solo dedotta dalla GPO di dominio

Se manca uno di questi punti, non si tratta ancora di una postura password affidabile.

Errori difensivi ricorrenti

Gli errori piu comuni sono:

  • trattare PasswordNeverExpires come semplice comodita operativa
  • dimenticare le FGPP e leggere solo la policy di dominio
  • svuotare description senza cambiare la password esposta
  • disabilitare un comportamento legacy su pochi host ma non nel resto del perimetro
  • correggere i flag di account senza rivedere servizi, task schedulati e dipendenze applicative
  • parlare di password policy senza classificare gli account di servizio che restano fuori dalla disciplina normale

Un lettore tecnico non vuole sentirsi dire che "le password sono importanti". Vuole sapere quali segreti restano facili da trovare, facili da rompere o facili da riutilizzare, e su quali account questo crea un percorso praticabile.

Fonti primarie

Come EtcSec rileva questo

EtcSec copre questo tema da piu angoli:

  • PASSWORD_NEVER_EXPIRES
  • PASSWORD_POLICY_WEAK
  • PASSWORD_NOT_REQUIRED
  • PASSWORD_IN_DESCRIPTION
  • WDIGEST_ENABLED
  • NTLMV1_ALLOWED

Presi insieme, questi finding rispondono a una sola domanda utile: i segreti AD sono soltanto "conformi" sulla carta, oppure sono davvero difficili da estrarre, crackare e riutilizzare?

Letture correlate

🏢 Active DirectoryPasswordAccountsConfig
Sicurezza Password Active Directory | EtcSec