Des extensions de navigateur malveillantes volent les cookies de session : guide de détection

Les équipes de sécurité assistent une fois de plus à la répétition d'un schéma bien connu dans l'écosystème des boutiques d'extensions : des extensions qui faisaient jusque-là quelque chose d'ennuyeux et d'utile — capture d'écran, gestion d'onglets, recherche de codes promo, conversion PDF — changent de mains, reçoivent une mise à jour automatique silencieuse et se mettent à collecter discrètement les cookies de session et les jetons OAuth de tous les sites où l'utilisateur est connecté. Il ne s'agit pas d'un incident isolé. C'est une tendance récurrente de 2026, et elle continue de fonctionner précisément parce qu'elle ne ressemble pas à du malware aux yeux des outils conçus pour attraper les malwares.

Le mécanisme est simple, et c'est ce qui le rend durable. Un développeur d'extension revend une fiche populaire, ou un attaquant compromet un compte développeur, ou un mainteneur rebrande discrètement sous une nouvelle propriété. Rien ne change pour l'utilisateur côté installation : même icône, même demande de permissions qu'il a déjà acceptée des mois plus tôt. Puis une mise à jour automatique livre du nouveau code. L'extension dispose déjà de permissions d'hôte étendues héritées de son usage légitime d'origine : elle n'a donc besoin de rien demander de nouveau. Elle commence simplement à lire document.cookie, à intercepter les appels à l'API chrome.cookies ou à extraire des jetons du stockage local et de sessionStorage, puis à envoyer ces données vers un endpoint distant à intervalles réguliers.

Pourquoi cela passe sous les radars de la détection traditionnelle

Si cette technique fonctionne toujours, la raison est architecturale et ne tient pas à la défaillance du produit d'un éditeur en particulier :

• Le code s'exécute dans chrome.exe ou msedge.exe — un processus que tout agent EDR approuve déjà et inspecte rarement au niveau JavaScript.
• Aucun nouveau fichier n'est déposé sur le disque, aucune filiation de processus inhabituelle n'apparaît, et aucun binaire non signé n'est à signaler.
• L'extension a été revue et approuvée par la boutique lors de sa soumission initiale ; les mises à jour automatiques ultérieures font généralement l'objet d'un contrôle nettement plus léger.
• Les requêtes réseau se fondent dans le trafic ordinaire du navigateur — du HTTPS vers un domaine qui ressemble à n'importe quel endpoint d'analytics ou de CDN.
• Les jetons de session et les cookies sont, par conception, destinés à quitter le navigateur pour rejoindre des services first-party et third-party légitimes : le trafic d'exfiltration ne paraît donc pas anormal au premier regard.

Il en résulte un angle mort de détection situé exactement entre le processus de revue de la boutique de l'éditeur de navigateur et la pile de sécurité des terminaux — deux systèmes qui présument chacun que l'autre surveille cette couche.

Détecter les extensions malveillantes par le hash, pas à l'intuition

Parce que l'artefact, c'est l'extension elle-même et pas seulement son trafic réseau, l'angle de détection le plus fiable consiste à traiter le paquet de l'extension comme n'importe quel autre binaire suspect : calculer son hash et vérifier sa réputation.

• Récupérez le paquet .crx installé (ou le répertoire de l'extension décompressée) et calculez le hash du paquet ainsi que du manifest.json et des éventuels scripts background.js / service workers embarqués.
• Passez ces hashes dans des recherches de réputation de hash de fichier pour vérifier les correspondances avec des échantillons connus comme malveillants, et pas seulement avec la version d'origine saine de l'extension.
• Suivez la dérive des hashes d'une version à l'autre pour les extensions auxquelles votre organisation fait déjà confiance : un changement de hash seul ne prouve pas la compromission, mais un changement de hash associé à de nouveaux hôtes distants contactés constitue un signal fort.
• Comparez les permissions demandées dans le manifeste et les host_permissions entre les versions ; le passage d'un jeu de permissions restreint à un accès large <all_urls> après un changement de propriétaire est un signal d'alerte qui mérite investigation, même sans correspondance de hash.
• Injectez les nouveaux hashes d'extensions observés dans votre pipeline de détection existant basé sur les hashes, afin que les futures installations sur l'ensemble du parc soient signalées automatiquement plutôt que de nécessiter une revue manuelle à chaque fois.

C'est exactement la même discipline que les équipes SOC appliquent déjà aux exécutables et aux scripts — il suffit de la pointer vers une partie de la surface d'attaque du navigateur historiquement considérée comme hors périmètre.

Remonter les domaines et les IP de C2

Une fois confirmée l'exfiltration de données par une extension, l'infrastructure de balise avec laquelle elle communique est généralement le chemin le plus rapide pour délimiter le périmètre de l'incident et retrouver les autres machines touchées.

• Extrayez chaque domaine et chaque IP contactés par le script d'arrière-plan de l'extension, y compris ceux dissimulés dans des chaînes obfusquées ou encodées en base64 à l'intérieur du bundle.
• Passez chacun d'eux dans l'intelligence sur les domaines pour vérifier l'ancienneté d'enregistrement, l'historique DNS et les schémas d'hébergement typiques d'une infrastructure C2 jetable.
• Recoupez les IP résolues avec des recherches de réputation d'IP pour évaluer les hébergeurs, la réputation de l'ASN et l'infrastructure malveillante colocalisée.
• Surveillez la réutilisation d'infrastructure : les attaquants qui mènent ces campagnes font souvent tourner les domaines mais conservent le même hébergeur, le même schéma d'émetteur de certificat TLS ou le même bloc d'IP pour plusieurs extensions malveillantes.
• Une fois un domaine C2 confirmé, pivotez sur le DNS passif et les données de certificats partagés pour découvrir les domaines frères avant qu'ils ne soient armés contre un autre ensemble de victimes.

Enrichir cette infrastructure tôt transforme la découverte d'une seule extension en une règle de détection applicable à l'ensemble du parc, plutôt qu'en un nettoyage ponctuel.

Playbook de réponse à incident pour le détournement de session

Si une extension malveillante est confirmée dans votre environnement, traitez l'événement comme une compromission active de sessions, et non comme une simple tâche de suppression de malware :

• Révoquez toutes les sessions actives et les refresh tokens de chaque compte sur lequel l'extension était installée, pour tous les services couverts par les permissions d'hôte de l'extension — pas seulement le fournisseur SSO principal.
• Forcez une réauthentification avec MFA pour les utilisateurs concernés, et faites tourner toutes les clés d'API ou jetons de longue durée susceptibles d'avoir séjourné dans le stockage du navigateur.
• Supprimez l'extension sur l'ensemble du parc via une politique de navigateur managée, et bloquez sa réinstallation par ID d'extension au niveau du terminal ou du proxy.
• Recherchez les domaines et IP de C2 confirmés dans les journaux de proxy, DNS et pare-feu pour identifier chaque hôte ayant émis des balises, et pas uniquement celui à l'origine de l'alerte initiale.
• Conservez le paquet de l'extension, le manifeste et tout trafic réseau capturé avant remédiation : ce sont les indicateurs de hash et d'infrastructure qui vous permettront de détecter le prochain rebranding de la même campagne.
• Intégrez cet incident à votre workflow de réponse à incident afin que les indicateurs restent conservés et interrogeables lors de la prochaine vague similaire.

Continuer à surveiller après le nettoyage

Une suppression unique et une réinitialisation des mots de passe referment l'exposition immédiate, mais l'infrastructure sous-jacente de la campagne disparaît rarement : elle refait surface sous un nouveau nom d'extension, une nouvelle fiche ou une nouvelle mise à jour quelques mois plus tard. C'est la surveillance continue des hashes et de l'infrastructure que vous avez déjà confirmés comme malveillants qui permet d'attraper la vague suivante avant qu'elle n'atteigne à nouveau vos utilisateurs. Branchez les vérifications de hashes et de domaines sur votre pipeline de détection existant via l'API de threat intelligence pour que chaque nouvelle mise à jour d'extension, chaque nouveau domaine de balise et chaque hash réutilisé soit contrôlé automatiquement, au lieu d'attendre le prochain titre de presse pour déclencher une revue manuelle.