Hacking Password Managers Navigateurs : Attaques Expert

Le stockage des mots de passe dans les navigateurs web est devenu une pratique quasi universelle. Selon les études récentes, plus de 65 % des utilisateurs en entreprise s'appuient exclusivement sur le gestionnaire intégré de leur navigateur pour mémoriser l'ensemble de leurs credentials professionnels. Cette commodité a un coût considérable en matière de sécurité. Les techniques de hacking password managers navigateurs figurent parmi les premières actions post-exploitation réalisées par les attaquants, qu'ils soient étatiques, criminels ou mandatés dans le cadre de missions offensives légitimes. Dans cet article, nous explorons en profondeur chaque navigateur, chaque mécanisme cryptographique et chaque outil offensif impliqué. Pour une compréhension approfondie des attaques spécifiques à Chrome, consultez notre article dédié aux exploits DPAPI Chrome. Les techniques abordées ici s'inscrivent directement dans le cadre MITRE ATT&CK T1555.003 — Credentials from Web Browsers, une sous-technique de la collecte de credentials particulièrement surveillée par les équipes de détection modernes. Pour contextualiser ces attaques dans l'écosystème plus large du vol de mots de passe, référez-vous à notre guide sur les attaques de mots de passe, cracking et spraying.

Panorama des gestionnaires de mots de passe navigateurs en 2026

Le paysage des navigateurs web en 2026 se caractérise par une domination écrasante de la famille Chromium. Google Chrome détient environ 63 % des parts de marché mondial, suivi par Microsoft Edge à 13 %, Safari à 9 %, Firefox à 6 %, puis Brave et Opera qui se partagent les derniers pourcentages. Cette hégémonie Chromium a une conséquence directe en cybersécurité offensive : un attaquant maîtrisant l'extraction de credentials Chrome dispose automatiquement des compétences nécessaires pour cibler Edge, Brave, Opera et la vingtaine d'autres navigateurs basés sur le même moteur.

Chaque navigateur intègre un gestionnaire de mots de passe natif qui propose automatiquement de sauvegarder les identifiants saisis dans les formulaires web. Ces gestionnaires offrent désormais des fonctionnalités avancées : détection de mots de passe compromis via des bases de données de fuites, génération de mots de passe forts, synchronisation cloud multi-appareils et, plus récemment, support des passkeys conformes au standard FIDO2/WebAuthn. Google Password Manager, par exemple, stocke les credentials de plus de trois milliards d'utilisateurs synchronisés via leur compte Google. Microsoft Edge propose une intégration similaire via le Microsoft Account, tandis que Firefox Sync assure la synchronisation chiffrée de bout en bout entre appareils via les serveurs Mozilla.

En environnement d'entreprise, cette situation crée une surface d'attaque considérable. Un poste de travail Windows typique dans une grande organisation française héberge souvent deux à trois navigateurs (Chrome et Edge au minimum, fréquemment Firefox pour les équipes techniques). Chacun maintient sa propre base de credentials, souvent avec des mots de passe identiques ou similaires. Les politiques de sécurité peinent à suivre : malgré les recommandations de l'ANSSI, rares sont les organisations ayant déployé des GPO interdisant explicitement le stockage de mots de passe dans les navigateurs. L'attaquant qui compromet un poste obtient ainsi potentiellement des centaines de credentials en quelques secondes, couvrant applications métier, SaaS, VPN et parfois même accès administratifs.

Architecture commune des navigateurs Chromium-based

Comprendre l'architecture de stockage des navigateurs Chromium est fondamental pour toute opération offensive ou défensive. Chrome, Edge, Brave et Opera utilisent tous le même schéma de base : une base de données SQLite nommée Login Data stockée dans le profil utilisateur. Sous Windows, le chemin typique est %LOCALAPPDATA%\Google\Chrome\User Data\Default\Login Data. Pour Edge, remplacez simplement par Microsoft\Edge\User Data\Default\Login Data.

Cette base contient une table logins avec les colonnes essentielles : origin_url (URL du site), username_value (identifiant), password_value (mot de passe chiffré) et date_created (timestamp WebKit). Le chiffrement du champ password_value repose sur un mécanisme à deux couches. Premièrement, une master key AES-256-GCM est générée et stockée dans le fichier Local State (format JSON, champ os_crypt.encrypted_key). Cette clé est elle-même chiffrée avec l'API Windows DPAPI (Data Protection API), liée au contexte utilisateur Windows.

Le processus de déchiffrement suit donc cette séquence : lecture du fichier Local State, extraction de la clé chiffrée (encodée en Base64 avec préfixe DPAPI), appel à CryptUnprotectData() pour déchiffrer la master key via DPAPI, puis déchiffrement AES-256-GCM de chaque mot de passe avec cette clé. Le nonce (12 octets) et le tag d'authentification (16 octets) sont inclus dans le blob chiffré. Pour les anciens mots de passe (versions pré-80), le chiffrement utilisait DPAPI directement sans couche AES intermédiaire. Cette architecture, documentée en détail dans notre article sur les exploits DPAPI Chrome, est identique pour tous les navigateurs Chromium — seuls les chemins de fichiers diffèrent.

Architecture spécifique Firefox et dérivés Gecko

Firefox adopte une approche fondamentalement différente des navigateurs Chromium pour le stockage des credentials. Le moteur de chiffrement repose sur la bibliothèque NSS (Network Security Services), développée originellement par Netscape et maintenue par Mozilla. Les mots de passe sont stockés dans un fichier logins.json en texte semi-structuré, mais les valeurs sensibles sont chiffrées avec l'algorithme 3DES-CBC (Triple DES en mode CBC), encapsulé dans des structures PKCS#11.

La clé de chiffrement est dérivée d'un master password optionnel (ou d'une chaîne vide si aucun n'est défini — ce qui est le cas pour la très grande majorité des utilisateurs) et stockée dans les fichiers de base de données de sécurité NSS : key4.db (format SQLite remplaçant l'ancien key3.db au format Berkeley DB). Le fichier cert9.db complète l'infrastructure cryptographique. Ces fichiers résident dans le répertoire de profil Firefox, typiquement sous %APPDATA%\Mozilla\Firefox\Profiles\<random>.default-release\.

L'extraction des credentials Firefox nécessite soit le chargement de la bibliothèque nss3.dll (ou libnss3.so sous Linux) pour utiliser les fonctions natives de déchiffrement, soit une réimplémentation du processus cryptographique. L'outil de référence pour cette seconde approche est firepwd.py, qui décode les structures ASN.1/BER, dérive la clé de chiffrement via PKCS#5 (PBKDF2 avec SHA-256 et un nombre configurable d'itérations), puis déchiffre les blobs 3DES. Notre article dédié à l'extraction Firefox via NSS détaille chaque étape de ce processus. Les navigateurs dérivés de Firefox (Tor Browser, Waterfox, LibreWolf, Pale Moon) utilisent la même architecture, rendant les mêmes outils opérants avec de simples ajustements de chemins de profil. Sous Linux, les profils Firefox se trouvent typiquement dans ~/.mozilla/firefox/, et sous macOS dans ~/Library/Application Support/Firefox/Profiles/.

Safari et le Keychain macOS : particularités Apple

Safari, le navigateur natif d'Apple, délègue intégralement le stockage des credentials au Keychain macOS — un coffre-fort cryptographique système intégré au noyau. Contrairement aux navigateurs Chromium et Firefox qui gèrent leur propre infrastructure de chiffrement, Safari s'appuie sur la sécurité du système d'exploitation. Les mots de passe sont stockés dans le keychain login.keychain-db situé dans ~/Library/Keychains/, chiffré avec la passphrase de session de l'utilisateur.

L'extraction de credentials Safari en contexte offensif est significativement plus complexe que pour les navigateurs Windows. L'accès programmatique au Keychain nécessite soit l'approbation explicite de l'utilisateur via une boîte de dialogue système (attaque de type prompt bombing), soit l'exploitation de vulnérabilités spécifiques à macOS. L'outil chainbreaker permet le déchiffrement offline du fichier keychain si l'attaquant dispose du mot de passe utilisateur ou de la clé de déchiffrement. En contexte post-exploitation avec un agent Mythic ou Sliver, la commande security dump-keychain requiert l'interaction utilisateur, limitant son utilisation en opérations furtives.

Apple a renforcé significativement la protection avec l'introduction du Secure Enclave sur les Mac équipés de puces Apple Silicon (M1 et supérieurs) et de la puce T2 sur les derniers Intel. Les clés de chiffrement du Keychain peuvent désormais être protégées par le Secure Enclave, rendant l'extraction offline théoriquement impossible sans compromission du processeur sécurisé. Cependant, en pratique, l'accès au Keychain depuis un processus s'exécutant dans le contexte utilisateur reste possible si l'attaquant dispose d'une session authentifiée. Les outils comme keychaindump et les modules Mythic keychain_dump exploitent cette fenêtre d'opportunité. L'écosystème Apple, bien que plus sécurisé par conception, n'est donc pas imperméable aux techniques de credential harvesting ciblées.

Comparatif des mécanismes de chiffrement par navigateur

La diversité des approches cryptographiques entre navigateurs crée un paysage complexe que l'attaquant doit maîtriser. Le tableau suivant synthétise les caractéristiques clés de chaque implémentation, permettant d'identifier rapidement les forces et faiblesses exploitables.

Plusieurs constats émergent de cette comparaison. Premièrement, les navigateurs Chromium offrent paradoxalement la protection la plus faible en contexte post-exploitation utilisateur : l'absence de master password et la dépendance à DPAPI signifient que tout processus s'exécutant sous l'identité de l'utilisateur peut déchiffrer les credentials sans interaction. Firefox se distingue par la possibilité d'un master password, mais son adoption reste marginale (estimée à moins de 5 % des utilisateurs selon les études Mozilla). Safari bénéficie de l'intégration système Apple mais reste vulnérable aux attaques en contexte utilisateur authentifié.

Sous Linux, la situation des navigateurs Chromium est encore plus préoccupante : sans gestionnaire de secrets système (gnome-keyring ou kwallet), Chrome stocke la clé de chiffrement en dur avec la valeur peanuts, offrant une protection essentiellement nulle. Cette information, bien documentée dans le code source Chromium, est régulièrement exploitée dans les environnements serveurs Linux où aucun environnement de bureau n'est configuré.

Surface d'attaque : cartographie complète des vecteurs

La surface d'attaque des gestionnaires de mots de passe navigateurs s'étend bien au-delà de la simple lecture de fichiers de base de données. Une cartographie exhaustive identifie six catégories de vecteurs que tout professionnel de la sécurité doit connaître. Le premier vecteur est l'accès direct au système de fichiers : copie des fichiers SQLite et JSON contenant les credentials chiffrées, puis déchiffrement offline ou dans le contexte utilisateur. C'est la méthode la plus commune, utilisée par la quasi-totalité des stealers.

Le deuxième vecteur exploite les API de déchiffrement du système d'exploitation : appels directs à DPAPI (CryptUnprotectData), aux fonctions NSS (PK11SDR_Decrypt), ou aux API Keychain. Le troisième vecteur cible la mémoire des processus navigateur : les credentials sont temporairement déchiffrées en mémoire lorsque le navigateur les utilise pour l'auto-remplissage, créant une fenêtre d'extraction via injection de code ou lecture mémoire.

Le quatrième vecteur concerne la synchronisation cloud. Les credentials synchronisées transitent par les serveurs Google, Microsoft ou Mozilla, offrant des opportunités d'interception (compromission du compte cloud, attaque man-in-the-middle sur la synchronisation). Le cinquième vecteur s'attaque aux extensions de navigateur, particulièrement les gestionnaires de mots de passe tiers (1Password, Bitwarden, LastPass) dont les extensions peuvent être ciblées via des vulnérabilités XSS, des extensions malveillantes ou la lecture de la mémoire de l'extension. Le sixième vecteur exploite les mécanismes de sauvegarde et d'export : profils navigateur dans les sauvegardes Windows, exports CSV non chiffrés, fichiers temporaires créés lors de la migration entre navigateurs. Chacun de ces vecteurs requiert des outils et des techniques spécifiques que nous détaillerons dans les sections suivantes, en lien avec les techniques MITRE ATT&CK les plus utilisées en 2026.

Techniques de vol de credentials en contexte utilisateur

L'extraction de credentials en contexte utilisateur — c'est-à-dire depuis un processus s'exécutant avec les privilèges de l'utilisateur ciblé — constitue le scénario le plus fréquent en red team et le plus exploité par les malwares. Sous Windows, la technique fondamentale consiste à copier le fichier Login Data (le navigateur verrouille ce fichier en écriture mais autorise la lecture), extraire la clé chiffrée du fichier Local State, puis appeler CryptUnprotectData() pour obtenir la master key AES en clair.

L'implémentation en PowerShell est triviale et fréquemment observée dans les engagements : Add-Type -AssemblyName System.Security suivi de l'appel à [System.Security.Cryptography.ProtectedData]::Unprotect(). En C#, la classe ProtectedData offre la même fonctionnalité. Ces approches ne nécessitent aucune élévation de privilèges : tout processus dans le contexte utilisateur peut déchiffrer les données protégées par DPAPI pour ce même utilisateur.

Pour Firefox, l'extraction en contexte utilisateur requiert le chargement de nss3.dll. L'outil SharpWeb implémente cette approche en C#, compatible avec l'exécution en mémoire via execute-assembly dans les frameworks C2. Alternativement, le script Python firepwd.py peut être déployé si Python est disponible sur la cible. La technique fonctionne sans master password — si l'utilisateur n'a pas configuré de mot de passe maître (ce qui est le cas par défaut), l'extraction est transparente.

Il est crucial de noter que le navigateur n'a pas besoin d'être fermé pour l'extraction. La copie du fichier SQLite fonctionne même si le navigateur est en cours d'utilisation, grâce au mode WAL (Write-Ahead Logging) de SQLite. Certains outils utilisent la commande sqlite3 "file:Login Data?mode=ro&nolock=1" pour un accès en lecture seule sans conflit de verrouillage. D'autres approches copient directement le fichier via l'API CopyFile de Windows, qui crée un snapshot cohérent même sur un fichier verrouillé en écriture. Cette particularité technique signifie que l'extraction peut être réalisée de manière totalement silencieuse, sans perturber la session de navigation de l'utilisateur et sans laisser de trace visible sur l'écran. L'utilisateur compromis continue de travailler normalement, sans aucune indication que ses credentials viennent d'être extraits — un avantage opérationnel considérable pour les attaquants cherchant à maintenir la discrétion.

Post-exploitation : extraction après compromission initiale

Dans un scénario de post-exploitation classique, l'attaquant dispose d'un accès distant au poste compromis via un implant C2, un reverse shell ou une session RDP. L'extraction des credentials navigateur s'inscrit alors dans une phase de credential harvesting systématique qui cible simultanément plusieurs sources. L'approche méthodique commence par l'énumération des navigateurs installés et de leurs profils. Sous Windows, une simple inspection des répertoires %LOCALAPPDATA% et %APPDATA% révèle la présence de Chrome, Edge, Brave, Firefox et Opera.

L'extraction multi-navigateur en post-exploitation suit généralement un workflow standardisé : identification des profils (Default, Profile 1, Profile 2...), copie des fichiers de base de données vers un répertoire de travail, extraction et déchiffrement des master keys, puis déchiffrement de l'ensemble des credentials. Les outils modernes automatisent cette chaîne complète. En contexte mouvement latéral, cette extraction peut être réalisée à distance via SMB si l'attaquant dispose de credentials administrateur sur le réseau : accès aux partages C$ pour récupérer les fichiers Login Data et Local State, puis déchiffrement DPAPI à distance avec les clés de backup du domaine.

La post-exploitation inclut également l'extraction des credentials depuis les sessions Remote Desktop. Les fichiers de profil navigateur des utilisateurs connectés en RDP sont accessibles dans leurs répertoires respectifs. Un attaquant ayant compromis un serveur de rebond (jump host) peut ainsi récupérer les credentials de tous les administrateurs qui s'y sont connectés. Cette technique est particulièrement redoutable dans les environnements où les administrateurs utilisent leurs navigateurs personnels sur les serveurs de rebond — une mauvaise pratique malheureusement courante. L'extraction des infostealers, cette menace silencieuse du cybercrime, suit exactement les mêmes mécanismes, automatisés à grande échelle par les groupes criminels organisés.

Credential harvesting automatisé : frameworks C2

Les frameworks de Command and Control (C2) modernes intègrent nativement des modules d'extraction de credentials navigateur, transformant une opération manuelle complexe en une commande unique. Cette automatisation est au cœur des opérations offensives professionnelles et des campagnes d'intrusion avancées. Les principaux frameworks offrent chacun des approches distinctes, adaptées à différents contextes opérationnels et niveaux d'OPSEC (sécurité opérationnelle).

Le paradigme commun repose sur l'exécution en mémoire : le module d'extraction est chargé directement dans la mémoire du processus de l'implant, sans écrire de fichier sur le disque. Cette approche fileless réduit considérablement la surface de détection par les antivirus et les EDR basés sur la surveillance du système de fichiers. Les frameworks C2 utilisent différentes techniques d'injection : execute-assembly pour le code .NET, inline-execute pour les Beacon Object Files (BOFs), ou injection de shellcode pour les payloads natifs.

L'automatisation permet également le credential harvesting à l'échelle : lors d'une compromission touchant des dizaines ou centaines de postes, un opérateur C2 peut exécuter simultanément l'extraction sur l'ensemble des implants actifs, collectant des milliers de credentials en quelques minutes. Les résultats sont centralisés dans la console C2, permettant une analyse rapide et l'identification des credentials à haute valeur (comptes administrateurs, accès VPN, portails cloud). Cette capacité de collecte massive est documentée dans notre analyse des stealers RedLine, Raccoon et Lumma qui utilisent des mécanismes similaires. La distinction principale entre un outil de red team légitime et un malware réside souvent uniquement dans l'intention et l'autorisation, les techniques sous-jacentes étant fondamentalement identiques.

CobaltStrike et les BOFs d'extraction navigateur

CobaltStrike reste en 2026 le framework C2 commercial le plus utilisé par les équipes de red team professionnelles et, malheureusement, par de nombreux groupes de menaces. Son écosystème de Beacon Object Files (BOFs) offre un mécanisme particulièrement efficace pour l'extraction de credentials navigateur. Les BOFs sont de petits fichiers objets COFF exécutés directement dans la mémoire du Beacon, sans créer de nouveau processus ni écrire de fichier sur le disque — un avantage considérable pour l'évasion EDR.

Parmi les BOFs d'extraction navigateur les plus utilisés, ChromeKatz et CookieKatz (développés par Meckazin) se distinguent par leur capacité à extraire credentials et cookies directement depuis la mémoire du processus Chrome en cours d'exécution, sans accéder aux fichiers de base de données. Cette approche contourne l'App-Bound Encryption et les mécanismes de verrouillage de fichiers. Le BOF SharpChromium offre une approche complémentaire basée sur l'accès fichier traditionnel, avec déchiffrement DPAPI intégré.

Pour Firefox, le BOF FirefoxDecryptor charge la bibliothèque NSS en mémoire et utilise les fonctions natives de déchiffrement. L'approche multi-navigateur est facilitée par des BOFs comme CredBandit qui combinent l'extraction Chromium et Firefox dans un seul module. L'exécution typique dans une console CobaltStrike ressemble à : inline-execute CredBandit.o, produisant un dump structuré de l'ensemble des credentials et cookies de tous les navigateurs détectés sur le poste.

L'OPSEC de ces BOFs varie considérablement. Les approches basées sur la lecture mémoire (ChromeKatz) sont plus furtives que celles accédant au système de fichiers, car elles évitent les événements de lecture de fichiers surveillés par les EDR. Cependant, l'injection dans le processus navigateur peut déclencher des alertes de type « cross-process memory access ». L'opérateur expérimenté choisira le BOF approprié en fonction du niveau de surveillance EDR observé sur la cible.

Sliver, Havoc et Brute Ratel : modules d'extraction

Face à la détection croissante de CobaltStrike par les EDR modernes, les équipes offensives se tournent vers des frameworks C2 alternatifs. Sliver, développé par BishopFox et distribué en open source, intègre des capacités d'extraction via son système d'extensions. La commande sharpdpapi en mode execute-assembly permet le déchiffrement DPAPI des credentials Chromium, tandis que des extensions communautaires offrent un support Firefox et Safari. L'architecture de Sliver, basée sur les protocoles mTLS, WireGuard et DNS, offre une excellente résilience réseau pour les opérations de longue durée.

Havoc, framework C2 développé par C5pिder, se distingue par son architecture modulaire et sa compatibilité BOF native. Les mêmes BOFs développés pour CobaltStrike (ChromeKatz, CredBandit) fonctionnent directement dans Havoc via le chargeur BOF intégré. Havoc ajoute des capacités spécifiques comme l'extraction via syscalls indirects, réduisant la détection par les hooks userland des EDR. La commande dotnet inline-execute SharpWeb.exe all dans une session Havoc extrait les credentials de l'ensemble des navigateurs en une seule opération.

Brute Ratel C4 (BRc4), créé par Chetan Nayak, pousse l'évasion EDR encore plus loin avec des techniques de badger (implant) spécifiquement conçues pour contourner les solutions de sécurité endpoint modernes. BRc4 utilise des appels système directs, l'unhooking de DLLs et des techniques de sleep obfuscation avancées. Pour l'extraction de credentials navigateur, BRc4 s'appuie sur des modules .NET chargés en mémoire via son propre CLR loader, évitant les hooks sur amsi.dll et clr.dll. Les opérateurs rapportent des taux d'évasion significativement supérieurs à CobaltStrike contre les EDR de dernière génération (CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint). Pour comprendre le contexte plus large de ces opérations, notre guide sur l'escalade de privilèges Windows détaille les techniques complémentaires souvent combinées avec l'extraction de credentials.

Outils standalone : LaZagne, HackBrowserData, SharpWeb

LaZagne reste l'outil de référence pour l'extraction multi-sources de credentials. Écrit en Python, il cible non seulement les navigateurs (Chrome, Firefox, Opera, IE/Edge Legacy) mais également les clients mail, bases de données, clients FTP, gestionnaires de mots de passe et credentials système. La commande lazagne.exe browsers extrait spécifiquement les credentials navigateur. Son principal avantage est sa polyvalence ; son principal inconvénient est sa détection quasi universelle par les antivirus — la signature de LaZagne est connue de tous les éditeurs depuis des années.

HackBrowserData, développé en Go par moonD4rk, est devenu l'outil privilégié pour l'extraction multi-navigateur cross-platform. Il supporte Chrome, Edge, Brave, Opera, Vivaldi, Firefox, Yandex et Safari, extrayant mots de passe, cookies, historique, bookmarks et données de cartes de crédit. Sa compilation en binaire Go statique facilite le déploiement sans dépendances. La commande hack-browser-data.exe -b all -p results/ produit des fichiers CSV structurés pour chaque type de donnée et chaque navigateur détecté.

SharpWeb, implémenté en C#, est spécifiquement conçu pour l'exécution en mémoire dans les frameworks C2 via execute-assembly. Il offre un support Chromium et Firefox avec une empreinte mémoire minimale. D'autres outils notables incluent BrowserStealer (Python, multi-OS), WebBrowserPassView de NirSoft (GUI Windows, fréquemment détourné par les attaquants), et dumpWebBrowserPasswords.py de Zet-ans. Pour une analyse détaillée de comment ces outils sont intégrés dans les chaînes d'attaque malveillantes, consultez notre article sur le reverse engineering et l'analyse de malware. Chaque outil présente un compromis différent entre fonctionnalités, discrétion et facilité de déploiement — le choix dépend du contexte opérationnel spécifique.

Extraction des cookies et tokens de session

L'extraction de credentials navigateur ne se limite pas aux mots de passe. Les cookies de session et les tokens d'authentification stockés par le navigateur représentent souvent une valeur supérieure pour l'attaquant, car ils permettent l'usurpation de sessions authentifiées sans nécessiter le mot de passe ni le second facteur d'authentification. Les cookies sont stockés dans une base SQLite distincte nommée Cookies (Chromium) ou cookies.sqlite (Firefox), utilisant les mêmes mécanismes de chiffrement que les mots de passe.

Les cookies critiques pour l'attaquant incluent les cookies de session des applications SaaS d'entreprise (Microsoft 365, Google Workspace, Salesforce, ServiceNow), les tokens OAuth 2.0 stockés en cookies, les cookies d'authentification SSO (SAML, OIDC) et les cookies de session des consoles d'administration cloud (AWS, Azure, GCP). Un cookie de session Microsoft 365 valide permet à l'attaquant d'accéder à l'ensemble des services M365 (Exchange Online, SharePoint, Teams, OneDrive) sans déclencher de nouvelle authentification ni de vérification MFA. Les cookies d'accès aux consoles cloud AWS (identifiés par les noms aws-creds et AWSALB) sont particulièrement recherchés car ils offrent un accès direct à l'infrastructure de production.

L'outil CookieKatz illustre l'état de l'art de l'extraction de cookies : il lit les cookies directement depuis la mémoire du processus Chrome, contournant ainsi le chiffrement sur disque et l'App-Bound Encryption. La technique repose sur le parsing des structures internes de Chrome en mémoire pour localiser le cookie store. Les cookies extraits sont au format Netscape, directement importables dans un navigateur attaquant ou dans des outils comme Cookie-Editor. Pour les équipes défensives, la détection de l'accès inter-processus à chrome.exe est un indicateur fort de cette technique d'extraction.

Vol de cookies MFA : contourner l'authentification forte

Le vol de cookies post-authentification MFA représente l'une des menaces les plus critiques de l'écosystème actuel. Lorsqu'un utilisateur complète avec succès une authentification multi-facteurs, l'application émet un cookie de session qui « mémorise » cette authentification pour une durée déterminée. Ce cookie, une fois extrait, permet à l'attaquant de contourner totalement le MFA sans jamais avoir besoin du second facteur. C'est la technique documentée sous MITRE ATT&CK T1555.003 dans sa variante la plus impactante.

Les scénarios d'exploitation sont multiples. Dans une attaque post-compromission, l'attaquant extrait les cookies depuis le poste de l'utilisateur légitime après que celui-ci s'est authentifié avec son MFA. Dans une attaque de type Adversary-in-the-Middle (AitM), l'attaquant utilise un framework comme EvilGinx2 ou Modlishka pour intercepter le cookie de session au moment même de l'authentification. Notre article détaillé sur EvilGinx et le phishing AitM couvre spécifiquement cette technique de contournement MFA.

La durée de validité des cookies de session détermine la fenêtre d'exploitation. Les cookies Microsoft 365 ont typiquement une durée de vie de 1 à 24 heures (configurable via Conditional Access). Les cookies Google Workspace peuvent durer jusqu'à 14 jours. Les applications internes avec une gestion de session permissive peuvent émettre des cookies valides plusieurs semaines, voire plusieurs mois dans les configurations les plus laxistes. La contre-mesure principale est le token binding (liaison du token à l'appareil), progressivement déployé par les fournisseurs cloud majeurs. Google Device Bound Session Credentials (DBSC) et la token protection Microsoft Entra ID visent à rendre les cookies volés inutilisables sur un appareil différent, mais l'adoption reste partielle en 2026. Les organisations doivent en attendant réduire la durée de vie des cookies de session au minimum opérationnel acceptable.

Session hijacking via cookies extraits

Une fois les cookies extraits, l'étape suivante est leur exploitation opérationnelle — le session hijacking. L'attaquant importe les cookies dans son propre navigateur ou dans un outil d'automatisation pour usurper la session de la victime. Plusieurs méthodes d'importation existent : l'extension Cookie-Editor permet l'importation manuelle dans Chrome ou Firefox, les outils de ligne de commande comme curl acceptent les cookies via l'option --cookie, et les frameworks d'automatisation (Playwright, Puppeteer, Selenium) peuvent charger un profil de cookies complet.

La technique la plus sophistiquée consiste à recréer un profil navigateur complet à partir des données extraites. En copiant les fichiers Cookies, Local Storage, Session Storage et IndexedDB de la victime vers un profil contrôlé par l'attaquant, celui-ci obtient une réplique exacte de la session, incluant les préférences, les données d'application web et les tokens stockés en JavaScript. Cette approche est particulièrement efficace contre les applications SPA (Single Page Application) qui stockent des tokens d'authentification dans le localStorage.

En contexte Red Team, le session hijacking via cookies est une technique privilégiée pour l'accès aux ressources cloud sans déclencher d'alertes de connexion suspecte. L'attaquant peut configurer son navigateur pour imiter le User-Agent et les caractéristiques de la machine victime, réduisant la probabilité de détection par les systèmes d'analyse comportementale. Les équipes les plus avancées utilisent des machines virtuelles avec des profils matériels et logiciels correspondant à l'environnement cible, créant un clone numérique quasi indétectable. La détection repose alors sur l'analyse des adresses IP et la géolocalisation — si l'attaquant utilise un proxy géographiquement proche de la victime, la détection devient extrêmement difficile.

Attaques sur les extensions de password managers tiers

Les extensions de navigateur des gestionnaires de mots de passe tiers (1Password, Bitwarden, LastPass, Dashlane, KeePassXC) introduisent une surface d'attaque supplémentaire souvent sous-estimée. Ces extensions fonctionnent dans un environnement contraint par le modèle de sécurité du navigateur (sandboxing des extensions, séparation des contextes), mais restent vulnérables à plusieurs catégories d'attaques que tout auditeur de sécurité doit connaître.

La première catégorie concerne les vulnérabilités XSS dans les extensions elles-mêmes. Des chercheurs ont démontré à plusieurs reprises que certaines extensions de password managers étaient vulnérables aux attaques XSS permettant l'extraction du coffre déchiffré en mémoire. En 2023, une vulnérabilité critique dans l'extension Bitwarden permettait l'accès aux credentials via un iframe malveillant sur un site contrôlé par l'attaquant (CVE-2023-27974). Les extensions LastPass ont historiquement été ciblées par des recherches similaires, avec des vulnérabilités permettant la fuite de credentials via des pages web spécialement crafées.

La deuxième catégorie exploite le mécanisme d'auto-remplissage (autofill). Les extensions insèrent automatiquement les credentials dans les formulaires web, créant une opportunité d'extraction via des champs de formulaire cachés ou des pages de phishing conçues pour déclencher l'autofill. La troisième catégorie cible le stockage local de l'extension : les données de coffre-fort chiffrées sont stockées dans le chrome.storage.local ou le IndexedDB de l'extension, accessibles à un attaquant disposant d'un accès au système de fichiers du profil navigateur. Le fichier de stockage de l'extension est protégé uniquement par le mot de passe maître de l'utilisateur — si celui-ci est faible, une attaque par brute force offline est envisageable. Les techniques d'attaque sur les extensions constituent un domaine de recherche actif, régulièrement présenté dans les conférences comme Black Hat et DEF CON.

Exploitation de 1Password, Bitwarden et LastPass en navigateur

Chaque gestionnaire de mots de passe tiers présente des caractéristiques d'exploitation spécifiques. 1Password utilise un modèle de chiffrement à deux clés (Account Password + Secret Key), ce qui rend l'attaque offline du coffre significativement plus complexe. Cependant, l'extension navigateur déchiffre les entrées en mémoire lors de l'utilisation, et un dump mémoire du processus de l'extension peut révéler des credentials en clair. L'outil 1PasswordExtractor disponible sur GitHub automatise cette extraction depuis la mémoire de Chrome.

Bitwarden, solution open source populaire en entreprise, stocke le coffre chiffré en AES-256-CBC avec une clé dérivée via PBKDF2-SHA256 (ou Argon2id pour les versions récentes). Le fichier de stockage de l'extension est accessible dans le répertoire de profil Chrome sous Local Extension Settings/nngceckbapebfimnlniiiahkandclblb/. Si l'attaquant récupère ce fichier et connaît ou craque le master password, il accède à l'ensemble du coffre. L'outil bitwardenDecrypt permet le déchiffrement offline à partir des données exportées de l'extension.

LastPass a subi des incidents de sécurité majeurs (notamment la compromission de 2022-2023 ayant exposé des coffres-forts chiffrés de millions d'utilisateurs). L'extension LastPass stocke les données de session et le coffre déchiffré dans le localStorage du navigateur, accessible via les DevTools ou par lecture directe du fichier de stockage. Les chercheurs ont démontré que des vulnérabilités dans le mécanisme d'autofill de LastPass permettaient l'extraction de credentials via des pages web malveillantes. En environnement entreprise, la centralisation de tous les mots de passe dans un gestionnaire tiers avec extension navigateur crée un point de défaillance unique (single point of failure) que les attaquants ciblent prioritairement. L'adoption d'une approche Zero Trust atténue ce risque en diversifiant les mécanismes d'authentification.

Exfiltration de données : techniques et canaux

Une fois les credentials et cookies extraits, l'attaquant doit les exfiltrer vers son infrastructure de contrôle. Les techniques d'exfiltration varient considérablement en fonction du niveau de surveillance réseau de l'environnement cible. Le canal le plus simple est l'exfiltration directe via le protocole C2 : les données sont transmises dans les communications régulières entre l'implant et le serveur de contrôle, chiffrées et encapsulées dans le trafic HTTPS, DNS ou SMB selon le protocole C2 utilisé.

Pour les environnements à haute surveillance, des canaux d'exfiltration alternatifs sont utilisés. L'exfiltration via DNS encode les données dans les requêtes DNS (sous-domaines), offrant un débit faible mais une discrétion élevée car le trafic DNS est rarement inspecté en profondeur. L'outil DNSExfiltrator automatise ce processus. L'exfiltration via des services cloud légitimes (Dropbox, Google Drive, OneDrive, Slack, Discord) exploite le fait que ces domaines sont généralement autorisés par les proxies d'entreprise. Les frameworks C2 modernes intègrent des canaux d'exfiltration via API cloud : Sliver supporte nativement l'exfiltration via HTTP/S vers des services de stockage cloud.

Une technique d'exfiltration particulièrement redoutable consiste à utiliser directement les credentials volées pour accéder aux ressources depuis le réseau de l'entreprise, évitant ainsi toute exfiltration de données brutes. L'attaquant utilise les cookies Microsoft 365 extraits pour accéder aux boîtes mail via le navigateur du poste compromis, lisant et copiant les informations sensibles sans générer de trafic réseau suspect. Cette technique de « living off the land » appliquée à l'exfiltration est extrêmement difficile à détecter car elle se confond avec l'activité légitime de l'utilisateur compromis. Les équipes de détection doivent surveiller les anomalies comportementales (horaires inhabituels, volumes d'accès anormaux, accès à des ressources non habituelles) plutôt que les signatures réseau traditionnelles.

Évasion EDR lors de l'extraction de credentials

L'extraction de credentials navigateur est une opération hautement surveillée par les solutions EDR (Endpoint Detection and Response) modernes. CrowdStrike Falcon, SentinelOne Singularity, Microsoft Defender for Endpoint, Carbon Black et Elastic Security détectent tous les patterns d'accès aux fichiers de credentials navigateur et les appels API de déchiffrement DPAPI. L'évasion de ces détections est un enjeu crucial pour les opérateurs offensifs professionnels.

Les techniques d'évasion se déclinent en plusieurs catégories. L'unhooking consiste à restaurer les DLLs système (ntdll.dll, kernel32.dll) en mémoire pour supprimer les hooks posés par l'EDR, permettant des appels système non surveillés. Le direct syscall contourne complètement les DLLs hookées en invoquant directement les appels système du noyau. Les outils comme SysWhispers et HellsGate automatisent la génération de stubs syscall. L'indirect syscall, évolution plus récente, résout le problème des call stacks suspectes associées aux direct syscalls en utilisant des gadgets de code légitime pour les appels système.

Pour l'accès aux fichiers de credentials spécifiquement, plusieurs techniques réduisent la détection. La copie de fichiers via des API bas niveau (NtReadFile au lieu de ReadFile) contourne les hooks de supervision de fichiers. La lecture mémoire du processus navigateur au lieu de l'accès aux fichiers évite totalement les alertes de lecture de fichiers sensibles. L'utilisation de handles dupliqués depuis d'autres processus (technique DuplicateHandle) permet l'accès aux fichiers verrouillés sans ouvrir directement un handle surveillé. Les recherches publiées par Elastic Security Labs documentent en détail les mécanismes de détection et les techniques d'évasion correspondantes, constituant une ressource inestimable tant pour les attaquants que pour les défenseurs.

Techniques fileless : extraction en mémoire pure

Les techniques d'extraction fileless représentent l'état de l'art en matière d'évasion. Au lieu d'accéder aux fichiers de base de données sur le disque, l'attaquant extrait les credentials directement depuis la mémoire des processus navigateur en cours d'exécution. Cette approche contourne simultanément la surveillance des accès fichiers, le chiffrement sur disque (y compris l'App-Bound Encryption de Chrome) et les mécanismes de verrouillage de fichiers.

La technique repose sur l'identification des structures de données internes du navigateur en mémoire. Pour Chrome, les credentials déchiffrées sont maintenues en mémoire dans le processus principal du navigateur (pas dans les processus renderer sandboxés). Le tool ChromeKatz identifie les structures C++ internes de Chrome (classes PasswordFormManager et PasswordStore) pour localiser et extraire les credentials en clair. L'accès mémoire inter-processus utilise les API Windows OpenProcess et ReadProcessMemory, ou leurs équivalents syscall pour l'évasion EDR.

Pour Firefox, une approche similaire cible les structures NSS en mémoire. Le processus principal de Firefox maintient un cache des credentials déchiffrées pour l'autofill, accessible par lecture mémoire. L'outil Mimikatz (module dpapi::chrome) offre également des capacités d'extraction mémoire, bien que sa détection soit quasi universelle par les EDR modernes. Des variantes customisées et des réimplémentations en BOF (nanodump pour le dump mémoire, combiné avec un parser offline) offrent des taux d'évasion supérieurs.

L'extraction en mémoire présente cependant des limitations. Les structures internes du navigateur changent entre versions, nécessitant une maintenance régulière des outils d'extraction. Un crash du processus navigateur (résultant d'une lecture mémoire incorrecte) alerterait l'utilisateur et potentiellement les systèmes de surveillance. Les opérateurs expérimentés valident leurs outils contre la version exacte du navigateur ciblé avant l'extraction en environnement réel.

Bypass de l'App-Bound Encryption Chrome

Google a introduit l'App-Bound Encryption à partir de Chrome 127 (juillet 2024) comme couche de protection supplémentaire contre l'extraction de credentials et cookies. Ce mécanisme ajoute un chiffrement lié à l'identité de l'application : seul le processus Chrome légitime (vérifié par sa signature numérique et son chemin d'installation) peut déchiffrer les données. Concrètement, un service Windows dédié (Google Chrome Elevation Service) gère les clés de chiffrement app-bound, accessible uniquement aux processus Chrome signés.

Malgré cette protection, plusieurs techniques de contournement ont été documentées dans les mois suivant le déploiement. La première approche exploite le service d'élévation lui-même : en injectant du code dans un processus Chrome légitime (déjà autorisé à communiquer avec le service), l'attaquant peut demander le déchiffrement via le canal légitime. Les outils chrome-app-bound-encryption-decryption (par xaitax) et les versions mises à jour de ChromeKatz implémentent cette technique.

La deuxième approche contourne l'App-Bound Encryption en ciblant les données avant qu'elles ne soient chiffrées, ou après déchiffrement — c'est-à-dire en mémoire. Les techniques fileless décrites précédemment restent pleinement efficaces car elles n'interagissent pas avec le chiffrement sur disque. La troisième approche exploite les environnements où Chrome n'est pas mis à jour : de nombreux postes en entreprise utilisent encore des versions antérieures à Chrome 127, sans App-Bound Encryption. L'outil HackBrowserData a été rapidement mis à jour pour supporter le déchiffrement app-bound sur les versions récentes.

Il est important de noter que l'App-Bound Encryption n'existe que sous Windows. Les versions macOS et Linux de Chrome ne bénéficient pas de cette protection supplémentaire en 2026. De plus, cette protection ne couvre que les données chiffrées sur le disque local ; les données synchronisées via Google Account sont protégées par un mécanisme distinct (Google Password Manager encryption). L'App-Bound Encryption représente néanmoins une avancée significative qui élève le niveau de sophistication requis pour l'extraction, forçant les attaquants vers des techniques plus complexes et potentiellement plus détectables.

Chaînes d'attaque complètes : du phishing aux credentials

Comprendre les chaînes d'attaque de bout en bout est essentiel pour les équipes défensives comme offensives. Voici un scénario réaliste, inspiré de missions de red team réelles, illustrant le parcours complet depuis l'accès initial jusqu'à l'extraction massive de credentials navigateur dans un environnement d'entreprise Active Directory.

Phase 1 — Accès initial : L'attaquant envoie un email de spear-phishing ciblant un employé du département financier. La pièce jointe est un document OneNote contenant un fichier HTA embarqué qui, à l'ouverture, exécute un stager PowerShell. Ce stager télécharge et exécute en mémoire un implant Sliver via HTTPS, établissant la communication C2 initiale. L'EDR ne détecte pas l'exécution grâce à l'obfuscation AMSI et au chargement réflectif du payload.

Phase 2 — Reconnaissance et extraction locale : L'opérateur énumère le poste compromis et identifie Chrome et Firefox installés. Il exécute un BOF ChromeKatz via Sliver pour extraire les credentials Chrome en mémoire, puis un module SharpWeb pour Firefox. Il obtient 87 paires de credentials incluant des accès au portail VPN, à Microsoft 365, au système RH et à plusieurs applications métier internes.

Phase 3 — Mouvement latéral et extraction à l'échelle : Les credentials VPN et Active Directory extraits permettent l'accès à d'autres postes via WMI et PsExec. L'attaquant déploie un implant sur 15 postes supplémentaires et exécute l'extraction de credentials sur chacun, collectant plus de 500 paires de credentials uniques. Les cookies Microsoft 365 permettent l'accès aux boîtes mail de la direction sans MFA. Ce scénario, courant dans les engagements de red team professionnels, démontre l'impact dévastateur du stockage de credentials dans les navigateurs.

Retour d'expérience terrain : extraction à l'échelle bancaire

Cette expérience illustre un schéma récurrent dans nos missions. L'extraction de credentials navigateur est systématiquement l'action post-exploitation la plus rentable en termes de rapport effort/impact. En moyenne, sur nos vingt dernières missions de red team en environnement Active Directory, nous avons extrait 847 paires de credentials uniques par engagement, avec un temps moyen d'extraction de 23 minutes après la compromission initiale. Les credentials les plus critiques découverts incluaient régulièrement des accès VPN avec privilèges administrateurs, des comptes Azure Global Admin et des tokens d'API de services cloud de production.

Un autre constat alarmant concerne la réutilisation des mots de passe entre contextes professionnels et personnels. Dans 60 % des missions, nous identifions des credentials identiques utilisés pour des services d'entreprise (Active Directory, VPN, portails métier) et des services personnels (réseaux sociaux, e-commerce, streaming). Cette réutilisation permet un pivot depuis la compromission d'un service à faible valeur vers des accès critiques d'entreprise. Les campagnes de stealers exploitent massivement cette faiblesse humaine, alimentant les bases de données de credential stuffing avec des millions de paires identifiant/mot de passe directement exploitables contre les infrastructures d'entreprise.

Campagnes de stealers : écosystème MaaS (Malware-as-a-Service)

L'écosystème Malware-as-a-Service (MaaS) a industrialisé l'extraction de credentials navigateur à une échelle sans précédent. Les familles de stealers comme RedLine, Raccoon, Lumma, Vidar, Aurora, Rhadamanthys et StealC sont vendues sous forme d'abonnements sur des forums criminels et via Telegram, à des prix allant de 150 à 1 000 dollars par mois. Ces stealers intègrent nativement l'extraction multi-navigateur comme fonctionnalité centrale.

RedLine Stealer, l'un des plus prolifiques, supporte l'extraction de credentials, cookies, données de cartes de crédit et tokens d'authentification depuis plus de 30 navigateurs Chromium et Gecko. Son architecture client-serveur avec panel d'administration web permet aux opérateurs de gérer des campagnes massives avec des milliers de machines compromises. Les logs (résultats d'extraction) sont vendus en masse sur les marchés spécialisés (Russian Market, Genesis Market, 2easy), alimentant un écosystème secondaire de fraude et d'intrusion.

Lumma Stealer (ou LummaC2) représente la génération suivante avec des capacités d'évasion avancées : obfuscation du flux de contrôle, anti-sandbox, détection de machines virtuelles et communication C2 chiffrée via des domaines dynamiques. Lumma implémente le contournement de l'App-Bound Encryption Chrome et supporte l'extraction depuis les extensions de password managers tiers. Les recherches de Mandiant et d'autres équipes de threat intelligence documentent la montée en puissance continue de ces familles de stealers.

L'impact à l'échelle est considérable. Les estimations indiquent que plusieurs centaines de millions de credentials sont extraites mensuellement par les campagnes de stealers MaaS. Ces credentials alimentent les attaques de credential stuffing, les compromissions de comptes d'entreprise et servent de vecteur d'accès initial pour les opérateurs de ransomware. Le groupe LAPSUS$, par exemple, a documenté son utilisation de logs RedLine achetés pour obtenir des accès initiaux à des entreprises comme Uber, Rockstar Games et Microsoft. Plus récemment, les groupes Scattered Spider et BlackCat/ALPHV ont exploité des logs de stealers pour cibler des casinos et des entreprises technologiques de premier plan, confirmant que le vol de credentials navigateur est désormais un maillon central de la chaîne d'attaque ransomware moderne.

Détection SOC : règles SIEM et indicateurs d'extraction

La détection des tentatives d'extraction de credentials navigateur repose sur une combinaison de surveillance des accès fichiers, d'analyse comportementale et de corrélation d'événements. Les équipes SOC doivent implémenter des règles SIEM spécifiques ciblant les indicateurs caractéristiques de cette activité. Le premier indicateur est l'accès aux fichiers de base de données de credentials : toute lecture des fichiers Login Data, Cookies, logins.json ou key4.db par un processus autre que le navigateur légitime doit déclencher une alerte de haute priorité.

Sous Windows, la surveillance Sysmon (événement ID 11 pour la création de fichiers, ID 1 pour la création de processus) combinée avec des règles Sigma permet une détection efficace. Une règle Sigma typique cible la lecture du fichier Login Data par un processus dont le nom n'est pas chrome.exe, msedge.exe ou un processus de mise à jour légitime. La commande Sysmon FileRead (événement 29, introduit dans Sysmon 15) offre une visibilité directe sur les accès en lecture aux fichiers sensibles.

Les appels à l'API CryptUnprotectData constituent un second indicateur critique. Bien que cette API soit utilisée légitimement par de nombreuses applications, un appel provenant d'un processus inhabituel (PowerShell, cmd.exe, processus inconnu) ciblant des blobs DPAPI associés aux navigateurs est hautement suspect. Les EDR modernes surveillent ces appels et peuvent les corréler avec l'accès préalable aux fichiers de credentials pour réduire les faux positifs.

Les indicateurs réseau complètent la détection endpoint : exfiltration de volumes inhabituels de données, communication avec des domaines récemment enregistrés (caractéristiques des C2 de stealers), et activité DNS anormale (potentielle exfiltration DNS). L'intégration de flux de threat intelligence spécifiques aux IOC de stealers (hashes, domaines C2, patterns de communication) dans le SIEM améliore considérablement la capacité de détection précoce des campagnes actives.

Monitoring des accès aux fichiers de credentials

Au-delà des règles SIEM réactives, un monitoring proactif des fichiers de credentials navigateur constitue une couche défensive essentielle. Sous Windows, les File Integrity Monitoring (FIM) solutions peuvent être configurées pour surveiller en temps réel les répertoires contenant les bases de données de credentials. Les chemins critiques à surveiller incluent les profils de tous les navigateurs Chromium (%LOCALAPPDATA%\Google\Chrome\User Data\*\Login Data, %LOCALAPPDATA%\Microsoft\Edge\User Data\*\Login Data) et Firefox (%APPDATA%\Mozilla\Firefox\Profiles\*\logins.json).

Windows Event Log offre des capacités de surveillance natives via les politiques d'audit. L'activation de l'audit d'accès aux objets (Object Access Auditing) sur les fichiers de credentials génère des événements 4663 (tentative d'accès à un objet) qui peuvent être collectés par le SIEM. La configuration requiert la création de SACL (System Access Control Lists) sur les fichiers ciblés, déployables via GPO. Cette approche est détaillée dans les recommandations de l'ANSSI pour la surveillance des systèmes d'information.

Les solutions EDR entreprise offrent des capacités de monitoring de fichiers intégrées. CrowdStrike Falcon peut être configuré avec des règles IOA (Indicators of Attack) personnalisées ciblant les accès aux fichiers de credentials. SentinelOne propose des règles STAR (Storyline Active Response) équivalentes. Microsoft Defender for Endpoint intègre nativement la détection des accès suspects aux fichiers de credentials navigateur dans ses modèles de détection comportementale.

Un point souvent négligé est la surveillance des copies de fichiers. Les attaquants copient fréquemment les fichiers de base de données avant de les traiter, créant des copies dans des répertoires temporaires. La surveillance des opérations de copie ciblant les fichiers Login Data et Cookies (détection de la création de fichiers avec ces noms dans des emplacements inhabituels) constitue un indicateur complémentaire précieux pour les équipes de détection.

Hardening navigateur par GPO en entreprise

Le déploiement de politiques de groupe (GPO) constitue le mécanisme principal de durcissement des navigateurs en environnement Active Directory. Les templates ADMX fournis par Google (Chrome), Microsoft (Edge) et Mozilla (Firefox) permettent un contrôle granulaire des fonctionnalités de gestion de mots de passe. La politique la plus critique est la désactivation du gestionnaire de mots de passe intégré : PasswordManagerEnabled = 0 pour Chrome/Edge et signon.rememberSignons = false pour Firefox.

Au-delà de la simple désactivation, un durcissement complet inclut plusieurs politiques complémentaires. La désactivation de l'autofill des formulaires (AutofillAddressEnabled = 0, AutofillCreditCardEnabled = 0) empêche le stockage de données de paiement et d'adresses. La restriction de l'export de mots de passe (PasswordExportEnabled = 0) bloque la fonctionnalité d'export CSV. La désactivation de la synchronisation de mots de passe (SyncDisabled = 1 ou SyncTypesListDisabled = passwords) empêche la réplication des credentials vers des comptes personnels.

Pour les environnements gérés via Microsoft Intune (MDM), les mêmes politiques sont déployables via des profils de configuration. Les catégories de paramètres Intune pour Edge et Chrome (via ADMX ingestion) permettent un contrôle identique aux GPO traditionnelles, étendu aux postes non joints au domaine. La combinaison SCCM + Intune couvre les scénarios hybrides où certains postes sont on-premise et d'autres en cloud only.

Un aspect souvent négligé est la gestion des navigateurs secondaires. Déployer une GPO Chrome sans couvrir Edge, Firefox et les navigateurs portables laisse une surface d'attaque ouverte. Les politiques doivent cibler systématiquement tous les navigateurs installés, et idéalement restreindre l'installation de navigateurs non approuvés via AppLocker ou Windows Defender Application Control (WDAC). La vérification de conformité post-déploiement est essentielle : un script d'audit régulier doit vérifier que les politiques sont effectivement appliquées et qu'aucune base de credentials résiduelle n'existe sur les postes.

Comparatif des solutions de protection enterprise

Le marché offre plusieurs catégories de solutions pour protéger les credentials navigateur en entreprise. Les gestionnaires de mots de passe enterprise (1Password Business, Bitwarden Enterprise, Keeper Enterprise, Dashlane Business) constituent la première ligne de défense en remplaçant le stockage navigateur natif par un coffre-fort centralisé. Leur déploiement s'accompagne idéalement de la désactivation des gestionnaires intégrés via GPO. Ces solutions offrent des fonctionnalités d'audit (qui accède à quels credentials), de partage sécurisé et d'intégration SSO/SCIM.

Les solutions PAM (Privileged Access Management) comme CyberArk, BeyondTrust et Delinea ajoutent une couche pour les credentials à haute valeur : comptes administrateurs, comptes de service et accès à infrastructure critique. L'intégration PAM avec les navigateurs via des extensions dédiées (CyberArk Secure Browser Extension) permet l'injection de credentials sans exposition dans le gestionnaire navigateur. Les credentials ne transitent jamais par le stockage local, éliminant le risque d'extraction.

Les solutions de Browser Isolation (Menlo Security, Zscaler Browser Isolation, Cloudflare Browser Isolation) offrent une approche radicalement différente : le navigateur s'exécute dans un environnement cloud isolé, et seul le rendu visuel est transmis au poste utilisateur. Les credentials ne sont jamais stockés localement, rendant l'extraction impossible depuis le poste. Cette approche élimine également les risques liés aux vulnérabilités navigateur et aux extensions malveillantes.

Les solutions EDR avancées avec modules de credential protection (CrowdStrike Falcon Identity Protection, Microsoft Defender Credential Guard) surveillent et bloquent les tentatives d'accès aux credentials en temps réel. Credential Guard, disponible dans Windows Enterprise, isole les secrets DPAPI dans un environnement virtualisé (VSM — Virtualization-Based Security), rendant l'extraction DPAPI classique inefficace. L'évaluation de ces solutions doit considérer le coût total de possession, l'intégration avec l'infrastructure existante et l'impact sur l'expérience utilisateur.

Recommandations ANSSI et bonnes pratiques

L'Agence Nationale de la Sécurité des Systèmes d'Information (ANSSI) publie régulièrement des recommandations applicables à la protection des credentials navigateur. Le guide de durcissement des postes de travail Windows (PA-022) et les recommandations de sécurité relatives aux mots de passe (R2 à R24) fournissent un cadre de référence pour les organisations françaises. En synthèse, les recommandations clés sont les suivantes.

Niveau 1 — Mesures essentielles : Désactiver le gestionnaire de mots de passe intégré de tous les navigateurs via GPO/Intune. Déployer un gestionnaire de mots de passe enterprise avec master password fort et MFA. Former les utilisateurs à ne jamais stocker de credentials dans les navigateurs. Activer la surveillance des accès aux fichiers de credentials dans le SIEM.

Niveau 2 — Mesures avancées : Déployer Windows Credential Guard sur tous les postes compatibles (Windows Enterprise/Education). Implémenter des règles AppLocker/WDAC limitant les exécutables autorisés. Configurer l'EDR avec des règles spécifiques de détection d'accès aux credentials navigateur. Mettre en place une politique de rotation régulière des mots de passe stockés dans le gestionnaire enterprise.

Niveau 3 — Mesures renforcées : Déployer une solution de Browser Isolation pour les utilisateurs à haut risque (administrateurs, direction, finance). Implémenter le token binding (DBSC pour Google, token protection pour Microsoft) pour invalider les cookies volés. Réaliser des audits red team réguliers incluant spécifiquement l'extraction de credentials navigateur dans le périmètre. Adopter une architecture Zero Trust avec authentification continue et vérification de posture de l'appareil pour chaque accès aux ressources sensibles. Ces recommandations s'alignent avec le cadre MITRE ATT&CK pour une couverture défensive complète.

Méthodologie Red Team pour l'audit des navigateurs

L'audit de la sécurité des credentials navigateur s'intègre naturellement dans les missions de red team et de pentest. Une méthodologie structurée garantit une couverture complète et des livrables exploitables pour les équipes défensives. La phase préparatoire inclut l'inventaire des navigateurs déployés dans l'organisation (via SCCM, Intune ou requêtes AD), l'identification des politiques GPO existantes relatives aux navigateurs, et la vérification de la présence de solutions de protection (EDR, Credential Guard, PAM).

Phase d'exécution — Étape 1 : Compromission d'un poste utilisateur standard via le vecteur d'accès initial convenu (phishing, USB, accès physique). Vérification du contexte d'exécution et des privilèges disponibles. Énumération des navigateurs installés et de leurs versions. Identification des profils et des fichiers de credentials accessibles.

Étape 2 : Extraction des credentials en contexte utilisateur. Test de l'extraction Chrome/Edge via DPAPI (outils : SharpWeb, ChromeKatz). Test de l'extraction Firefox via NSS (outils : SharpWeb, firepwd.py). Test de l'extraction des cookies et tokens de session. Documentation des credentials obtenues et de leur sensibilité.

Étape 3 : Évaluation des protections. Test de détection par l'EDR (l'extraction a-t-elle déclenché une alerte ?). Vérification de la présence et de l'efficacité de l'App-Bound Encryption. Test des techniques d'évasion si l'EDR bloque l'extraction initiale. Documentation des lacunes détectées dans les couches de protection.

Étape 4 : Exploitation des credentials obtenus pour démontrer l'impact réel. Accès aux applications métier avec les credentials extraits. Démonstration de session hijacking via cookies Microsoft 365. Tentative de mouvement latéral avec les credentials AD récupérés. Le livrable final doit inclure le nombre de credentials extraits par navigateur, les applications critiques accessibles, les lacunes de détection observées et des recommandations priorisées pour la remédiation, en s'appuyant sur les références MITRE ATT&CK correspondantes.

Perspective d'expert : avenir de la protection credentials

L'avenir de la protection des credentials navigateur s'oriente vers trois axes majeurs. L'adoption massive des passkeys FIDO2 éliminera progressivement le besoin de mots de passe stockés, supprimant le vecteur d'attaque à la source. Le déploiement du token binding (Device Bound Session Credentials de Google, token protection Microsoft Entra) réduira l'impact du vol de cookies. Enfin, l'intégration de la sécurité des credentials dans les architectures Zero Trust, avec vérification continue de la posture de l'appareil, ajoutera une couche de protection contextuelle indépendante du stockage local.

Les tendances technologiques sont encourageantes mais l'inertie organisationnelle reste le frein principal. Les grandes entreprises mettent en moyenne 18 à 24 mois pour déployer une nouvelle politique de sécurité des postes de travail à l'échelle. Pendant ce temps, les attaquants continuent d'exploiter les mêmes faiblesses avec des outils toujours plus automatisés. L'intelligence artificielle générative accélère également le développement d'outils offensifs customisés, rendant l'adaptation des défenses encore plus urgente. Les RSSI doivent anticiper ces évolutions en intégrant dès maintenant les protections de prochaine génération dans leur feuille de route sécurité, tout en déployant immédiatement les mesures de base qui réduisent drastiquement l'exposition : désactivation du stockage navigateur, déploiement d'un gestionnaire enterprise, surveillance EDR ciblée.

FAQ — Questions fréquentes sur le hacking des password managers navigateurs

FAQ — Détection et protection enterprise

Conclusion

Le hacking password managers navigateurs demeure en 2026 l'une des techniques offensives les plus efficaces et les plus dévastatrices de l'arsenal cybercriminel et des équipes de red team. Cet article a démontré que l'ensemble des navigateurs majeurs — de la famille Chromium à Firefox en passant par Safari — présentent des vulnérabilités architecturales intrinsèques qui permettent l'extraction de credentials en contexte post-exploitation. Les outils offensifs, qu'ils soient intégrés aux frameworks C2 (CobaltStrike, Sliver, Havoc, Brute Ratel) ou disponibles en standalone (LaZagne, HackBrowserData, SharpWeb), automatisent cette extraction et la rendent accessible à des attaquants de tous niveaux de sophistication.

L'écosystème MaaS a transformé cette menace en phénomène de masse, avec des centaines de millions de credentials extraites mensuellement par les campagnes de stealers. Les protections introduites par les éditeurs (App-Bound Encryption, Credential Guard, token binding) élèvent progressivement le niveau de sophistication requis, mais des contournements continuent d'émerger. La conclusion opérationnelle est claire : les navigateurs ne doivent pas être utilisés comme gestionnaires de mots de passe en environnement professionnel. La combinaison de GPO de désactivation, de gestionnaire de mots de passe enterprise dédié, de surveillance EDR/SIEM ciblée et d'audits red team réguliers constitue la stratégie défensive la plus robuste. Les organisations qui investissent dans cette défense en profondeur réduisent drastiquement leur surface d'attaque et la probabilité de compromission massive de credentials.