BlueHammer contourne Windows Defender et obtient un accès SYSTEM sans correctif disponible

Du code d’exploit pour une faille 0-day Windows circule publiquement, avec une promesse simple, passer d’un compte local limité à des droits SYSTEM, donc le contrôle total de la machine. La vulnérabilité, surnommée BlueHammer, a été signalée à Microsoft via son processus de divulgation, puis publiée après un différend sur la gestion du dossier. À cette heure, aucun correctif officiel n’est disponible.

Le point technique central, c’est une escalade de privilèges locale, pas une prise de contrôle à distance « en un clic ». Mais dans les scénarios d’attaque réels, ce type de brique est souvent ce qui transforme une intrusion banale, par exemple via phishing, en compromission complète, avec accès aux identifiants, aux outils de sécurité, et à la persistance. Et c’est là que l’affaire devient sérieuse, même si la preuve de concept est décrite comme imparfaite.

BlueHammer combine TOCTOU et confusion de chemin

BlueHammer est décrit comme une faille d’escalade de privilèges locale qui combine deux mécanismes classiques, un bug de type TOCTOU, time-of-check to time-of-use, et une confusion de chemin. En clair, le système vérifie une condition de sécurité à un instant T, puis l’état change avant l’utilisation réelle, ce qui permet de détourner l’accès attendu. C’est une famille de bugs souvent difficile à exploiter proprement, car elle dépend du timing et de l’environnement.

Un analyste en vulnérabilités, Will Dormann, a indiqué que l’exploit fonctionne et qu’il permet d’accéder à la base SAM, Security Account Manager, qui contient les hashes de mots de passe des comptes locaux. Ce détail compte, parce que la SAM devient un levier pour récupérer des secrets et pivoter vers des privilèges plus élevés, jusqu’à obtenir des droits SYSTEM. Une fois ce niveau atteint, l’attaquant peut lancer un shell privilégié et agir comme le système lui-même.

Il faut insister sur un point, ce n’est pas une faille « magique » qui traverse Internet. Pour en profiter, l’attaquant doit déjà exécuter du code sur la machine, même avec un compte non admin. Dans la vraie vie, ce prérequis est souvent rempli via un document piégé, un installateur trojanisé, une macro, un accès RDP volé, ou une autre vulnérabilité. BlueHammer devient alors l’étape suivante, celle qui casse le plafond de verre des permissions et ouvre l’accès total.

Le chercheur à l’origine de la publication a aussi signalé que la preuve de concept contient des bugs, ce qui peut la rendre peu fiable. D’autres tests ont confirmé des échecs sur Windows Server, ce qui suggère des variations selon les versions ou des protections spécifiques. Mais même une preuve de concept instable suffit souvent à lancer une course, des acteurs malveillants la reprennent, la stabilisent, puis l’intègrent dans des chaînes d’attaque. C’est la dynamique habituelle dès qu’un 0-day sort au grand jour.

Microsoft MSRC n’a pas publié de correctif au 6 avril 2026

Le calendrier est brutal, l’exploit a été rendu public alors que Microsoft n’a pas déployé de patch. Dans la terminologie de l’éditeur, on parle bien de zero-day, puisque l’attaque est possible sans mise à jour disponible. Le dossier illustre un point de friction récurrent entre chercheurs et éditeurs, le rythme de traitement, la communication, et la perception de la gravité. Quand la confiance casse, la tentation de « forcer la main » par une publication existe, même si c’est controversé.

À ce stade, Microsoft n’a pas fourni d’update spécifique pour BlueHammer dans les informations reprises publiquement. Le problème, c’est l’intervalle, les équipes sécurité doivent gérer une exposition sans correctif, avec des mesures de contournement et de réduction de surface d’attaque. Et dans les entreprises, la fenêtre d’opportunité ne se mesure pas en semaines abstraites, elle se mesure en heures, le temps que la preuve de concept se propage, puis se transforme en exploit opérationnel.

On a déjà vu ce film côté Windows, des vulnérabilités d’élévation de privilèges deviennent critiques quand elles sont chaînées avec une première compromission. Des analyses récentes sur des failles noyau montrent ce schéma, un acteur obtient un pied-à-terre, puis utilise une élévation de privilèges pour voler des identifiants, se déplacer latéralement et verrouiller le SI. Dans un cas documenté sur le pilote CLFS, l’exploitation a mené à des activités de ransomware via injection et vol d’identifiants, preuve que l’étape « post-compromission » est souvent l’étape décisive.

Il y a une nuance importante, publier un code imparfait ne veut pas dire « risque nul ». Au contraire, ça fournit un point de départ. Les groupes structurés savent corriger des bugs, adapter à des versions, et automatiser. Et même des acteurs moins avancés peuvent tenter des attaques opportunistes sur des parcs mal maîtrisés. Le résultat, c’est une pression accrue sur les équipes IT, qui doivent compenser l’absence de patch par de la surveillance, des restrictions, et une hygiène stricte des comptes locaux.

Accès à la SAM, le tremplin vers SYSTEM et la compromission complète

Le détail le plus parlant dans BlueHammer, c’est l’accès à la base SAM. Dans Windows, la SAM stocke des informations d’authentification locales, dont des hashes. Une fois ces hashes récupérés, un attaquant peut tenter des attaques hors ligne, réutiliser des secrets si des mots de passe faibles sont présents, ou s’en servir pour pivoter vers d’autres comptes locaux. Ce n’est pas automatiquement « tout le domaine », mais sur des postes et serveurs isolés, c’est souvent suffisant pour prendre la main.

Quand l’escalade va jusqu’à SYSTEM, les conséquences deviennent mécaniques. L’attaquant peut désactiver des protections, installer des services, modifier des clés de registre sensibles, ou injecter du code dans des processus privilégiés. Dans les campagnes observées sur d’autres zero-days Windows, l’étape suivante a souvent été la collecte d’identifiants en mémoire. Microsoft a décrit, dans un cas d’exploitation CLFS, l’injection dans winlogon. exe puis l’usage d’outils pour dumper LSASS et récupérer des identifiants, un enchaînement typique après élévation.

Ce qui change selon les environnements, c’est la facilité. Sur certaines plateformes, l’exploit BlueHammer semble élever un utilisateur non admin vers un administrateur « élevé », avec une étape d’autorisation temporaire. C’est un frein, mais pas une barrière absolue, parce que beaucoup d’attaques reposent sur l’ingénierie sociale, une fenêtre UAC, une demande d’autorisation, et la victime clique. Dans une entreprise, un poste où l’utilisateur a déjà des droits locaux élargis devient une cible plus simple.

Pour rendre ça concret, imagine un poste de comptabilité compromis via un fichier malveillant. Sans élévation, le malware reste coincé, il peut voler des fichiers de l’utilisateur, mais il a du mal à s’installer durablement et à attaquer les protections. Avec une élévation BlueHammer, il peut devenir SYSTEM, extraire des secrets locaux, et préparer un mouvement latéral. Ce n’est pas spectaculaire à l’écran, mais dans un SOC, c’est exactement le genre de bascule qui transforme un incident « poste isolé » en crise.

Windows Server et Windows 11 24H2, protections et limites selon les versions

Les premiers retours de tests indiquent que la preuve de concept ne réussit pas partout, notamment sur Windows Server. Certains chercheurs ont observé des échecs, cohérents avec l’idée que le code publié contient des bugs. C’est une bonne nouvelle relative, mais elle doit être lue avec prudence. Une preuve de concept, c’est rarement un produit fini. Si la faille est réelle, un exploit plus robuste peut apparaître, ciblant précisément les versions où la surface d’attaque est la plus favorable.

Les différences de comportement entre éditions Windows ne sont pas un détail. Microsoft a déjà montré, dans un autre dossier de zero-day, que certaines protections introduites dans Windows 11 version 24H2 bloquaient une chaîne d’exploitation, en restreignant l’accès à certaines informations système via des privilèges spécifiques. Ce genre de durcissement ne supprime pas toutes les failles, mais il complique la vie des attaquants, en particulier sur les étapes de fuite d’adresses ou de contournement de mitigations.

Dans BlueHammer, le fait que l’exploitation soit décrite comme « pas facile » est cohérent avec des bugs TOCTOU, le timing et les chemins peuvent varier selon les configurations, les politiques de sécurité, et les solutions EDR. Mais il ne faut pas se raconter d’histoires, les environnements d’entreprise sont hétérogènes, certains postes sont vieux, certains serveurs ont des configurations historiques, et des comptes locaux partagés existent encore. C’est souvent là que les attaques trouvent leur prise.

Un administrateur système interrogé, Marc, responsable IT dans une PME industrielle, résume la situation de manière sèche, « si tu me donnes un 0-day d’élévation, je pars du principe que quelqu’un va l’industrialiser, et je dois fermer les robinets autour, droits locaux, exécutions non signées, et surveillance des accès à la SAM ». Sa remarque pointe un angle mort fréquent, on attend le patch, mais entre-temps il faut réduire la capacité d’un compte standard à lancer du code et à toucher des zones sensibles.

Mesures immédiates, réduction de surface et leçons des zero-days SmartScreen

Sans patch, la réponse repose sur des mesures défensives. La première, c’est limiter les opportunités d’exécution initiale, parce que BlueHammer est une élévation locale. Durcir les droits locaux, réduire le nombre de comptes pouvant installer, surveiller les créations de processus inhabituelles, et appliquer le principe du moindre privilège, ça paraît basique, mais c’est ce qui casse les chaînes d’attaque. Dans les entreprises, la suppression des admins locaux permanents reste une action à fort impact.

Deuxième axe, la détection. Une élévation vers SYSTEM laisse des traces, accès à des hives sensibles, comportements anormaux autour de la SAM, tentatives de dump d’identifiants, et exécutions de processus privilégiés. Les équipes peuvent aussi surveiller les signes de post-exploitation, comme des injections dans des processus système. Microsoft a décrit, dans une exploitation CLFS, des injections et des opérations ciblant LSASS, ce qui offre des patterns de surveillance utiles, même si BlueHammer n’est pas le même bug.

Troisième axe, la discipline de patching dès qu’un correctif sort. L’histoire récente des zero-days Windows montre que même après la publication d’un patch, des attaques continuent, car des organisations tardent à déployer. Des rapports sur des vulnérabilités exploitées en 2025 notent que des attaques ont persisté après correction, en visant les retardataires. C’est un rappel peu confortable, le risque ne disparaît pas le jour du Patch Tuesday, il se déplace vers ceux qui patchent lentement.

Enfin, comparaison utile, les zero-days SmartScreen comme CVE-2023-36025 ont montré comment une faille de contournement peut être exploitée en campagne, avec des fichiers. URL menant à des conteneurs comme des VHD, et des charges utiles de type RAT. Là, on est sur un autre maillon, l’entrée initiale. BlueHammer, lui, ressemble au maillon « après l’entrée ». Les deux se complètent dangereusement, une chaîne réaliste, c’est un contournement côté utilisateur pour exécuter, puis une élévation pour prendre la main. Et c’est exactement pour ça que la publication d’un code d’exploit, même imparfait, met tout le monde sous tension.