CodeKitHubEn quoi consiste cet outil ?
NTLM (NT LAN Manager) est le protocole d'authentification défi-réponse historique de Microsoft, encore utilisé aujourd'hui pour les connexions aux comptes Windows locaux et comme solution de repli dans de nombreux environnements Active Directory. Son vérificateur de mot de passe — communément appelé « le hash NTLM » — est défini dans la spécification du protocole MS-NLMP de Microsoft comme `MD4(UTF-16-LE(password))` : le mot de passe est d'abord encodé en UTF-16 little-endian (chaque caractère devient donc 2 octets, contrairement à l'UTF-8), puis cette séquence d'octets est hachée une seule fois avec l'algorithme MD4 du RFC 1320.
L'étape UTF-16LE est le détail que la plupart des gens ratent en réimplémentant NTLM : hacher les octets UTF-8 d'une chaîne au lieu de ses octets UTF-16LE produit un résultat totalement différent et incorrect, même si le texte visible semble identique. Cet outil encode correctement, donc sa sortie correspond exactement à ce que Windows stocke lui-même et à ce qu'attendent des outils comme hashcat (mode 1000) et Mimikatz.
Comme NTLM est antérieur aux principes modernes de hachage des mots de passe, il ne dispose d'aucune des protections conçues par la suite pour ralentir le cassage : pas de sel par utilisateur, pas de facteur de coût configurable, pas d'itération volontaire. Il s'agit d'une seule passe MD4, ce qui le rend extrêmement rapide à calculer — un avantage pour la compatibilité avec l'existant, mais un désastre face aux attaques par force brute et par dictionnaire.
Pourquoi l'utiliser ?
- Vous êtes en plein pentest autorisé, vous venez de dumper le NTDS.dit du contrôleur de domaine et devez confirmer rapidement qu'un hash donné correspond au mot de passe que vous venez de casser avec hashcat, sans rien téléverser sur un service en ligne.
- Vous avez écrit votre propre script Python pour calculer des hashs NTLM et le résultat ne correspond pas à celui de Mimikatz — il vous faut une implémentation de référence fiable pour isoler si le bug vient de votre encodage UTF-16LE ou d'ailleurs.
- Vous préparez un labo de formation sécurité pour votre équipe et devez générer plusieurs hashs NTLM de mots de passe d'exemple pour qu'elle s'entraîne avec hashcat en mode 1000, sans exposer de vraies credentials.
- Vous résolvez un challenge CTF qui exige de générer le hash NTLM d'une chaîne précise avant de pouvoir passer à l'étape suivante.
- Vous auditez la configuration héritée d'un Active Directory et devez vérifier manuellement si un compte de service ancien utilise encore un mot de passe faible et connu.
- 100 % local : votre saisie ne quitte jamais le navigateur, ce qui la rend sûre même pour des credentials sensibles dans le cadre d'une évaluation autorisée.
Mode d'emploi
- Saisissez le mot de passe ou la chaîne à hacher dans le champ de saisie.
- Cliquez sur « Générer le hash NTLM ».
- Lisez le hash NTLM sur 32 caractères hexadécimaux (la sortie en majuscules est activée par défaut, comme l'affichent Windows et la plupart des outils de cassage — décochez la case pour obtenir des minuscules).
- Cliquez sur « Copier » pour copier le hash dans le presse-papiers.
Exemple
Entrée
passwordRésultat
8846F7EAEE8FB117AD06BDD830B7586CIl s'agit d'un vecteur de test bien connu et vérifiable de manière indépendante : le hash NTLM de la chaîne littérale « password » est toujours 8846F7EAEE8FB117AD06BDD830B7586C. Vous pouvez comparer la sortie de cet outil à celle de n'importe quelle autre implémentation NTLM correcte.
NTLM face au hachage moderne des mots de passe
Le tableau ci-dessous montre pourquoi NTLM est considéré comme obsolète pour protéger de nouveaux systèmes, même s'il reste présent dans l'infrastructure Windows et Active Directory héritée.
| Propriété | NTLM | bcrypt / scrypt / Argon2 |
|---|---|---|
| Primitive sous-jacente | Une seule passe MD4 | Hash lent conçu spécifiquement, avec coût ajustable |
| Salage | Aucun — des mots de passe identiques donnent toujours le même hash | Sel aléatoire unique par mot de passe |
| Itération / stretching | Aucune | Facteur de coût configurable, augmentable dans le temps |
| Résistance à la force brute | Très faible — des milliards de tentatives par seconde sur les GPU actuels | Volontairement coûteux à chaque tentative |
| Où on le trouve encore | Authentification Windows héritée, repli Active Directory | Applications récentes, meilleure pratique actuelle |
Outils associés
Si vous avez besoin d'un hash cryptographique généraliste plutôt que de la construction MD4(UTF-16LE) propre à NTLM, ces outils conviendront peut-être mieux.
→ Générateur de hash multi-algorithme · Générateur de MD5 · Générateur de mot de passe
Erreurs courantes en réimplémentant NTLM à partir de zéro
- Encoder en UTF-8 au lieu d'UTF-16LE avant le MD4 — l'erreur la plus fréquente, qui produit un hash à l'aspect correct (32 caractères hex) mais totalement faux.
- Oublier que MD4 n'est pas MD5 : ce sont des algorithmes distincts aux sorties différentes, même si les deux produisent un résumé sur 128 bits — utiliser une bibliothèque MD5 par erreur est un bug silencieux très courant.
- Ne pas vérifier l'ordre des octets little-endian au sein de chaque paire UTF-16 — certains langages utilisent le big-endian par défaut, il faut alors forcer explicitement le little-endian.
- Confondre le hash NTLM de base avec le hash de session NTLMv2 — ce sont des calculs distincts, le second dépendant d'un défi du serveur qui ne peut pas être reproduit avec le seul mot de passe.
Foire aux questions
Qu'est-ce qu'un hash NTLM exactement ?
C'est le vérificateur de mot de passe que Windows calcule et stocke pour l'authentification NT LAN Manager, défini dans la spécification MS-NLMP de Microsoft comme MD4(UTF-16LE(password)) — une seule passe MD4 sur l'encodage en octets UTF-16 little-endian du mot de passe. Il fait toujours 128 bits, affichés sous forme de 32 caractères hexadécimaux.
Pourquoi UTF-16LE en particulier, et pas UTF-8 ou ASCII ?
Windows stocke le texte en interne en UTF-16LE depuis la conception de NT, donc les mots de passe sont encodés de la même façon avant d'être hachés. Chaque caractère devient 2 octets (en ordre little-endian), y compris les caractères ASCII classiques comme « a », qui deviennent 0x61 0x00 au lieu de simplement 0x61. Hacher les octets UTF-8 de la même chaîne donne un résultat totalement différent et faux — c'est le bug le plus fréquent dans les implémentations NTLM refaites à partir de zéro.
NTLM est-il sûr à utiliser aujourd'hui ?
Non, et Microsoft lui-même recommande d'y renoncer au profit de Kerberos dès que possible. NTLM n'utilise aucun sel, donc des mots de passe identiques produisent toujours des hashs identiques chez tous les utilisateurs et sur tous les systèmes, ce qui permet des recherches via des rainbow tables précalculées. Il n'a non plus ni itération ni facteur de coût — une simple passe MD4 sans sel —, si bien que les GPU modernes peuvent tenter des milliards de combinaisons par seconde contre un hash capturé. Il ne survit que pour la compatibilité avec d'anciens systèmes et applications Windows.
En quoi NTLM diffère-t-il des hachages de mots de passe modernes comme bcrypt, scrypt ou Argon2 ?
Les hacheurs de mots de passe modernes sont volontairement lents et salés : bcrypt, scrypt et Argon2 ajoutent chacun un sel aléatoire unique par mot de passe et un facteur de coût ajustable, qui peut être augmenté au fil du temps à mesure que le matériel progresse, précisément pour rendre la force brute coûteuse même à grande échelle. NTLM ne fait ni l'un ni l'autre — il a été conçu à une époque où le brute-force hors ligne n'était pas encore une menace concrète, et cela se voit. C'est exactement pour cela que NTLM ne devrait jamais servir à protéger quoi que ce soit de conçu aujourd'hui ; les usages légitimes de cet outil sont la compatibilité avec une infrastructure Windows existante et les tests de sécurité autorisés, pas la construction de nouveaux systèmes.
Quels sont les usages légitimes d'un générateur de hash NTLM ?
Vérifier des hashs extraits d'une base SAM ou d'un NTDS.dit lors d'un test d'intrusion autorisé ou d'un audit de credentials ; contrôler que vos propres outils ou scripts implémentent correctement MS-NLMP ; générer des hashs de test pour hashcat (mode 1000) ou pour vérifier la compatibilité avec le format Mimikatz dans un laboratoire que vous maîtrisez ; et travailler sur des exercices CTF ou de formation impliquant explicitement NTLM. Utiliser cet outil pour attaquer des comptes ou des systèmes que vous ne possédez pas, ou pour lesquels vous n'avez pas d'autorisation écrite, n'est pas un usage légitime.
Mon mot de passe ou ma saisie est-il envoyé à un serveur ?
Non. Le calcul MD4 s'exécute entièrement en JavaScript dans votre navigateur — il n'existe aucune API native du navigateur pour MD4, elle est donc implémentée directement dans le code côté client de cette page — et rien de ce que vous tapez n'est transmis où que ce soit.
Pourquoi mon hash ne correspond-il pas à celui obtenu avec un petit script Python ?
La cause la plus fréquente est d'encoder la chaîne en UTF-8 au lieu d'UTF-16LE avant d'appliquer MD4 — vérifiez que votre script utilise `.encode('utf-16le')` en Python, et non `.encode('utf-8')`, qui est la valeur par défaut de la plupart des bibliothèques et l'erreur la plus courante en réimplémentant NTLM à partir de zéro.
Le hash change-t-il si le mot de passe contient des accents ou des caractères comme é, à, ç ?
Oui, à juste titre : UTF-16LE encode fidèlement chaque caractère Unicode, donc un mot de passe comme « éléphant123 » produit des octets différents — et donc un hash différent — d'une version sans accents. C'est exactement ce que fait Windows en interne.
Puis-je utiliser cet outil pour calculer le hash NTLMv2, pas seulement le NTLM de base ?
Non — cet outil calcule uniquement le hash NTLM de base (MD4 sur UTF-16LE), le vérificateur de mot de passe stocké. NTLMv2 est un protocole défi-réponse qui utilise ce hash de base comme entrée d'un calcul HMAC-MD5 supplémentaire avec des données de session, et nécessite des paramètres allant au-delà d'un simple mot de passe en entrée.