Résumé
CVE-2025-50154 est une vulnérabilité de l'Explorateur de fichiers Windows qui peut exposer des informations d'authentification sensibles sur le réseau. Microsoft classe ce problème comme une usurpation d'identité, la faille sous-jacente étant associée à CWE-200 (Exposition d'informations sensibles).
Dans les configurations concernées, Windows Explorer peut lancer une authentification réseau lors du traitement des métadonnées liées aux raccourcis. Si la destination distante référencée est contrôlée par un pirate, celui-ci peut capturer les données de défi-réponse NTLM. Selon les contrôles de sécurité mis en place par l'organisation, cela peut permettre des abus ultérieurs tels que le relais NTLM ou la devinette de mot de passe hors ligne.
Dans cet article, nous examinons la vulnérabilité CVE-2025-50154 à partir des recherches menées par des étudiants diplômés participant au programme OPSWAT Fellowship Program, et nous fournissons des conseils pratiques pour réduire le risque d'authentification NTLM forcée.
Impact et risque
CVE-2025-50154 a été divulgué le 12 août 2025 et affecte plusieurs versions prises en charge des clients et serveurs Windows ( Server Windows 10/11 et Windows Server ) antérieures aux versions corrigées. La vulnérabilité est classée CVSS v3.1 6.5 (moyenne).
La principale conséquence en matière de sécurité est l'exposition des identifiants : un pirate peut obtenir des informations de type « challenge-response » NTLM en amenant Explorer à s'authentifier auprès d'un terminal contrôlé par le pirate. Selon l'environnement, cela peut être utilisé pour :
• Relais NTLM (usurpation d'identité) : authentification auprès d'autres services en se faisant passer pour la victime lorsque les protections contre les relais sont absentes ou mal configurées.
• Deviner/pirater des mots de passe hors ligne : tenter de récupérer des mots de passe faibles à partir de données de défi-réponse capturées.
La faisabilité dépend fortement des contrôles d'entreprise tels que la signature SMB, les restrictions NTLM, la segmentation du réseau et le renforcement côté service.
Scénario d'attaque
CVE-2025-50154 est un problème d'authentification forcée. Lorsque Windows Explorer traite un raccourci qui fait référence à un emplacement SMB/UNC distant, il peut initier une connexion SMB pendant le rendu normal ou la validation du chemin d'accès. En conséquence, le point de terminaison distant peut recevoir des données d'échange d'authentification NTLM générées pendant la configuration de la session.
Un scénario d'attaque représentatif est le suivant :
- Préparation de l'attaquant : l'adversaire contrôle un serveur SMB et prépare un partage référencé par le raccourci.
- Placement du raccourci: un fichier .lnk pointant vers le chemin SMB contrôlé par l'attaquant est transmis à l'environnement de la victime via des canaux courants (par exemple, des pièces jointes de phishing, des dossiers synchronisés, des référentiels de fichiers partagés ou un point d'ancrage existant).
- Accès déclenché par l'Explorateur: lorsque la victime parcourt un répertoire contenant le raccourci, l'Explorateur Windows analyse les métadonnées du raccourci et peut tenter de résoudre la cible distante dans le cadre du traitement habituel de l'interface utilisateur.
- Authentification implicite: lors de la configuration d'une session SMB, Windows s'authentifie dans le contexte de l'utilisateur (souvent via NTLM). La victime n'a pas besoin d'exécuter la cible du raccourci pour que l'échange d'authentification ait lieu.
- Résultats après capture (dépendant de l'environnement) : en fonction des contrôles de l'environnement, les données NTLM capturées peuvent être utilisées pour le relais NTLM ou le craquage de mots de passe hors ligne. La faisabilité pratique dépend de facteurs tels que la signature SMB, les restrictions NTLM et la segmentation du réseau.
Contexte technique
Explorateur Windows et rendu des raccourcis
Windows Explorer (explorer.exe) est le processus shell Windows qui énumère le contenu des répertoires et affiche l'interface utilisateur de l'Explorateur de fichiers, en invoquant les composants Shell (par exemple, les gestionnaires d'icônes/superpositions/miniatures) pour obtenir et afficher les icônes, les superpositions et les miniatures.
Un raccourci Windows (.lnk) n'est pas un simple pointeur texte ; il s'agit d'un format de métadonnées structuré qui peut stocker un chemin cible (chemin local ou chemin UNC/SMB), des arguments facultatifs et un répertoire de travail, ainsi qu'une référence d'icône distincte. Lors de la navigation normale dans les dossiers, l'Explorateur analyse les métadonnées du raccourci afin de présenter celui-ci dans l'interface utilisateur (par exemple, en résolvant l'icône et en validant la cible). En fonction de la cible référencée et des métadonnées associées, ce traitement peut amener l'Explorateur à tenter d'accéder au réseau dans le cadre du rendu de routine ou de la vérification du chemin d'accès.
Authentification NTLM via SMB
Dans le partage de fichiers Windows, l'authentification SMB privilégie généralement Kerberos dans les environnements de domaine, mais NTLM peut toujours être négocié lorsque Kerberos n'est pas disponible ou n'est pas sélectionné. NTLM est un protocole de type challenge-response : le client annonce d'abord ses capacités, le serveur renvoie un challenge (nonce), et le client répond avec un message d'authentification dérivé du challenge et du secret de l'utilisateur, sans envoyer le mot de passe en clair.
Variantes NTLM et posture de sécurité (NTLMv1 vs NTLMv2)
Il existe plusieurs variantes de NTLM. Les environnements Windows modernes s'appuient généralement sur NTLMv2 et doivent éviter autant que possible l'utilisation de LM/NTLMv1.
NTLMv1 a été largement reconnu comme non sécurisé pour plusieurs raisons clés (cryptage faible, clés à faible entropie, vulnérabilité au relais, risque de piratage hors ligne, etc.).
Pour améliorer cela, Microsoft a introduit NTLMv2, qui renforce le calcul de la réponse. En pratique, NTLMv2 remplace l'ancienne construction de réponse de type DES par un schéma basé sur HMAC-MD5 et intègre un contexte supplémentaire dans la réponse, ce qui le rend nettement plus robuste que NTLMv1 contre plusieurs classes de techniques de récupération hors ligne.
Même avec NTLMv2, les organisations doivent continuer à considérer NTLM comme un protocole d'authentification à haut risque par rapport à Kerberos et appliquer des contrôles de défense en profondeur (par exemple, signature SMB et segmentation) afin de réduire l'ampleur des scénarios d'authentification forcée.
Pourquoi NTLM reste une cible fréquente
Bien que NTLM soit un protocole de type challenge-response, il reste attractif pour les pirates, car l'échange d'authentification est directement utilisable dans des conditions réseau hostiles. Lors de la configuration d'une session SMB, le point de terminaison distant reçoit les métadonnées d'authentification et les valeurs de défi-réponse nécessaires pour authentifier le client. Si un adversaire peut exploiter le point de terminaison de destination (par exemple, un serveur SMB contrôlé par l'attaquant) ou peut intercepter/interrompre la connexion en transit, il peut capturer les données d'échange NTLM et tenter des abus ultérieurs tels que le relais NTLM ou la devinette de mot de passe hors ligne, en fonction des protections de l'environnement.
Windows intègre également NTLM dans son expérience d'authentification unique (SSO). Les informations d'identification dérivées du secret de l'utilisateur sont gérées par LSASS et peuvent être utilisées pour s'authentifier auprès des ressources réseau (par exemple, les partages SMB) sans demander à plusieurs reprises à l'utilisateur de s'identifier. Bien que cela améliore la convivialité, cela élargit la surface d'attaque pour les scénarios d'authentification forcée : lorsqu'un raccourci .lnk fait référence à un chemin SMB distant, Windows Explorer peut initier une connexion SMB pendant le traitement de routine du raccourci et négocier automatiquement l'authentification.
Dans le contexte de CVE-2025-50154, cela signifie que les données d'authentification NTLM peuvent être envoyées à un terminal SMB contrôlé par un pirate sans que la victime n'exécute la cible référencée, créant ainsi une voie d'exposition silencieuse des identifiants lors de la navigation normale dans les dossiers.
Analyse technique
Rendu des icônes Explorer et traitement des raccourcis
Lorsqu'un dossier est ouvert dans l'Explorateur de fichiers, Explorer énumère le contenu du répertoire et détermine le type de chaque élément en fonction de son association de fichiers enregistrée (généralement déterminée par l'extension du fichier). Windows utilise ensuite l'enregistrement de classe shell correspondant (par exemple, via les mappages CLSID/ProgID associés dans le registre) pour localiser le gestionnaire shell approprié, généralement un composant COM responsable de l'extraction et du rendu des icônes. Explorer invoque les interfaces pertinentes pour récupérer et afficher l'icône.
Pour les fichiers .lnk (Shell Link), Explorer n'affiche généralement pas d'icône de raccourci générique par défaut. Au lieu de cela, il analyse les métadonnées du raccourci, tente de résoudre la cible référencée (et les informations relatives à l'icône), puis affiche l'icône associée à cette cible résolue.
Lorsque l'Explorateur affiche un fichier .lnk, il détermine l'icône en appelant CShellLink::GetIconLocation, qui identifie l'emplacement à partir duquel l'icône doit être chargée (par exemple, le fichier binaire cible, un chemin d'accès explicite à l'icône ou une icône système par défaut). Dans le cadre de ce flux, Explorer initialise l'extraction de l'icône (_InitExtractIcon), puis exécute la logique de résolution principale (_GetExtractIcon), qui évalue la source de l'icône (via _CheckExtractLocation).
• Si le raccourci spécifie un emplacement d'icône local (par exemple, un fichier exécutable ou une DLL sur le disque), Explorer charge l'icône directement à partir de cette ressource.
• Si l'emplacement de l'icône est une URL distante, Explorer peut télécharger l'icône dans son cache local (par exemple, à l'aide de URLDownloadToCacheFileW), puis charger l'icône à partir de la copie mise en cache.
• Si aucune source d'icône valide n'est disponible, Explorer utilise une icône par défaut fournie par le gestionnaire système.
Après avoir résolu les métadonnées liées aux icônes, Explorer passe par CShellLink::Extract, qui gère la cible du raccourci et termine le processus d'extraction. Dans le cadre de ce chemin, Explorer invoque CShellLink::_ShortNetTimeout pour appliquer des délais d'attente réseau plus courts lorsque le raccourci fait référence à un emplacement distant, ce qui réduit les délais d'interface utilisateur si la cible réseau est lente ou inaccessible.
Lorsque la cible est identifiée comme un chemin réseau (UNC), Explorer effectue la validation de la cible de manière asynchrone. Il génère un thread de travail qui exécute CShellLink::_VerifyPathThreadProc, qui vérifie si la cible référencée existe.
Dans cette routine, Explorer appelle PathFileExistsAndAttributesW pour vérifier l'existence de la cible et ses attributs de base (par exemple, fichier ou répertoire), ce qui nécessite à son tour une tentative d'accès au réseau pour les cibles SMB/UNC.
Cause profonde de la vulnérabilité
Dans le flux de rendu des raccourcis décrit ci-dessus, deux opérations sortantes sont pertinentes :
• Récupération d'icônes via URLDownloadToCacheFileW (lorsque la source de l'icône du raccourci est une URL distante).
• Validation de la cible via PathFileExistsAndAttributesW (lorsque la cible du raccourci est un chemin UNC/SMB).
Pour valider le comportement de URLDownloadToCacheFileW, nous avons testé API un test minimal et autonome.
L'activité réseau consistait en une requête HTTP classique et, d'après nos observations, elle n'a pas exposé d'informations d'identification pertinentes pour cette vulnérabilité.
Le comportement le plus significatif se produit avec PathFileExistsAndAttributesW lorsque le chemin évalué est une cible UNC/SMB. Lors du débogage, nous avons observé que cette vérification peut lancer la configuration d'une session SMB et négocier l'authentification dans le contexte utilisateur actuel.
Étant donné qu'Explorer peut invoquer automatiquement cette validation lors du traitement d'un fichier .lnk, un point de terminaison SMB contrôlé par un attaquant peut recevoir des informations d'authentification NTLM sans que la victime n'exécute le fichier référencé, créant ainsi une voie d'exposition silencieuse des informations d'identification lors de la navigation courante dans les dossiers.
Preuve de concept
Dans un laboratoire isolé, les participants à notre programme OPSWAT Fellowship ont validé la vulnérabilité CVE-2025-50154 en utilisant un raccourci (.lnk) qui faisait référence à un chemin SMB/UNC distant. Sur un système Windows vulnérable, le simple fait de parcourir le dossier dans l'Explorateur Windows a déclenché une connexion SMB pendant le traitement normal du raccourci, provoquant l'envoi des données d'authentification NTLM au point de terminaison distant, sans que la victime n'exécute la cible du raccourci.
Remédiation
Les organisations doivent veiller à ce que leurs systèmes d'exploitation et leurs applications soient régulièrement mis à jour afin d'atténuer les vulnérabilités connues. Cela implique notamment d'appliquer toutes les mises à jour de sécurité Microsoft pertinentes et de vérifier que tous les terminaux exécutent les dernières versions corrigées de Windows. Parallèlement, les organisations doivent réduire leur surface d'attaque en renforçant l'accès SMB sortant lorsque cela est nécessaire et en renforçant les contrôles de sécurisation NTLM/SMB en fonction de leur environnement.
MetaDefender soutient ces efforts et aide à les mettre en œuvre à grande échelle en offrant une visibilité claire sur l'exposition et l'état de préparation des correctifs. Grâce à ses solides capacités de gestion des vulnérabilités et des correctifs prenant en charge plus de 1 100 applications, MetaDefender Endpoint identifieEndpoint les terminaux exécutant des versions Windows non corrigées ou obsolètes ainsi que des applications tierces, et fournit les correctifs recommandés.
De plus, grâce à la console de gestion My OPSWAT Central Management, les administrateurs bénéficient d'une vue centralisée et unifiée de l'état de sécurité des terminaux, de l'exposition aux vulnérabilités et de la gestion des correctifs, le tout au sein d'une plateforme unique permettant de définir et d'appliquer des politiques de sécurité à l'échelle de l'entreprise. Les administrateurs peuvent également créer et déployer des scripts personnalisés sur les terminauxEndpoint MetaDefender Endpoint afin d'automatiser les mesures de renforcement liées à l'accès SMB et à l'utilisation de NTLM. Cette approche rationalise l'application des mesures de sécurité tout en fournissant des informations claires sur les résultats d'exécution, ce qui permet aux administrateurs d'identifier rapidement les terminaux qui peuvent nécessiter une investigation plus approfondie ou une intervention manuelle.
MetaDefender Endpoint aux équipes informatiques et de sécurité de hiérarchiser les déploiements, d'accélérer les corrections, de surveiller en permanence la posture de sécurité de l'entreprise et, au final, de réduire l'exposition aux vulnérabilités et expositions courantes (CVE) telles que CVE-2025-50154 et autres menaces similaires visant les terminaux.
