Quand le navigateur devient l’agent : la face offensive des extensions Chromium

Votre EDR surveille les processus, la mémoire, les injections. Mais que surveille-t-il dans le navigateur : ce processus légitime, signé par Google ou Microsoft, ouvert en permanence, et qui contient vos sessions, vos jetons et vos mots de passe ? Lors de BarbHack 2026, un chercheur a montré comment une simple extension Chromium devient un agent de commande et contrôle (C2) complet, à l’angle mort de la plupart des défenses.

Nous y étions. Voici l’essentiel, et surtout ce que nous en tirons pour vous, côté défense. Précision utile : cet article décrit une menace et ses implications, pas un mode d’emploi.

Pourquoi le navigateur est une cible en or

L’idée de départ est limpide. Les agents système classiques sont très surveillés par les EDR. Le navigateur, lui, est un angle mort commode :

• c’est un processus légitime et signé, ce qui réduit fortement les alertes comportementales ;
• il est partout en entreprise (Edge par défaut sur Windows, Chrome, Vivaldi…) ;
• il concentre une mine d’or : identifiants, sessions actives, jetons d’authentification ;
• une extension s’exécute dans le bac à sable du navigateur, sans injection mémoire classique, et y persiste naturellement tant que l’utilisateur ne la supprime pas, sur Windows, macOS comme Linux.

De l’extension à l’agent C2

Techniquement, une extension Chromium tient en trois briques : un manifest qui déclare ses permissions, des content scripts qui lisent et modifient les pages web, et un Service Worker en arrière-plan qui a accès aux API du navigateur et peut dialoguer avec un serveur distant. C’est là que loge la charge utile.

Avec les bonnes permissions, les capacités démontrées donnent le vertige : interception du trafic et des sessions, enregistrement de frappe dans les formulaires, lecture du presse-papiers (y compris ce qui sort d’un gestionnaire de mots de passe par copier-coller), récupération des téléchargements, proxy et redirections, clonage de session pour naviguer « comme la victime ».

Plus loin encore, l’API Native Messaging permet à l’extension de parler à un binaire local et de déclencher de l’exécution de code. Effet pervers pour le défenseur : l’arbre des processus montre le navigateur comme parent du shell, ce qui masque la signature réseau d’un agent système traditionnel. Une fausse notification « mise à jour critique » suffit à faire cliquer l’utilisateur et à lancer le tout.

Contourner les garde-fous d’entreprise

En théorie, une politique de groupe (GPO) bien réglée bloque ce scénario : elle désactive le chargement d’extensions « décompressées » et impose une liste blanche d’identifiants autorisés. En théorie.

La présentation a montré deux contournements conceptuels qui font tomber cette barrière. D’une part, la manipulation du fichier d’état local du navigateur (le Secure Preferences), protégé par des sommes d’intégrité, pour y faire accepter une extension comme si elle était légitime. D’autre part, l’usurpation d’identifiant : comme l’ID d’une extension dérive de sa clé publique, réutiliser la clé publique d’une extension légitime du store produit le même identifiant, donc un ID déjà présent sur la liste blanche. L’extension malveillante devient active malgré la GPO. Des outils publics (présentés sous les noms Stomp et Beloader) automatisent cette injection.

La leçon n’est pas « la GPO ne sert à rien ». C’est que l’allowlisting d’extensions n’est pas une frontière étanche, et qu’il faut le compléter par de la surveillance.

La persistance qui refuse de mourir

Le clou du spectacle est une technique de persistance furtive. Le Service Worker d’une extension est compilé puis conservé en cache. En jouant sur ce cache, on peut faire tourner l’agent malveillant derrière une extension d’apparence inoffensive : ce que l’utilisateur voit est anodin, mais le code actif en arrière-plan reste celui de l’attaquant.

Résultat : la persistance survit au redémarrage du navigateur, au redémarrage de la machine et même aux mises à jour du navigateur, avec peu de traces sur le disque et sans alerte EDR notable.

Le plus instructif est la réponse des éditeurs. Signalé à Chromium et à Microsoft, le comportement a été qualifié d’« attendu » (expected behavior), donc non corrigé. Autrement dit : n’attendez pas de correctif. C’est un risque à gérer par l’exploitation et la surveillance, pas par un patch.

Ce que ça change pour votre défense

Au-delà de la prouesse offensive, ce talk est un excellent rappel pour toute organisation, PME comprise :

• Le navigateur fait partie de votre surface d’attaque. Une extension est du code exécutable : traitez-la comme tel dans votre inventaire et votre analyse de risque.
• L’EDR ne suffit pas ici. Processus légitime, bac à sable, cache : plusieurs signaux classiques sont absents. La défense se joue aussi côté gouvernance du navigateur.
• Durcissez, puis surveillez. Une liste blanche d’extensions par politique reste indispensable, mais surveillez ce qui la contourne : modifications inattendues de l’état local du navigateur, hôtes Native Messaging nouvellement déclarés, et processus enfants lancés par le navigateur.
• Formez à la bonne alerte. La fausse notification « mise à jour critique » est un vecteur d’ingénierie sociale simple et efficace. Vos équipes doivent savoir la reconnaître.
• Faites-vous attaquer d’abord. Ces angles morts se découvrent avec un regard offensif. C’est précisément le rôle d’un test d’intrusion ou d’un exercice Red Team : trouver la faille de posture avant l’adversaire.

Note. Compte-rendu, à visée de sensibilisation défensive, d’une conférence de BarbHack 2026 consacrée à l’usage offensif des extensions de navigateur Chromium. Nous décrivons la menace et ses contre-mesures, pas de procédure d’attaque. Deuxième volet de notre couverture de l’événement. Une extension douteuse dans votre parc, ou l’envie de tester votre exposition ? Parlons-en.