What Is WDigest abilitato?
WDigest abilitato significa che un sistema torna a conservare materiale di autenticazione riutilizzabile collegato a WDigest dentro LSASS, quando l’obiettivo difensivo dovrebbe essere ridurre la quantità di segreti sfruttabili in memoria. La guidance Microsoft legata al Security Advisory 2871997 mirava proprio a rendere più difficile il furto di credenziali sui sistemi Windows joined al dominio. Uno dei punti di hardening più pratici è assicurarsi che UseLogonCredential non riattivi la memorizzazione di segreti WDigest in memoria.
Il rischio conta perché WDigest non è solo una nota di protocollo ormai superata. La documentazione Microsoft spiega che supplementalCredentials può contenere Primary:WDigest, descritto come materiale crittografico derivato dalla password in chiaro per il protocollo Digest. Se un team riabilita l’archiviazione WDigest su un host, aumenta la probabilità che una compromissione locale esponga credenziali riutilizzabili che non dovrebbero trovarsi in LSASS.
Per questo WDigest abilitato va considerato insieme a Sicurezza password AD: configurazioni errate che contano, Password nei campi descrizione AD: rilevazione e bonifica e Account obsoleti e sovraprivilegiati in AD. In tutti questi casi il problema non è soltanto un’impostazione debole, ma il fatto che materiale riutilizzabile sia più facile da rubare e riutilizzare di quanto l’organizzazione pensi.
How WDigest abilitato Works
Microsoft documenta UseLogonCredential sotto il percorso WDigest come il controllo che impedisce a WDigest di memorizzare credenziali in memoria. Quando la configurazione viene riattivata, materiale di autenticazione torna disponibile a codice che riesce a raggiungere LSASS con privilegi sufficienti.
La logica di hardening è semplice:
- se l’archiviazione WDigest è disabilitata, un attaccante con compromissione locale deve trovare altri segreti riutilizzabili
- se l’archiviazione WDigest è abilitata, l’host offre una superficie di credential theft più ricca del necessario
Il Security Advisory 2871997 mette in evidenza anche il gruppo Protected Users. I suoi membri non possono autenticarsi con NTLM, Digest Authentication o CredSSP, e le loro password non vengono trattate allo stesso modo sui sistemi supportati. Questo non sostituisce la disattivazione di WDigest, ma persegue lo stesso obiettivo: ridurre la quantità di materiale riutilizzabile disponibile dopo una compromissione locale.
| Stato | Significato operativo | Perché conta |
|---|---|---|
UseLogonCredential assente o disabilitato | WDigest non mantiene segreti riutilizzabili in memoria | Superficie LSASS più piccola |
UseLogonCredential abilitato | Materiale collegato a WDigest torna a essere memorizzato | Il furto di credenziali diventa più semplice |
| Protected Users per gli admin sensibili | NTLM, Digest e CredSSP vengono limitati | Riduce il riuso per le identità più critiche |
The Attack Chain
Passo 1 - Ottenere admin locale o SYSTEM su un host Windows
WDigest abilitato raramente è il vettore iniziale. Diventa pericoloso quando l’attaccante dispone già di admin locale, SYSTEM o esecuzione equivalente su una macchina. A quel punto la differenza tra un host ben protetto e uno debole è quanta autenticazione riutilizzabile resta ancora in LSASS.
Passo 2 - Leggere LSASS e recuperare credenziali utili
Quando l’impostazione è abilitata, l’attaccante non ha bisogno di un ambiente completamente compromesso. Basta un singolo host dove la compromissione locale possa trasformarsi in accesso a credenziali.
# Verifica difensiva dell'impostazione WDigest
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' -Name UseLogonCredential
Per il team difensivo, il punto importante non è lo strumento di dump, ma il fatto che l’host mantenga in memoria più materiale riutilizzabile del necessario.
Passo 3 - Riutilizzare il segreto su sistemi vicini
Se la credenziale rubata appartiene a un admin privilegiato, a un operatore helpdesk o a un account di servizio con ampia portata, l’attaccante può muoversi rapidamente verso altri sistemi o ulteriori percorsi di privilegio. Per questo WDigest abilitato raramente è un finding isolato: amplifica l’impatto di altri errori di controllo accessi.
La stessa logica compare in Percorsi di attacco AD verso Domain Admin: qualsiasi impostazione che trasformi un host compromesso in una fonte di credenziali riutilizzabili accorcia il percorso verso obiettivi più critici.
Detection
Non serve intuizione per rilevare questa esposizione. Microsoft fornisce già il punto di controllo principale: il valore di registro UseLogonCredential. Una review seria dovrebbe anche verificare se gli admin più sensibili restano fuori da Protected Users e se la telemetria sarebbe in grado di individuare rapidamente modifiche al registro o accessi sospetti a LSASS.
| Indicatore | Fonte | Cosa verificare |
|---|---|---|
UseLogonCredential abilitato | Review del registro | L’host sta riattivando esplicitamente l’archiviazione WDigest? |
| Mancano i controlli dell’Advisory 2871997 | Review di baseline e patch | Gli host più vecchi sono stati davvero portati a una baseline più sicura? |
| Admin privilegiati fuori da Protected Users | Review del gruppo AD | Le identità critiche usano ancora percorsi di autenticazione più deboli? |
| Alert su LSASS o sul registro | EDR, auditing del registro, detection di credential theft | Una riattivazione sarebbe visibile rapidamente? |
# Controllo rapido di WDigest su un host
reg query HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential
# Verificare la membership del gruppo Protected Users
Get-ADGroupMember 'Protected Users'
Il controllo del registro è il modo più rapido per iniziare, ma non dovrebbe essere l’unico. In una review di incidente, confermate anche se il valore compare su admin workstation, jump host o server dove si collegano identità ad alto valore.
Perché questa impostazione torna nell’ambiente
WDigest raramente ricompare perché un team vuole deliberatamente meno protezione. Più spesso torna per abitudini di troubleshooting: un tecnico copia un workaround vecchio, una gold image conserva il valore, oppure uno script di supporto viene riusato senza verificare se la dipendenza applicativa originaria esiste ancora. Questo schema cambia il tipo di review necessario. La domanda non è soltanto “la chiave è impostata?”, ma anche “quale baseline, quale script o quale owner la sta reintroducendo?”.
Negli ambienti maturi questa verifica dovrebbe includere admin workstation, jump host e qualsiasi tier server su cui le identità privilegiate lavorano in modo interattivo. Se la configurazione è pulita sui client comuni ma resta debole sugli host dove vivono le credenziali più preziose, il rischio residuo resta elevato.
Remediation
💡 Quick Win: se un host non ha una dipendenza giustificata dallo storage WDigest, disabilitatelo e verificate che la configurazione non ricompaia tramite baseline vecchie, immagini base o script di supporto.
Un percorso di remediation pulito è di solito breve:
- Inventariare dove
UseLogonCredentialè abilitato. Partite da admin workstation, jump host e server sensibili. - Disabilitare l’impostazione.
Sui sistemi supportati, impostate
UseLogonCredentiala0o tornate al default della baseline moderna. - Rivedere le dipendenze legacy. Se un team sostiene di aver bisogno di WDigest, chiedete un flusso applicativo concreto e una data di ritiro dell’eccezione.
- Proteggere le identità di alto valore. Usate Protected Users quando è operativamente possibile per gli account privilegiati.
- Monitorare la deriva. Allertate su modifiche nel percorso di registro WDigest e su accessi sospetti a LSASS.
# Esempio di remediation locale su un host Windows
New-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' -Name UseLogonCredential -Type DWord -Value 0
Validate Before You Close the Finding
La remediation non dovrebbe essere considerata chiusa solo perché il valore è stato impostato a 0 una volta. Validate lo stato del registro su sistemi rappresentativi, confermate che un eventuale flusso applicativo critico continui a funzionare se esiste una dipendenza legittima e assicuratevi che la vostra detection stack avviserebbe se UseLogonCredential venisse riattivato in futuro. È proprio il tipo di controllo che sembra banale finché un incidente non dimostra che era tornato silenziosamente mesi prima.
Vale la pena rivedere anche il lato identità. Se gli admin privilegiati continuano a fare logon su superfici troppo ampie e senza protezioni più forti, una singola eccezione WDigest può essere molto più grave del previsto.
Dove controllare prima la deriva di WDigest
La review di WDigest dovrebbe iniziare dai sistemi in cui si collegano davvero le identità di maggior valore. La documentazione di supporto Microsoft sull’hardening delle credenziali chiarisce che il comportamento di default cambia in base alla generazione di Windows. Su Windows 7, Windows Server 2008 R2, Windows 8 e Windows Server 2012, UseLogonCredential resta a 1 per impostazione predefinita dopo l’aggiornamento se l’organizzazione non lo forza a 0. Su Windows 8.1, Windows Server 2012 R2 e versioni successive, invece, il caching WDigest è disabilitato per default quando la voce di registro non esiste. Questa differenza spiega perché vecchie immagini, script legacy o baseline di supporto continuino a reintrodurre il rischio.
In pratica conviene verificare separatamente admin workstation, jump host e server che ospitano logon privilegiati. Se il build moderno è pulito ma una legacy image usata per l’amministrazione reimposta UseLogonCredential=1, il rischio reale rimane concentrato proprio sugli host con le credenziali più preziose.
Un altro controllo utile consiste nel confrontare baseline documentata, image pipeline e stato locale reale dei sistemi in produzione. Quando queste tre fonti non descrivono lo stesso valore, il problema è spesso organizzativo più che tecnico. Capire quale script, quale eccezione o quale artefatto di build continua a reintrodurre la chiave è spesso la parte più importante della remediation.
La review deve anche restare coerente con la guidance Microsoft su Protected Users. Il gruppo non corregge WDigest da solo, ma Microsoft specifica che i suoi membri non possono autenticarsi con NTLM, Digest Authentication o CredSSP. Controllare WDigest senza valutare dove lavorano interattivamente gli account privilegiati e se godono già di questa protezione lascia spesso fuori la parte più importante del rischio.
How EtcSec Detects This
EtcSec collega questo tema direttamente a WDIGEST_ENABLED. Il punto utile non è solo sapere se la chiave esiste da qualche parte, ma se gli host più importanti continuano a mantenere materiale riutilizzabile in LSASS e se l’eccezione ha un owner chiaro.
ℹ️ Note: EtcSec rileva automaticamente lo storage di credenziali WDigest durante le review Active Directory per aiutare i team a dare priorità ai sistemi in cui una compromissione locale esporrebbe le identità di maggior valore.
Official References
- Microsoft Security Advisory 2871997: Update to Improve Credentials Protection and Management
- Microsoft Support article for
UseLogonCredentialand WDigest credential storage behavior - Microsoft protocol documentation for
supplementalCredentialsandPrimary:WDigest
Related Reading
Rivedete questo tema insieme a Sicurezza password AD: configurazioni errate che contano, Password nei campi descrizione AD: rilevazione e bonifica, Account obsoleti e sovraprivilegiati in AD, Come auditare la sicurezza di Active Directory: checklist pratica per i team interni e Monitoraggio sicurezza AD: Event ID e SIEM. Questi temi aiutano a collegare una chiave di registro locale alla domanda più ampia su quali credenziali riutilizzabili siano ancora presenti nell’ambiente.
