Sicurezza delle Password in Active Directory: errori critici

Cos'è la sicurezza delle password in Active Directory?

La sicurezza delle password in Active Directory copre le policy, i flag di account e le impostazioni di autenticazione legacy che determinano come le credenziali vengono create, memorizzate e riutilizzate nel dominio. Quando questi controlli sono deboli, l'attaccante non ha bisogno di una catena di exploit per iniziare. Una password debole, un account amministrativo che non scade mai, o una password copiata in un attributo possono bastare.

Questi problemi spesso passano inosservati nelle operazioni quotidiane. Gli account con PasswordNeverExpires o PasswordNotRequired possono rimanere in produzione per mesi, le password copiate nei campi di descrizione sono facili da trascurare, e impostazioni legacy come WDigest o NTLMv1 rendono molto più facile riutilizzare le credenziali recuperate.

Questo articolo si concentra su sei configurazioni errate delle password ad alto impatto in Active Directory e su come convalidare che le correzioni abbiano davvero eliminato l'esposizione.

Come funziona

Active Directory applica i controlli sulle password tramite due meccanismi principali:

• Default Domain Password Policy, applicata a livello di dominio tramite Group Policy
• Fine-Grained Password Policies (FGPP), applicate a utenti o gruppi specifici tramite Password Settings Objects

Le Fine-Grained Password Policies sono implementate come Password Settings Objects (PSO), e la loro precedenza è definita tramite l'attributo msDS-PasswordSettingsPrecedence: un valore più basso indica un PSO con priorità più alta. Un PSO collegato direttamente a un utente vince sempre; quando più PSO si applicano tramite l'appartenenza a un gruppo, quello con il valore di precedenza più basso diventa la policy risultante, e la Default Domain Password Policy si applica solo se nessun PSO corrisponde affatto. In pratica, gli account tier-0 e gli account di servizio dovrebbero trovarsi sotto un PSO con un valore di precedenza basso e una base sostanzialmente più rigorosa rispetto a quella predefinita del dominio.

Se nessuna delle due viene rivista regolarmente, il risultato è prevedibile: password deboli o con vita troppo lunga, account esentati dai controlli normali e impostazioni di autenticazione legacy che facilitano l'abuso delle credenziali una volta che un attaccante ottiene un punto d'appoggio.

La catena di attacco

Fase 1 - Enumerare gli account deboli

Qualsiasi utente di dominio autenticato può interrogare AD per trovare account con impostazioni di password deboli:

# Account con password che non scadono mai
Get-ADUser -Filter {PasswordNeverExpires -eq $true} -Properties PasswordNeverExpires, PasswordLastSet |
    Select-Object SamAccountName, PasswordLastSet | Sort-Object PasswordLastSet

# Account per cui non è richiesta alcuna password
Get-ADUser -Filter {PasswordNotRequired -eq $true} -Properties PasswordNotRequired |
    Select-Object SamAccountName

# Account con password nel campo descrizione
Get-ADUser -Filter * -Properties Description |
    Where-Object {$_.Description -match "pass|pwd|mdp|mot de passe|contrasena"} |
    Select-Object SamAccountName, Description

Fase 2 - Verificare l'esposizione ai protocolli legacy

# Verificare se WDigest è abilitato
Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest -Name UseLogonCredential

# Verificare il livello di compatibilità NTLM
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LmCompatibilityLevel
# I valori 0-2 consentono NTLMv1; il valore 5 impone solo NTLMv2

Fase 3 - Raccogliere e crackare

Con WDigest abilitato, una compromissione locale che raggiunge LSASS può esporre direttamente credenziali in chiaro:

# Esempio Mimikatz quando WDigest è abilitato
sekurlsa::wdigest

Per password deboli o con vita troppo lunga, gli attaccanti possono anche crackare offline il materiale NTLM dopo un dump degli hash:

hashcat -m 1000 ntlm_hashes.txt /usr/share/wordlists/rockyou.txt

Fase 4 - Persistere tramite una scarsa igiene delle password

Gli account con PasswordNeverExpires sono obiettivi di persistenza duraturi. Se l'account è sensibile e la password non viene mai ruotata, l'attaccante mantiene un percorso di autenticazione valido finché un amministratore non lo reimposta esplicitamente.

Detection

Event ID di Windows

Segnali comportamentali

• Account con password più vecchie della finestra di rotazione approvata
• Account abilitati con PasswordNeverExpires o PasswordNotRequired
• Campi descrizione contenenti stringhe simili a credenziali
• WDigest abilitato su endpoint o server dove non è esplicitamente richiesto
• NTLMv1 ancora negoziato in ambienti che dovrebbero essere solo NTLMv2

Query di rilevamento SIEM (Elastic KQL)

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

Remediation

1. Applicare una policy password di dominio rigorosa

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

2. Correggere le password che non scadono mai

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

3. Correggere gli account senza password richiesta

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

4. Rimuovere le password dai campi descrizione

Get-ADUser -Filter * -Properties Description |
    Where-Object {$_.Description -match "pass|pwd|mdp"} | ForEach-Object {
        Set-ADUser -Identity $_ -Description ""
        Write-Host "Descrizione cancellata per: $($_.SamAccountName)"
    }

5. Disabilitare WDigest

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

Distribuite tramite GPO quando possibile: Computer Configuration > Administrative Templates > MS Security Guide > WDigest Authentication = Disabled

6. Imporre solo NTLMv2

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

Oppure tramite policy: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network security: LAN Manager authentication level = Send NTLMv2 response only. Refuse LM & NTLM

7. Distribuire Microsoft Entra Password Protection (ambienti ibridi)

Per i domini sincronizzati con Microsoft Entra ID, Microsoft Entra Password Protection on-premises blocca le password deboli a livello di domain controller durante i cambi e i reset password — colmando una lacuna che la policy di complessità integrata non copre: parole di dizionario, pattern di tastiera e termini specifici dell'organizzazione che soddisfano tecnicamente le regole di complessità ma sono facilmente indovinabili.

Il deployment ha due componenti: un servizio Password Protection Proxy che recupera le liste globali e personalizzate di password vietate da Microsoft Entra ID, e un DC Agent installato su ogni domain controller che applica localmente la policy memorizzata nella cache durante gli eventi di cambio e reset password. Il DC Agent continua ad applicare la policy dalla sua copia in cache anche se la connettività al proxy viene temporaneamente persa.

# Confermare che il DC Agent sia installato e registri gli eventi di enforcement
Get-EventLog -LogName "Microsoft-AADPasswordProtection-DCAgent/Admin" -Newest 20

Iniziate in modalità audit per stabilire una baseline di quante password esistenti verrebbero rifiutate prima di passare alla modalità enforced, e aggiungete termini specifici dell'organizzazione — nomi di brand, nomi di prodotto, nomi in codice di progetti interni — alla lista personalizzata vietata; la sola lista globale non li intercetterà.

Come EtcSec rileva questo

EtcSec verifica i controlli identitari legati alle password a ogni scansione AD.

PASSWORD_NEVER_EXPIRES segnala gli account abilitati con password che non scadono mai e aiuta a far emergere per prime le identità a rischio più elevato.

PASSWORD_POLICY_WEAK valuta la Default Domain Password Policy rispetto alla baseline scelta per lunghezza, complessità, cronologia ed età.

PASSWORD_NOT_REQUIRED identifica gli account per cui il flag PASSWD_NOTREQD è ancora impostato.

PASSWORD_IN_DESCRIPTION analizza le descrizioni della directory alla ricerca di stringhe simili a credenziali.

WDIGEST_ENABLED verifica la memorizzazione in cache delle credenziali in chiaro da parte di WDigest.

NTLMV1_ALLOWED evidenzia gli ambienti che consentono ancora la negoziazione NTLMv1.

Account che richiedono una gestione particolare

Non applicate la stessa remediation in modo indiscriminato a tutte le classi di account.

• Gli account di servizio spesso si rompono se resettate una password senza aggiornare il servizio, l'attività pianificata o l'application pool che ne dipende.
• Gli account tier-0 o break-glass non devono mantenere credenziali deboli o condivise solo perché usati raramente; richiedono una gestione più rigorosa, uno storage più rigoroso e un monitoraggio esplicito.
• Le identità amministrative condivise devono essere rimosse, non semplicemente ruotate. La rotazione non risolve il problema dell'accountability.
• Le applicazioni legacy che dipendono ancora da NTLMv1 o da una gestione debole delle password necessitano di un'eccezione a tempo determinato e di un piano di migrazione, non di una deroga permanente.

Come dovrebbe apparire una buona evidenza

Una revisione di hardening delle password è molto più facile da difendere quando il team conserva l'evidenza esatta che ha dimostrato l'avvenuta pulizia. Tra gli artefatti utili figurano l'export prima/dopo degli account con PasswordNeverExpires, l'elenco degli account che in precedenza avevano PasswordNotRequired, la conferma che WDigest è disabilitato su sistemi rappresentativi, e la nota su proprietario o migrazione per ogni account di servizio che necessita ancora di un'eccezione temporanea. Questa evidenza conta perché l'igiene delle password tende a peggiorare nel tempo attraverso eccezioni urgenti e scorciatoie applicative.

Validazione dopo la remediation

Chiudete il finding solo dopo aver rieseguito gli stessi passaggi di discovery che userebbe un attaccante:

• rieseguite i report PasswordNeverExpires e PasswordNotRequired e confermate che le eccezioni rimanenti sono intenzionali
• verificate che le eccezioni degli account di servizio siano documentate, assegnate a un proprietario e collegate a un piano di migrazione come l'adozione di gMSA
• controllate a campione sistemi rappresentativi per confermare che UseLogonCredential sia 0 dove WDigest dovrebbe essere disabilitato
• convalidate che LmCompatibilityLevel corrisponda al vostro piano di rollout solo NTLMv2 e che i sistemi legacy siano stati gestiti esplicitamente
• rieseguite la ricerca nei campi descrizione e confermate che le credenziali siano state rimosse e non semplicemente nascoste in un altro attributo

Controlli correlati

L'igiene delle password diventa molto più pericolosa quando si combina con Kerberoasting: come gli attaccanti crackano le password degli account di servizio, Account privilegiati obsoleti: un rischio nascosto in Active Directory, Monitoraggio di Active Directory: gli Event ID di sicurezza che contano, o Attacchi NTLM Relay: dirottare l'autenticazione in AD. Rivedete questi controlli nella stessa finestra di remediation per eliminare il percorso di attacco anziché un singolo sintomo.