En plaçant des métadonnées contradictoires dans des fichiers LNK, un chercheur a découvert quatre nouvelles façons d’usurper des cibles, de masquer des arguments et d’exécuter des programmes involontaires dans l’Explorateur Windows.
Le nombre de façons dont les fichiers de raccourci Windows (.LNK) peuvent être abusés ne cesse de croître : un chercheur en cybersécurité a documenté quatre nouvelles techniques pour inciter les utilisateurs Windows à exécuter des actions malveillantes via des raccourcis d’apparence innocente.
Wietze Beukema a montré comment usurper la destination LNK visible, masquer les arguments de ligne de commande et exécuter un programme différent de celui présenté à l’utilisateur, offrant potentiellement aux attaquants de nouveaux vecteurs de phishing, d’attaques via USB ou d’opérations d’accès initial.
Cette divulgation s’ajoute aux inquiétudes de longue date concernant une faille dans la gestion des LNK qui a été exploitée à plusieurs reprises par des acteurs malveillants mais qui s’est avérée difficile à éliminer complètement.
Bien que Microsoft n’ait pas immédiatement répondu à une demande de commentaires sur la divulgation, il a déjà reconnu les risques dans ce domaine par le biais de directives de sécurité, notamment d’un avis de novembre 2025.
Jusqu’à présent, Microsoft s’est toujours abstenu de classer le comportement de Windows avec les fichiers LNK comme une « vulnérabilité » conventionnelle, mais le grand nombre d’exploits démontrés par Beukema rend la position de Microsoft selon laquelle il s’agit simplement d’un problème d’interface utilisateur plus difficile à défendre.
Appât et interrupteur
Les raccourcis Windows servent de pointeurs vers des programmes ou des documents, mais ils peuvent stocker plus que de simples chemins de fichiers. Les fichiers LNK peuvent spécifier des arguments de ligne de commande, des répertoires de travail, des icônes et d’autres paramètres d’exécution, agissant efficacement comme un lanceur.
Beukema a identifié plusieurs façons jusqu’alors non divulguées de créer des décalages entre ce qu’un raccourci Windows semble cibler et ce qu’il lance réellement. Étant donné que le format LNK permet de stocker le chemin cible dans plusieurs structures, notamment les champs « TargetIDList », « EnvironmentVariableDataBlock » et « LinkInfo », Windows doit choisir à quelle valeur faire confiance. Ce processus de décision peut être manipulé.
Selon Beukema, dans des conditions normales, l’Explorateur Windows donne la priorité à l’entrée EnvironmentVariableDataBlock lorsqu’elle et TargetIDList sont présentes, affichant et exécutant ce chemin. Toutefois, si le chemin de la variable d’environnement est un chemin de fichier Windows syntaxiquement non valide, l’Explorateur l’affiche toujours dans la boîte de dialogue Propriétés mais revient silencieusement au chemin masqué TargetIDList au moment de l’exécution.
Cela permet à un raccourci de présenter une destination apparemment inoffensive tout en exécutant un programme entièrement différent.
De plus, les failles divulguées par Beukema exploitent d’autres comportements de secours résultant de métadonnées conflictuelles. Si un EnvironmentVariableDataBlock est présent mais que LinkTargetIDList ne correspond pas, Windows exécute à la place l’exécutable à partir de la structure LinkInfo tout en continuant à afficher le chemin de la variable d’environnement.
Dans une variante de cet exploit, fournir uniquement la valeur cible ANSI tout en laissant le champ Unicode apparié vide amène Explorer à traiter les données comme incohérentes. Il affiche un chemin différent de celui de LinkTargetIDList, désactive le champ Target modifiable et masque les arguments. Pourtant, le chemin ANSI masqué est exécuté.
Ensemble, ces comportements peuvent potentiellement permettre aux attaquants d’usurper la cible visible, de dissimuler la cible réelle et d’induire les utilisateurs en erreur en les incitant à lancer des programmes involontaires.
Arguments de ligne de commande cachés
Au-delà de l’usurpation d’identité de cible, Beukema a démontré une technique permettant de cacher des instructions de ligne de commande malveillantes derrière des exécutables légitimes. Les fichiers LNK peuvent lancer des binaires Windows fiables tout en transmettant des instructions contrôlées par l’attaquant via des arguments intégrés, permettant ainsi une exécution « vivant de l’extérieur » (LOLBIN) sans pointer directement vers des logiciels malveillants.
Selon le chercheur, cela peut être fait en manipulant les entrées transmises dans certains champs de la section « ExtraData » de LNK qui détermine des métadonnées cibles supplémentaires. L’activation de l’indicateur « HasExpString » et la configuration de « EnvironmentVariableDataBlock » avec des champs « TargetANSI/TargetUnicode » remplis d’octets nuls produisent ce qu’il a décrit comme des résultats « inattendus ».
« Premièrement, cela désactive le champ cible, ce qui signifie que le champ cible devient en lecture seule et ne peut pas être sélectionné », a expliqué Beukema. « Deuxièmement, il masque les arguments de la ligne de commande ; pourtant, lorsque le LNK est ouvert, il les transmet toujours. » Ce comportement peut être exploité pour lancer un composant système inoffensif tout en exécutant secrètement des commandes arbitraires telles que le téléchargement de charges utiles ou l’exécution de scripts.
Selon la divulgation, il s’agit d’une meilleure approche pour les attaquants que d’exploiter CVE-2025-9491, car elle est plus difficile à détecter en raison de l’absence de lignes de commande visibles et rembourrées.
Beukema a noté que cette technique, comme les autres qu’il a décrites, repose sur la gestion normale des raccourcis de Windows plutôt que sur des bogues pouvant être corrigés, ce qui signifie que l’atténuation dépend en grande partie du traitement des fichiers LNK non fiables comme potentiellement dangereux et du fait d’empêcher les utilisateurs de les ouvrir. « Microsoft fait valoir que comme cela oblige l’utilisateur à faire quelque chose, sans briser les limites de sécurité, il ne s’agit pas d’une faille de sécurité », a-t-il déclaré. « Ce n’est pas totalement déraisonnable car en fin de compte, la plupart d’entre eux se résument à des bugs de l’interface utilisateur. »
