• Guide, Sicurezza, Sistemi Operativi
• 21 Novembre 2025

In un mondo IT che corre verso Zero Trust, passwordless e autenticazioni moderne come OAuth2 e Kerberos, il solo sentire nominare NTLM fa spesso sollevare un sopracciglio. Eppure, continua a vivere, annidato nei sistemi Windows, nelle applicazioni legacy e in più infrastrutture di quanto si voglia ammettere.
Capirlo non è un esercizio accademico: è una verifica di maturità di sicurezza.

In questo articolo vediamo:

• che cos’è NTLM;
• come funziona;
• a cosa serve oggi;
• perché è ancora così diffuso;
• quali rischi introduce in un ambiente moderno;
• come individuarlo e, soprattutto, come disattivarlo in modo controllato.
• NTLM e Passwordless: quando il passato incontra il futuro
• Come evitare determinati problemi

Che cos’è NTLM?

NTLM (NT LAN Manager) è uno dei primi protocolli di autenticazione sviluppati da Microsoft per consentire agli utenti di accedere a risorse condivise all’interno delle reti Windows. Nasce nei primi anni ’90, in un’epoca in cui le infrastrutture erano composte da PC collegati in LAN semplici, domini NT 4.0 e applicazioni che vivevano interamente on-premise.

A differenza dei protocolli moderni, pensati per ecosistemi distribuiti, ibridi e basati su identità federate, NTLM è costruito su un modello estremamente basilare: un meccanismo di challenge-response basato sull’hash della password dell’utente.
È un sistema efficace per l’epoca, ma incapace di garantire le proprietà di sicurezza richieste oggi.

Un punto importante: NTLM non è un protocollo di Single Sign-On nel senso moderno del termine.
Consente sì di riutilizzare le credenziali in certi contesti, ma manca dei meccanismi avanzati di delega, mutua autenticazione e emissione di ticket che hanno reso Kerberos la spina dorsale della sicurezza Active Directory.

Nel tempo NTLM ha subito revisioni, ma la sua architettura di base è rimasta invariata:

• NTLMv1
  La versione originale.
  Oggi è considerata gravemente insicura, vulnerabile a:
  • cracking offline molto veloce degli hash;
  • attacchi pass-the-hash;
  • attacchi di relay quasi immediati;
  • assenza totale di protezioni crittografiche moderne.
    Microsoft stessa ne sconsiglia l’utilizzo da oltre un decennio.
• NTLMv2
  Introdotto per mitigare alcune debolezze della prima versione, aggiunge:
  • un meccanismo di hashing migliorato,
  • protezioni contro replay,
  • valori di challenge più robusti.
    È più resistente, sì, ma non arriva comunque ai livelli di sicurezza, scalabilità e flessibilità di Kerberos o delle identità federate moderne basate su token (SAML, OAuth2, OpenID Connect).

È importante ricordare che NTLM nasce in un mondo in cui:

• non esisteva Active Directory;
• le reti erano chiuse, spesso fisicamente isolate;
• l’autenticazione avveniva su sistemi locali o su singoli server;
• la minaccia era più “interna” che “remota”.

In quel contesto, NTLM era una soluzione sensata e relativamente sicura.
Il problema è che il mondo si è evoluto, mentre NTLM è rimasto quello di trent’anni fa e continua a funzionare per compatibilità retroattiva, non per modernità.

Come funziona

A livello logico, NTLM segue questo schema challenge–response:

• Richiesta di accesso
  Il client chiede accesso a una risorsa (file server, servizio, applicazione).
• Challenge dal server
  Il server risponde con un valore casuale (challenge).
• Calcolo della risposta
  Il client prende:
  • l’hash NT della password dell’utente, presente in locale;
  • combina challenge + hash;
  • genera una risposta crittografica (response) che invia al server.
• Verifica lato Domain Controller
  Il server gira challenge e response al Domain Controller:
  • il DC recupera l’hash NT della password dal proprio database;
  • rifà lo stesso calcolo;
  • se il risultato coincide → autenticazione riuscita.

La password in chiaro non viene mai inviata sulla rete, il che all’epoca era un buon passo avanti.
Il problema è che:

• l’hash NT è non saltato e facilmente utilizzabile per:
  • cracking offline (GPU, cloud, ecc.);
  • attacchi Pass-the-Hash (l’hash è la credenziale);
• NTLM non prevede una vera mutual authentication:
  • il client non verifica davvero l’identità del server;
• è relativamente semplice orchestrare attacchi relay, inoltrando una sessione NTLM verso un altro servizio.

In un contesto moderno, è come avere una porta blindata… con la chiave appesa di fianco.

A cosa serve ancora oggi

La risposta breve è semplice: NTLM serve a far funzionare tutto ciò che non si è ancora evoluto.
La risposta lunga, invece, è che NTLM sopravvive perché è diventato una sorta di “ammortizzatore di compatibilità” su cui molte infrastrutture fanno affidamento senza saperlo.

In una rete Windows moderna, quando qualcosa non riesce ad autenticarsi usando Kerberos o un metodo più recente, NTLM interviene come fallback silenzioso. Ed è proprio questa sua capacità di infilarsi tra le crepe che lo rende così difficile da estirpare.

Vediamo gli scenari principali in cui NTLM è ancora attivo:

1. Applicazioni legacy (troppe per essere un’eccezione)

Parliamo di vecchie applicazioni web, servizi client/server, gestionali scritti in .NET 2.0 o addirittura in ASP classico, tool interni non documentati e software di terze parti che non hanno mai ricevuto aggiornamenti per supportare Kerberos.

Spesso queste applicazioni:

• non gestiscono gli SPN,
• non supportano ticket Kerberos,
• funzionano solo con autenticazione integrata NTLM.

Il risultato? La loro sopravvivenza dipende interamente da NTLM. E fintanto che restano operative, NTLM non può essere disattivato.

2. Condivisioni SMB storiche e “mappature dimenticate”

Molte aziende hanno file server che funzionano da anni, con share configurate in epoche diverse da team diversi.
Alcune di queste condivisioni:

• sono mappate via GPO o via script antichi,
• usano credenziali memorizzate localmente,
• sono state create prima dell’introduzione delle policy moderne.

In centinaia di reti succede questo: togli NTLM → metà delle mappature SMB interne iniziano a generare errori di accesso.

Non perché “serva NTLM”, ma perché nessuno ha mai aggiornato quelle configurazioni per sfruttare Kerberos.

3. Ambienti multi-forest o trust mal configurati

Quando esistono più foreste AD collegate da trust, Kerberos dovrebbe occuparsi in modo elegante della delega cross-domain.
Ma basta che:

• un trust non sia configurato correttamente,
• le SPN non si risolvano,
• ci siano problemi DNS,
• il time sync non sia perfetto,

e Windows cade automaticamente nel piano B: NTLM.

In contesti complessi (fusioni, acquisizioni, forest legacy), NTLM diventa l’unico collante funzionante, anche se nessuno lo dice apertamente.

4. Autenticazione locale (account non di dominio)

Quando un utente accede con:

• un account locale della macchina,
• oppure un servizio usa credenziali locali memorizzate,

Kerberos non può essere utilizzato. In questi casi l’unica forma di autenticazione possibile è NTLM. Almeno fino a Windows Server 2025, che introduce il Kerberos Local Key Distribution Center (LocalKDC), progettato per permettere al protocollo Kerberos di essere usato anche per account locali (non solo in dominio) in scenari in cui tradizionalmente si usava NTLM.

Questo vale ancora oggi per:

• server stand-alone in DMZ,
• workstation non joinate,
• appliance Windows dedicate.

5. Device fuori dominio o configurati in modo incompleto

In una rete reale convivono:

• laptop non ancora joinati,
• postazioni BYOD,
• macchine virtuali temporanee,
• dispositivi mal configurati dal reparto IT,
• strumenti di terze parti che parlano SMB ma non conoscono Kerberos.

Ogni volta che un client non rispetta i prerequisiti per Kerberos (DNS, SPN, time sync, configurazione browser, ecc.), Windows tenta automaticamente NTLM.
È il suo modo di dire: “Kerberos non parte? Non importa, provo comunque a farti entrare.”

Un comportamento comodo, ma pericoloso: perché rende difficile distinguere ciò che è moderno da ciò che è rimasto nel passato tecnologico.

Perché questo è un problema

NTLM non è tanto un protocollo attivo “per volontà esplicita”, quanto una presenza fantasma: entra in scena solo quando qualcosa non è stato configurato nel modo corretto.

Questo significa che NTLM è spesso un sintomo, non la causa:

• sintomo di applicazioni non aggiornate,
• sintomo di SPN rotti,
• sintomo di trust mal gestiti,
• sintomo di share storiche mai riviste.

Ed è proprio questa sua natura invisibile che lo rende difficile da eliminare: NTLM mantiene in piedi cose che si vorrebbero rimuovere… ma che nessuno ha ancora mappato.

Perché è ancora così diffuso

Perché è comodo, compatibile e soprattutto perché:

• Kerberos richiede prerequisiti (SPN corretti, DNS sano, orologi sincronizzati).
• Le aziende spesso non sanno dove NTLM viene usato.
• Molti servizi non funzionano più appena lo disattivi, quindi nessuno lo disattiva.

È il classico “non si tocca per non rompere nulla”.

Perché è un rischio

NTLM è terreno fertile per attacchi moderni:

• Pass-the-Hash
  Rubi l’hash → autentichi senza password.
• Relay Attack
  Inoltri una richiesta NTLM verso un server diverso, senza compromettere il client.
• Crack offline degli hash
  Gli hash NT sono veloce cibo per GPU e cloud righe arcobaleno.
• Assenza di mutual authentication
  Il server non autentica il client e viceversa: male in qualunque scenario Zero Trust.

Come scoprire dove viene utilizzato

Prima regola: non si disattiva NTLM alla cieca. Serve mappare chi lo utilizza e per cosa.

I canali principali:

1. Log di sicurezza Windows (Event ID 4624)

I logon di tipo 3 (network) con AuthenticationPackageName = NTLM indicano autenticazioni NTLM verso il sistema.

Questi log, aggregati su un SIEM (es. Microsoft Sentinel), permettono di capire:

• quali server usano NTLM;
• quali account;
• da quali client.

2. Eventi specifici di auditing NTLM

Abilitando le policy di “Restrict NTLM: Audit” lato dominio, si ottengono event ID dedicati (NTLM in ingresso/uscita, blocchi, ecc.) che tracciano in modo chiaro le dipendenze da NTLM.

Inoltre, sarebbe opportune loggare anche le informazioni di Logon.

Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Audit Policies → Logon/Logoff → Audit Logon

Figura 1 – GPO Audit Logon

Figura 2 – GPO Security Options

Aprire Event Viewer sul DC.

Navigare a: Applications and Services Logs → Microsoft → Windows → NTLM. Tasto destro su Operational → Enable Log.

Figura 3 – Event Viewer

Qui di seguito riporto uno script che colleziona eventi NTLM da tutti i Domain Controller e li unisce in un unico report.

Il risultato sarà qualcosa del genere:

Figura 4 – Risultato esecuzione script

Invece questo script esporta gli eventi di logon NTLM dal Security Log del computer locale.

Il risultato sarà qualcosa del genere

Figura 5 – Risultato esecuzione script

Con un terzo script possiamo esportare gli eventi del log Microsoft-Windows-NTLM/Operational (audit NTLM).

Il risultato sarà qualcosa del genere

Figura 6 – Risultato esecuzione script

3. Analisi del traffico di rete

Con Wireshark o strumenti analoghi, puoi filtrare per NTLMSSP e vedere dove avvengono handshake NTLM.

4. Strumenti di sicurezza Microsoft

Soluzioni come Microsoft Defender for Identity o simili possono evidenziare pattern di autenticazione legacy e potenziali rischi legati a NTLM.

5. Script PowerShell di discovery

Script mirati sui Domain Controller e sui server principali aiutano a:

• estrarre e normalizzare gli eventi;
• costruire report su chi/che cosa usa NTLM;
• identificare le applicazioni critiche da migrare.

Volendo, si possono utilizzare gli script che ho utilizzato sopra che forniscono già una base per:

• creare un report mensile sull’uso di NTLM;
• alimentare un playbook SOC per monitorare riduzione/andamento;
• supportare l’esecutivo con numeri (“NTLM usage baseline → riduzione del X%”).

Stato attuale del supporto NTLM secondo Microsoft

Negli ultimi anni Microsoft ha iniziato un processo di deprecazione progressiva del protocollo NTLM, annunciando cambiamenti importanti che impatteranno tutti gli ambienti Windows, sia client che server.

Nella pagina ufficiale “Deprecated features in the Windows client”, Microsoft ha dichiarato che:

“All versions of NTLM, including LANMAN, NTLMv1, and NTLMv2, are no longer under active feature development and are deprecated.”

Questo significa che lo sviluppo attivo del protocollo è terminato e che NTLM è considerato a tutti gli effetti una tecnologia destinata a essere rimossa. Tuttavia, Microsoft chiarisce anche che la deprecazione non implica l’immediata eliminazione del supporto in tutti gli scenari.

Nel documento “Upcoming changes to NTLMv1 in Windows 11, version 24H2 and Windows Server 2025”, Microsoft ha annunciato un cambiamento cruciale:

• NTLMv1 è stato completamente rimosso da Windows 11 versione 24H2.
• NTLMv1 è stato rimosso anche da Windows Server 2025.

Il protocollo NTLMv2 rimane attualmente supportato, ma anch’esso è etichettato come deprecato e sarà rimosso in una futura release dei sistemi operativi Windows.

Microsoft ha inoltre pubblicato l’articolo tecnico “Mitigating NTLM Relay Attacks by Default”, in cui descrive come Windows Server 2025 introduca una serie di mitigazioni automatiche contro gli attacchi NTLM Relay, attive di default su vari servizi (come LDAP, ADCS ed Exchange). Tra queste rientrano il rafforzamento del Channel Binding e dell’Extended Protection, misure pensate per ridurre ulteriormente la superficie di attacco del protocollo.

Nel complesso, gli annunci Microsoft indicano chiaramente una direzione definitiva: NTLM è una tecnologia destinata alla dismissione.
Per questo motivo è fondamentale iniziare, o accelerare, la migrazione verso Kerberos e verso sistemi di autenticazione più moderni e sicuri.

Come disattivarlo

L’obiettivo non dev’essere “spegnere NTLM domani”, ma ridurlo progressivamente fino a eliminarlo.

Il percorso tipico:

Step 1 – Abilita l’auditing NTLM

Via Group Policy a livello di dominio: Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options

Le voci importanti:

• Network security: Restrict NTLM: Audit NTLM authentication in this domain
  Impostala in modalità audit per vedere chi usa cosa, senza bloccare traffico.

Raccogli log per almeno 30 giorni (meglio 60–90 per avere copertura di job mensili, ecc.).

Step 2 – Analizza chi dipende da NTLM

Una volta raccolti i log:

• Individua i server più coinvolti;
• gruppi di utenti/applicazioni che usano NTLM;
• pattern ricorrenti (es. una vecchia applicazione web, un file server specifico, un’app in DMZ).

Questa fase è anche un’ottima occasione per fare “pulizia storica” delle applicazioni legacy.

Step 3 – Migra a Kerberos o ad autenticazioni moderne

Per ridurre NTLM, spesso basta “sbloccare” Kerberos:

• sistemare gli SPN;
• correggere problemi DNS;
• garantire time sync;
• configurare correttamente “Intranet zone” e autenticazione integrata nei browser;
• per nuove applicazioni, usare direttamente autenticazioni moderne (OIDC, SAML, OAuth2).

Ogni servizio che passa a Kerberos o ad auth moderna è un pezzo di NTLM in meno.

Step 4 – Restringi NTLM gradualmente

Quando hai una buona visibilità, puoi iniziare a limitare:

• Network security: Restrict NTLM: NTLM authentication in this domain
  • prima con esclusioni mirate;
  • poi restringendo progressivamente fino a bloccare scenari non necessari.
• Network security: Restrict NTLM: Incoming NTLM traffic
  Per bloccare NTLM in ingresso su server specifici.
• Network security: LAN Manager authentication level
  Imposta:
  • Send NTLMv2 response only. Refuse LM & NTLM
    almeno per evitare LM e NTLMv1.

Step 5 – Monitoraggio post-cut e remediation

Dopo ogni cambio:

• monitora i log di errori di autenticazione;
• tieni d’occhio helpdesk e incident;
• documenta quali applicazioni sono state migrate, quali sono in eccezione, quali hanno deadlines di decommissioning.

NTLM e Passwordless: quando il passato incontra il futuro (e non si riconoscono)

Negli ultimi anni sempre più organizzazioni stanno introducendo sistemi di autenticazione passwordless, basati su FIDO2, Windows Hello for Business (WHfB) o chiavi di sicurezza hardware. L’obiettivo è chiaro: eliminare le password, ridurre drasticamente il rischio di furto di credenziali e muoversi verso un modello Zero Trust più solido.

Il problema? NTLM non è nato per un mondo senza password. E quando una tecnologia del 1993 incontra un endpoint del 2025, la conversazione raramente va liscia.

Il nodo fondamentale: NTLM ha bisogno della password

NTLM costruisce la sua autenticazione partendo da un elemento essenziale: l’hash NT ricavato dalla password dell’utente.

Se l’utente non ha più una password, perché sta usando FIDO2, WHfB o un meccanismo basato su chiavi, quell’hash semplicemente non esiste. E senza hash, il client non può generare la risposta crittografica richiesta dal protocollo NTLM.

Per questo motivo gli endpoint passwordless non possono autenticarsi tramite NTLM, nemmeno volendo.

Questo è uno dei rari casi in cui un protocollo legacy non è semplicemente “insicuro”: è proprio incompatibile con il paradigma moderno.

Cosa succede quando una risorsa richiede NTLM?

Qui il comportamento diventa interessante (e spesso frustrante).

Se un server, una condivisione SMB o un’applicazione legacy impone l’uso di NTLM, il client passwordless si trova davanti a un vicolo cieco:

1. prova a usare Kerberos → fallisce (perché il servizio non lo supporta);
2. prova a eseguire NTLM (fallback automatico di Windows) → impossibile;
3. l’autenticazione termina con un errore, spesso poco chiaro.

Il risultato per l’utente è un generico:

• “Accesso negato”
• “Impossibile connettersi alla risorsa”
• peggio: un prompt di credenziali che non potrà mai funzionare, perché non esiste una password da fornire.

Quando Kerberos fallisce la situazione peggiora. Gli endpoint passwordless funzionano perfettamente solo se l’ambiente Kerberos è integro: DNS corretto, SPN impostati, time sync ufficiale, trust funzionanti, configurazione dei browser per l’Intranet Zone, ecc.

Basta un singolo elemento fuori posto per far sì che Windows tenti un fallback su NTLM.

Ma NTLM, in questo scenario, non è utilizzabile.

Il risultato è una sceneggiatura ricorrente:

• Kerberos non parte → Windows dice “ok, provo NTLM” → NTLM non è disponibile → accesso negato.

Una catena di fallimenti silenziosi che spesso viene scambiata per:

• bug dell’applicazione,
• errore del file server,
• problemi di rete,
• “misterioso problema di autenticazione”.

In realtà è semplicemente incompatibilità tra passwordless e fallback legacy.

Gli scenari più frequenti di rottura

1. Condivisioni SMB che accettano solo NTLM

I file server più anziani o non aggiornati spesso richiedono NTLM. Un client passwordless può accedere solo via Kerberos; se qualcosa lo impedisce, l’accesso salta del tutto.

2. Applicazioni interne che usano autenticazione integrata “vecchio stile”

Molti gestionali aziendali inviano richieste NTLM per default. Un endpoint senza password non può completarli.

3. Ambienti ibridi Azure AD + On-prem

Con WHfB, soprattutto in modalità Cloud Kerberos Trust, è fondamentale che i Domain Controller siano aggiornati e aderenti ai requisiti Microsoft. In caso contrario il client cade in fallback → NTLM → fallisce.

4. Device fuori dominio o in configurazioni incerte

Laptop BYOD o macchine non joinate tentano NTLM quasi automaticamente → impossibile con FIDO2.

Un caso raro, ma molto critico

Questa incompatibilità emerge solo quando si incastrano tre condizioni contemporaneamente:

1. L’utente usa un metodo passwordless puro (FIDO2/WHfB).
2. Il servizio tenta NTLM invece di Kerberos.
3. Il client non ha un hash password da usare come chiave.

Quando queste tre variabili si allineano, ogni autenticazione che fa affidamento su NTLM diventa impraticabile. Non è un problema di sicurezza: è un problema di coerenza architetturale.

Come evitare questi problemi

Per far convivere passwordless e modern authentication senza intoppi è necessario:

• Assicurare che Kerberos funzioni sempre (DNS, SPN, time sync, trust).
• Eliminare NTLM dove possibile, soprattutto sulle risorse critiche o colpite da utenti passwordless.
• Aggiornare Domain Controller e configurazione WHfB, in particolare per Cloud Kerberos Trust.
• Evitare applicazioni che richiedono NTLM, migrandole a metodi moderni.
• Usare policy Restrict NTLM per impedire fallback non desiderati.

È un percorso graduale, ma inevitabile se si vuole distribuire WHfB o FIDO2 su larga scala.

In sintesi, l’incontro tra NTLM e passwordless è un perfetto esempio di “scontro generazionale” tecnologico:

• NTLM vive di hash password.
• Il passwordless elimina le password.
• Uno dei due, inevitabilmente, deve cedere.

E quando l’obiettivo è sicurezza, protezione dell’identità e aderenza a Zero Trust, è chiaro quale dei due debba andare in pensione.

Conclusioni

NTLM non è il male assoluto, è semplicemente un residuo storico.
Il problema è che oggi:

• compromette i principi Zero Trust,
• favorisce attacchi noti e automatizzati,
• sopravvive per pigrizia tecnologica.

Disattivarlo è possibile, ma richiede disciplina: discovery → audit → hardening → disable.

Stay tuned!