600 dollars pour secouer le noyau Windows : on vit une drôle d’époque
Imaginez une scène simple : deux chercheurs, un budget équivalent à un dîner un peu chic, et un objectif qui ferait trembler n’importe quel admin système… trouver des failles dans les drivers Windows. Résultat : 521 vulnérabilités repérées, et plus de 100 exploitables pour faire de l’escalade de privilèges sur Windows 11. Le tout, grâce à une approche qui mélange automatisation, reverse engineering et agents IA basés sur des LLM.
Le message derrière ce chiffre n’est pas juste “oh non, encore des bugs”. C’est surtout : le coût d’entrée pour auditer (et potentiellement attaquer) le noyau Windows via ses drivers s’effondre. Et quand le coût s’effondre, devinez qui arrive en courant ? Les attaquants. Avec leurs baskets neuves.
Dans cet article, on va décortiquer ce qui s’est passé, pourquoi les drivers kernel Windows sont une mine d’or, comment les chercheurs ont industrialisé la découverte de failles, et surtout ce que ça implique côté défense. Parce que oui, à la fin, c’est vous, votre parc, et votre cloud qui prennent.
Drivers Windows : le “petit” détail qui parle au noyau
Sous Windows, les drivers sont ces composants qui permettent à l’OS de discuter avec du matériel et certains logiciels bas niveau. Sauf que… un driver en mode kernel, c’est littéralement une porte d’entrée vers le noyau. Et le noyau, c’est le quartier VIP : accès total, droits maximum, aucune barrière.
Le problème, c’est que l’écosystème de drivers est gigantesque, hétérogène, parfois ancien, parfois maintenu “quand on a le temps”, et souvent écrit en mode “ça marche donc on ship”. Et quand un driver expose une interface accessible à des utilisateurs non privilégiés, la moindre erreur peut devenir un tremplin.
C’est précisément ce que les chercheurs ont exploré : pas le noyau Windows “pur”, mais la galaxie de drivers tiers signés, distribués, installés partout, y compris sur des machines d’entreprise et des instances cloud.
La cible préférée : les IOCTL, la sonnette entre userland et kernel
Pour parler à un driver, Windows utilise des commandes appelées IOCTL (Input Output Control). En gros, un programme en espace utilisateur envoie un IOCTL, le driver le reçoit et exécute un handler (une fonction qui traite la requête).
Et c’est là que la magie noire commence :
- plus un handler IOCTL est complexe, plus il y a de chances qu’il contienne une erreur
- plus il manipule des buffers, des pointeurs, des tailles, plus on peut espérer une corruption mémoire
Les chercheurs ont donc construit un pipeline qui repère et priorise les drivers dont les handlers IOCTL ont une grosse surface d’attaque. Pas besoin de tout analyser au hasard : on commence par les endroits où les bugs aiment se cacher.
METHOD_NEITHER : le mode “sans ceinture de sécurité”
Un point clé dans leur tri : la recherche de drivers utilisant METHOD_NEITHER.
Pourquoi c’est important ? Parce que dans ce mode, le driver peut recevoir des pointeurs fournis par l’espace utilisateur sans que Windows fasse un filtrage protecteur équivalent à d’autres modes. En clair : c’est un transfert où l’application dit “tiens, voilà un pointeur”, et le driver répond “ok chef”.
Dans un monde parfait, le développeur du driver valide tout : tailles, adresses, droits d’accès, conditions de course, etc. Dans le monde réel, la validation ressemble parfois à un post-it “TODO: check later”.
Résultat : METHOD_NEITHER est souvent associé à des bugs de type :
- lecture arbitraire
- écriture arbitraire
- corruption mémoire (heap, stack, pool)
Et ces classes de bugs, en mode kernel, peuvent mener très vite à l’exécution de code et à la prise de contrôle du système.
Le pipeline en 5 étapes : de la collecte au tri, puis l’audit par agents IA
L’approche présentée repose sur une chaîne assez simple dans l’idée, mais redoutable dans l’exécution.
1) Collecte massive de drivers
Les chercheurs ont récupéré 1654 drivers uniques depuis le catalogue Microsoft Update et les sites constructeurs. Autrement dit : ils ont aspiré une portion significative de l’écosystème réel, celui qu’on retrouve dans la nature.
2) Prétraitement et classement par surface d’attaque
Ensuite, ils ont classé les drivers selon des heuristiques liées à leur exposition IOCTL et à la complexité des handlers. Objectif : investir du temps machine (et des tokens) là où le retour sur investissement en vulnérabilités est le plus élevé.
3) Un “conseil” de 3 agents LLM
C’est le cœur du sujet : ils ont mis en place trois agents IA, chacun avec un rôle distinct :
- Agent A : décompilation, renommage, reconstruction de logique
- Agent B : identification de la surface d’attaque et des chemins intéressants
- Agent C : audit des fonctions et recherche de corruptions mémoire
Le tout a été orchestré via OpenRouter, en mélangeant des modèles pour optimiser le ratio coût/efficacité.
4) Analyse à grande échelle
Sur 202 binaires analysés, ils ont sorti 521 vulnérabilités. Et ce n’est pas “juste” du bug de logique gentillet :
- environ 45% seraient des bugs de lecture/écriture mémoire arbitraire
- environ 70% classés High ou Critical
5) Tri manuel des faux positifs
Évidemment, l’IA n’est pas une baguette magique. Ils annoncent environ 60% de faux positifs, ce qui est à la fois beaucoup et… pas si surprenant. Mais même après validation manuelle, il reste 100+ failles exploitables pour l’escalade de privilèges.
Dit autrement : même en jetant plus de la moitié à la poubelle, le sac déborde encore.
Les constructeurs concernés : pas des figurants
Le plus inquiétant, c’est que les drivers touchés ne viennent pas d’éditeurs obscurs compilant dans un garage. On parle de noms très installés : AMD, Intel, NVIDIA, Dell, Lenovo, IBM, Fujitsu.
Ce détail compte pour une raison simple : ces drivers sont partout. Sur des postes de travail, des laptops d’entreprise, des serveurs, des environnements virtualisés… et souvent installés parce que Windows Update ou un outil constructeur les a poussés “gentiment”.
Le cas AMD Crash Defender : quand le cloud devient une extension du problème
Un exemple marquant : AMD Crash Defender (amdfendr.sys).
Dans le scénario décrit, le device serait accessible en écriture par n’importe quel utilisateur, exposerait des IOCTL sans validation stricte, et permettrait de la corruption heap. Avec les bonnes techniques (pool grooming), on peut aboutir à de l’exécution de code en mode kernel.
Là où ça pique vraiment : ce driver se retrouverait aussi sur des instances AWS EC2 Windows avec CPU AMD. Donc la surface d’attaque ne se limite pas à “mon PC perso”. Elle s’étend potentiellement à des environnements cloud où l’on croit souvent être plus “encadré”.
Moralité : si un driver vulnérable est présent sur un parc d’instances, la question devient :
- qui peut l’atteindre ?
- depuis quel niveau de privilèges ?
- avec quelle chaîne d’exploitation possible ?
Et si votre réponse est “on verra plus tard”, sachez que les attaquants, eux, ont déjà mis ça dans un tableur.
Le vrai scandale : des vulnérabilités signalées, presque aucun patch
On pourrait se dire : “ok, mais au moins, ça sera patché”. Eh bien… pas vraiment.
Sur 15 vulnérabilités critiques (CVSS supérieur à 7) rapportées à 8 vendeurs, un seul aurait patché : Fujitsu, via CVE-2025-65001.
Les autres auraient rejeté les rapports ou diminué la priorité, parfois malgré des preuves de concept montrant des effets sérieux comme un crash système déclenchable depuis un compte standard.
Et là, on arrive au point qui rend les défenseurs légèrement nerveux (et les attaquants très joyeux).
BYOVD : le comeback éternel des drivers vulnérables signés
Même quand un produit est en fin de vie, ses drivers restent souvent signés, et leurs certificats ne sont pas forcément révoqués. Conséquence : un attaquant peut mener une attaque BYOVD (Bring Your Own Vulnerable Driver).
Le principe est simple :
- l’attaquant obtient sur la machine la capacité de charger un driver (directement ou via une faille, un outil détourné, une configuration faible)
- il charge un driver vulnérable mais signé
- il exploite la faille du driver pour obtenir des primitives kernel (lecture/écriture)
- il escalade et prend la main au niveau noyau
Ce modèle est particulièrement gênant parce qu’il contourne une partie de la confiance accordée à la signature. Le driver est “légitime” aux yeux du système, mais il est vulnérable, et parfois non corrigé pour toujours.
C’est un peu comme si vous aviez une serrure certifiée… mais avec un double de la clé en libre service.
Pourquoi l’IA change la donne en cybersécurité
Cette affaire illustre un tournant : l’IA n’est plus seulement un outil pour résumer des rapports ou écrire des scripts. Ici, elle sert à :
- décompiler à grande échelle
- renommer et reconstruire une logique de code
- prioriser la surface d’attaque
- proposer des hypothèses de bugs mémoire
Même avec des faux positifs, l’effet industriel est énorme : on passe d’un audit artisanal à une recherche semi-automatisée, où l’humain devient le validateur final.
Et le détail qui fait réfléchir : le coût annoncé est de l’ordre de 3 dollars par cible, pour un total de 600 dollars. Ce n’est pas un budget “nation-state”, c’est un budget “side project”.
Comment savoir si vous êtes concernés : vérifier les hashes des drivers
Les chercheurs ont publié une liste de 234 hashes (double SHA256) pour permettre aux équipes sécurité de vérifier la présence de drivers concernés.
L’idée : vous calculez le hash de vos drivers, puis vous comparez avec la liste. Exemple de commande partagée :
sha256sum driver.sys | awk '{print $1}' | tr -d '\n' | sha256sum
Si vous gérez un parc, ce type de vérification peut être automatisé via un inventaire logiciel, un EDR, ou une collecte centralisée.
Ce que les équipes sécu devraient faire dès maintenant
Sans tomber dans la panique (gardez-la pour la prochaine réunion budget), voici des actions pragmatiques.
Cartographier les drivers kernel présents
- inventorier les drivers installés
- identifier ceux exposant des interfaces accessibles aux utilisateurs
- repérer ceux liés à du matériel répandu (GPU, chipset, outils OEM)
Réduire la capacité à charger des drivers
- vérifier les stratégies de sécurité Windows liées au chargement de drivers
- limiter l’installation de composants OEM inutiles
- surveiller les tentatives de chargement de drivers non attendus
Mettre en place des listes de blocage
Quand des drivers vulnérables signés circulent, l’approche défensive passe souvent par des mécanismes de blocage (selon ce qui est disponible dans votre environnement).
Accélérer le patch management côté constructeurs
Oui, c’est facile à dire. Mais la leçon ici, c’est que les drivers sont un angle mort classique : on patch l’OS, on patch les apps, et on oublie le reste. Or, “le reste” parle au noyau.
Tester vos environnements cloud Windows
Si vous avez des workloads Windows dans le cloud, intégrez la couche driver dans vos contrôles :
- images de base
- mises à jour OEM
- composants liés au type d’instance
Parce que la surprise du jour, c’est que le cloud n’est pas une bulle magique. C’est juste votre infrastructure… avec plus de facturation.
Ce qu’il faut retenir (et raconter à votre future IA de garde)
- Des agents IA peuvent accélérer la découverte de vulnérabilités dans les drivers Windows à un coût très faible.
- Les IOCTL et surtout METHOD_NEITHER restent des points chauds classiques pour les bugs kernel.
- Les impacts dépassent largement le PC local : certains drivers se retrouvent en environnement cloud.
- Le vrai problème n’est pas seulement la découverte des failles, c’est le manque de patch et la persistance des drivers signés vulnérables, qui alimentent BYOVD.
La prochaine étape logique, c’est que ces pipelines deviennent plus accessibles, mieux outillés, et utilisés à la fois par les défenseurs et… par ceux qui n’ont pas prévu d’envoyer un rapport responsable.
Autrement dit : si votre stratégie sécurité s’arrête à “on patch Windows tous les mardis”, il est peut-être temps d’ajouter une ligne “et les drivers, on en parle ou on fait semblant ?”.