NTLM en 2026 : le protocole Windows qui refuse de mourir — et qui coûte des millions

CVE-2026-124194 vient de rappeler brutalement que NTLM, un protocole d'authentification créé dans les années 1980, est toujours actif dans la quasi-totalité des domaines Active Directory français. En 2026, avec un zero-day Outlook qui vole vos hachés NTLMv2 par simple prévisualisation d'email, il est temps d'avoir une conversation sérieuse sur pourquoi vous n'avez pas encore désactivé ce protocole — et comment le faire sans casser votre SI.

NTLM : un protocole conçu il y a 35 ans, toujours dominant en 2026

NT LAN Manager (NTLM) est un protocole d'authentification challenge-response développé par Microsoft à la fin des années 1980 pour les premiers réseaux Windows NT. Sa logique est simple : le serveur envoie un challenge aléatoire, le client y répond en utilisant le hachage du mot de passe de l'utilisateur. Pas d'échange de ticket, pas d'autorité centrale nécessaire, pas de révocation possible — le serveur vérifie directement la réponse.

Kerberos, introduit avec Windows 2000, était censé remplacer NTLM définitivement. Dans les environnements idéaux — domaine unique, postes joints, DNS fonctionnel, tous les services à jour — Kerberos fonctionne très bien. Le problème, c'est que le monde réel n'est jamais idéal.

En 2026, NTLM reste utilisé dans les situations suivantes dans la quasi-totalité des entreprises :

• Connexion à un serveur via son adresse IP plutôt que son nom DNS (Kerberos nécessite un FQDN résolvable)
• Accès à des ressources dans des domaines sans relation d'approbation Kerberos configurée
• Applications legacy qui ne supportent pas Kerberos : ERP anciens, outils de supervision industrielle, logiciels métier non mis à jour depuis dix ans
• Authentification sur des postes non joints au domaine ou des workgroups
• Fallback automatique quand Kerberos échoue pour une raison quelconque — délai de synchronisation d'horloge, SPN mal configuré, ticket expiré

Selon les données de télémétrie publiées par Microsoft en 2024 lors de l'annonce de sa roadmap de dépréciation NTLM, environ 65 % des authentifications dans les environnements Windows d'entreprise utilisent encore NTLM, au moins partiellement. Dans les PME industrielles et les environnements avec du matériel OT, ce chiffre dépasse fréquemment 80 %.

Les trois attaques NTLM que tout attaquant connaît — et que vous devriez aussi connaître

Pass-the-Hash : le hachage comme clé universelle

L'attaque la plus classique et la plus documentée. Dans NTLM, le hachage du mot de passe est fonctionnellement équivalent au mot de passe lui-même pour le protocole. Si un attaquant dispose du hachage NT d'un utilisateur — extrait de la base SAM locale avec secretsdump, récupéré depuis la mémoire LSASS avec Mimikatz, ou capturé en transit — il peut s'authentifier sur n'importe quelle ressource réseau acceptant NTLM sans jamais connaître le mot de passe en clair.

Cette attaque est documentée et exploitée depuis 1997. Elle est intégrée nativement dans des frameworks comme Impacket, CrackMapExec et Metasploit. Le changement de mot de passe d'un utilisateur ne neutralise pas un hachage déjà capturé avant le changement — le hachage NT de l'ancien mot de passe continue de fonctionner sur toutes les sessions qui l'ont mis en cache. Cette propriété est particulièrement dangereuse dans le contexte d'un mouvement latéral post-compromission.

NTLM Relay : intercepter et rejouer en temps réel

Plus sophistiquée et plus dangereuse : l'attaque de relayage. L'attaquant se positionne en man-in-the-middle entre le client et le serveur. Quand le client initie une authentification NTLM, l'attaquant intercepte le challenge-response et le relaie immédiatement vers un autre service acceptant NTLM — Exchange, SMB, MSSQL, LDAP, HTTP. Le service cible croit authentifier le client légitime et accorde l'accès à l'attaquant.

L'outil Responder, utilisé quasi-universellement dans les tests d'intrusion sur des réseaux Windows, exploite cette technique en répondant aux requêtes LLMNR et NetBIOS sur le réseau local. Sur un réseau d'entreprise moyen, Responder capture des hachés NTLM en quelques minutes. ntlmrelayx d'Impacket permet de les relayer instantanément. C'est souvent la première action d'un attaquant après avoir obtenu un accès initial sur un poste de travail.

CVE-2026-124194 exploite une variante distante de ce principe : forcer Outlook à initier une connexion SMB vers un serveur contrôlé par l'attaquant, sans que l'utilisateur soit sur le même réseau. La capture de hachés NTLM n'est plus limitée au réseau local — elle devient possible depuis Internet, via un simple email.

Offline cracking : NTLMv2 est vulnérable aux mots de passe insuffisants

Contrairement à Kerberos, les hachés NTLMv2 capturés en transit peuvent être soumis à des attaques par force brute ou dictionnaire. Hashcat sur un GPU RTX 5090 teste environ 150 milliards de candidats par seconde contre des hachés NTLM. Un mot de passe de 8 caractères alphanumériques est crackable en quelques heures. Un mot de passe de 10 caractères avec majuscules et caractères spéciaux résiste davantage, mais une passphrase générée aléatoirement de 20 caractères reste la seule protection réelle contre cette attaque à long terme.

La roadmap Microsoft de dépréciation NTLM : ambitieuse, mais lente

Microsoft a officiellement annoncé en juin 2024 sa volonté de déprécier NTLM dans les futures versions de Windows. La roadmap prévoyait plusieurs étapes : Windows 11 24H2 (fin 2024) pour l'audit détaillé et les nouvelles GPO ; Windows Server 2025 pour la désactivation par défaut de NTLMv1 dans les nouvelles installations ; et un horizon 2027-2028 pour la désactivation progressive de NTLMv2 dans les environnements ne l'utilisant pas.

En novembre 2026, NTLMv1 est effectivement désactivé dans les nouvelles installations de Windows Server 2025. Microsoft a enrichi ses outils d'audit NTLM et publié des guides de migration Kerberos détaillés. Mais NTLMv2 reste actif par défaut sur les domaines existants, et la migration des applications legacy progresse lentement dans la plupart des organisations.

Les deux obstacles principaux que je rencontre systématiquement dans mes missions d'audit sont les suivants.

Premier obstacle : l'inventaire incomplet des applications legacy. Dans une entreprise de taille intermédiaire, identifier toutes les applications, services et équipements utilisant NTLM peut prendre plusieurs semaines. ERP sur AS/400, automates industriels, imprimantes réseau, outils de monitoring configurés avec des comptes de service NTLM, logiciels RH datant des années 2000 — chacun peut être une source silencieuse dont la coupure NTLM provoquerait un incident de production inattendu.

Deuxième obstacle : l'absence d'urgence perçue. Tant qu'aucun incident ne touche directement l'organisation, les projets de migration NTLM peinent à obtenir priorité et budget. CVE-2026-124194 devrait changer cette dynamique. C'est précisément ce type de zero-day exploité que les RSSI doivent utiliser comme levier pour obtenir les arbitrages de direction nécessaires.

Comment désactiver NTLM progressivement sans casser votre SI

La désactivation complète et immédiate de NTLM dans un environnement d'entreprise existant est rarement réaliste. L'approche correcte est progressive, outillée et pilotée par les données d'audit.

Étape 1 : activer l'audit NTLM exhaustif

Avant de bloquer quoi que ce soit, il faut savoir qui utilise NTLM et pourquoi. La stratégie de groupe Network Security: Restrict NTLM: Audit NTLM authentication in this domain génère des événements dans le journal de sécurité pour chaque authentification NTLM (Event IDs 8004, 8003). Avec un SIEM ou un simple script PowerShell d'extraction sur 48 heures, vous obtenez une cartographie complète des sources NTLM dans votre environnement. Sans cet inventaire, toute tentative de dépréciation se solde par des incidents de production non anticipés.

Étape 2 : bloquer NTLMv1 en urgence

NTLMv1 est tellement faible (hachage LM 56 bits, crackable en secondes) qu'il n'existe aucune justification opérationnelle à le maintenir actif. La stratégie de groupe LAN Manager authentication level réglée à 5 (Send NTLMv2 response only/refuse LM & NTLM) bloque NTLMv1 sur toutes les machines du domaine. Cette action devrait être appliquée en urgence dans tout environnement qui ne l'a pas encore fait. J'ai audité des dizaines d'entreprises françaises en 2025-2026 : je n'en ai pas vu une seule où la désactivation de NTLMv1 aurait provoqué un incident de production. Faites-le maintenant.

Étape 3 : neutraliser les vecteurs de capture les plus courants

Même si NTLMv2 reste actif pendant la phase de migration, plusieurs mesures réduisent drastiquement le risque de capture de hachés :

• Bloquer le port TCP 445 sortant vers Internet au niveau du pare-feu périmétrique. Cette seule règle neutralise la majorité des vecteurs d'exfiltration NTLM via email, y compris CVE-2026-124194.
• Désactiver LLMNR et NetBIOS over TCP/IP via GPO sur toutes les machines. Ces protocoles permettent l'empoisonnement de cache (technique Responder) pour capturer des hachés sur le LAN.
• Activer SMB Signing obligatoire sur tous les serveurs et contrôleurs de domaine. Le signing cryptographique empêche les attaques de relayage NTLM même si un hachage est capturé.
• Activer l'Extended Protection for Authentication (EPA) sur Exchange, IIS et tous les services HTTP avec authentification Windows intégrée.

Étape 4 : traiter les applications legacy une par une

Pour chaque application identifiée comme utilisant NTLM dans l'audit, évaluer l'option de mise à jour ou de remplacement. Les éditeurs d'ERP modernes supportent Kerberos depuis des années — un appel de mise à jour ou un upgrade de version résout souvent le problème. Pour les applications qui ne peuvent pas migrer, les isoler dans des segments réseau contrôlés avec des règles de flux NTLM explicites et documentées, en attendant une migration ou un remplacement planifié.

L'argument économique : combien coûte NTLM à votre organisation ?

Selon le rapport Verizon DBIR 2026, le coût médian d'une compromission de compte dans une PME française est estimé à 180 000 euros en incluant la remédiation, la perte d'exploitation et les notifications réglementaires. Pour une ETI ou une grande entreprise, les incidents impliquant un mouvement latéral via pass-the-hash — souvent la suite logique d'une capture de hachés NTLMv2 — se chiffrent en millions d'euros et peuvent conduire à des demandes de rançon à huit chiffres.

Côté investissement, un projet de migration NTLM vers Kerberos dans une entreprise de 500 postes coûte typiquement entre 15 000 et 60 000 euros selon la complexité du SI, la présence d'applications legacy et les ressources internes disponibles. Le rapport coût/risque est favorable à la migration dans la quasi-totalité des cas.

Pour les entreprises soumises à NIS2 (applicable depuis octobre 2024 en France), la désactivation de NTLM n'est pas explicitement requise mais s'inscrit directement dans les mesures de gestion des accès et d'authentification forte attendues par le texte. Un audit NIS2 qui révèle NTLMv1 encore actif dans un domaine sera noté comme une non-conformité significative par tout auditeur qualifié.

Ce que l'IA offensive change au calcul NTLM en 2026

Un facteur aggravant mérite d'être mentionné : l'automatisation des attaques NTLM par des outils d'IA offensive. Des frameworks de red teaming automatisé utilisent désormais des LLM pour orchestrer des campagnes de phishing ciblé visant spécifiquement à capturer des hachés NTLM, en combinant spear phishing contextuel et exploitation de failles comme CVE-2026-124194. Ce qui nécessitait auparavant plusieurs heures de travail manuel d'un pentesteur qualifié peut désormais être automatisé en quelques minutes à l'échelle d'une organisation entière. Cette évolution rend l'exposition NTLM encore plus risquée qu'elle ne l'était en 2020 ou 2022 — les acteurs de la menace disposant de moyens limités peuvent désormais lancer des campagnes de vol de hachés à grande échelle contre des cibles multiples simultanément.

Conclusion : NTLM est WEP

NTLM en 2026 est l'équivalent de continuer à utiliser WEP pour votre WiFi parce que "ça marche encore". Le protocole a des défauts architecturaux qui ne seront jamais corrigés par des patches, il est exploité dans des dizaines de campagnes chaque année, et les outils pour le déprécier progressivement existent et sont documentés par Microsoft. CVE-2026-124194 est une opportunité — pas seulement de patcher Outlook, mais de lancer enfin le projet NTLM Deprecation dans votre organisation. Profitez de la fenêtre de communication ouverte par cette zero-day pour obtenir le budget et l'arbitrage de direction que vous n'avez peut-être pas réussi à obtenir jusqu'à présent. Dans six mois, ce ne sera plus un argument d'urgence — et vous serez toujours vulnérable.