NetNTLMv1 : cryptanalyse, rainbow tables et fin de vie — ce que votre SI risque encore

TL;DR — NetNTLMv1 repose sur DES, un algorithme cryptographique symétrique cassé depuis les années 90. Des rainbow tables précalculées permettent de retrouver le hash NT (pass-the-hash ready) depuis un challenge/réponse NetNTLMv1 intercepté sur le réseau — sans GPU dédié, sans FPGA (sous réserve d’un challenge fixe 1122334455667788). Mandiant l’a démontré à grande échelle en ce début 2026. Notre outil shuck.sh, développé par Yann CAM, y est cité. BZHunt a reproduit l’attaque. Si votre SI accepte encore NetNTLMv1, ce n’est plus un risque théorique.

Pourquoi NetNTLMv1 est toujours là

Trente ans après la mise en évidence des faiblesses de DES (Data Encryption Standard), NetNTLMv1 est encore accepté dans de nombreux environnements Active Directory que nous auditons chez BZHunt. Non pas par négligence, mais en raison d’équipements ou logiciels métier anciens qui ne parlent que NetNTLMv1, et que personne n’a jamais eu de bonne raison de le désactiver — jusqu’à ce que quelqu’un ait une très bonne raison de l’exploiter.

NetNTLMv1 (aussi appelé NTLMv1 ou LM/NTLM v1) est le mécanisme d’authentification réseau hérité de Windows NT. Il est basé sur un challenge/réponse où le client chiffre un nonce avec des clés dérivées du hash NT issu du mot de passe (un NetNTLMv1 n’est donc pas un “hash”). La faiblesse fondamentale : ce chiffrement utilise DES, avec trois clés de 56 bits chacune — dont une ne contient que 16 bits effectifs.

Ce n’est pas une hypothèse académique. C’est une faille structurelle connue, documentée, et désormais exploitée en conditions réelles à l’échelle industrielle.

Le fonctionnement de l’attaque

Du challenge/réponse au hash NT

Lors d’une authentification NetNTLMv1, voici ce qui circule sur le réseau :

1. Le serveur envoie un challenge de 8 octets au client
2. Le client calcule une réponse en chiffrant ce challenge avec les 3 clés DES dérivées de son hash NT
3. Le serveur vérifie la réponse

Ce que l’attaquant capte — via Responder, une position de MITM ou un relai — c’est le {challenge + réponse NetNTLMv1}. À partir de là, deux chemins sont possibles en fonction du challenge observé :

Challenge aléatoire ou ESS/SSP activé

Le hash NT (16 octets) est découpé en 3 portions (PT1, PT2 et PT3) de respectivement 56, 56 et 16 bits. Quelques opérations binaires étendent ces portions à 64 bits chacune, donnant les trois clés DES K1, K2 et K3.

La dérivation de PT3 (2 octets) en K3 (8 octets) induit une première faiblesse : il suffit de tester toutes les valeurs entre 0x0000 et 0xFFFF pour redéterminer les 2 derniers octets (PT3) d’un hash NT à partir d’un NetNTLMv1 (brute-force instantané).

Ainsi, seules les deux clés K1 et K2 nécessitent des calculs plus importants pour être cassées et permettre de reconstruire le hash NT initial.

Si le challenge est différent de 1122334455667788, ou que les mécanismes de Microsoft ESS/SSP (Extended Session Security / Security Support Provider) sont activés (induisant un second challenge renforçant l’aléa), alors pour casser K1 et K2 il est envisageable de :

• Utiliser shuck.sh pour shucker instantanément le NetNTLMv1 et en déduire le hash NT correspondant (sous réserve qu’il ait précédemment fuité sur HaveIBeenPwned) ;
• Utiliser hashcat en mode 5500 ou 27000 pour espérer retrouver respectivement le plaintext ou le hash NT à partir de dictionnaires ;
• Ou encore mieux, utiliser hashcat en mode 14000 (attaque KPA, Known Plaintext Attack) pour retrouver avec certitude les valeurs de K1 et K2 après quelques heures/jours de cryptanalyse (quelque soit la complexité initiale du mot de passe associé au hash NT, donc fonctionnel même pour les comptes machines).

Les rainbow tables avec le challenge fixe 1122334455667788

Les rainbow tables pour NetNTLMv1 précalculent la correspondance {résultat DES → clé DES} pour un challenge fixe vallant impérativement 1122334455667788. La technique crack.sh (et ses variantes) exploit(ait) le fait que ce challenge peut être forcé par l’attaquant.

Si l’attaquant contrôle le challenge (ce qui est le cas sur un MITM ou avec Responder en mode -c, sans ESS/SSP), il peut utiliser un challenge fixe connu (1122334455667788), et employer des rainbow tables pour retrouver les clés DES K1 et K2 — donc le hash NT originel — depuis la réponse capturée en quelques minutes, sans brute force GPU.

L’excellent projet de recherche crack.sh, qui demeure en maintenance depuis plusieurs mois, se fondait sur l’usage d’une infrastructure à base de FPGA dédiés, rendant difficile une telle cryptanalyse on-premise et sans adhérence à un service en-ligne.

La grande innovation des équipes de Mandiant / Google Cloud Security de ce début d’année 2026 est la génération et la mise à disposition de nouvelles rainbow tables qui fonctionnent parfaitement sur du matériel classique, sans avoir recours à des FPGA.

Ainsi, une fois équipé de ces rainbow tables (~8To), n’importe quel NetNTLMv1 avec le challenge 1122334455667788 (sans ESS/SSP) peut être brisé localement pour obtenir le hash NT associé (quelque soit la complexité du mot de passe originel) en quelques minutes/heures et donc ouvrir la voie au pass-the-hash, sans avoir recours à un service tiers.

shuck.sh, Mandiant et la confirmation terrain

shuck.sh : un outil né de la curiosité

shuck.sh est un outil développé par Yann CAM (ycam), hacker éthique chez BZHunt, pour explorer et rendre accessibles les faiblesses de NetNTLMv1. L’objectif initial était pédagogique : disséquer et faire comprendre concrètement comment fonctionne cet algorithme de challenge/response, détailler les attaques possibles à son encontre et proposer une méthode de shucking instantanée sur la base du service HaveIBeenPwned.

L’outil permet notamment de :

• Immédiatement casser via la technique du hash shucking un NetNTLMv1 si le mot de passe associé avait précédemment fuité ;
• Déterminer si un hash NetNTLMv1 capturé est crackable via des tables précalculées
• Interfacer avec les services de cassage (crack.sh, tables locales, hashcat 5500, 27000 ou 14000)
• Générer, disséquer ou convertir des challenges NetNTLMv1 pour en comprendre le fonctionnement

Le moteur de shuck.sh, à savoir ShuckNT est disponible en opensource sur GitHub et un article MISC Mag (n°128) détaille le fonctionnement technique pas à pas.

La recherche Mandiant : l’exploitation à grande échelle confirmée

Début 2026, les équipes Google Cloud Security / Mandiant ont publié une recherche approfondie démontrant l’exploitation industrielle de NetNTLMv1 via rainbow tables — sans matériel spécialisé (pas de FPGA, pas de cluster GPU dédié). Leur conclusion est sans appel : NetNTLMv1 représente un risque bien réel dans de nombreux environnements de production.

Dans leurs ressources et supports de conférence, shuck.sh est cité comme outil complémentaire — une reconnaissance aussi inattendue que gratifiante pour notre équipe.

La reproduction BZHunt

Cette publication a été pour nous l’occasion d’aller plus loin. Nous avons :

1. Reproduit l’approche Mandiant dans un environnement de lab représentatif d’un SI corporate
2. Équipé nos ressources cryptanalytiques des rainbow tables NetNTLMv1 adaptées, on-premise
3. Intégré la technique dans notre arsenal offensif pour démontrer la faisabilité en conditions réelles lors de missions Red Team

Le résultat est sans ambiguïté : dans un environnement qui accepte encore NetNTLMv1, un attaquant positionné sur le réseau (via Responder ou un relai) peut obtenir des hashs NT en clair en quelques minutes/heures, sans aucune ressource computationnelle exceptionnelle et sans service tiers.

Ce croisement entre outillage indépendant, recherche de pointe et retour terrain illustre une réalité simple : les faiblesses connues depuis longtemps restent exploitables… tant qu’elles existent encore en production.

La fin de NetNTLMv1 : ce que Microsoft a annoncé

Dépréciation officielle de NTLM

En juin 2024, Microsoft a officialisé la dépréciation de l’ensemble du protocole NTLM dans Windows Server 2025 et les futures versions de Windows. L’annonce précise que NTLM — dans toutes ses versions, y compris NetNTLMv2 — sera progressivement retiré au profit de Kerberos et des mécanismes d’authentification modernes (Negotiate, IAKerb, NLMP).

Ce n’est pas une fin immédiate : NTLM restera fonctionnel pour assurer la compatibilité, mais il ne sera plus activement développé et sa désactivation deviendra la configuration recommandée par défaut.

Pour NetNTLMv1 spécifiquement, la situation est encore plus tranchée : Microsoft recommande sa désactivation depuis Windows Vista (2006). Vingt ans plus tard, il reste encore présent en production sur des périmètres que nous auditons régulièrement.

Pourquoi c’est difficile à éteindre

La persistance de NetNTLMv1 s’explique par plusieurs facteurs que nous observons sur le terrain :

• Applicatifs legacy : imprimantes réseau, NAS, logiciels métier anciens qui ne parlent que NetNTLMv1
• GPO non documentée : l’héritage de configurations Active Directory parfois vieilles de 15 ans, où personne ne touche à ce qui “fonctionne”
• Absence de monitoring : sans logs d’authentification NTLM actifs, personne ne sait que NetNTLMv1 est encore utilisé
• Peur de la coupure : désactiver NTLM sans inventaire préalable peut casser des services de production

Ce que vous devez faire : guide de remédiation pour le RSSI

Étape 1 — Inventorier avant de couper

Avant toute action, activez l’audit des authentifications NTLM sur vos contrôleurs de domaine :

GPO : Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options

Analysez ensuite le journal Operational NTLM (Applications and Services Logs > Microsoft > Windows > NTLM > Operational) pour identifier quels systèmes et applications utilisent encore NTLM — et surtout quelle version.

Étape 2 — Désactiver NetNTLMv1 immédiatement

La désactivation de NetNTLMv1 (tout en conservant NetNTLMv2 si nécessaire) est la priorité absolue. Elle ne casse rien dans un environnement Windows moderne (à pondérer et nuancer en fonction de l’hétérogénéité du parc).

GPO : Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options

Cette valeur correspond au niveau 5 dans le registre (LmCompatibilityLevel = 5). Elle bloque LM et NetNTLMv1 tout en autorisant NetNTLMv2.

Déployez cette GPO d’abord en audit uniquement (LmCompatibilityLevel = 3) sur quelques OU tests, surveillez les erreurs d’authentification pendant 48-72h, puis déployez en mode restrictif.

Étape 3 — Migrer vers Kerberos

Kerberos doit devenir le protocole par défaut pour toutes les authentifications réseau de votre SI. Les points d’attention :

Prérequis Kerberos :

• La résolution DNS doit fonctionner correctement (Kerberos utilise les FQDN, pas les IPs)
• L’heure des machines doit être synchronisée (tolérance de 5 minutes)
• Les SPNs (Service Principal Names) doivent être correctement enregistrés

Cas où NTLM reste inévitable (à documenter et surveiller) :

• Authentification par adresse IP directe (pas de FQDN)
• Certaines applications legacy sans support Kerberos
• Workgroup (machines hors domaine)

Forcer Kerberos là où c’est possible :

HKLM\SYSTEM\CurrentControlSet\Control\Lsa
RestrictSendingNTLMTraffic = 1  (audit) ou 2 (blocage)

Étape 4 — Durcir ce qui reste de NTLM

Si NetNTLMv2 reste nécessaire sur certains flux, durcissez-le :

Étape 5 — Surveiller en continu

Une fois le nettoyage effectué, mettez en place une surveillance permanente :

• Event ID 4624 (Logon Success) avec AuthenticationPackageName = NTLM — filtre sur LmPackageName = NTLM V1 pour détecter toute résurgence NetNTLMv1
• Event ID 4625 (Logon Failure) — tentatives d’authentification échouées, potentiellement des sprays de mot de passe
• Intégrez ces sources dans votre SIEM avec une alerte sur toute authentification NetNTLMv1 détectée

Conclusion

NetNTLMv1 est une faille de conception vieille de trente ans, désormais exploitable industriellement sur du matériel grand public. La recherche Mandiant et les outils comme shuck.sh ont transformé une faiblesse théorique en technique d’attaque opérationnelle que nous utilisons lors de nos missions Red Team.

La bonne nouvelle : la correction est connue, documentée, et déployable progressivement sans casser votre production — à condition de procéder dans l’ordre (audit → NTLMv1 off → Kerberos first → NTLMv2 hardening).

La mauvaise nouvelle : si vous ne savez pas si NetNTLMv1 est encore accepté dans votre SI, la réponse est probablement oui.

Pour aller plus loin :

• Closing the Door on Net-NTLMv1 — Google Cloud Security / Mandiant
• Net-NTLMv1: The Easy Path for Red Teamers — Google Cloud Security / Mandiant
• Shuck.sh — Yann CAM
• ShuckNT — Yann CAM
• Shuck Hash before trying to Crack it — MISC n°128 — Yann CAM
• HaveIBeenPwned — Troy HUNT
• The world’s fastest DES cracker — crack.sh

Yann CAM (ycam) est hacker éthique et chercheur en sécurité chez BZHunt, auteur de shuck.sh. Ses travaux sur NetNTLMv1 ont été cités dans les recherches de Google Cloud Security / Mandiant.