La vulnérabilité sans patch expose NTLMv2 aux liens manipulés par les gestionnaires URI

Les chercheurs en cybersécurité ont décrit une vulnérabilité sans patch qui permet à un attaquant de provoquer la filtration du hash NTLMv2 d'un utilisateur en induisant l'ouverture de liens manipulés dans le navigateur. Bien que la mécanique rappelle l'incident résolu en avril 2026 avec la poignée URI de l'outil Snipping (ms-screenshot), la nouvelle technique profite de la poignée recherche: avec paramètres de type mimb = emplacement: forcer le système à se connecter contre une ressource contrôlée par l'attaquant et ainsi capturer le Net-NTLMv2 que l'équipe essaie d'envoyer à authentifier.

La racine du problème est le même type de défaillance : un gestionnaire de protocole qui accepte les paramètres fournis par l'utilisateur sans les valider et qui, lors de leur traitement, provoque une connexion sortante aux routes UNC. Cette connexion à un serveur SMB malveillant déclenche le protocole NTLM et expose le hachage, qu'un attaquant peut utiliser pour le relais ou pour essayer d'authentifier au sein d'un réseau compromis. Des cas antérieurs avaient déjà montré comment des paramètres tels que fichier Voie ou miette des entreprises comme Varonis ont documenté les utilisations de miette En 2024, et des fournisseurs comme Huntress ont publié une analyse des dérivés récents.

La décision de Microsoft de ne pas publier un patch pour cette conclusion sur l'argument qu'il n'a pas atteint son seuil de gravité pour le service laisse les organisations face à un risque opérationnel spécifique: en l'absence d'un arrangement officiel, les vecteurs sont encore exploitables par les acteurs qui peuvent attirer les utilisateurs vers des liens malveillants intégrés dans le courrier ou les pages Web. Cela rend la protection à la périphérie du réseau et les politiques de contrôle du protocole et du port dans les postes de travail particulièrement pertinentes.

En termes d'impact, l'exposition de Net-NTLMv2 est dangereuse parce que le hachage peut servir de base aux attaques de relais et aux mouvements latéraux, et parce que de nombreux environnements d'entreprise continuent de permettre ou de tolérer NTLM pour la compatibilité avec les logiciels existants. Un seul a des privilèges élevés dont le titre partiel est filtré peut faciliter l'escalade et la persistance dans un réseau, avec des conséquences qui incluent l'exfiltration de données, le déploiement de logiciels malveillants ou l'engagement de service interne.

En tant que contre-mesures immédiates pratiques et viables, il est conseillé de bloquer le trafic SMB sortant (TCP / 445 et TCP / 139) dans des équipements qui n'ont pas besoin de communiquer avec des serveurs internes via ces ports à partir de réseaux publics ou de sous-réseaux dangereux. En outre, forcer la signature SMB et permettre des politiques de protection d'authentification élargie réduit la possibilité qu'un hachage capturé soit réutilisé avec succès contre elle. Dans la mesure du possible, les organisations devraient envisager d'éliminer progressivement le NTLM en faveur de Kerberos et d'autres authentifications plus sûres.

De la couche de détection et de réponse, vous devez surveiller les tentatives inhabituelles d'authentification NTLM vers des destinations externes, examiner les enregistrements de connexion SMB et déployer des règles EDR qui alertent les processus qui lancent des gestionnaires URI avec des paramètres externes. La sensibilisation du personnel demeure critique : les techniques de génie social qui induisent le clic restent le vecteur préféré, de sorte que la formation et le filtrage du courrier de sandboxing aident à réduire la probabilité d'exploitation.

Sur le plan stratégique, cet incident rappelle deux enseignements : premièrement, que les gestionnaires de protocole locaux peuvent devenir des portes de sortie s'ils acceptent des entrées non validées; deuxièmement, que les décisions des fournisseurs sur le stationnement peuvent laisser des lacunes qui exigent des contre-mesures au niveau de la configuration et de l'architecture par les responsables de la sécurité. La mise en œuvre de la segmentation du réseau, des restrictions d'évacuation et des règles du pare-feu hôte sont des mesures qui permettront d'atténuer l'exposition en attendant un patch officiel.

Ceux qui veulent approfondir peuvent lire des analyses et des publications techniques des équipes qui ont étudié des variantes de cette attaque sur des blogs spécialisés et de la documentation officielle sur NTLM et SMB. Les ressources utiles pour la contextualisation et l'atténuation de la planification comprennent la contribution des fabricants et de la communauté à la gestion du NTLM et du SMB, comme la documentation technique de Microsoft sur le NTLM et les publications des sociétés de sécurité qui ont documenté des avoirs avec des paramètres dans les gestionnaires d'URI: https: / / learn.microsoft.com / fr-us / windows-server / sécurité / ntlm / et https: / / www.varonis.com / blog, en plus des rapports et des blogs de recherche de sites spécialisés tels que https: / / www.huntress.com / blog.

Enfin, ma recommandation pour les gestionnaires de l'informatique et de la sécurité est de prioriser les contrôles qui ne dépendent pas d'un patch fournisseur : bloquer le SMB sortant inutile, renforcer la signature SMB, planifier la désactivation NTLM et améliorer la surveillance d'authentification. Ces mesures réduisent la fenêtre d'opportunité des attaquants et augmentent les coûts d'exploitation même si la vulnérabilité reste non corrigée par le fabricant.