Pass-the-Hash in Active Directory: rilevamento e mitigazione

Che cos’è il Pass-the-Hash?

Pass-the-Hash è una tecnica di autenticazione che riutilizza materiale di autenticazione derivato da NTLM rubato al posto della password in chiaro dell’utente. In pratica, l’attaccante sottrae materiale riutilizzabile da un sistema Windows compromesso e lo usa per accedere a un altro host o servizio come quell’utente.

In questo articolo il perimetro è volutamente ristretto: Windows, Active Directory, NTLM e movimento laterale. Non è un articolo generico sul furto di credenziali. Il focus è il modello operativo specifico che rende Pass-the-Hash ancora rilevante negli ambienti AD enterprise: una workstation o un server compromesso, materiale di autenticazione riutilizzabile presente su quel sistema e un secondo host che accetta ancora autenticazione basata su NTLM.

Questa distinzione conta perché Pass-the-Hash viene spesso confuso con tecniche adiacenti:

Password spraying prova password comuni contro molti account e non richiede hash rubati.
Pass-the-Ticket riutilizza ticket Kerberos rubati, non materiale derivato da NTLM.
Overpass-the-Hash parte da materiale derivato da NTLM per ottenere materiale di autenticazione Kerberos e poi pivotare verso accesso basato su Kerberos.
Kerberoasting richiede service ticket e li cracka offline per recuperare le password degli account di servizio.

Pass-the-Hash è quindi un problema distinto: l’attaccante possiede già materiale di autenticazione riutilizzabile e non ha bisogno della password in chiaro per continuare a muoversi.

Come funziona il Pass-the-Hash

MITRE classifica Pass-the-Hash come T1550.002, sottotecnica di Use Alternate Authentication Material. L’idea di fondo è semplice: dopo un logon, Windows e alcuni flussi di autenticazione mantengono materiale di autenticazione che in alcuni casi può essere riutilizzato se un attaccante riesce a sottrarlo.

Negli ambienti Windows, NTLM resta il motivo principale per cui Pass-the-Hash è ancora operativamente rilevante. Se un target remoto accetta NTLM, l’attaccante può talvolta presentare materiale derivato da NTLM rubato e autenticarsi senza conoscere la password in chiaro. È proprio per questo che ridurre l’uso di NTLM e ridurre i punti in cui credenziali riutilizzabili atterrano sono difese fondamentali.

Nella pratica, il materiale riutilizzabile proviene più spesso da uno di questi percorsi:

Memoria LSASS su un endpoint o server compromesso, dopo il logon della vittima
Hive SAM / SECURITY per il materiale associato agli account locali del sistema
Account amministratore locale condivisi riutilizzati su più sistemi
Credential dumping dopo che l’attaccante ha già ottenuto privilegi di amministratore locale o esecuzione equivalente su un host

La documentazione Microsoft su Credential Guard è particolarmente utile qui, perché spiega in modo preciso che cosa la funzionalità protegge davvero: segreti NTLM, Kerberos e Credential Manager isolati tramite virtualizzazione invece di rimanere solo nello spazio di memoria normale di LSASS. Questo non elimina ogni rischio di credential theft, ma cambia in modo sostanziale la superficie di attacco delle catene PtH classiche.

Prerequisiti per un attacco Pass-the-Hash riuscito

Pass-the-Hash di solito funziona solo quando si allineano più condizioni.

1. L’attaccante ha già compromesso un host Windows

Pass-the-Hash raramente è la mossa iniziale. In genere l’attaccante parte da phishing, malware, accesso remoto esposto, scarsa igiene dei privilegi locali o un altro vettore iniziale. PtH diventa poi una tecnica di movimento laterale.

2. Sul sistema compromesso è presente materiale di autenticazione riutilizzabile

Questo è il requisito centrale. Se account privilegiati fanno logon su sistemi meno fidati, se gli amministratori usano RDP senza protezioni più forti oppure se i server accumulano segreti amministrativi riutilizzabili in LSASS, l’attaccante ha qualcosa da rubare.

3. Il target successivo accetta ancora autenticazione NTLM

La tecnica diventa molto più difficile se l’ambiente ha ridotto la dipendenza da NTLM, ha irrobustito i flussi di amministrazione remota o ha spostato i percorsi critici lontano da autenticazione riutilizzabile basata su NTLM.

4. La credenziale compromessa conserva diritti significativi altrove

Un hash rubato di un account poco privilegiato serve a poco. Il materiale davvero pericoloso è quello di un amministratore locale riutilizzato su più endpoint, di un account helpdesk con ampia portata o di un account AD privilegiato che effettua logon su server membri.

5. L’igiene amministrativa è abbastanza debole da consentire una catena di salti

Per questo Pass-the-Hash è strettamente legato al movimento laterale e non solo al furto di credenziali. Se le password degli amministratori locali sono uniche, se gli amministratori usano workstation dedicate e se le credenziali privilegiate non atterrano su sistemi di tier inferiore, l’attaccante perde il percorso che rende PtH davvero utile.

La catena di attacco

Una sequenza tipica di Pass-the-Hash in un ambiente AD assomiglia a questa.

Passo 1 - Ottenere esecuzione su un primo host

L’attaccante compromette una workstation o un server tramite phishing, malware, software vulnerabile o un percorso di accesso già esistente.

Passo 2 - Dump del materiale riutilizzabile

Una volta ottenuti i privilegi necessari su quell’host, l’attaccante punta a LSASS o agli archivi locali di credenziali per estrarre materiale riutilizzabile. MITRE collega esplicitamente strumenti come Mimikatz all'uso di Pass-the-Hash: il suo modulo SEKURLSA::Pth «può impersonare un utente, con solo un hash della password, per eseguire comandi arbitrari».

Passo 3 - Identificare l’account migliore da riutilizzare

L’attaccante non ha bisogno di tutti gli account. Gli serve l’account che apre il passo successivo. Negli ambienti reali questo significa spesso:

un account amministratore locale riutilizzato
un’identità helpdesk o di amministrazione endpoint
un account di amministrazione server che ha toccato molti host
un account AD privilegiato che non avrebbe mai dovuto finire su quell’endpoint

Passo 4 - Autenticarsi verso un altro host tramite un percorso che accetta ancora NTLM

A questo punto l’attaccante si muove lateralmente tramite protocolli amministrativi, creazione remota di servizi, accesso SMB amministrativo, WMI, task pianificati o altri percorsi di gestione Windows che ancora accettano quel materiale riutilizzato.

Passo 5 - Ripetere fino a raggiungere un tier più privilegiato

Il rischio di Pass-the-Hash non è un singolo salto. Il rischio è la catena. Una workstation compromessa porta a un altro contesto amministrativo, poi a un server di gestione, poi a un sistema dove sono presenti credenziali di maggior valore e infine al controllo di dominio o di foresta. È la stessa logica operativa descritta più in generale in percorsi di attacco AD: ogni confine di credenziali debole rende il salto successivo più facile.

Pass-the-Hash vs Overpass-the-Hash vs Pass-the-Ticket

Queste tecniche sono correlate, ma non sono intercambiabili.

Pass-the-Hash resta centrato su materiale di autenticazione derivato da NTLM e su percorsi di accesso che continuano ad accettare NTLM.

Overpass-the-Hash parte da materiale derivato da NTLM ma lo usa per ottenere materiale di autenticazione Kerberos, pivotando poi verso accesso basato su Kerberos.

Pass-the-Ticket non usa materiale derivato da NTLM; riutilizza direttamente ticket Kerberos rubati.

Questa distinzione conta sia per la detection sia per la remediation. Se i difensori schiacciano tutto sotto un unico concetto, di solito costruiscono una strategia di rilevamento debole e applicano i controlli sbagliati al percorso sbagliato.

Rilevamento

Non esiste un singolo evento Windows che dica “questo è stato Pass-the-Hash”. Una strategia utile di rilevamento è una strategia di correlazione.

La strategia di rilevamento Windows di MITRE per T1550.002 è corretta nell'impostazione: segnala autenticazioni NTLM LogonType 3 anomale che si verificano senza un evento di logon di dominio corrispondente, correlate al contesto di processo, sessione e rete, invece di affidarsi a un singolo indicatore isolato.

Che cosa osservare

Pattern intorno a 4624

4624 (An account was successfully logged on — un account ha effettuato correttamente il logon) è utile quando interessa capire dove compare la sessione, quale tipo di logon viene usato e quale contesto di account risulta inatteso su quel sistema.

Esempi ad alto valore:

un logon di rete che colloca un’identità amministrativa su un host che tocca raramente
movimento laterale ripetuto da una workstation compromessa verso più peer o server
lo stesso contesto di amministratore locale che compare su più endpoint

4672 sul sistema di destinazione

4672 (Special privileges assigned to new logon — privilegi speciali assegnati a un nuovo logon) è utile quando un nuovo logon riceve privilegi speciali sul sistema di destinazione. Non è un rilevatore PtH da solo, ma aiuta a capire quali logon remoti contano davvero.

Contesto NTLM dove disponibile

Se la tua telemetria espone contesto di autenticazione NTLM, quel dato è prezioso perché PtH vive o muore sui percorsi che ancora accettano NTLM. L’obiettivo non è generare alert su ogni evento NTLM. L’obiettivo è identificare attività amministrativa basata su NTLM inattesa, che coinvolge account, sistemi o traiettorie che non si vedono normalmente insieme.

Movimento privilegiato anomalo fra host

I segnali più forti spesso derivano dal comportamento, non da un solo event ID:

la stessa identità amministrativa che compare su più host in un intervallo breve
contesto di amministratore locale riutilizzato su host che dovrebbero avere password locali uniche
attività amministrativa che parte da una workstation al di fuori del normale flusso admin

Segnali EDR di credential dumping e accesso a LSASS

Pass-the-Hash dipende di solito da un precedente furto di credenziali. Se l’EDR mostra accesso sospetto a LSASS, comportamento di credential dumping e poi attività amministrativa remota dallo stesso host, questa correlazione vale spesso più di una regola basata su un singolo evento.

Un framing corretto della detection

Non impostare il rilevamento come “4624 significa Pass-the-Hash”. Un framing migliore è:

comportamento sospetto di accesso a credenziali sull’host A
seguito da logon remoto o attività amministrativa basata su NTLM sull’host B
usando un contesto di account che non corrisponde né al sistema sorgente abituale né al normale workflow amministrativo

È a questo livello che PtH viene realmente individuato in pratica.

Dipendenza dal monitoraggio

Se il monitoraggio AD e Windows è debole, questa tecnica sarà facile da perdere. Ecco perché il monitoraggio della sicurezza AD rientra nella stessa famiglia di controlli della detection del Pass-the-Hash.

Remediation

La mitigazione di Pass-the-Hash non è un’unica impostazione. È una strategia per ridurre i luoghi in cui esistono credenziali riutilizzabili, ridurre i percorsi che accettano ancora NTLM e limitare fino a dove può viaggiare un contesto amministrativo rubato.

1. Abilitare Credential Guard dove supportato

Microsoft dichiara che Credential Guard protegge gli hash delle password NTLM, i Ticket Granting Ticket (TGT) Kerberos e le credenziali che le applicazioni memorizzano come credenziali di dominio, isolandoli tramite sicurezza basata sulla virtualizzazione. È uno dei controlli più diretti contro le catene classiche di furto di credenziali che rendono possibile PtH.

Prima di pianificare un rollout, verifica cosa è già attivo. A partire da Windows 11, versione 22H2 e Windows Server 2025, Credential Guard è abilitato per impostazione predefinita sui sistemi joinati al dominio che soddisfano i requisiti hardware e di licenza e che non sono domain controller. In molti ambienti attuali il lavoro consiste nel confermare che sia ancora attivo, non nell’attivarlo da zero.

Caveat importanti documentati da Microsoft, dai limiti di protezione di Credential Guard:

alcune funzionalità di autenticazione vengono bloccate, quindi le applicazioni devono essere testate prima del rollout
gli account locali e gli account Microsoft non sono protetti. Credential Guard copre i segreti derivati dal dominio, quindi il materiale degli account locali dietro un amministratore locale riutilizzato resta esposto
le credenziali fornite per l’autenticazione NTLM non sono protette: Microsoft dichiara che se a un utente viene richiesto di inserire credenziali per l’autenticazione NTLM e le inserisce, tali credenziali sono vulnerabili e possono essere lette dalla memoria LSASS
anche i ticket di servizio Kerberos non sono protetti; è protetto solo il TGT Kerberos
Microsoft dichiara esplicitamente che abilitare Credential Guard sui domain controller non è consigliato: non aggiunge sicurezza in quel contesto e può causare problemi di compatibilità delle applicazioni

2. Usare Remote Credential Guard o Restricted Admin per i flussi RDP

Microsoft documenta due protezioni diverse per i workflow amministrativi basati su RDP, e attribuisce a entrambe la capacità di prevenire il Pass-the-Hash. Quale usare dipende da quanto ritieni affidabile l’host remoto.

Remote Credential Guard reindirizza le richieste Kerberos verso il dispositivo che avvia la connessione, così né la credenziale né i suoi derivati vengono mai trasmessi all’host remoto. È adatta per connessioni verso un host che consideri affidabile.

Restricted Admin è l’opzione che Microsoft raccomanda per gli scenari di supporto helpdesk, ed è il punto più spesso interpretato al contrario. Microsoft dichiara che Remote Credential Guard non è consigliato per il lavoro di helpdesk: se la sessione viene aperta verso un client già compromesso, l’attaccante può usare quel canale aperto per creare sessioni per conto dell’utente e raggiungere le sue risorse per un periodo limitato dopo la disconnessione della sessione. Per l’helpdesk, Microsoft indica che le connessioni RDP dovrebbero essere avviate solo con il parametro /RestrictedAdmin.

Caveat importanti dalla documentazione Microsoft:

Remote Credential Guard funziona solo con RDP
il server e il client devono autenticarsi tramite Kerberos, e Remote Credential Guard non consente il fallback a NTLM, perché esporrebbe le credenziali
è supportato solo per connessioni dirette alla macchina di destinazione, non tramite Remote Desktop Connection Broker o Remote Desktop Gateway
l’host remoto deve essere unito a un dominio Active Directory; non può essere usato per connettersi a un dispositivo unito solo a Microsoft Entra ID (un client unito a Microsoft Entra può comunque connettersi a un host unito ad AD)
non supporta l’autenticazione composita (compound authentication), quindi restano necessari test di compatibilità
anche Restricted Admin ha un costo: richiede l’appartenenza al gruppo Administrators sull’host remoto e non offre single sign-on verso altri sistemi

3. Eliminare il riuso delle password di amministratore locale con Windows LAPS

Le password locali condivise sono uno dei modi più semplici per rendere scalabile Pass-the-Hash. Microsoft cita «la protezione contro gli attacchi pass-the-hash e di spostamento laterale» come primo vantaggio di Windows LAPS. Distribuisci il Windows LAPS integrato invece del vecchio MSI Microsoft LAPS, deprecato da Microsoft a partire da Windows 11 23H2.

Se la stessa password amministratore locale esiste su decine o centinaia di endpoint, la compromissione di un solo sistema può trasformarsi in una campagna ampia di movimento laterale. Windows LAPS non distribuito va quindi trattato come un’esposizione direttamente legata a PtH, non come un semplice tema di igiene.

4. Evitare che credenziali privilegiate atterrino su host meno fidati

La documentazione Microsoft su Credential Guard è diretta su questo punto. Credential Guard non impedisce a un attaccante con malware sul PC di usare i privilegi associati a una credenziale qualsiasi; per questo Microsoft raccomanda «l'uso di PC dedicati per gli account ad alto valore, come gli IT Pro e gli utenti con accesso a risorse di alto valore». È uno dei controlli anti-PtH più pratici, perché riduce la probabilità che materiale di autenticazione privilegiato finisca su workstation generaliste.

Questo può assumere diverse forme:

workstation amministrative dedicate
jump host amministrativi con perimetro di ruolo rigoroso
amministrazione a tier che impedisce ai sistemi di livello inferiore di raccogliere credenziali di livello superiore
identità amministrative separate invece di uso quotidiano privilegiato

5. Ridurre l’uso di NTLM dove possibile

Pass-the-Hash resta operativamente utile perché NTLM resta operativamente utile. Se percorsi critici di amministrazione dipendono ancora da NTLM, l’attaccante mantiene più spazio di manovra. Ridurre NTLM, eliminare dipendenze inutili ed evitare fallback silenziosi abbassa quindi direttamente l’esposizione a PtH.

Per lo stesso motivo, PtH e gli attacchi NTLM Relay dovrebbero essere valutati insieme. Sono tecniche diverse, ma entrambe sopravvivono grazie allo stesso debito di protocollo.

6. Proteggere gli account che vale davvero la pena rubare

Per le identità più privilegiate conviene considerare controlli che rendano l’uso di NTLM e lo storage di segreti riutilizzabili molto meno accettabili dal punto di vista operativo:

evitare il logon di account privilegiati su sistemi generalisti
usare il gruppo Protected Users quando l’ambiente può sostenere le relative restrizioni
rivedere gli account obsoleti e sovraprivilegiati e rimuovere identità datate che mantengono una portata eccessiva
rafforzare la sicurezza delle password in Active Directory affinché pratiche deboli sulle password non amplifichino l’impatto di un singolo contesto amministrativo compromesso

Protected Users è potente, ma non è gratuito. Microsoft documenta che i membri non possono autenticarsi tramite NTLM, non possono usare la crittografia DES o RC4 nella preautenticazione Kerberos, non possono essere oggetto di delega vincolata o non vincolata, e non possono rinnovare i TGT Kerberos oltre una durata iniziale di quattro ore. Sul dispositivo, CredSSP e Windows Digest smettono di memorizzare nella cache le credenziali in chiaro, NTLM smette di memorizzare nella cache la funzione unidirezionale NT, e il logon offline smette di funzionare. Microsoft avverte inoltre di non aggiungere membri di Domain Admins o Enterprise Admins prima di eseguire test, perché è possibile bloccare quegli account. Questo lo rende un controllo forte per gli account ad alto valore, ma non una modifica da applicare senza validazione.

Validazione dopo l’hardening

Non chiudere la remediation del Pass-the-Hash solo perché è stato abilitato un singolo controllo. Devi validare il percorso end-to-end.

confermare che gli account privilegiati non effettuino più logon su sistemi di tier inferiore che espongono il loro materiale di autenticazione
verificare che Windows LAPS ruoti davvero password amministratore locale uniche sui sistemi nel perimetro
testare la compatibilità di Credential Guard su sistemi rappresentativi prima del rollout esteso e confermare poi che resti abilitato
validare che i workflow amministrativi RDP usino davvero Remote Credential Guard o Restricted Admin dove previsto
rivedere se i percorsi amministrativi residui dipendono ancora da NTLM o da fallback silenziosi
testare se un endpoint compromesso può ancora raggiungere altri sistemi usando un contesto amministratore locale riutilizzato

Il corretto criterio di successo non è “abbiamo attivato un controllo”. Il corretto criterio di successo è: “un singolo contesto amministrativo rubato non consente più all’attaccante di percorrere la stessa catena”.

Come EtcSec rileva l’esposizione correlata

EtcSec non ha bisogno di un tag di tassonomia artificiale per Pass-the-Hash. Il valore sta nelle esposizioni correlate che rendono PtH praticabile.

Le famiglie di controllo più rilevanti intorno a PtH sono:

Presi insieme, questi controlli mostrano se l’ambiente conserva ancora gli ingredienti che permettono a una credenziale Windows rubata di trasformarsi in una catena di movimento laterale.

Controlli correlati

Pass-the-Hash raramente è l’unico problema di identità dell’ambiente. Se vuoi ridurre il movimento reale di un attaccante e non solo migliorare un singolo punto di una checklist, conviene rivedere PtH insieme a Windows LAPS non distribuito, WDigest abilitato, gli attacchi NTLM Relay, gli account obsoleti e sovraprivilegiati, il monitoraggio sicurezza AD e il Kerberoasting. Sono questi controlli adiacenti a determinare se Pass-the-Hash rimane una tecnica realmente praticabile nel tuo ambiente AD.