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, incluso il modulo SEKURLSA::Pth.
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 detection MITRE per T1550.002 è corretta nell’impostazione: bisogna correlare attività anomala di NTLM LogonType 3 con contesto di processo, sessione e rete, invece di affidarsi a un singolo indicatore isolato.
Che cosa osservare
Pattern intorno a 4624
4624 è 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 è 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.
Mitigazione
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 spiega che Credential Guard protegge hash NTLM, TGT Kerberos e altri segreti isolandoli tramite virtualizzazione. È uno dei controlli più diretti contro le catene classiche di furto di credenziali che rendono possibile PtH.
Caveat importanti documentati da Microsoft:
- alcune funzionalità di autenticazione vengono bloccate, quindi le applicazioni devono essere testate prima del rollout
- Credential Guard non protegge account locali e account Microsoft nello stesso modo in cui protegge i segreti derivati dal dominio
- le credenziali fornite per autenticazione NTLM non sono completamente protette in ogni scenario
- Microsoft dichiara esplicitamente che non è consigliato abilitare Credential Guard sui domain controller
2. Usare Remote Credential Guard o Restricted Admin per i flussi RDP
Microsoft documenta due protezioni diverse per i workflow amministrativi basati su RDP.
Remote Credential Guard impedisce che le credenziali vengano inviate al dispositivo remoto ed è l’opzione preferita quando lo scenario la supporta.
Restricted Admin resta comunque utile. Microsoft lo raccomanda in particolare per scenari di supporto helpdesk, perché riduce l’esposizione di credenziali riutilizzabili e risorse utente verso un host remoto compromesso.
Caveat importanti dalla documentazione Microsoft:
- Remote Credential Guard funziona solo con RDP
- richiede Kerberos
- è supportato solo per connessioni dirette alla macchina target, non tramite RD Gateway o Connection Broker
- non può essere usato quando l’host remoto è unito solo a Microsoft Entra
- non copre tutti gli scenari di autenticazione, quindi restano necessari test di compatibilità
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 presenta esplicitamente Windows LAPS come protezione contro attacchi che sfruttano account locali per il movimento laterale, inclusa progressione di tipo PtH.
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 è molto chiara su questo punto: gli account ad alto valore devono usare PC dedicati. È 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 di questo gruppo non possono autenticarsi tramite NTLM, Digest o delega predefinita CredSSP, e che alcuni workflow legacy possono quindi non funzionare. È un controllo forte per gli account ad alto valore, ma non una modifica da applicare alla cieca.
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:
- Windows LAPS non distribuito
- WDigest abilitato
- NTLM Relay
- Account obsoleti e sovraprivilegiati
- Monitoraggio sicurezza AD
- Kerberoasting
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.
