Des raccourcis dangereux pour que les fichiers LNK puissent tromper Windows et exécuter des logiciels malveillants

Depuis des décennies, l'accès direct à .lnk fait partie de l'écosystème Windows : ils sont arrivés avec Windows 95 et depuis, leur format binaire a augmenté en complexité. Cette complexité est précisément ce qu'un chercheur néerlandais en sécurité, Wietze Beukema, a profité pour montrer que ces fichiers peuvent devenir des pièges sophistiqués pour les utilisateurs non préparés.

Dans une présentation à Wild West Hackin 'Fest, Beukema a détaillé plusieurs nouvelles techniques qui permettent de créer des raccourcis qui montrent une chose dans la fenêtre de propriété de l'Explorateur de Windows mais qui, en les exécutant, ils lancent un complètement différent. Le noyau du problème est qu'un fichier .lnk peut contenir plusieurs structures optionnelles qui décrivent la route cible, et l'Explorateur Windows ne priorise pas ou ne valide pas toujours ces champs. Le résultat : vous pouvez faire un accès direct qui semble pointer vers un PDF, par exemple, et qui exécute réellement PowerShell ou d'autres ordres malveillants.

Parmi les techniques décrites sont des variantes qui exploitent les caractères interdits sur les routes Windows - comme les guillemets doubles - pour construire des routes qui semblent valides à l'œil nu mais sont techniquement invalides. Explorer, au lieu de rejeter ces .lnk, les présente de manière conciliante, montrant la route "faux" tout en ouvrant l'accès direct exécute la route "réelle" cachée dans une autre structure du fichier.

Une des techniques les plus puissantes est basée sur la manipulation de l'environnementVariableDataBlock structure dans le .lnk. Beukema a constaté que laisser le champ Unicode vide et ne remplir que la version ANSI de la destination, il est possible de montrer une cible inoffensive sur l'interface - par exemple, "invoice.pdf" - tandis que le contenu réel de l'environnementVariableDataBlock invoque des commandes malveillantes ou exécutables. De plus, dans ces paramètres, les arguments en ligne de commande peuvent être cachés, ce qui complique encore plus la détection de la tromperie par un simple examen des propriétés.

Beukema a publié une analyse technique avec des exemples et des tests sur son blog, où il explique en détail comment ces structures fonctionnent et pourquoi Explorer se comporte permissivement à des fichiers LNK mal formés: analyse de Wietze Beukema. Il a également publié un outil open source appelé lnk-it@-@ up qui vous permet de générer des raccourcis avec ces techniques et de comparer ce qu'Explorateur montre avec ce qui fonctionne réellement, utile pour tester et détecter: Dans GitHub.

Lorsque Beukema a informé Microsoft du problème lié à EnvironmentVariableDataBlock (enregistrement VULN-162145), la société a décidé de ne pas le classer comme une vulnérabilité de sécurité dans son MSRC, en faisant valoir que son exploitation exige de l'utilisateur d'exécuter volontairement un fichier malveillant et ne rompt donc pas les limites de sécurité du système. Cette position a été communiquée par Microsoft à différents médias, et la société a rappelé que Windows avertit en essayant d'ouvrir .lnk téléchargé depuis Internet et que des outils comme Microsoft Defender et Smart App Control ajoutent des couches de protection.

Cependant, l'histoire récente montre pourquoi de nombreux chercheurs et équipes d'intervention s'intéressent à .lnk. Un échec connexe, identifié comme CVE-2025-9491, a également permis de cacher les arguments en ligne de commande et a été exploité dans des attaques réelles pendant des années. Les rapports de l'industrie montrent que de nombreux groupes, y compris des acteurs étatiques et des gangs criminels, ont utilisé ces faiblesses pour déployer des logiciels malveillants et des chevaux de Troie à distance. Pour de plus amples renseignements sur la portée de ces exploitations, voir le dossier public de la CVE : CVE-2025-9491 en NVD et l'analyse des menaces qui ont documenté l'activité de plusieurs acteurs: Tendance Micro rapport.

Face à l'exploitation active de CVE-2025-9491 Microsoft a fini par introduire des changements dans la gestion de .lnk en juin 2025 dans l'intention d'atténuer le vecteur qui était utilisé dans les attaques réelles. Toutefois, la position selon laquelle une technique « exige l'interaction de l'utilisateur » demeure la ligne officielle pour la classification de la gravité, laissant place à la discussion sur l'obligation de corriger la façon dont le système affiche et hiérarchise l'information en accès direct.

Pour tout utilisateur ou agent de sécurité, il y a plusieurs points pratiques qui devraient être pris en compte dès maintenant. Premièrement, .lnk devrait être considéré comme des fichiers potentiellement dangereux: s'ils proviennent de sources inconnues ou de messages inattendus, l'option la plus sûre est de ne pas les ouvrir. Deuxièmement, les solutions de détection et la politique de mise en œuvre de l'application (p. ex., Smart App Control) réduisent les risques mais ne les éliminent pas; les attaquants continuent d'inventer des astuces pour échapper aux contrôles. Enfin, ceux qui gèrent des équipements ou des réseaux peuvent utiliser des outils comme celui mentionné par Beukema pour analyser et détecter les suspects .lnk dans leur environnement, toujours dans des laboratoires contrôlés et non dans des systèmes de production.

Le cas de .lnk accès direct est un bon rappel que les vecteurs d'attaque ne passent pas toujours par des e-mails avec des pièces jointes .exe ou par des documents macro: parfois l'exploitation est plus subtile et profite des comportements permissifs du système d'exploitation lui-même. La combinaison de l'ingénierie sociale (convaincre quelqu'un de cliquer) et d'une mise en œuvre clémente dans le logiciel entraîne des difficultés à détecter les pièges en vue.

Si vous souhaitez approfondir les tests techniques et expérimenter les exemples, vérifiez le matériel publié par Beukema et utilisez son outil dans un environnement isolé: données techniques et dépôt. Pour comprendre le contexte historique et les campagnes qui ont abusé des échecs similaires, les informations recueillies dans la base de données NVD et les rapports des sociétés de sécurité telles que Trend Micro fournissent des exemples concrets d'exploitation : NVD et analyse de Trend Micro.

Bref, ce n'est pas une mauvaise idée de revoir les pratiques de sécurité dans l'organisation et de rappeler aux utilisateurs que les avertissements système ne sont pas de simples formalités: de nombreuses campagnes réussies ont prospéré parce que les gens cliquent sans penser. Les raccourcis Windows, même innocents, restent un vecteur utile pour les attaquants et méritent l'attention des équipes de sécurité et des utilisateurs finaux.