Zero-days Windows actifs : ce que les équipes dev doivent...

Ce qui s'est passé

Un chercheur en sécurité connu sous le nom de « Chaotic Eclipse » a publié sur GitHub le 3 avril un code d'exploit fonctionnel pour une faille d'élévation de privilèges locale dans Windows, baptisée BlueHammer. Sans divulgation coordonnée, sans attribution de CVE, sans correctif. Le chercheur, apparemment excédé par la façon dont son rapport de vulnérabilité avait été traité, a décidé de rendre tout cela public.

Puis la situation s'est aggravée. Deux autres exploits ont suivi : RedSun et UnDefend, qui ciblent tous deux les processus propres de Windows Defender pour faire passer un utilisateur à faibles privilèges au niveau d'accès SYSTEM. Microsoft a corrigé BlueHammer (désormais CVE-2026-33825) dans la mise à jour du Patch Tuesday du 15 avril, mais RedSun et UnDefend restent non corrigés à ce jour. Et les attaquants n'attendent pas. Huntress a confirmé cette semaine que les trois exploits sont utilisés contre des cibles en entreprise actives.

Pourquoi cela compte plus que le bruit habituel du Patch Tuesday

Le Patch Tuesday d'avril était déjà massif en lui-même : 167 failles corrigées, dont huit classées critiques, plus un zero-day Adobe Reader exploité depuis novembre 2025. C'est beaucoup. Mais c'est l'affaire BlueHammer qui retient mon attention, car il ne s'agit pas seulement d'une histoire de vulnérabilité. C'est une histoire d'échec de processus.

Les exploits eux-mêmes sont ingénieux. BlueHammer exploite une faille de synchronisation dans le flux de mise à jour des signatures de Windows Defender, en enchaînant Volume Shadow Copy, les callbacks de l'API Cloud Files et des verrous opportunistes pour interrompre Defender exactement au bon moment et lire des ruches de registre (SAM, SYSTEM, SECURITY) normalement verrouillées. Pas d'exploit noyau, pas de corruption mémoire, pas de shellcode. Juste des fonctionnalités Windows légitimes combinées dans le mauvais ordre. L'équipe Cyderes Howler Cell a vérifié indépendamment que la chaîne complète fonctionne sur des systèmes Windows 10 et 11 à jour.

RedSun est sans doute plus vicieux. Il piège le moteur temps réel de Defender dans un cycle de détection-remédiation en utilisant un fichier de test EICAR comme appât, puis exploite la logique de remédiation pour écraser des fichiers système et obtenir des privilèges administrateur. Il fonctionne même après l'application des correctifs d'avril.

Ce qui rend la situation particulièrement inconfortable pour les équipes de développement : ces exploits ciblent Windows Defender, l'outil que la plupart des organisations supposent protéger leurs postes de travail. Si vous êtes une équipe qui développe et déploie sous Windows, vos machines de dev, vos runners CI, vos serveurs de staging — tous sont concernés.

Ce que cela signifie pour les équipes de développement

Dans le cadre de nos missions de tests d'intrusion auprès de studios de jeux vidéo et de clients en entreprise, nous avons constaté à maintes reprises que l'élévation de privilèges locale est l'étape qui transforme une prise de pied mineure en compromission totale. Quelqu'un clique sur un lien de phishing, obtient un shell limité, et c'est terminé si l'LPE est facile. Ces trois exploits rendent l'LPE très accessible sur les machines Windows non corrigées.

La préoccupation concrète pour les équipes de dev : les postes de développeurs sont souvent le maillon le plus faible. Ils ont tendance à avoir plus de logiciels installés, plus d'exceptions dans les politiques de sécurité, plus d'accès administrateur local qu'ils ne le devraient. Nous avons retrouvé ce schéma à plusieurs reprises, que nous testions des plateformes de voyage ou des déploiements SaaS en entreprise. La machine du développeur est la porte d'entrée des attaquants, et l'élévation de privilèges est ce qui leur permet de s'y installer.

Avec deux exploits sur trois toujours non corrigés, vous ne pouvez pas vous contenter d'« appliquer la mise à jour et passer à autre chose » cette fois-ci.

Ce que vous devez faire dès maintenant

Premièrement, appliquez immédiatement les mises à jour du Patch Tuesday d'avril si ce n'est pas encore fait. Cela couvre BlueHammer et les 166 autres vulnérabilités, dont le zero-day Adobe Reader et un RCE critique dans Active Directory (CVE-2026-33826). Ce n'est pas optionnel.

Deuxièmement, pour RedSun et UnDefend, vous avez besoin de mesures compensatoires en attendant que Microsoft publie des correctifs :

Recherchez les indicateurs connus. Huntress a signalé que les attaquants déposent des binaires nommés FunnyApp.exe, RedSun.exe et z.exe dans les dossiers Images des utilisateurs et dans des sous-dossiers à deux lettres dans Téléchargements. Scannez ces emplacements. Mettez en place des alertes pour les exécutables inattendus dans les répertoires de profil utilisateur.
Surveillez l'élévation de privilèges et les accès à SAM. Tout processus qui passe soudainement d'un utilisateur standard à SYSTEM, ou tout accès inattendu à la base SAM, doit déclencher une alerte. Si votre EDR ne détecte pas cela, vous avez un problème plus profond.
Appliquez le principe du moindre privilège de façon stricte. Ces exploits nécessitent un accès local. Chaque réduction du nombre de personnes pouvant se connecter, de ce qu'elles peuvent exécuter et des droits d'administration locale dont elles disposent rend l'exploitation plus difficile. C'est une bonne semaine pour auditer les politiques des machines de développeurs.
Vérifiez vos runners CI/CD. Si vous utilisez des agents de build sous Windows, assurez-vous qu'ils ne sont pas accessibles depuis l'internet public, qu'ils ne tournent pas avec des privilèges inutiles et qu'ils ne stockent pas de credentials susceptibles d'être récupérés après exploitation.

Troisièmement, n'oubliez pas le zero-day Adobe Reader. Si votre équipe reçoit des PDF — et c'est le cas de toutes les équipes —, mettez à jour Reader et Acrobat. Celui-ci est exploité depuis fin 2025 et vient seulement d'être corrigé.

Le tableau d'ensemble : la divulgation coordonnée s'effrite

La frustration du chercheur vis-à-vis du processus de divulgation n'est pas nouvelle, mais elle devient de plus en plus fréquente. Quand signaler des vulnérabilités ressemble à crier dans le vide, certains chercheurs finissent par tout rendre public par dépit. C'est mauvais pour tout le monde, mais la réponse des éditeurs concernés doit être plus rapide et plus respectueuse envers ceux qui trouvent ces failles.

Dans le cadre de nos activités en sécurité, nous avons été des deux côtés. Nous avons signalé des découvertes à des éditeurs qui ont agi rapidement et pris les choses au sérieux. Nous avons aussi vu des rapports rester dans les limbes pendant des mois. Le processus MSRC a déjà été critiqué, et cet incident — où le chercheur avait explicitement prévenu de ce qui arriverait — illustre clairement ce qui se brise quand la confiance entre chercheurs et éditeurs s'érode.

Pour les équipes qui dépendent d'une infrastructure Windows, cela signifie que vous ne pouvez pas simplement faire confiance au fait que les vulnérabilités seront discrètement corrigées avant de devenir votre problème. Vous avez besoin de capacités de détection et de réponse qui partent du principe que des zero-days se produiront, parce qu'ils continueront à se produire.

À surveiller cette semaine

Au-delà du feuilleton Windows, Apache ActiveMQ CVE-2026-34197 mérite un regard. Un chercheur a utilisé un assistant IA pour découvrir une vulnérabilité d'exécution de code à distance qui se cachait dans le code depuis 13 ans. Si vous utilisez ActiveMQ, appliquez le correctif. Et le variant du malware Chaos qui cible désormais les serveurs cloud Linux mal configurés — après s'être jusque-là limité aux routeurs — rappelle que chaque service exposé sur internet doit être durci, pas seulement ceux que vous pensez intéresser les attaquants.

Quand nous configurons l'infrastructure cloud et mettons en place une protection DDoS pour nos clients, la première étape est toujours un inventaire honnête de ce qui est réellement exposé. La plupart des équipes sont surprises par ce qu'elles trouvent.

En résumé

Cette semaine est un rappel que la sécurité des postes de travail n'est pas un exercice à configurer une fois pour toutes. Deux zero-days d'élévation de privilèges non corrigés sont activement utilisés, ciblant l'outil même (Windows Defender) sur lequel la plupart des organisations comptent pour se protéger. Les équipes de développement avec lesquelles nous travaillons connaissent ce schéma : la sécurité n'est pas un produit qu'on achète, c'est un processus qu'on maintient.

Corrigez ce que vous pouvez, traquez ce que vous ne pouvez pas corriger, et renforcez les politiques d'accès local sur vos machines de développeurs et vos serveurs de build. Si vous n'êtes pas sûr de l'état de votre environnement Windows ou souhaitez de l'aide pour évaluer l'exposition à ces zero-days, parlons-en.