Attaque par relais NTLM et signature SMB obligatoire

Le relais NTLM (NT LAN Manager) ne casse aucun mot de passe et ne récupère aucun condensat. Il place l’attaquant au milieu d’une authentification en cours, puis fait suivre les messages vers un autre service qui, lui, croit parler à la victime. Cette page monte le décor en laboratoire, exécute le relais, puis referme la faille sur le point exact où elle s’ouvre.

→ Lire l’explication complète de la marmotte

Pourquoi le défi NTLM se relaie sans liaison au transport

NTLM authentifie en trois messages : le client annonce ses capacités (NEGOTIATE), le serveur répond par un défi aléatoire de huit octets (CHALLENGE), le client renvoie une réponse calculée à partir de ce défi et du condensat de son mot de passe (AUTHENTICATE). Le serveur vérifie la réponse en refaisant le même calcul de son côté. À aucun moment le mot de passe ne circule, et c’est précisément ce qui a longtemps passé pour une garantie.

Le défaut tient en une phrase : rien dans les trois messages ne lie l’authentification au canal qui la transporte. Le défi prouve que le client connaît le condensat, pas qu’il parle au serveur qui a émis ce défi. Un intermédiaire peut donc ouvrir une session vers une cible, récupérer le défi que cette cible génère, le présenter à la victime comme s’il venait de lui, récupérer la réponse AUTHENTICATE que la victime calcule, et la renvoyer telle quelle à la cible. La cible valide : la réponse correspond bien à son défi. L’attaquant se retrouve authentifié en tant que victime sans avoir jamais tenu son secret.

La contre-mesure évidente serait de signer l’échange. NTLM sait négocier une clé de session dérivée de la réponse, mais cette signature est facultative, et un attaquant en position de relais retire simplement le drapeau NTLMSSP_NEGOTIATE_SIGN du message NEGOTIATE qu’il transmet. Vingt ans d’Active Directory apprennent une chose : une protection négociable est une protection absente dès qu’un intermédiaire tient le fil.

Monter l’ouvrage : victime, cible SMB et relais

Le décor tient en trois rôles sur un réseau de laboratoire isolé, machines jetables montées pour l’occasion : un poste victime dont un compte a des droits d’administration locale sur une autre machine, une cible qui expose le partage SMB (Server Message Block) sans imposer de signature, un poste attaquant qui capte la tentative d’authentification et la relaie. La bascule décisive est la signature SMB non obligatoire sur la cible.

L’attaquant provoque d’abord une authentification en empoisonnant la résolution de noms : quand un poste cherche un nom d’hôte que le serveur DNS (Domain Name System) ne connaît pas, Windows se rabat sur les protocoles de diffusion LLMNR (Link-Local Multicast Name Resolution) et NBT-NS (NetBIOS Name Service), auxquels n’importe quelle machine du segment peut répondre. Le poste attaquant répond « c’est moi », reçoit la tentative NTLM, et la fait suivre vers la cible.

# Environnement de laboratoire, réseau isolé, machines jetables.
# Deux outils de la suite Impacket / Responder, l'un empoisonne la
# résolution de noms, l'autre relaie l'authentification captée vers SMB.

# 1. Empoisonnement LLMNR/NBT-NS : le poste attaquant se fait passer pour
#    l'hote que la victime cherche, mais SANS répondre lui-meme au défi
#    (mode analyse des réponses désactivé pour laisser passer le relais).
sudo responder -I eth0 --lm --disable-ess

# 2. Relais : toute authentification NTLM captée est rejouée vers 10.0.0.20,
#    la cible SMB dont la signature n'est PAS obligatoire. En cas de succès,
#    l'outil exécute une commande sous l'identité relayée.
#    --no-http évite de capter en local, -smb2support parle le SMB moderne.
sudo ntlmrelayx.py -t smb://10.0.0.20 -smb2support --no-http \
    -c 'whoami /all'

Quand la victime déclenche l’accès (tâche planifiée, scan de partage, simple dir \\serveur-inexistant\), la chaîne se referme : Responder capte, ntlmrelayx relaie vers 10.0.0.20, la cible valide la réponse et exécute whoami /all sous l’identité de la victime. Aucun mot de passe deviné, aucun condensat cassé. Le compte relayé étant administrateur sur la cible, l’attaquant tient une exécution de commande à distance.

Signature SMB obligatoire, liaison de canal et retrait de NTLM

Trois contre-mesures, dans l’ordre où elles referment la faille pour de bon.

La signature SMB obligatoire ferme le relais vers SMB. Le serveur exige alors que chaque message soit signé avec la clé de session dérivée de l’authentification. L’attaquant, qui a relayé la réponse mais ne connaît pas le condensat, ne peut pas produire cette signature : la première requête post-authentification est rejetée. Sur les contrôleurs de domaine, elle est obligatoire depuis toujours ; sur les serveurs de fichiers ordinaires, elle doit être imposée explicitement, et Windows 11 comme Windows Server 2025 l’exigent désormais par défaut.

# Imposer la signature SMB obligatoire, coté serveur ET coté client.
# La valeur $true rend la signature NON négociable : une session non signée
# est refusée, ce qui casse le relais au lieu de le laisser négocier son
# retrait. À déployer par stratégie de groupe (GPO) sur tout le parc.
Set-SmbServerConfiguration -RequireSecuritySignature $true -Force
Set-SmbClientConfiguration -RequireSecuritySignature $true -Force

La liaison de canal (channel binding) ferme le relais vers les services en TLS (Transport Layer Security), là où la signature SMB ne s’applique pas : LDAP (Lightweight Directory Access Protocol) sur TLS, ou les services web. Le mécanisme EPA (Extended Protection for Authentication) insère dans le calcul de la réponse une empreinte du canal TLS sous-jacent (le Channel Binding Token). Une réponse calculée pour le canal de la victime ne valide plus sur celui de l’attaquant : les deux tunnels ont des empreintes différentes. Sur un contrôleur de domaine, forcer la liaison de canal LDAP coupe le relais vers l’annuaire, vecteur privilégié des chaînes qui visent la délégation.

Le retrait de NTLM au profit de Kerberos supprime le composant vulnérable au lieu de le durcir. Kerberos lie le ticket au service visé (le champ SPN, Service Principal Name) : un ticket émis pour un service ne s’accepte pas sur un autre, ce qui retire au relais sa matière première. La bascule reste longue (applications câblées sur NTLM, authentification par adresse IP qui repasse mécaniquement en NTLM), et c’est le coût de la contre-mesure définitive. Le compromis central est là : la signature et la liaison de canal referment les relais un service à la fois, sans rien casser ; le retrait de NTLM referme la classe entière, au prix d’un inventaire applicatif que personne ne tient à jour. La page NTLM : fonctionnement, vulnérabilités et durcissement détaille le calcul des réponses, et la section Failles rassemble les autres démonstrations du même acabit.

🐝 Ce qui arrive si on s’en passe

Sans signature SMB obligatoire ni liaison de canal, toute authentification NTLM circulant sur le segment devient rejouable vers n’importe quel service qui l’accepte : un compte au privilège modeste sur son poste se transforme en exécution de commande à distance sur toute cible où il dispose de droits, sans qu’aucun mot de passe soit deviné. La détection en souffre autant que la prévention : côté cible, l’accès porte l’identité légitime de la victime, donc les journaux d’authentification n’affichent aucune anomalie, seul un rapprochement d’adresses source révèle le relais. Laisser LLMNR et NBT-NS actifs fournit en prime le déclencheur, puisque n’importe quelle machine du segment peut répondre à leur place et capter la tentative. La fenêtre reste ouverte tant que NTLM répond, indépendamment de la robustesse des mots de passe.

🦫 Explication de la marmotte 🍫

Sur un réseau Windows, quand un ordinateur veut prouver son identité à un serveur, il ne lui envoie pas son mot de passe. Le serveur envoie d’abord un nombre tiré au hasard. L’ordinateur mélange ce nombre avec une empreinte secrète de son mot de passe et renvoie le résultat. Le serveur refait le même mélange de son côté : si les deux résultats collent, l’identité est prouvée. Le mot de passe lui-même n’a jamais voyagé.

Le problème est que ce résultat ne dit rien sur qui l’a demandé. Un attaquant qui se glisse entre les deux ouvre d’abord une conversation avec un serveur cible. Ce serveur lui envoie son propre nombre au hasard. L’attaquant le fait passer à la victime comme si c’était le sien. La victime calcule son mélange et le renvoie. L’attaquant le transmet tel quel au serveur cible, qui le vérifie et le trouve bon, puisque le nombre venait bien de lui. L’attaquant est maintenant reconnu comme la victime, sans avoir jamais connu le mot de passe.

Pour refermer la faille, on oblige le serveur à exiger que chaque message suivant soit scellé avec une clé que seule la vraie victime peut produire. L’attaquant, qui ne connaît pas le secret, ne sait pas sceller, et sa première requête est rejetée. On peut aussi rattacher la preuve au tunnel de communication précis, ou remplacer ce vieux protocole par un système qui délivre un laissez-passer valable pour un seul serveur nommé.

Pages voisines

La citent

Attaque par relais NTLM et signature SMB obligatoire

Elle cite

: les deux pages se citent l’une l’autre.

Attaque par relais NTLM et signature SMB obligatoire

Attaque par relais NTLM et signature SMB obligatoire

Pourquoi le défi NTLM se relaie sans liaison au transport

Monter l’ouvrage : victime, cible SMB et relais

Signature SMB obligatoire, liaison de canal et retrait de NTLM

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines