Sécurité des Identités : Authentification NTLM et Vulnérabilités

Danger

Alerte d’obsolescence (Contexte 2026) : Microsoft a officiellement déprécié la suite de protocoles NT LAN Manager (NTLM). Bien qu’il ait été historiquement la colonne vertébrale des réseaux Windows, les failles architecturales inhérentes à NTLM en font une cible privilégiée pour les mouvements latéraux et le vol d’identifiants. Dans les environnements Active Directory modernes, toute authentification NTLM réussie vers un serveur critique doit être traitée comme une anomalie et un risque de sécurité. Les organisations doivent agressivement faire la transition vers Kerberos.

1. La mécanique de NTLM : le défi-réponse

Contrairement aux protocoles modernes, NTLM ne s’appuie pas sur un système de tickets ou sur un fournisseur d’identité tiers lors de l’échange initial. Il utilise un mécanisme de défi-réponse (challenge-response).

Lorsqu’un client (ex: un poste de travail) tente d’accéder à une ressource sur un serveur cible (ex: un partage de fichiers SMB), la séquence suivante se produit :

1. Négociation (Type 1 Message) : le client contacte le serveur et annonce ses capacités et les versions NTLM qu’il supporte, en texte clair.
2. Défi (Type 2 Message) : le serveur répond avec un nombre aléatoire de 16 octets connu sous le nom de “Défi” (ou nonce). Le serveur dit essentiellement : “prouve-moi que tu connais ton mot de passe en chiffrant ce nombre aléatoire.”
3. Authentification (Type 3 Message) : c’est l’étape critique.
   • Le client ne connaît pas le mot de passe en clair. Il ne conserve en mémoire que le hash NT de l’utilisateur (un hachage MD4 du mot de passe).
   • Le client utilise le hash NT de l’utilisateur comme clé cryptographique pour chiffrer le défi de 16 octets du serveur.
   • La chaîne chiffrée qui en résulte est la réponse. Le client envoie cette réponse, accompagnée du nom d’utilisateur, au serveur.
4. Validation (Netlogon) : le serveur cible reçoit la réponse mais ne peut pas la vérifier car il ne possède pas le hash NT de l’utilisateur.
   • Le serveur établit un canal sécurisé Netlogon vers le contrôleur de domaine (DC) et lui transmet le nom d’utilisateur, le défi original et la réponse du client.
   • Le DC récupère le hash NT de l’utilisateur dans sa base de données (ntds.dit), effectue exactement le même chiffrement mathématique sur le défi, et compare son résultat avec la réponse du client.
   • S’ils correspondent, le DC indique au serveur que l’authentification est valide.

2. Évolution : NTLMv1 vs NTLMv2

NTLMv2 a été introduit pour corriger des faiblesses cryptographiques catastrophiques présentes dans NTLMv1.

Caractéristique	NTLMv1 (Très faible)	NTLMv2 (Standard moderne)
Gestion du défi	utilise uniquement le défi du serveur.	combine le défi du serveur avec un défi généré par le client.
Résistance au rejeu	très vulnérable.	intègre un horodatage (timestamp) dans la réponse, rendant les attaques par rejeu beaucoup plus difficiles.
Robustesse cryptographique	utilise le chiffrement DES, facilement cassable via des tables arc-en-ciel (rainbow tables, ex: L0phtCrack).	utilise HMAC-MD5, offrant une intégrité cryptographique beaucoup plus forte.

La faille fondamentale : bien que le défi client et l’horodatage de NTLMv2 atténuent avec succès les attaques par rejeu simples, cela ne corrige pas le péché architectural originel du protocole : il s’appuie toujours sur le hash NT de l’utilisateur comme secret cryptographique ultime.

3. Vulnérabilités fondamentales

En raison de son architecture, NTLM expose les réseaux à deux vecteurs d’attaque dévastateurs.

Pass-the-Hash (PtH)

Si un attaquant compromet une machine et extrait la mémoire du processus LSASS, il récupère le hash NT de l’utilisateur. Parce que NTLM ne nécessite que le hash NT pour chiffrer le défi (Étape 3), l’attaquant n’a jamais besoin de casser le mot de passe en clair. Il lui suffit de “passer” le hash volé dans sa propre requête d’authentification pour se déplacer latéralement.

Relais NTLM (NTLM Relaying)

Contrairement à Kerberos, NTLM est dépourvu d’authentification mutuelle. Le client s’authentifie auprès du serveur, mais le serveur ne prouve pas son identité au client. Un attaquant peut se positionner en “homme du milieu” (MitM). Lorsqu’une victime tente de s’authentifier, l’attaquant intercepte le message de Type 1, le relaie vers un serveur cible, reçoit le défi de Type 2, le renvoie à la victime, puis relaie la réponse de Type 3 valide de la victime pour compromettre le serveur cible.

4. Pourquoi NTLM est-il encore actif ?

Si Kerberos est supérieur, pourquoi le trafic NTLM existe-t-il encore sur les réseaux d’entreprise ? Le protocole sert de mécanisme de repli automatique :

• Accès par adresse IP : Kerberos nécessite des noms d’entité de service (SPN), qui reposent sur des noms de domaine pleinement qualifiés (FQDN). Si un utilisateur ou une application accède à un serveur via son adresse IP (ex: \\192.168.1.50\C$), le système rétrograde automatiquement vers NTLM.
• Groupes de travail (Workgroups) : dans les réseaux en pair-à-pair dépourvus de contrôleur de domaine Active Directory, NTLM est le seul protocole disponible.
• Applications héritées : des applications plus anciennes, codées en dur, peuvent demander explicitement les API d’authentification “Windows NT”.
• Frontières réseau : des pare-feux bloquant les ports Kerberos (TCP/UDP 88) forceront le repli vers NTLM (qui opère sur les ports SMB/RPC).

5. Investigation DFIR et Threat Hunting

Du point de vue de la Blue Team, le suivi de l’utilisation de NTLM est une activité à double objectif : découvrir la dette technique héritée et chasser les mouvements latéraux actifs.

A. Analyse des terminaux (Événement 4624)

Comme abordé dans notre Analyse des événements 4624 et 4625, un analyste peut identifier les authentifications NTLM sur un serveur cible en filtrant les connexions réseau réussies.

• Logon Type : 3 (Network)
• Authentication Package : NTLM

B. Analyse des contrôleurs de domaine (Événement 4776)

Les contrôleurs de domaine consignent l’Événement 4776 (“The computer attempted to validate the credentials for an account”) pour chaque requête de validation Netlogon NTLM. Une augmentation soudaine d’événements 4776 en échec est une alerte rouge majeure pour une campagne de Password Spraying ou de force brute.

KQL (Chasse au Pass-the-Hash)

hunt_ntlm_pth_lateral_movement.kql

// Détecte les connexions réseau NTLM réussies par des comptes administratifs
// Fortement révélateur d'un mouvement latéral Pass-the-Hash.
SecurityEvent
| where EventID == 4624
| where LogonType == 3
| where AuthenticationPackageName == "NTLM"
// Filtrer pour les comptes administratifs sensibles
| where TargetUserName has_any ("admin", "svc_", "administrator")
// Exclure les serveurs hérités attendus si applicable
| where IpAddress != "192.168.10.100"
| project TimeGenerated, Computer, TargetUserName, IpAddress, LogonProcessName
| sort by TimeGenerated desc

Splunk (Audit NTLM)

audit_ntlm_usage.spl

# Identifier les systèmes utilisant encore NTLM pour préparer la dépréciation
index=windows sourcetype="WinEventLog:Security" EventCode=4624 Logon_Type=3 Authentication_Package="NTLM"
| stats count by Target_User_Name, Source_Network_Address, host
| sort - count

---

Prochaines étapes

Comprendre les failles de NTLM est la première étape de la sécurité Active Directory. Pour comprendre comment les réseaux modernes sécurisent l’authentification et empêchent le relais NTLM, nous devons nous plonger dans son successeur.

👉 Lire la prochaine plongée architecturale : l’authentification Kerberos

---

Références

• Documentation Microsoft : Vue d’ensemble et dépréciation de NTLM
• SentinelOne : Sécurité des identités : Windows NTLM
• MITRE ATT&CK : Utilisation de matériel d’authentification alternatif : Pass the Hash (T1550.002)