BlueHammer : un chercheur publie un zero-day Windows

Ce qui s'est passé

Le 3 avril 2026, un chercheur en sécurité opérant sous le pseudonyme Chaotic Eclipse a publié sur GitHub un code d'exploitation pleinement fonctionnel visant une vulnérabilité jusque-là inconnue de Microsoft. L'exploit BlueHammer zero-day Windows combine une faille de type TOCTOU (time-of-check to time-of-use) et une confusion de chemin pour contourner les contrôles d'accès et lire la base SAM (Security Account Manager), qui stocke les empreintes des mots de passe de tous les comptes locaux de la machine. Un attaquant disposant d'un accès utilisateur standard peut ainsi obtenir des privilèges SYSTEM, extraire ces hachages, puis les rejouer ou les casser hors ligne pour se déplacer latéralement dans le réseau. La publication est intervenue sans divulgation coordonnée préalable, laissant les équipes de sécurité sans correctif officiel et contraintes d'appliquer des mesures d'atténuation temporaires.

Le chercheur a exprimé sa frustration envers le Microsoft Security Response Center (MSRC), déclarant : « Je ne bluffais pas, et je recommence. » Selon ses déclarations, il avait signalé la vulnérabilité de manière responsable, mais le traitement par Microsoft l'a poussé à divulguer publiquement l'exploit. Il a ajouté avec ironie : « Un grand merci au leadership du MSRC pour avoir rendu cela possible. »

Une fois l'accès à la base SAM obtenu, un attaquant local peut escalader ses privilèges jusqu'au niveau SYSTEM, obtenant ainsi un contrôle total sur la machine compromise. L'exploit ne nécessite aucune interaction utilisateur au-delà de l'exécution locale initiale, ce qui le rend particulièrement dangereux dans les environnements d'entreprise où un poste de travail compromis peut servir de pivot.

Pourquoi c'est important

Cette divulgation illustre une tension récurrente dans l'écosystème de la sécurité : le décalage entre les attentes des chercheurs et la réactivité des éditeurs. Lorsqu'un chercheur estime que sa découverte n'est pas traitée sérieusement, la tentation de la divulgation publique grandit, avec des conséquences potentiellement désastreuses pour des millions d'utilisateurs.

BlueHammer est classé comme zero-day selon la propre définition de Microsoft, puisqu'aucun correctif n'est disponible. Les équipes de sécurité doivent donc agir en mode dégradé : surveiller les accès à la base SAM, restreindre les privilèges locaux et renforcer la détection des mouvements latéraux. Les entreprises utilisant des postes Windows partagés ou des environnements avec des utilisateurs à faible confiance sont particulièrement exposées.

Ce qu'il faut retenir (2)

• BlueHammer est un exploit d'élévation de privilèges locale (LPE) combinant TOCTOU et confusion de chemin, donnant un accès SYSTEM.
• Aucun correctif Microsoft n'est disponible à ce jour ; l'exploit est public sur GitHub.
• Appliquer immédiatement des contrôles compensatoires : restriction des accès locaux, monitoring de la base SAM et segmentation réseau renforcée.

Ce mode de divulgation n'est pas inédit : il s'inscrit dans une lignée de « frustration disclosures » qui a déjà marqué l'écosystème Windows. Entre 2018 et 2019, la chercheuse connue sous le pseudonyme SandboxEscaper avait publié coup sur coup cinq exploits zero-day affectant le planificateur de tâches, le service d'installation MSI et d'autres composants du noyau Windows, invoquant les mêmes griefs envers le processus de traitement des vulnérabilités du MSRC. Chacune de ces divulgations avait été suivie, dans un délai de deux à six semaines, par un correctif hors cycle ou intégré au Patch Tuesday suivant. BlueHammer suit un scénario comparable : une faille d'élévation de privilèges locale, sans interaction utilisateur complexe, rendue publique avec preuve de concept fonctionnelle sur GitHub avant toute réponse officielle de l'éditeur.

L'impact sectoriel potentiel reste significatif compte tenu de la part de marché de Windows, présent sur plus de 70 % des postes de travail professionnels dans le monde selon StatCounter. Une vulnérabilité d'élévation de privilèges locale comme BlueHammer n'est pas exploitable à distance sans chaîne complémentaire, mais elle constitue une brique critique dans les scénarios d'attaque post-compromission : un attaquant ayant obtenu un accès initial limité (phishing, identifiants volés, exécution de code utilisateur standard) peut s'en servir pour basculer vers un contrôle SYSTEM complet, puis extraire les hash NTLM stockés dans la base SAM afin de mener des attaques de type Pass-the-Hash sur le reste du parc. C'est précisément ce type de vulnérabilité qui, historiquement, se retrouve intégré dans des frameworks post-exploitation comme Metasploit ou Cobalt Strike dans les jours suivant une divulgation publique.

Un débat récurrent sur la divulgation responsable

L'épisode BlueHammer relance la controverse entre deux modèles de divulgation qui structurent l'industrie depuis plus de vingt ans :

• Divulgation coordonnée (CVD) : le chercheur signale la faille à l'éditeur et attend un correctif avant publication, généralement sous 90 jours (norme popularisée par Google Project Zero).
• Divulgation complète (full disclosure) : le chercheur publie l'exploit sans attendre, estimant que la pression publique accélère la correction ou que l'éditeur a échoué à traiter le signalement de bonne foi.

Microsoft n'a pas communiqué publiquement sur les délais de traitement initiaux du signalement de Chaotic Eclipse, ce qui alimente les critiques d'une partie de la communauté sécurité sur l'opacité du MSRC dans le triage des rapports de vulnérabilité, notamment pour les failles jugées « low severity » par l'éditeur mais à fort potentiel de chaînage offensif.

Ce qu'il faut retenir

Pour les RSSI et équipes SOC, BlueHammer doit être traité comme un risque actif dès maintenant, indépendamment du calendrier de correctif de Microsoft. L'absence de CVE officiellement attribué à ce stade ne réduit en rien la surface d'exposition réelle des postes Windows non durcis.