Les logiciels anti-cheat au niveau noyau sont devenus l'une des plus grandes failles de sécurité du jeu PC

Les logiciels anti-cheat au niveau noyau s’exécutent aujourd’hui avec les mêmes privilèges que votre moteur antivirus sur des dizaines de millions de PC, et cet accès est devenu l’une des surfaces les plus exploitables de l’informatique grand public. Vanguard de Riot Games, Easy Anti-Cheat (EAC), BattlEye et Denuvo Anti-Cheat chargent tous un pilote signé dans l’anneau 0 du noyau Windows — le même niveau de privilège que le système d’exploitation lui-même — pour détecter les triches par manipulation de mémoire invisibles aux outils en mode utilisateur. Le problème, c’est qu’un pilote suffisamment fiable pour inspecter tous les processus en mémoire l’est aussi suffisamment pour désactiver les outils de sécurité, et des attaquants exploitent discrètement cette confiance depuis au moins 2022.

Ce n’est pas une hypothèse. Les chercheurs en sécurité et la Vulnerable Driver Blocklist (VBL) de Microsoft ont signalé à plusieurs reprises des pilotes anti-cheat et de jeu signés comme vecteur « bring your own vulnerable driver » (BYOVD) — les attaquants chargent un pilote légitimement signé mais vulnérable, puis utilisent l’accès noyau qu’il confère pour tuer les processus EDR avant de déployer un rançongiciel. Ce schéma est apparu dans des incidents liés à BlackByte et à d’autres groupes de rançongiciels, qui privilégient les pilotes vulnérables précisément parce qu’ils portent une signature Microsoft valide et passent les contrôles de signature de code qui bloqueraient d’emblée un module noyau non signé.

Comment un pilote de confiance devient une arme

Le mécanisme sous-jacent est simple. Windows exige que les pilotes en mode noyau soient signés, soit directement par Microsoft, soit via le programme WHQL (Windows Hardware Quality Labs), pour empêcher l’exécution de code arbitraire au niveau de privilège le plus élevé. Les éditeurs d’anti-cheat ont besoin de ce niveau d’accès pour lire la mémoire des processus adverses, intercepter les appels système et détecter les débogueurs — autant de choses qu’un processus de triche en mode utilisateur dissimulerait sinon. L’éditeur obtient donc un pilote légitimement signé installé sur chaque machine qui exécute le jeu.

Si ce pilote comporte un bug — un gestionnaire IOCTL exposé qui permet à n’importe quel processus de la machine de lui envoyer des commandes, par exemple — un attaquant n’a même pas besoin de son propre pilote malveillant. Il charge le pilote anti-cheat déjà signé et déjà approuvé, dialogue avec son interface exposée, et utilise ses privilèges noyau pour terminer des processus protégés, y compris les agents EDR de CrowdStrike, SentinelOne ou Microsoft Defender for Endpoint. C’est exactement ce qui s’est produit avec le pilote mhyprot2.sys de miHoYo, initialement livré avec le système anti-cheat de Genshin Impact : il exposait des fonctions permettant à n’importe quel processus local de terminer arbitrairement d’autres processus, et des opérateurs de rançongiciels l’ont adopté précisément parce qu’il s’agissait d’un binaire signé et propre, sans signature de malware évidente.

Le problème d’échelle

Le pilote anti-cheat de Capcom présentait une faille similaire de terminaison arbitraire de processus, révélée en 2020. Le pilote de Genshin Impact restait installé et actif sur certains systèmes même après la désinstallation du jeu lui-même, car la routine d’installation ne fournissait jamais de désinstalleur pour le composant noyau — un détail qui n’a attiré l’attention qu’après que des chercheurs en sécurité ont commencé à cartographier les pilotes que les groupes de rançongiciels répertoriaient pour réutilisation, dans ce qu’on appelle les « LOLDrivers » (living-off-the-land drivers). La VBL de Microsoft, diffusée via Windows Update et App Control for Business, bloque désormais par hachage des dizaines de versions spécifiques de pilotes anti-cheat et d’utilitaires de jeu, mais cette liste reste réactive : un pilote doit être pris en flagrant délit d’abus avant d’y être ajouté, et de nouvelles versions de pilotes anti-cheat sortent en permanence au fur et à mesure que les éditeurs corrigent les contournements.

L’ampleur compte ici plus que n’importe quel incident isolé. Valorant compte à lui seul plus de 20 millions de joueurs actifs mensuels, et Vanguard s’installe au démarrage, avant même le chargement de l’interface du système, précisément pour que les outils de triche ne puissent pas le désactiver en cours de partie. EAC et BattlEye couvrent ensemble des centaines de titres compétitifs. Il s’agit donc d’un binaire à privilèges noyau, contrôlé par un éditeur tiers plutôt que par le fabricant du système d’exploitation, installé sur une base immense — et contrairement à un éditeur d’antivirus, la plupart des éditeurs d’anti-cheat n’ont jamais subi le type d’audit de sécurité contradictoire que les produits EDR affrontent régulièrement, car leur modèle de menace a été conçu pour attraper les tricheurs, pas pour résister à une recherche d’exploitation de pilotes digne d’un État-nation.

Pourquoi ça se reproduit sans cesse

Les éditeurs d’anti-cheat font face à un problème d’incitation structurel : chaque nouvelle capacité noyau ajoutée pour détecter une triche plus sophistiquée est aussi une nouvelle capacité qu’un attaquant peut exploiter, mais l’indicateur de performance de l’éditeur reste le taux de détection des tricheurs, pas la réduction de la surface d’attaque. Reconcevoir ces systèmes pour qu’ils fonctionnent en mode utilisateur avec des capacités plus restreintes — la direction que Valve a prise avec la conception largement en mode utilisateur de VAC pour Steam, acceptant un plafond de détection plus bas en échange d’une empreinte noyau nettement réduite — est un compromis réel que la plupart des éditeurs ont refusé d’adopter, car les plaintes sur l’intégrité compétitive font bouger les notes et le nombre de joueurs plus vite qu’une CVE théorique sur un pilote.

Microsoft pousse aussi les éditeurs vers ses frameworks Kernel-Mode Hardware-Enforced Stack Protection et HVCI (Hypervisor-Protected Code Integrity), qui limitent ce qu’un pilote noyau peut faire même avec une signature de code valide, mais l’adoption reste facultative et lente car elle peut casser la logique de détection de l’anti-cheat, qui dépend d’une large visibilité sur la mémoire. Tant que le confinement de type HVCI ne deviendra pas obligatoire plutôt qu’optionnel, le modèle de confiance basé sur les pilotes signés qui fait fonctionner l’anti-cheat restera celui qui en fait une cible durable pour le BYOVD.

Que faire concrètement

Pour les administrateurs informatiques gérant des parcs de machines exécutant des jeux compétitifs — courant dans les cybercafés, les organisations esport, et même certains postes d’entreprise où les employés disposent de droits administrateur locaux — la mesure pratique consiste à garder la VBL de Microsoft activée et à jour plutôt que de la désactiver pour des raisons de compatibilité, car cette liste de blocage est le principal mécanisme retirant activement les pilotes de jeu connus pour être exploitables. Les déploiements EDR en entreprise devraient spécifiquement surveiller les événements de chargement de pilotes anti-cheat hors des processus de jeu attendus ; un pilote Vanguard ou EAC qui se charge sur un serveur ou un poste sans jeu correspondant installé est en soi un signal fort qui mérite d’être investigué.

Pour les joueurs, la conclusion pratique est plus étroite : désinstaller un jeu compétitif ne retire pas toujours son pilote noyau, donc vérifier la liste des pilotes installés sous Windows (via la commande driverquery dans un terminal élevé) après avoir désinstallé des titres protégés par anti-cheat vaut bien les trente secondes que cela prend. Pour les éditeurs qui réfléchissent encore à la prochaine génération d’anti-cheat, le compromis VAC de Valve est celui qui mérite d’être étudié sérieusement : un système de détection avec un plafond plus bas, mais une empreinte noyau suffisamment réduite pour cesser d’être le pilote signé préféré d’un groupe de rançongiciels.