Connexion Premium

Des pirates exploitent activement deux failles Windows, dont l’une n’est pas corrigée

Entre pas de correctif et deux correctifs

Des pirates exploitent activement deux failles Windows, dont l’une n’est pas corrigée

Illustration : Flock

Deux vulnérabilités de Windows, dont l’une critique, sont activement exploitées. Les pirates s’en prennent particulièrement aux installations Windows Server sur site, dans l’objectif de dérober des informations.

Depuis bientôt deux semaines, plusieurs groupes de pirates de type APT (Advanced Persistent Threat), le plus souvent étatiques, sont à pied d’œuvre pour exploiter deux failles de sécurité dans Windows.

La première, CVE-2025-9491, a été découverte en mars dernier par Trend Micro et réside dans le format binaire Windows Shortcut (les fichiers .LNK). Affichant un score CVSS de 7,8 sur 10, elle peut être exploitée depuis une page web malveillante pour provoquer l’exécution d’un code arbitraire à distance, avec les droits de l’utilisateur en cours.

La seconde, CVE-2025-59287, est beaucoup plus dangereuse. Affichant un score CVSS de 9,8, elle affiche le niveau presque maximal de dangerosité. Elle réside dans le Windows Server Update Service (WSUS) de Windows Server et permet la désérialisation de données non approuvées, avec à la clé la possibilité d’exécuter du code arbitraire.

Une campagne depuis des mois, une exploitation depuis des années

Différence fondamentale entre les deux failles : la première n’est pas corrigée et fait l’objet de campagnes actives. C’est ce que Trend Micro affirmait déjà le 18 mars. L’éditeur indiquait que la faille avait été découverte en septembre 2024, mais qu’elle était présente dans le système depuis 2017, et probablement exploitée plus ou moins activement depuis.

Trend Micro indiquait alors avoir identifié plus d’un millier de fichier LNK malveillants contenant des commandes cachées pour déclencher des actions. Onze groupes APT de Corée du Nord, d’Iran, de Russie et de Chine étaient épinglés. Selon l’entreprise de sécurité, une preuve de concept avait été envoyée à Microsoft, mais l’éditeur aurait refusé de corriger la faille, sans que l’on sache pourquoi.

Et si l’on en parle toujours, c’est parce qu’un rapport publié par Arctic Wolf le 30 octobre faisait état d’une exploitation toujours active de cette faille en septembre et octobre. Cette fois, les cibles étaient surtout situées en Europe, particulièrement « les entités diplomatiques hongroises et belges », signe d’une coordination précise. L’ingénierie sociale est utilisée pour envoyer de fausses invitations, avec des détails sur des évènements diplomatiques, « notamment les réunions de facilitation des frontières de la Commission européenne et les ateliers de l’OTAN sur les achats de défense ».

Toujours selon ce rapport, l’attaque passe par le chargement de bibliothèques DLL provenant d’utilitaires Canon pour imprimantes et ayant une signature authentique. Le logiciel malveillant PlugX est également utilisé pour établir la persistance et voler silencieusement des informations. Arctic Wolf ajoute que la taille du fichier CanonStager, utilisé pour charger le malware, est passée de 700 ko à seulement 4 ko entre septembre et octobre, signe selon la société d’un développement très actif.

En l’absence de correctif pour l’instant, la mesure recommandée consiste à verrouiller les fonctions des fichiers LNK.

Interrogée par HelpNetSecurity sur le sujet, Microsoft a indiqué que Defender et Smart App Control avaient été mis à jour en septembre 2024 pour tenir compte de cette menace, mais le système d’exploitation lui-même n’a pas eu de correctif. Dans une autre réponse donnée le 2 novembre, la société a simplement déclaré qu’elle appréciait « le travail de la communauté des chercheurs » et qu’elle encourageait « vivement les clients à tenir compte des avertissements de sécurité et à éviter d’ouvrir des fichiers provenant de sources inconnues ».

Une faille critique corrigée deux fois

L’autre faille, CVE-2025-59287, est beaucoup plus dangereuse, mais elle a le gros avantage d’avoir été corrigée. Deux fois en fait : une première lors du Patch Tuesday d’octobre, la seconde lors d’une mise à jour d’urgence (et hors cycle) le 24 octobre. Une preuve de concept était apparue rapidement après le premier correctif, prouvant que le colmatage était incomplet et expliquant la seconde mise à jour.

Comme toujours dans ce genre de cas, le problème pourrait être considéré comme réglé puisque le correctif bouche la vulnérabilité, mais la difficulté réside dans l’application du correctif. La faille résidant dans les installations sur site de Windows Server et l’utilisation de WSUS pour gérer et diffuser les mises à jour dans le parc informatique, il faut appliquer le correctif sur les serveurs concernés, nécessitant une interruption de service.

Selon la société de sécurité Huntress, des signes d’exploitation de cette faille sont apparus le 23 octobre, la veille de la diffusion du second correctif. Des observations corroborées par d’autres entreprises, dont Sophos qui évoquait le 24 octobre comme début des hostilités. La faille peut donc être considérée comme 0-day puisqu’elle n’était pas corrigée au moment de son exploitation. Elle a également fait l’objet d’une fiche par l’ANSSI le 27 octobre. On ne sait pas à l’heure actuelle si la preuve de concept publiée peu de temps après le premier correctif a été utilisée pour exploiter la faille.

En outre, même si le correctif disponible colmate bien la brèche, l’agence américaine de cybersécurité (CISA) a publié une note à ce sujet le 29 octobre. Elle enjoint le personnel concerné à mettre à jour aussi rapidement que possible les serveurs concernés et à effectuer d’autres tâches, dont la surveillance active de processus potentiellement suspects. Il est également conseillé de surveiller également les processus PowerShell imbriqués utilisant des commandes codées en Base64.

Commentaires (25)

votre avatar
En l’absence de correctif pour l’instant, la mesure recommandée consiste à verrouiller les fonctions des fichiers LNK.
A quel niveau ? Du serveur et/ou des postes clients ? Comment on verrouille cela ?
votre avatar
LinkResolveIgnoreLinkInfo ?
votre avatar
A priori LinkResolveIgnoreLinkInfo ne fonctionne plus sous Windows 10 :
How to disable automatic resolution of shortcuts (.lnk files) in Windows 10? Group policies not working
votre avatar
Ah mince.

Et en relisant la CVE, je ne pense pas que ca aurait servi a qqc. La faille n'a pas l'air liée au roaming. De ce que je comprend, le LNK contient plusieurs commandes mais seule la première est visible quand on inspecte les propriétés... les autres commandes sont hors champs (à coups d'espaces).
votre avatar
Quand je pense que j'ai des clients avec des serveurs Windows en directe sur internet avec une IP publique...
votre avatar
Il faut savoir vivre dangereusement :D
votre avatar
Après WSUS ne sert que pour balancer des mises à jours à d'autres ressources, c'est pas une application métier ou une BDD.
15-30 min de coupure pour pousser le patch c'est quoi le soucis pour pas l'avoir déjà fait ?
votre avatar
"Selon l’entreprise de sécurité, une preuve de concept avait été envoyée à Microsoft, mais l’éditeur aurait refusé de corriger la faille, sans que l’on sache pourquoi."

Hum, l'impression que MS ne se dépêche pas car c'est utilisé par des services US ?
votre avatar
Tout simplement car ce n'est pas un bug, c'est une fonctionnalité, dixit la doc du format .LNK:
learn.microsoft.com Microsoft
votre avatar
Selon l’entreprise de sécurité, une preuve de concept avait été envoyée à Microsoft, mais l’éditeur aurait refusé de corriger la faille, sans que l’on sache pourquoi.
Sérieusement, cette sale pub ... Et cette connerie ... (si avéré pour le "aurait")
votre avatar
Du coup, première faille majeure pour Windows 10 qui va lui survivre ad vitaem eternam.

That was fast!

Et donc un foutage de gueule monumental et irresponsable de la part de M$ qui la connait depuis des mois, mais qui ne fait rien, et qui termine tranquilou le support sécurité gratuit de W10, la fleur au fusil....
votre avatar
La faille sera bien entendue patchée pour Windows 10 via le programme de mises à jour de sécurité étendues, et pour les éditions LTSC et IoT LTSC encore supportées.
votre avatar
That was pas fast du tout, la faille est connue depuis déjà un an, visiblement Microsoft ne veut pas la corriger et semble plutôt considérer que c'est au logiciel de sécurité d'y veiller (leur Defender ou un autre) plutôt qu'à l'OS.

Et vu qu'aucun communiqué ne semble préciser de version de Windows concernées, il semble que Windows 11 le soit aussi, ainsi que les versions LTSC de Windows 10, et sans correction prévue non plus.
votre avatar
Les choses ne sont pas si simple. Est-ce qu'il y a un vecteur d'attaque via un fichier .lnk ? La réponse est oui.

Est-ce exploitable facilement ? Non. Déjà, il faut que :

  • l'utilisateur télécharge le fichier .lnk (1er redflag)

  • l'utilisateur "exécute" le fichier .lnk (2e redflag)

  • l'utilisateur passe outre les différents avertissements (fichiers téléchargés depuis internet, etc.) (3e redflag)



En gros, ce n'est pas différent que de télécharger directement un .exe. Bref, .exe/.lnk, c'est la même chose. Que la réponse apportée soit la même n'est donc pas choquant (sécurisé via antivirus et non au niveau de l'OS).
votre avatar
Si on avait eu tôt un équivalent des liens symboliques implémenté au niveau système de fichier, on n'aurait pas la possibilité évoquée de "fichier LNK malveillants contenant des commandes cachées pour déclencher des actions", permise par cet emplâtre sur jambe de bois qui participe à faire de windows un cas d'école de tout ce qu'il ne faudrait pas faire. Les liens soft/hard existant depuis la nuit des temps Unix ont certes été ajoutés (époque XP, venant probablement de NT), mais ils ne semblent guère utilisés... et même pas proposés par défaut depuis quand on veut créer un raccourci.
votre avatar
Les liens symboliques n'autorisent pas la définition du path, le passage d'arguments...
votre avatar
Un lien symbolique/soft pointe directement sur la cible du lien comme si de rien n'était. Donc pas vraiment de limite en terme d'utilisation vs le fichier (exécutable ou non) ou répertoire cible. On n'a même pas la contrainte d'être sur la même partition comme en lien hard (ou on est plutôt dans un alias de nom).

Mais bon, de toutes manières, quand on voit les possibilités offertes niveau montages/fonctionnalités des systèmes de fichier Unices vs Windows, yapaphoto comme on dit.
votre avatar
Je ne suis pas sûr que Microsoft offre moins de possibilité entre les symlinks, junctions, hardlinks et d'une façon générale les reparse points. "Out of the box" tu as sûrement raison.
votre avatar
C'est pas la même utilisation. Les liens symboliques sont là pour qu'un même fichier apparaisse plusieurs fois dans une arborescence, pas pour lancer des commandes prédéfinies.

Quand on crée un raccourci sur un bureau Linux, c'est pareil que sous Windows, on ne crée pas un lien symbolique, on crée un raccourci avec une commande, des arguments, un chemins d'exécution, des paramètres d'exécution divers...

Peut-être que le format LNK de Windows fait un peu trop de choses, mais un lien symbolique n'en ferait pas assez pour cette utilisation, en dehors du simple raccourci vers un dossier.
votre avatar
C'est pas l'utilisation majoritaire... et pour l'utilisation que tu cites, il y a les scripts.
votre avatar
Bien sur que si c'est l'utilisation majoritaire, rien que pour le chemin d'exécution déjà. Et quant à utiliser les scripts à la place, c'est encore pire niveau sécurité car on peut mettre n'importe quoi dedans sans contrainte.
votre avatar
Les scripts ne diffèrent pas à ce niveau des commandes que peut lancer un utilisateur à la main, selon ses droits.
votre avatar
Si c'est l'utilisation majoritaire. Le lien provoque un appel à ShellExecute sur la cible, qui "ouvre" la cible (exécution pour un exécutable). Si tu fais un lien symbolique à la place et que le programme a besoin de fichiers situés dans son répertoire (dll par exemple), ça ne marchera pas (il faudrait au moins que le path soit changé, ou le répertoire courant, et même avec ça ça peut échouer).
votre avatar
OK, j'avais pas compris le truc ainsi (j'ai pas fait bcp de dev Windows... et ca remonte à NT/95!!! Depuis VxWorks puis Linux et aucune envie d'y revenir)... Maintenant, si les applis ne sont pas fichues au besoin de récupérer un path physique (pwd -P sur Unices ; ou via getcwd() de la libc dans un programme compilé) pour ces besoins c'est à mon sens un 2nd pb de conception... qui résulte de ne même pas, à la base, envisager d'être lancé via un lien symbolique arrivé sur le tard chez Microsoft.
votre avatar
pwd -P, oui, parce que getcwd aurait le même problème que le reste, ne pas te donner le répertoire courant.
Bien sûr que les applis n'envisagent pas d'être lancées via un lien symbolique quand il y a un mécanisme dédié depuis Windows 95, et encore une fois, un lien symbolique ne permet pas de passer de paramètres.

Perso sous Linux, je n'utilise pas de symlinks dans le but de faire un raccourci. Pour ça y'a les fichiers desktops, qui permettent de passer des paramètres, définir une icône, le chemin d'exécution (en fait... comme les liens sous Windows).
Pour ça que Inodemus faisait cette comparaison, qui est la bonne.