Chrome Application-Bound Encryption neutralisée sans droits admin ni injection de code
Pour comprendre la portée de VoidStealer, il faut remonter à juillet 2024. Google déployait alors Chrome 127 avec l'Application-Bound Encryption (ABE), une protection conçue pour résoudre un problème chronique : les infostealers pouvaient accéder aux cookies, mots de passe et tokens de session de Chrome en tournant simplement au niveau de l'utilisateur connecté.
L'ABE a changé la règle du jeu. Elle chiffre la clé maître de Chrome — la v20_master_key — et la lie à un service Windows tournant au niveau SYSTEM : le Google Chrome Elevation Service. Pour déchiffrer les données du navigateur, un processus doit désormais passer par ce service, lequel vérifie que le demandeur est bien Chrome et non un malware. Google avait explicitement anticipé que les infostealers tenteraient de contourner ABE — mais assumait que les contournements seraient plus "bruyants" et donc plus détectables. Cette hypothèse stratégique vient d'être invalidée.
Depuis le déploiement d'ABE, diverses techniques de contournement ont émergé, presque toutes nécessitant des privilèges administrateur. VoidStealer est la première à opérer en conditions silencieuses, sans escalade de privilèges ni injection de code.
ANALYSE
La mécanique de l'attaque : attendre que la porte s'ouvre
Le génie opérationnel de VoidStealer v2.0 repose sur une observation simple mais redoutable : Chrome doit lui-même déchiffrer la v20_master_key au démarrage pour fonctionner. Pendant une fraction de seconde, cette clé existe en clair dans la mémoire du processus. C'est dans cet intervalle que VoidStealer frappe.
La séquence d'attaque commence par VoidStealer qui lance un nouveau processus navigateur en état suspendu tout en cachant la fenêtre de l'application à l'utilisateur. Le malware reprend immédiatement le thread et attache un débogueur pour surveiller le processus nouvellement créé. Comme les navigateurs chargent les cookies en mémoire au démarrage, le lancement initial fournit l'opportunité parfaite pour intercepter la clé.
Techniquement, VoidStealer commence par lancer un processus navigateur avec les flags CreateProcessW SW_HIDE et CREATE_SUSPENDED, puis reprend immédiatement et attache un débogueur via DebugActiveProcess. Il écoute ensuite les événements de débogage via WaitForDebugEvent, surveillant chaque DLL qui se charge dans l'espace mémoire du navigateur.
La précision chirurgicale de l'attaque réside dans l'usage des hardware breakpoints — des points d'arrêt utilisant les registres CPU (DR0–DR3) plutôt que de modifier le code en mémoire. VoidStealer utilise des hardware breakpoints parce qu'ils ne modifient pas le code. Contrairement aux software breakpoints, qui peuvent être détectés, les hardware breakpoints s'appuient sur des registres CPU, laissant la mémoire intacte et sans altérer l'exécution naturelle de Chrome.
Quand le breakpoint se déclenche, le registre R15 pour Chrome ou R14 pour Edge contient un pointeur direct vers la v20_master_key, que VoidStealer extrait avec seulement deux appels ReadProcessMemory. Deux lignes de code. La clé de chiffrement de l'ensemble des données sauvegardées dans Chrome est compromise.
Une fois la v20_master_key obtenue, le malware peut déchiffrer hors ligne la totalité des cookies, mots de passe, tokens d'authentification et données de remplissage automatique stockés dans les bases SQLite de Chrome — y compris les jetons de session permettant de prendre le contrôle de comptes sans connaître les identifiants.
Un MaaS en développement actif : 12 versions en 3 mois
Ce qui aggrave la menace est la vélocité de développement. Depuis sa première apparition en décembre 2025, le malware a rapidement évolué à travers des versions successives, suggérant une maintenance active et une demande probable sur les marchés underground. Le malware, qui fonctionne sur un modèle MaaS, a subi un total de 12 itérations, avec la dernière version "v2.1" déployée le 18 mars 2026.
Autrement dit : entre le 12 décembre 2025 et le 18 mars 2026 — soit exactement 97 jours — VoidStealer est passé de sa version initiale à v2.1, avec 12 itérations majeures dont une refonte architecturale complète de sa méthode de contournement ABE. Ce rythme est celui d'une startup logicielle en croissance accélérée, pas d'un groupe criminel artisanal.
Le modèle économique MaaS signifie que des acteurs peu qualifiés techniquement peuvent louer l'outil clé en main. Cette démocratisation a accéléré la propagation des capacités malveillantes sophistiquées parmi des acteurs moins compétents techniquement. La technique de debugging ABE, qui aurait requis des compétences avancées en reverse engineering il y a deux ans, est désormais accessible à un affilié MaaS en quelques clics.
La source académique : ElevationKatz sur GitHub
Un point mérite attention critique. VoidStealer n'a probablement pas inventé cette technique, mais l'a adaptée d'un projet open source appelé ElevationKatz, faisant partie de l'outillage ChromeKatz de dump de cookies démontrant les faiblesses de Chrome. Cette recherche académique démontrant les faiblesses de Chrome était disponible depuis plus d'un an.
C'est le dilemme classique de la recherche en sécurité offensive : publier les vulnérabilités pour forcer les corrections, ou garder les travaux confidentiels pour éviter l'armement par des acteurs malveillants. Dans le cas de ChromeKatz/ElevationKatz, la publication a précédé l'exploitation d'environ 12 à 18 mois — un délai relativement court pour une technique aussi avancée. Les équipes de recherche en sécurité qui publient des outils de démonstration sur GitHub doivent désormais intégrer ce paramètre : leurs travaux peuvent devenir des armes MaaS en moins de deux ans.
Ciblage : Chrome et Edge, les deux navigateurs dominants du monde enterprise
La portée de la menace est amplifiée par sa cible. VoidStealer cible actuellement Google Chrome et Microsoft Edge. Ces deux navigateurs représentent ensemble plus de 75% des parts de marché mondiales de navigation desktop, et pratiquement 100% du parc enterprise Windows. Chrome domine avec environ 65% de parts de marché mondiales. Edge, déployé nativement dans toutes les installations Windows 10 et 11 enterprise, complète le tableau. Un infostealer capable de contourner ABE sur ces deux navigateurs sans droits admin ni injection de code a techniquement accès aux credentials de la majorité des endpoints enterprise Windows dans le monde.
Ce que les défenseurs peuvent détecter — et ce qu'ils ne peuvent pas
Parce que VoidStealer évite l'injection et l'escalade de privilèges, les indicateurs traditionnels pourraient ne pas suffire. Le chercheur a indiqué que les défenseurs doivent se concentrer sur les signaux comportementaux, notamment les attachements inattendus de débogueur aux processus navigateur, l'utilisation inhabituelle d'APIs de lecture mémoire, et les patterns anormaux de spawn de processus Chrome.
Les indicateurs de compromission disponibles sont les suivants : processus navigateur lancé avec les flags SW_HIDE ou CREATE_SUSPENDED par un processus parent inconnu, appels DebugActiveProcess ciblant chrome.exe ou msedge.dll, et lectures mémoire croisées entre processus (ReadProcessMemory) depuis un processus non-signé Microsoft/Google. L'IoC de hash publié pour VoidStealer v2.0 est : f783fde5cf7930e4b3054393efadd3675b505cbef8e9d7ae58aa35b435adeea4.
Ce qui ne peut pas être détecté avec les outils classiques : l'attachement débogueur lui-même, quand il provient d'un processus signé ou d'un binaire légitime compromis par supply chain, et l'exfiltration des données déchiffrées si le canal de communication est chiffré et mimique du trafic HTTPS légitime.
IMPLICATIONS
Pour les équipes sécurité / CISOs
La menace est immédiate et concrète. VoidStealer v2.1 est actif sur les marchés MaaS depuis le 18 mars 2026 — soit moins d'une semaine. N'importe quel affilié cybercriminel peut acheter l'accès à l'outil aujourd'hui. Les endpoints Windows avec Chrome ou Edge déployés sans règles EDR comportementales spécifiques sont exposés. La priorité est d'ajouter des règles de détection sur DebugActiveProcess ciblant les navigateurs, les processus navigateur cachés (SW_HIDE), et les lectures mémoire cross-process sur chrome.exe/msedge.exe.
Pour les DSI
L'implication opérationnelle la plus urgente concerne les credentials enterprise stockés dans Chrome. Si vos équipes sauvegardent des mots de passe d'applications métier, tokens SSO, ou cookies de session SaaS dans le navigateur, ils sont exposés à cette technique — sans que l'utilisateur ait besoin de droits admin, sans que le malware ait besoin d'élever ses privilèges. La migration vers des gestionnaires de mots de passe dédiés (1Password, Bitwarden Enterprise, CyberArk) qui n'utilisent pas le keystore du navigateur est la seule protection structurelle contre ce vecteur.
Pour Google
La question posée est celle de la responsabilité de la défense. Google avait explicitement assumé que ABE pousserait les attaquants vers des comportements "plus bruyants" — et présenté cela comme un succès partiel acceptable. VoidStealer invalide cette hypothèse. La technique des hardware breakpoints est fondamentalement difficile à bloquer au niveau du navigateur sans casser des fonctionnalités légitimes (les outils de développement Chrome utilisent eux-mêmes des mécanismes similaires). La réponse de Google n'était pas disponible au moment de la publication des analyses — ce silence est en lui-même un signal.
CONCLUSION
VoidStealer v2.0 marque un point d'inflexion dans la guerre entre Google et les infostealers. L'Application-Bound Encryption a fonctionné comme prévu — elle a rendu les contournements plus difficiles et plus détectables pendant environ 18 mois. Mais la fenêtre de protection s'est refermée. VoidStealer est le premier infostealer observé dans la nature à employer une technique de contournement ABE basée sur un débogueur directement adaptée du projet public ElevationKatz, soulignant le paysage en constante évolution des bypasses ABE. Étant donné ces avantages combinés à la disponibilité d'un PoC public, il est prévisible que davantage d'infostealers adopteront cette technique dans un avenir proche.
Ce dernier point est le plus préoccupant. VoidStealer a été le premier, mais la technique est maintenant documentée, son code source partiellement disponible via ElevationKatz, et ses 12 itérations en 97 jours prouvent que l'écosystème MaaS peut industrialiser une nouveauté technique en quelques semaines. D'ici 30 à 60 jours, cette méthode sera probablement intégrée dans Lumma, Stealc, Vidar et les autres familles majeures d'infostealers.
La réponse de Google sera déterminante. Soit Chrome introduit une protection de processus qui empêche l'attachement de débogueur non autorisé (ce qui impacte les outils de développement légitimes et est techniquement complexe), soit ABE v2 repense fondamentalement où et comment la clé maître transite en mémoire. Dans les deux cas, le délai de réponse donnera aux acteurs MaaS une fenêtre supplémentaire d'exploitation à grande échelle.
TL;DR
VoidStealer a trouvé la faille qu'ABE ne peut pas colmater : Chrome doit ouvrir sa propre serrure pour fonctionner — et c'est à ce moment précis que le malware frappe.
- VoidStealer v2.0, déployé le 13 mars 2026 et déjà à sa 12ème version en moins de 100 jours, est le premier infostealer observé dans la nature à contourner l'Application-Bound Encryption de Chrome sans droits admin ni injection de code, en attachant un débogueur au navigateur et en posant un hardware breakpoint au moment précis où la v20_master_key apparaît brièvement en clair en mémoire — permettant de déchiffrer l'intégralité des mots de passe, cookies et tokens de session stockés dans Chrome et Edge.
- La technique est adaptée d'un projet open source académique (ElevationKatz/ChromeKatz) disponible depuis plus d'un an sur GitHub, démontrant que le délai entre publication d'une vulnérabilité de recherche et son armement dans un MaaS actif se mesure désormais en mois, pas en années.
- L'impact enterprise est immédiat : tout endpoint Windows exécutant Chrome ou Edge sans règles EDR comportementales spécifiques (détection DebugActiveProcess sur navigateurs, processus navigateur cachés, ReadProcessMemory cross-process) est exposé — et la seule protection structurelle est la migration des credentials critiques vers des gestionnaires de mots de passe dédiés hors du keystore navigateur.
Questions fréquentes
Qu'est-ce que l'Application-Bound Encryption (ABE) de Chrome et pourquoi cette protection était-elle considérée comme solide jusqu'ici ?
L'ABE, introduite dans Chrome 127 en juillet 2024, chiffre la clé maître de Chrome (v20_master_key) en la liant à un service Windows tournant avec les privilèges SYSTEM les plus élevés — le Google Chrome Elevation Service. Avant ABE, n'importe quel processus tournant au niveau de l'utilisateur connecté pouvait accéder aux données du navigateur. ABE a rendu cela impossible en théorie : seul Chrome pouvait demander la déchiffrement, via ce service vérifiant l'identité du processus demandeur. La protection était considérée comme solide parce qu'elle obligeait les contournements à être "bruyants" — nécessitant soit des privilèges SYSTEM, soit une injection de code dans Chrome, deux comportements facilement détectables par les EDR modernes. VoidStealer invalide cette hypothèse en opérant sans l'un ni l'autre.
Comment une entreprise peut-elle détecter une infection VoidStealer sur son parc d'endpoints ?
Trois signaux comportementaux sont les plus fiables selon les chercheurs de Gen Digital. Premièrement, surveiller tout processus qui appelle DebugActiveProcess (ou NtDebugActiveProcess) ciblant chrome.exe ou msedge.exe — les applications légitimes ne font pas cela en production. Deuxièmement, alerter sur les processus Chrome ou Edge lancés avec les flags SW_HIDE (fenêtre cachée) ou CREATE_SUSPENDED par un processus parent inconnu ou non-signé. Troisièmement, détecter les lectures mémoire cross-process (ReadProcessMemory) ciblant les processus navigateur depuis des binaires tiers non-signés Microsoft ou Google. L'IoC de hash pour VoidStealer v2.0 est f783fde5cf7930e4b3054393efadd3675b505cbef8e9d7ae58aa35b435adeea4. Les équipes SOC doivent intégrer ces règles dans leur SIEM/EDR en priorité.
La migration vers un gestionnaire de mots de passe externe protège-t-elle réellement contre VoidStealer ?
Oui, si la migration est complète. VoidStealer cible spécifiquement le keystore de Chrome — les données stockées dans les bases SQLite du profil navigateur (Login Data, Cookies, Web Data). Un gestionnaire de mots de passe dédié comme 1Password, Bitwarden Enterprise ou CyberArk stocke les credentials dans son propre vault chiffré, indépendant du navigateur, avec une clé maître distincte protégée différemment. VoidStealer ne peut pas accéder à ce vault via la technique ABE. En revanche, si le gestionnaire de mots de passe dispose d'une extension navigateur qui auto-remplit les formulaires, un malware plus avancé pourrait tenter d'intercepter les données au moment du remplissage. La protection absolue n'existe pas — mais la migration hors du keystore Chrome réduit drastiquement la surface d'attaque pour cette famille de menaces.