Vol de Mots de Passe Chrome : DPAPI, Exploits et Outils

La compromission des gestionnaires de mots de passe intégrés aux navigateurs web reste un vecteur d'attaque fondamental dans presque toutes les opérations offensives modernes. Que ce soit lors d'un test d'intrusion avec cracking de mots de passe ou dans le cadre d'une campagne de diffusion d'infostealers, l'extraction des credentials stockés dans Chrome est souvent la première action post-compromission. La documentation officielle de MITRE ATT&CK T1555.003 — Credentials from Web Browsers répertorie cette technique comme l'une des plus répandues, utilisée par des dizaines de groupes APT et de familles de malware documentés. Cet article explore en profondeur chaque aspect technique de cette menace, depuis les fondations cryptographiques jusqu'aux contre-mesures opérationnelles.

Architecture de stockage des mots de passe Chrome

Google Chrome utilise une architecture de stockage relativement simple mais efficace pour persister les identifiants enregistrés par l'utilisateur. Au cœur de ce mécanisme se trouve une base de données SQLite, un moteur de base de données relationnelle embarqué, léger et ne nécessitant aucun serveur. Le fichier principal, nommé Login Data, est localisé dans le répertoire du profil utilisateur Chrome. Sous Windows, le chemin standard est %LOCALAPPDATA%\Google\Chrome\User Data\Default\Login Data. Pour macOS, il se trouve dans ~/Library/Application Support/Google/Chrome/Default/Login Data, et sous Linux dans ~/.config/google-chrome/Default/Login Data.

Cette base SQLite contient plusieurs tables, dont la plus critique est logins. Chaque ligne de cette table représente un ensemble d'identifiants sauvegardés : l'URL d'origine (origin_url), l'URL de l'action du formulaire (action_url), le nom d'utilisateur (username_value) et le mot de passe chiffré (password_value). Le mot de passe n'est jamais stocké en clair — il est chiffré avec un mécanisme qui a évolué significativement au fil des versions de Chrome, comme le montre le code source de Chromium. Le fichier Local State, situé dans %LOCALAPPDATA%\Google\Chrome\User Data\Local State, contient quant à lui la clé de chiffrement encodée en Base64 pour les versions récentes. La compréhension de cette architecture est un prérequis indispensable pour tout auditeur souhaitant évaluer les risques liés au stockage de credentials dans les navigateurs Chromium. Il faut noter que Chrome crée un verrou exclusif sur la base SQLite lorsqu'il est en cours d'exécution, ce qui empêche la lecture directe par un processus tiers — une particularité que tous les outils d'extraction doivent contourner en copiant le fichier préalablement.

Le fichier Login Data : structure SQLite détaillée

L'analyse forensique du fichier Login Data révèle une structure SQLite bien définie. La table logins est le cœur du stockage des credentials et comprend les colonnes suivantes : origin_url (TEXT), action_url (TEXT), username_element (TEXT), username_value (TEXT), password_element (TEXT), password_value (BLOB), signon_realm (TEXT), date_created (INTEGER, timestamp WebKit), blacklisted_by_user (INTEGER), et scheme (INTEGER). Le champ password_value est un BLOB binaire contenant le mot de passe chiffré.

Pour extraire les données brutes, on peut utiliser l'utilitaire sqlite3 en ligne de commande : sqlite3 "Login Data" "SELECT origin_url, username_value, hex(password_value) FROM logins;". Il faut cependant noter que Chrome verrouille ce fichier avec un lock SQLite lorsqu'il est en cours d'exécution. Les outils offensifs contournent généralement ce problème en copiant le fichier avant de l'ouvrir. Le timestamp date_created utilise l'epoch WebKit (microsecondes depuis le 1er janvier 1601), différent de l'epoch Unix. La conversion se fait par la formule : unix_timestamp = (webkit_timestamp / 1000000) - 11644473600. La table stats enregistre les statistiques d'utilisation des credentials, et sync_entities_metadata gère la synchronisation avec le compte Google. Cette connaissance approfondie du schéma est essentielle pour écrire des outils d'extraction personnalisés ou analyser les artefacts lors d'une investigation numérique.

Évolution du chiffrement Chrome : de DPAPI à AES-256-GCM

L'histoire du chiffrement des mots de passe dans Chrome se divise en deux époques distinctes. Avant la version 80 (février 2020), Chrome sous Windows utilisait directement l'API DPAPI (Data Protection Application Programming Interface) de Microsoft pour chiffrer chaque mot de passe individuellement. Chaque valeur dans password_value était un blob DPAPI que le système pouvait déchiffrer directement via l'appel CryptUnprotectData(), à condition d'exécuter le code dans le contexte de l'utilisateur propriétaire.

À partir de Chrome v80, Google a introduit une couche supplémentaire : une clé maître AES-256-GCM est générée, elle-même protégée par DPAPI, puis stockée dans le fichier Local State en JSON sous la clé os_crypt.encrypted_key. Les mots de passe sont désormais préfixés par la chaîne v10 (ou v11 sur certaines versions) suivie d'un nonce de 12 octets, du ciphertext AES-GCM et d'un tag d'authentification de 16 octets. Le processus de déchiffrement consiste donc à : (1) extraire la clé chiffrée du Local State, (2) décoder le Base64, (3) retirer le préfixe DPAPI de 5 octets, (4) appeler CryptUnprotectData() pour obtenir la clé AES en clair, puis (5) utiliser cette clé pour déchiffrer chaque mot de passe via AES-256-GCM. Cette évolution a complexifié l'extraction mais n'a pas fondamentalement changé le modèle de menace, car l'accès au contexte utilisateur reste suffisant pour déchiffrer la clé maître. Il est aussi intéressant de noter que Chrome sur Linux utilise un mécanisme différent : la clé est stockée dans le keyring GNOME ou KWallet (selon l'environnement de bureau), avec un fallback vers une clé hardcodée peanuts lorsqu'aucun keyring n'est disponible — une faiblesse historique bien connue des pentesters ciblant les environnements Linux headless ou les serveurs de développement.

Windows DPAPI : fonctionnement interne et faiblesses

La Data Protection API (DPAPI) est le mécanisme cryptographique central de Windows pour la protection des données utilisateur. Son fonctionnement repose sur deux fonctions principales : CryptProtectData() pour le chiffrement et CryptUnprotectData() pour le déchiffrement. DPAPI utilise une hiérarchie de clés dérivée du mot de passe de session Windows de l'utilisateur. Lorsqu'un utilisateur se connecte, Windows dérive une clé pré-maître à partir de son mot de passe (via PBKDF2 avec SHA-512 dans les versions récentes), qui est ensuite utilisée pour déchiffrer les Master Keys DPAPI stockées dans le profil.

Les faiblesses de DPAPI dans le contexte Chrome sont multiples. Premièrement, tout processus s'exécutant dans le contexte de l'utilisateur peut appeler CryptUnprotectData() sans authentification supplémentaire — il n'y a pas de mécanisme de contrôle d'accès au niveau applicatif. Deuxièmement, les Master Keys DPAPI ont une durée de vie de 90 jours par défaut, mais les anciennes clés sont conservées pour la rétrocompatibilité, créant un historique de clés exploitable. Troisièmement, un administrateur local ou un attaquant ayant compromis le contrôleur de domaine peut extraire les clés de backup DPAPI du domaine, permettant le déchiffrement offline de tous les blobs DPAPI de tous les utilisateurs du domaine. Cette architecture rend le passage de l'utilisateur standard à SYSTEM particulièrement dévastateur pour la confidentialité des credentials navigateur. Comme le documente la documentation officielle de Microsoft sur DPAPI, cette API a été conçue pour la facilité d'utilisation, pas pour résister à un attaquant ayant un accès local.

DPAPI Master Keys : localisation et extraction

Les Master Keys DPAPI constituent le maillon critique de la chaîne de chiffrement. Sous Windows, elles sont stockées dans le répertoire %APPDATA%\Microsoft\Protect\{SID}\ pour les clés utilisateur, et dans %SYSTEMDIR%\Microsoft\Protect\S-1-5-18\ pour les clés SYSTEM. Chaque fichier de Master Key est identifié par un GUID et contient la clé chiffrée avec le mot de passe de l'utilisateur (ou le mot de passe de la machine pour les clés SYSTEM).

L'extraction des Master Keys peut se faire de plusieurs manières selon le niveau d'accès. Avec un accès utilisateur actif, le processus lsass.exe conserve les Master Keys déchiffrées en mémoire, accessibles via des outils comme mimikatz sekurlsa::dpapi. En mode offline, il est possible d'attaquer les Master Keys par force brute si l'on connaît le SID utilisateur et qu'on dispose du fichier de Master Key — l'outil DPAPImk2john convertit les Master Keys au format John the Ripper pour le cracking. La robustesse de cette attaque dépend directement de la complexité du mot de passe Windows de l'utilisateur : un mot de passe faible expose l'ensemble des données protégées par DPAPI en quelques minutes.

En environnement Active Directory, la clé de backup DPAPI du domaine (stockée dans l'attribut ms-Bkup-Rsa-Private-Key de l'objet domaine) permet de déchiffrer toutes les Master Keys de tous les utilisateurs du domaine. Mimikatz offre cette capacité via lsadump::backupkeys /system:DC01 /export. Cette clé de backup ne change jamais durant la durée de vie du domaine, ce qui signifie qu'une seule extraction donne un accès permanent aux données DPAPI historiques et futures de tous les utilisateurs. Cette technique est particulièrement dévastatrice lors d'un mouvement latéral car une seule compromission du DC donne accès à l'ensemble des credentials navigateur de l'organisation. Les équipes défensives doivent considérer la clé de backup DPAPI comme un actif cryptographique critique, au même titre que le hash du compte KRBTGT.

Chrome v80+ : chiffrement AES-256-GCM et App-Bound Encryption

Le passage à AES-256-GCM dans Chrome v80 a introduit un modèle de chiffrement authentifié pour les credentials stockés. Le mode GCM (Galois/Counter Mode) offre simultanément la confidentialité et l'intégrité des données, empêchant les manipulations du ciphertext sans détection. Chaque entrée chiffrée dans password_value suit le format : v10 (3 octets) + nonce (12 octets) + ciphertext (longueur variable) + tag GCM (16 octets). Le nonce est unique pour chaque opération de chiffrement, garantissant qu'un même mot de passe produit un ciphertext différent à chaque enregistrement.

Plus récemment, Chrome 127 (juillet 2024) a introduit l'App-Bound Encryption sur Windows. Ce mécanisme ajoute une couche de protection supplémentaire en liant le déchiffrement de la clé au binaire signé de Chrome lui-même. Concrètement, un service Windows (GoogleChromeElevationService) chiffre la clé AES avec une clé machine liée à l'identité du processus appelant, vérifiant la signature du binaire Chrome. Cela signifie qu'un processus tiers, même exécuté sous le même utilisateur, ne peut théoriquement plus appeler directement CryptUnprotectData() pour obtenir la clé. Cependant, comme nous le verrons dans les sections suivantes, des contournements ont rapidement été documentés, notamment via l'injection dans le processus Chrome lui-même ou via le détournement du service d'élévation. L'efficacité réelle de cette protection fait encore débat dans la communauté offensive.

Extraction des mots de passe avec accès utilisateur actif

Le scénario le plus courant en pentest est l'extraction de credentials Chrome avec un accès utilisateur actif — c'est-à-dire une session Windows ouverte ou un shell obtenu dans le contexte de l'utilisateur cible. Dans ce cas, le déchiffrement est trivial car DPAPI fonctionne de manière transparente. L'attaquant doit simplement : copier le fichier Login Data (pour éviter le lock SQLite), lire la clé chiffrée depuis Local State, appeler l'API DPAPI pour déchiffrer la clé AES, puis déchiffrer chaque mot de passe.

En pratique, la commande la plus directe utilise PowerShell avec les classes .NET : [System.Security.Cryptography.ProtectedData]::Unprotect($encryptedKey, $null, 'CurrentUser'). Cette méthode ne nécessite aucun outil tiers et est souvent suffisante pour un proof-of-concept rapide. L'alternative classique est l'utilisation d'outils spécialisés qui automatisent l'ensemble du processus. Lors de mes missions de pentest, j'ai constaté que dans plus de 80 % des cas, les utilisateurs stockent des credentials sensibles dans Chrome — mots de passe de messagerie professionnelle, accès VPN, portails d'administration, et parfois même des accès à des interfaces de gestion d'infrastructure critique. La simplicité de l'extraction dans ce scénario souligne l'importance de ne jamais considérer un accès utilisateur standard comme anodin. Un seul poste compromis peut fournir des dizaines de credentials réutilisables pour le mouvement latéral dans l'infrastructure.

Outils offensifs : SharpChromium et ChromeKatz

SharpChromium est un outil offensif écrit en C# spécialement conçu pour l'extraction de données depuis les navigateurs Chromium. Développé pour être exécuté en mémoire via des frameworks C2 comme Cobalt Strike (via execute-assembly), il ne laisse pas de traces sur le disque. SharpChromium extrait les mots de passe, les cookies, l'historique de navigation et les données de formulaires. L'utilisation typique en opération Red Team est : execute-assembly SharpChromium.exe logins pour extraire uniquement les credentials, ou execute-assembly SharpChromium.exe all pour une extraction complète.

ChromeKatz, plus récent, adopte une approche différente en lisant directement la mémoire du processus Chrome pour extraire les credentials déchiffrés sans toucher aux fichiers sur le disque. Cette technique est particulièrement intéressante car elle contourne les mécanismes de protection basés sur le monitoring des accès aux fichiers Login Data et Local State. ChromeKatz fonctionne en identifiant les structures de données en mémoire du processus Chrome via la lecture de la mémoire du processus avec NtReadVirtualMemory. Son module complémentaire, CookieKatz, utilise la même approche pour les cookies. Ces outils illustrent la course permanente entre les mécanismes de défense et les techniques d'extraction : chaque nouvelle protection génère de nouvelles méthodes de contournement. En opération, je recommande d'utiliser ChromeKatz lorsque les solutions EDR surveillent activement les accès aux fichiers de profil Chrome, car l'approche mémoire génère moins d'alertes.

LaZagne : extraction multi-navigateurs automatisée

LaZagne est un outil open-source Python développé par Alessandro Zanni (AlessandroZ) qui automatise l'extraction de credentials depuis de multiples sources, dont les navigateurs Chromium. Son architecture modulaire lui permet de cibler simultanément Chrome, Firefox, les clients de messagerie, les clients Wi-Fi, les bases de données et de nombreuses autres applications stockant des mots de passe. L'exécution est simple : lazagne.exe browsers -chrome pour cibler uniquement Chrome, ou lazagne.exe all pour une extraction exhaustive de toutes les sources de credentials disponibles.

Le module Chrome de LaZagne implémente la logique complète de déchiffrement : lecture du fichier Local State, extraction et déchiffrement de la clé AES via DPAPI, copie du fichier Login Data, et déchiffrement itératif de chaque entrée. LaZagne gère automatiquement les deux formats de chiffrement (ancien DPAPI direct et nouveau AES-256-GCM). L'un de ses avantages majeurs est sa capacité à énumérer automatiquement tous les profils Chrome présents sur le système, y compris les profils secondaires souvent négligés par les attaquants moins expérimentés. En situation de pentest, LaZagne est souvent l'outil de premier choix pour un balayage rapide des credentials disponibles. Cependant, sa signature est extrêmement connue des solutions antivirus et EDR — il est détecté par la quasi-totalité des moteurs. Les opérateurs expérimentés préfèrent donc compiler une version personnalisée, obfusquer le code Python avant compilation avec PyInstaller, ou extraire uniquement les modules nécessaires pour réduire l'empreinte de détection.

Mimikatz et DPAPI : dpapi::chrome et sekurlsa

Mimikatz, l'outil emblématique de Benjamin Delpy, offre un support étendu pour l'extraction de credentials Chrome via ses modules DPAPI. La commande principale est mimikatz # dpapi::chrome /in:"C:\Users\target\AppData\Local\Google\Chrome\User Data\Default\Login Data" /unprotect qui déchiffre directement les mots de passe en utilisant le contexte DPAPI de l'utilisateur courant. Pour les versions post-v80, il faut d'abord extraire la clé maître depuis le Local State : dpapi::chrome /in:"Login Data" /masterkeyfile:mk.bin.

Le module sekurlsa::dpapi est complémentaire et permet d'extraire les Master Keys DPAPI directement depuis la mémoire du processus LSASS. Cette approche est particulièrement puissante car elle donne accès aux Master Keys de tous les utilisateurs connectés sur la machine, pas uniquement l'utilisateur courant. La séquence typique en opération est : privilege::debug pour obtenir le privilège SeDebugPrivilege, puis sekurlsa::dpapi pour dumper les Master Keys, et enfin dpapi::chrome avec les clés extraites pour déchiffrer les credentials de chaque profil. Mimikatz supporte également le déchiffrement offline via dpapi::masterkey /in:{GUID} /rpc qui contacte le contrôleur de domaine pour déchiffrer une Master Key en utilisant la clé de backup du domaine. Ce processus est documenté dans la chaîne MITRE ATT&CK comme technique courante des groupes APT ciblant les environnements Active Directory.

HackBrowserData : outil cross-platform

HackBrowserData est un outil open-source écrit en Go qui se distingue par sa compatibilité cross-platform et son support étendu des navigateurs. Contrairement à de nombreux outils limités à Windows, HackBrowserData fonctionne sur Windows, macOS et Linux. Il cible l'ensemble des navigateurs Chromium (Chrome, Edge, Brave, Opera, Vivaldi, Yandex) ainsi que Firefox. L'exécution est directe : hack-browser-data.exe -b chrome -p passwords pour extraire uniquement les mots de passe Chrome, avec export possible en JSON, CSV ou console.

Sur macOS, l'extraction des mots de passe Chrome nécessite la récupération de la clé "Chrome Safe Storage" depuis le Keychain. HackBrowserData automatise cette étape en invoquant security find-generic-password -wa "Chrome", bien que cela déclenche une invite de mot de passe administrateur. Sur Linux, Chrome utilise le keyring GNOME ou kwallet pour stocker la clé, et HackBrowserData gère ces deux backends. L'outil produit des rapports structurés particulièrement utiles pour les audits, avec des fichiers séparés pour chaque type de données (mots de passe, cookies, historique, bookmarks, cartes de crédit). En environnement d'audit, je l'utilise régulièrement car il offre un bon compromis entre facilité d'utilisation et exhaustivité des données extraites. Sa compilation en binaire Go statique facilite le déploiement sans dépendances, et sa taille relativement modeste (quelques Mo) le rend pratique pour le transfert sur les systèmes cibles lors des missions offensives. L'outil gère aussi l'extraction des données de remplissage automatique des formulaires et des cartes de crédit stockées dans la base Web Data, élargissant le spectre des données sensibles récupérables.

Extraction via Python : scripts personnalisés

L'écriture de scripts Python personnalisés pour l'extraction de credentials Chrome reste une compétence fondamentale pour tout pentester. Un script minimal nécessite les bibliothèques sqlite3 (standard), json (standard), base64 (standard), win32crypt (module pywin32) et Cryptodome pour AES-GCM. La logique de base consiste à ouvrir le fichier Local State, extraire la clé sous os_crypt.encrypted_key, la décoder en Base64, retirer les 5 premiers octets (DPAPI), puis appeler win32crypt.CryptUnprotectData() pour obtenir la clé AES en clair.

Ensuite, pour chaque entrée de la table logins, on extrait le password_value, on vérifie le préfixe v10/v11, on sépare le nonce (octets 3 à 15), le ciphertext et le tag (16 derniers octets), puis on déchiffre avec AES.new(key, AES.MODE_GCM, nonce=nonce).decrypt_and_verify(ciphertext, tag). Les avantages du script personnalisé sont nombreux : contrôle total sur la logique, possibilité d'ajouter des filtres (par domaine, par date), export dans des formats spécifiques, et surtout une empreinte de détection beaucoup plus faible qu'un outil connu. Dans mes missions, je maintiens un script d'extraction personnalisé que je modifie pour chaque engagement, changeant les noms de variables, la structure du code et les méthodes d'appel API pour éviter les signatures statiques. Cette approche est bien plus efficace que d'utiliser des outils publics facilement détectés par les EDR modernes.

Exploitation sans accès interactif : techniques post-exploitation

L'extraction de credentials Chrome sans session interactive représente un défi supplémentaire, courant dans les scénarios de compromission via webshell, reverse shell limité ou accès via service compromis. Le principal obstacle est que DPAPI nécessite le contexte utilisateur pour fonctionner. Plusieurs techniques permettent de contourner cette limitation. La première est l'impersonation de token : si l'attaquant a un accès SYSTEM, il peut usurper le token de l'utilisateur cible via ImpersonateLoggedOnUser() puis appeler DPAPI dans ce contexte.

La deuxième technique utilise les Master Keys DPAPI extraites précédemment. Avec les Master Keys en clair (obtenues via LSASS dump ou backup domain key), le déchiffrement peut se faire entièrement offline sans aucun appel à l'API Windows. L'outil dpapi.py d'Impacket implémente cette capacité : dpapi.py unprotect -file blob.bin -key {masterkey_hex}. La troisième approche exploite les tâches planifiées ou les services Windows pour exécuter un processus d'extraction dans le contexte de l'utilisateur cible. On crée une tâche planifiée exécutant le script d'extraction avec les droits de l'utilisateur propriétaire des credentials : schtasks /create /tn "Update" /tr "cmd /c extraction.exe > output.txt" /sc once /st 00:00 /ru TARGET_USER. Chaque technique a ses avantages et ses inconvénients en termes de discrétion et de fiabilité, et le choix dépend du contexte opérationnel et des défenses en place.

Vol de cookies et tokens de session Chrome

Au-delà des mots de passe, les cookies de session stockés par Chrome représentent souvent une cible encore plus précieuse. Un cookie de session valide permet de bypasser complètement l'authentification, y compris l'authentification multi-facteurs (MFA), car le cookie prouve que l'authentification a déjà eu lieu. Le fichier Cookies suit la même structure que Login Data — c'est une base SQLite avec une table cookies contenant les champs host_key, name, encrypted_value, path, expires_utc, et is_httponly.

Le chiffrement des cookies utilise exactement le même mécanisme que les mots de passe : la même clé AES-256-GCM extraite du Local State. Les cookies particulièrement intéressants pour un attaquant sont les cookies de session des applications SaaS (Office 365, Google Workspace, Salesforce), les tokens OAuth stockés comme cookies, et les cookies d'authentification des interfaces d'administration. L'attaque dite de "pass-the-cookie" consiste à injecter ces cookies dans un navigateur contrôlé par l'attaquant pour reprendre la session de la victime. Les stealers comme RedLine et Raccoon extraient systématiquement les cookies en plus des mots de passe, car la revente de cookies de session actifs est devenue un marché florissant dans l'économie souterraine. La durée de validité variable des cookies (de quelques heures à plusieurs mois selon l'application) rend cette technique plus volatile mais souvent plus immédiatement exploitable que le vol de mots de passe.

Exploitation des profils Chrome multiples

Chrome supporte les profils multiples, chacun ayant sa propre instance du fichier Login Data. Les profils sont stockés dans des sous-répertoires du répertoire User Data : Default pour le profil principal, puis Profile 1, Profile 2, etc. Un utilisateur peut avoir un profil personnel et un profil professionnel, chacun contenant des credentials différents. Les outils d'extraction naïfs ne ciblent souvent que le profil Default, manquant potentiellement les credentials les plus sensibles stockés dans les profils secondaires.

L'énumération des profils se fait en listant les répertoires correspondant au pattern Profile * dans le répertoire User Data, ou en analysant le fichier Local State qui contient un objet JSON profile.info_cache listant tous les profils avec leurs métadonnées (nom, avatar, adresse email associée). Un script d'extraction robuste doit itérer sur tous les profils disponibles. Il est crucial de noter que tous les profils partagent la même clé de chiffrement AES (stockée dans le Local State commun), ce qui simplifie l'extraction multi-profils. En environnement d'entreprise, j'ai observé des utilisateurs avec 3 à 5 profils distincts, incluant des profils liés à des comptes de service ou des comptes administratifs. La découverte de ces profils secondaires lors d'un audit peut révéler des credentials à haut privilège que l'utilisateur pensait isolés de son profil principal.

Attaques sur Chrome Sync et Google Account

La fonctionnalité Chrome Sync synchronise les mots de passe, cookies, historique et extensions entre tous les appareils associés à un compte Google. Lorsqu'un attaquant compromet un compte Google (via phishing, credential stuffing, ou extraction de tokens OAuth), il peut potentiellement accéder aux mots de passe synchronisés depuis n'importe quel appareil. Chrome Sync utilise un chiffrement supplémentaire : les données sont chiffrées côté client avec une passphrase de synchronisation (par défaut, les credentials Google) avant d'être envoyées aux serveurs Google.

L'attaque la plus directe consiste à utiliser le token OAuth du compte Google compromis pour accéder à l'API Google Password Manager via passwords.google.com. Si l'utilisateur a activé la synchronisation sans passphrase personnalisée, Google stocke les clés de déchiffrement et les mots de passe sont accessibles via l'interface web après authentification. Les stealers modernes ciblent spécifiquement les tokens de session Google Chrome en extrayant les cookies SSID, HSID, SID et APISID du domaine .google.com. Avec ces cookies, l'attaquant peut accéder au compte Google complet, y compris le gestionnaire de mots de passe en ligne. Cette technique élargit considérablement la surface d'attaque : au lieu de compromettre un seul appareil, l'attaquant obtient potentiellement les credentials de tous les appareils synchronisés, ce qui en fait une des techniques les plus dévastatrices documentées dans les campagnes d'infostealers actuelles.

CVE notables ciblant le password manager Chrome

Plusieurs CVE ont directement impacté la sécurité du gestionnaire de mots de passe Chrome. CVE-2023-4863, une vulnérabilité de heap buffer overflow dans la bibliothèque libwebp, a été exploitée in the wild pour exécuter du code arbitraire dans le processus renderer Chrome, potentiellement donnant accès aux données du navigateur. CVE-2024-0519, une vulnérabilité de type out-of-bounds memory access dans le moteur V8, a été activement exploitée et pouvait être chaînée avec d'autres vulnérabilités pour compromettre l'ensemble du navigateur, y compris l'accès aux credentials stockés.

Plus spécifiquement lié au stockage des mots de passe, CVE-2021-30566 concernait une faille dans la gestion des suggestions d'autocomplétion qui pouvait exposer des informations de credentials. CVE-2020-6452 affectait la gestion de la mémoire lors de l'accès aux credentials stockés. Des vulnérabilités dans les extensions Chrome ont également été exploitées pour voler des mots de passe : CVE-2023-32784, bien que ciblant KeePass, illustre comment un processus local peut extraire des secrets de la mémoire d'un gestionnaire de mots de passe. Les chercheurs ont également démontré des attaques de type Spectre (CVE-2017-5753) capables de lire la mémoire cross-site dans le contexte du navigateur, compromettant potentiellement les credentials remplis automatiquement. La tendance montre une augmentation constante des vulnérabilités ciblant les navigateurs comme vecteur d'accès aux credentials, renforçant la nécessité d'un patching rapide et d'une stratégie de défense en profondeur. Les équipes de réponse à incident doivent maintenir une veille active sur les CVE affectant les composants de stockage de credentials des navigateurs Chromium et intégrer ces informations dans leur processus de gestion des correctifs prioritaires.

RedLine Stealer : analyse de la chaîne d'extraction Chrome

RedLine Stealer est l'un des infostealers les plus prolifiques depuis 2020, et son module d'extraction Chrome illustre parfaitement les techniques utilisées par les malwares modernes. Après exécution, RedLine crée une copie du processus dans un répertoire temporaire, puis énumère les installations de navigateurs Chromium en vérifiant les chemins connus pour Chrome, Edge, Opera, Brave et Vivaldi. Pour chaque navigateur détecté, il copie les fichiers Login Data, Cookies, Web Data (cartes de crédit) et Local State dans un répertoire de travail.

L'analyse par rétro-ingénierie de RedLine révèle qu'il implémente nativement le déchiffrement AES-256-GCM en C#, sans dépendance externe. Le code utilise ProtectedData.Unprotect() du framework .NET pour le déchiffrement DPAPI de la clé maître, puis AesGcm pour le déchiffrement des credentials individuels. RedLine gère également l'ancien format DPAPI direct pour assurer la compatibilité avec les anciennes versions de Chrome. Les données extraites sont encodées en Base64, compressées, puis exfiltrées vers le C2 via HTTP POST. Une caractéristique notable de RedLine est sa capacité à extraire les données même lorsque Chrome est en cours d'exécution, en utilisant des techniques de contournement du lock SQLite comme la copie shadow du fichier via l'API Volume Shadow Copy ou simplement la copie du fichier avec les handles partagés.

Raccoon et Vidar : variantes d'extraction Chromium

Raccoon Stealer (v2, aussi connu sous le nom RecordBreaker) et Vidar représentent deux autres familles majeures de stealers ciblant les navigateurs Chromium. Raccoon v2, réécrit en C/C++ après le démantèlement de la v1, adopte une approche modulaire : le payload initial est léger et télécharge les bibliothèques nécessaires (sqlite3.dll, nss3.dll pour Firefox) depuis son infrastructure C2. Cette technique de chargement dynamique réduit la taille initiale du malware et complique l'analyse statique, car les modules critiques ne sont pas présents dans le binaire original.

Vidar, issu d'un fork d'Arkei Stealer, se distingue par sa configuration distante : le stealer télécharge sa configuration depuis un profil sur des plateformes sociales (Telegram, Steam, Mastodon) contenant l'adresse du vrai C2, une technique d'obfuscation d'infrastructure connue sous le nom de "dead drop resolver". Pour l'extraction Chrome, Vidar suit le même schéma que RedLine mais utilise les DLL SQLite téléchargées dynamiquement pour parser les bases de données. Les deux familles ciblent également les extensions de portefeuilles de cryptomonnaies (MetaMask, Phantom, Trust Wallet) en cherchant les données des extensions dans %LOCALAPPDATA%\Google\Chrome\User Data\Default\Local Extension Settings\. En 2023, les pertes liées au vol de wallets crypto via des infostealers ont dépassé 300 millions de dollars selon les estimations de Chainalysis, faisant de cette fonctionnalité un vecteur de monétisation directe pour les opérateurs de stealers. L'économie des stealers-as-a-service (SaaS criminel) rend ces outils accessibles pour quelques centaines de dollars par mois, démocratisant l'accès aux techniques avancées d'extraction de credentials navigateur pour des acteurs avec un faible niveau technique.

Lumma Stealer : techniques d'évasion avancées

Lumma Stealer (aussi appelé LummaC2) représente l'évolution la plus récente et la plus sophistiquée des infostealers ciblant Chrome. Développé en C, distribué en tant que Malware-as-a-Service (MaaS), Lumma intègre des techniques d'évasion avancées qui le distinguent de ses prédécesseurs. Sa première technique notable est le contournement de l'App-Bound Encryption de Chrome 127+ : Lumma déchiffre la clé protégée en injectant du code directement dans le processus chrome.exe lui-même, exploitant le fait que Chrome, en tant que processus légitime et signé, a accès à ses propres clés.

Lumma implémente également des techniques anti-analyse sophistiquées : vérification de la résolution d'écran (rejet des résolutions typiques de sandbox comme 800x600), contrôle de la présence de debuggers via NtQueryInformationProcess, détection des environnements virtualisés par interrogation du registre matériel, et mesure du temps d'exécution pour détecter le single-stepping. Pour l'extraction Chrome, Lumma utilise une approche hybride : il tente d'abord la méthode standard (copie fichier + DPAPI), et en cas d'échec (App-Bound Encryption), bascule sur l'injection mémoire. Les versions récentes de Lumma incluent également un module de restauration de cookies expirés en manipulant les tokens de rafraîchissement Google, une technique particulièrement innovante qui permet de prolonger la durée d'utilité des données volées. L'analyse de Lumma et de ses pairs montre une professionnalisation croissante du développement malveillant.

Navigateurs Chromium : Edge, Brave, Opera, Vivaldi

Tous les navigateurs basés sur le moteur Chromium partagent fondamentalement la même architecture de stockage des mots de passe, rendant les techniques d'extraction transposables avec des ajustements mineurs. Microsoft Edge stocke ses données dans %LOCALAPPDATA%\Microsoft\Edge\User Data\, utilisant le même format SQLite et le même chiffrement AES-256-GCM. Brave utilise %LOCALAPPDATA%\BraveSoftware\Brave-Browser\User Data\, Opera est dans %APPDATA%\Opera Software\Opera Stable\, et Vivaldi dans %LOCALAPPDATA%\Vivaldi\User Data\.

Les différences entre ces navigateurs sont principalement cosmétiques du point de vue de l'extraction. Le fichier Local State et la clé os_crypt.encrypted_key existent dans chaque navigateur. Brave ajoute cependant une couche de protection supplémentaire en chiffrant certaines données avec une clé dérivée du mot de passe Brave Sync, si celui-ci est configuré. Opera intègre un VPN et un portefeuille crypto dont les credentials constituent des cibles supplémentaires. Edge, en tant que navigateur par défaut de Windows, est particulièrement intéressant car il est souvent utilisé par les administrateurs systèmes et contient fréquemment des credentials d'accès aux portails d'administration cloud (Azure, M365 Admin). Un script d'extraction complet doit énumérer tous les navigateurs Chromium installés en parcourant les répertoires connus et le registre Windows, pour ne manquer aucune source de credentials. L'article compagnon sur le hacking des gestionnaires de mots de passe multi-navigateurs approfondit ces différences.

App-Bound Encryption Windows : contournements documentés

L'App-Bound Encryption introduite dans Chrome 127 a été présentée par Google comme une avancée majeure dans la protection des credentials stockés. Le mécanisme utilise le service GoogleChromeElevationService qui fonctionne avec les privilèges SYSTEM pour chiffrer et déchiffrer les clés de manière liée à l'identité de l'application Chrome. En théorie, seul un processus Chrome signé par Google peut demander le déchiffrement de la clé via ce service, empêchant les outils tiers d'accéder aux credentials.

Cependant, plusieurs contournements ont été rapidement documentés par la communauté sécurité. Le premier exploite l'injection de DLL dans le processus Chrome : en chargeant une DLL malveillante dans chrome.exe (via DLL side-loading ou injection de thread distant), le code s'exécute dans le contexte du processus Chrome signé et peut légitimement demander le déchiffrement. Le deuxième contournement cible le service d'élévation lui-même : avec des privilèges administrateur, il est possible de remplacer ou modifier le binaire Chrome par un binaire instrumenté qui exporte les clés déchiffrées. Un troisième vecteur exploite le fait que Chrome utilise des IPC (Inter-Process Communication) pour communiquer avec le service d'élévation — en interceptant ces communications, il est possible de récupérer la clé déchiffrée. Alexander Hagenah a publié l'outil "Chrome-App-Bound-Encryption-Decryption" démontrant un contournement fonctionnel. Ces contournements illustrent un principe fondamental en sécurité : une protection basée sur l'identité du processus est intrinsèquement fragile face à un attaquant ayant un contrôle local sur la machine.

Attaque par déchiffrement offline des Master Keys DPAPI

Le déchiffrement offline des Master Keys DPAPI représente une technique avancée permettant de récupérer les credentials Chrome sans jamais exécuter de code sur la machine cible après l'exfiltration initiale des fichiers nécessaires. Les fichiers requis sont : le fichier Login Data, le fichier Local State, les fichiers de Master Keys DPAPI (depuis %APPDATA%\Microsoft\Protect\{SID}\) et, idéalement, le hash NTLM ou le mot de passe en clair de l'utilisateur.

L'outil dpapi.py d'Impacket permet le déchiffrement complet offline. La séquence est la suivante : d'abord, convertir le hash NTLM en clé de déchiffrement DPAPI via dpapi.py masterkey -file {GUID} -sid {SID} -password {password} ou avec le hash NT : -nthash {hash}. Si ni le mot de passe ni le hash ne sont disponibles, mais que la clé de backup du domaine a été extraite (via secretsdump.py sur le DC), on peut utiliser : dpapi.py masterkey -file {GUID} -pvk domain_backup.pvk. Une fois la Master Key déchiffrée, on procède au déchiffrement de la clé AES du Local State, puis au déchiffrement de chaque password_value. Cette technique est particulièrement utile lors d'opérations où la persistance sur le poste n'est pas souhaitable ou lorsque l'accès initial était éphémère (exploitation d'une vulnérabilité avec exfiltration rapide des fichiers critiques). Elle est aussi employée en forensique lors de l'analyse de disques saisis dans le cadre d'investigations judiciaires.

Extraction depuis les sauvegardes et Shadow Copies

Les Volume Shadow Copies (VSS) de Windows et les sauvegardes systèmes représentent une source souvent négligée de credentials Chrome. Les Shadow Copies sont des instantanés automatiques du système de fichiers, créés par Windows lors des mises à jour, des installations de logiciels ou par des politiques de sauvegarde. Ces copies contiennent des versions antérieures des fichiers Login Data et Local State qui peuvent contenir des credentials qui ont été supprimés du profil actif.

L'accès aux Shadow Copies nécessite des privilèges administrateur et se fait via vssadmin list shadows pour énumérer les copies disponibles, puis accès au volume shadow via le chemin \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy{N}\. La commande mklink /d C:\shadow \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\ crée un lien symbolique pour naviguer facilement dans le snapshot. En contexte de pentest, j'ai découvert dans des Shadow Copies des fichiers Login Data datant de plusieurs mois contenant des mots de passe qui n'étaient plus dans le profil actif — notamment des credentials d'anciens prestataires ayant eu temporairement accès au poste. Les sauvegardes réseau (NAS, sauvegardes d'image système) sont également des cibles intéressantes. Les fichiers de backup Windows (.vhdx, .wim) peuvent être montés et analysés offline. Cette technique s'intègre dans une approche plus large de persistance et d'exploitation des artefacts Windows souvent méconnue des équipes défensives.

Détection : journalisation et monitoring des accès

La détection des tentatives d'extraction de credentials Chrome repose sur plusieurs couches de monitoring. La première couche est le monitoring des accès aux fichiers critiques via Windows Event Log ou des solutions EDR. Les fichiers à surveiller sont : Login Data, Cookies, Local State et les fichiers de Master Keys DPAPI. L'événement Windows Security 4663 (Object Access) avec l'audit activé sur ces fichiers permet de détecter tout accès non autorisé. La règle de détection clé est : tout processus autre que chrome.exe (ou le navigateur légitime correspondant) accédant à Login Data est suspect.

La deuxième couche concerne le monitoring des appels API. Les appels à CryptUnprotectData() depuis des processus non-navigateurs doivent déclencher des alertes. Sysmon, avec une configuration appropriée, peut capturer ces événements. Les solutions EDR modernes (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint) intègrent des règles de détection spécifiques pour l'accès aux fichiers de profil navigateur. La troisième couche est l'analyse comportementale : un processus qui copie Login Data puis effectue des requêtes SQLite est hautement suspect. Les règles Sigma pour la détection DPAPI abuse sont disponibles dans le repository SigmaHQ. En SIEM, une corrélation entre accès au fichier Login Data, appel DPAPI et communication réseau sortante dans une fenêtre de temps courte constitue un indicateur fort de compromission par un stealer.

Contre-mesures : GPO, EDR et bonnes pratiques

La protection contre le vol de mots de passe Chrome nécessite une approche de défense en profondeur combinant mesures techniques et organisationnelles. Au niveau des Group Policy Objects (GPO), plusieurs politiques sont directement applicables : désactiver l'enregistrement de mots de passe dans Chrome via PasswordManagerEnabled = false, forcer l'utilisation d'un gestionnaire de mots de passe d'entreprise (CyberArk, 1Password Business, Bitwarden Enterprise), et restreindre les extensions Chrome via allowlist. La politique BrowserSigninMode = 0 empêche la synchronisation des credentials avec les comptes Google personnels.

Au niveau des solutions EDR, les règles de protection doivent cibler spécifiquement les patterns d'extraction : alerter sur l'accès au fichier Login Data par un processus non-Chrome, bloquer les appels DPAPI depuis des processus non signés ou non whitelistés, et détecter les copies massives de fichiers de profil navigateur. Les bonnes pratiques incluent également : l'activation de l'App-Bound Encryption (Chrome 127+), la mise en place d'une rotation régulière des mots de passe critiques, le déploiement systématique du MFA sur tous les accès sensibles (réduisant la valeur des mots de passe volés), et la sensibilisation des utilisateurs à ne pas stocker de credentials dans le navigateur. Le déploiement de Windows Credential Guard peut protéger les clés DPAPI en mémoire contre l'extraction via LSASS dump, bien que cela ne protège pas contre les techniques basées sur le contexte utilisateur actif.

Comparatif des outils d'extraction Chrome

Le choix de l'outil d'extraction dépend du contexte opérationnel, des contraintes de discrétion et de l'environnement cible. Le tableau suivant synthétise les caractéristiques des principaux outils disponibles pour l'extraction de credentials Chrome, permettant aux opérateurs Red Team de choisir l'outil le plus adapté à chaque situation.

Les critères de sélection principaux sont la discrétion face aux EDR, la compatibilité avec les frameworks C2 (exécution en mémoire via execute-assembly ou inline-execute), et la capacité à gérer les dernières protections comme l'App-Bound Encryption. En opération, je recommande ChromeKatz pour les environnements hautement surveillés, SharpChromium pour les opérations Cobalt Strike standard, et un script Python personnalisé pour les audits nécessitant un rapport détaillé avec export structuré.

Implications MITRE ATT&CK et chaîne de kill

L'extraction de credentials Chrome s'inscrit dans un cadre plus large documenté par le framework MITRE ATT&CK. La technique principale est T1555.003 — Credentials from Password Stores: Credentials from Web Browsers, classée dans la tactique "Credential Access". Mais la chaîne complète implique de nombreuses autres techniques : T1083 (File and Directory Discovery) pour l'énumération des profils navigateur, T1005 (Data from Local System) pour la collecte des fichiers, T1140 (Deobfuscate/Decode Files) pour le déchiffrement des credentials, et T1041 (Exfiltration Over C2 Channel) pour l'exfiltration.

Dans le contexte d'une kill chain complète, l'extraction Chrome intervient typiquement après l'accès initial (phishing, exploitation de vulnérabilité) et la persistance, mais avant le mouvement latéral. Les credentials récupérés alimentent directement les techniques de mouvement latéral : T1021.001 (Remote Desktop Protocol) avec les mots de passe VPN ou RDP découverts, T1021.006 (Windows Remote Management) avec les credentials administratifs, et T1078 (Valid Accounts) pour l'utilisation de comptes légitimes dans la progression de l'attaque. Les groupes APT documentés utilisant cette technique incluent APT33, APT41, Lazarus Group, FIN7 et de nombreux opérateurs de ransomware. La cartographie MITRE ATT&CK complète de cette menace permet aux équipes défensives de mettre en place des détections à chaque étape de la chaîne, plutôt que de se concentrer uniquement sur la protection des fichiers de credentials eux-mêmes.

Recommandations pour les équipes Red Team

Les équipes Red Team doivent intégrer l'extraction de credentials navigateur comme une étape systématique de leurs opérations post-exploitation. Voici les recommandations opérationnelles issues de centaines de missions : premièrement, toujours énumérer tous les navigateurs Chromium installés, pas uniquement Chrome — Edge est souvent négligé malgré sa prévalence en environnement corporate. Deuxièmement, ne pas oublier les profils multiples, qui contiennent fréquemment des credentials de comptes différents et potentiellement plus privilégiés.

Troisièmement, adapter l'outil au contexte défensif : dans un environnement fortement surveillé par un EDR, privilégier ChromeKatz (approche mémoire) ou un script inline-execute personnalisé plutôt que des outils connus comme LaZagne ou Mimikatz. Quatrièmement, extraire les cookies en plus des mots de passe — les cookies de session MFA-authenticated sont souvent plus précieux que les mots de passe eux-mêmes pour un accès immédiat. Cinquièmement, cibler les données de synchronisation Chrome : si un compte Google est récupéré, les credentials de tous les appareils synchronisés deviennent accessibles. Sixièmement, documenter chaque credential découvert dans un format structuré pour faciliter la phase de mouvement latéral. Septièmement, vérifier les Shadow Copies et les sauvegardes pour des credentials historiques qui pourraient donner accès à des systèmes où les mots de passe actuels ont été changés mais où d'anciens credentials sont encore valides. Enfin, toujours corréler les credentials découverts avec les techniques de password spraying pour maximiser l'impact de la collecte.

Retour d'expérience terrain et avis d'expert

Scénarios d'attaque avancés et chaînage de techniques

Les attaquants sophistiqués ne se limitent pas à l'extraction simple des credentials Chrome. Ils chaînent plusieurs techniques pour maximiser l'impact. Un scénario courant commence par un accès initial via phishing avec un document malveillant qui déploie un loader en mémoire. Ce loader exécute un stealer optimisé qui extrait simultanément les credentials de tous les navigateurs, les tokens de session, les clés SSH depuis %USERPROFILE%\.ssh\, et les fichiers de configuration d'outils comme FileZilla, WinSCP ou PuTTY.

Le chaînage avec d'autres techniques post-exploitation est particulièrement efficace. Les credentials Chrome extraits alimentent des attaques de credential stuffing automatisées contre les portails web internes non encore compromis. Les cookies de session Google permettent d'accéder à Google Workspace et de pivoter vers les environnements cloud GCP. Les mots de passe de messagerie Outlook récupérés dans Chrome permettent de configurer des règles de redirection de mail pour maintenir un accès persistant aux communications internes. Dans les cas les plus avancés, les attaquants utilisent les credentials bancaires stockés dans Chrome pour des transferts frauduleux, ou les accès aux plateformes de gestion de domaines pour détourner des enregistrements DNS. Cette interconnexion des données volées illustre pourquoi le vol de credentials navigateur est rarement un objectif isolé — c'est un catalyseur pour l'ensemble de la chaîne d'attaque, un point pivot qui démultiplie les possibilités de l'attaquant.

Analyse forensique post-incident des artefacts Chrome

L'analyse forensique des artefacts Chrome après un incident de vol de credentials suit un processus structuré. L'analyste doit d'abord préserver les fichiers critiques du profil Chrome : Login Data, Login Data-journal (journal WAL SQLite), Cookies, Local State, History, Web Data et les fichiers de préférences. Le fichier Login Data-journal est particulièrement important car il peut contenir des entrées supprimées de la base principale, récupérables par analyse du journal de transactions SQLite.

L'horodatage des accès aux fichiers est crucial pour établir la timeline de l'incident. Les timestamps NTFS (création, modification, accès, MFT entry modification) du fichier Login Data révèlent quand le dernier accès suspect a eu lieu. L'analyse du History SQLite permet de corréler les activités de navigation de l'attaquant. Le fichier Preferences en JSON contient des informations sur les extensions installées — certains stealers installent temporairement des extensions malveillantes pour accéder aux données du navigateur via l'API chrome.storage. L'analyse des journaux Windows (événements 4663 si l'audit est activé, journaux Sysmon événements 1, 11 et 23) permet de reconstituer la séquence d'actions du malware. Les artefacts mémoire du processus Chrome, capturés via un dump mémoire complet, peuvent révéler des credentials en clair et les clés de déchiffrement. La combinaison de ces sources forensiques permet de déterminer précisément quels credentials ont été compromis et d'informer la réponse à incident.

Impact sur les environnements cloud et SaaS

Le vol de credentials Chrome a un impact disproportionné sur les environnements cloud et SaaS, car ces plateformes sont principalement accessibles via le navigateur web. Les credentials stockés dans Chrome incluent typiquement les accès aux consoles d'administration cloud (AWS Management Console, Azure Portal, GCP Console), aux plateformes de collaboration (Microsoft 365, Google Workspace, Slack), aux outils DevOps (GitHub, GitLab, Jenkins, Jira) et aux solutions de sécurité elles-mêmes (SIEM, EDR, firewall management).

La compromission de ces credentials cloud est particulièrement dévastatrice car elle permet souvent un accès direct à des données sensibles sans nécessiter de mouvement latéral réseau traditionnel. Un attaquant récupérant les credentials Azure d'un administrateur peut immédiatement accéder aux abonnements Azure, aux bases de données, aux secrets stockés dans Azure Key Vault, et potentiellement à toute l'infrastructure cloud de l'organisation. Les cookies de session OAuth sont encore plus dangereux : un cookie valide pour la console AWS permet un accès complet sans MFA, car l'authentification a déjà été validée. Cette réalité rend le vol de credentials navigateur particulièrement critique pour les organisations ayant adopté le modèle cloud-first. Les équipes sécurité doivent intégrer cette menace dans leur évaluation des risques cloud et mettre en place des contrôles compensatoires comme les Conditional Access Policies, le monitoring des connexions depuis de nouveaux appareils, et la limitation des durées de session.

Questions fréquentes sur le vol de mots de passe Chrome

Les questions suivantes couvrent les interrogations les plus courantes que nous recevons de la part des professionnels de la sécurité, des administrateurs systèmes et des utilisateurs concernés par la protection de leurs credentials navigateur. Les réponses s'appuient sur notre expérience terrain et les données techniques analysées tout au long de cet article.

Bonnes pratiques et alternatives au stockage navigateur

Techniques d'extraction discrètes et synchronisation

Automatisation de l'extraction à grande échelle en environnement Active Directory

Dans le cadre d'opérations Red Team ciblant des environnements Active Directory de grande envergure (plusieurs milliers de postes), l'extraction manuelle des credentials Chrome poste par poste est impraticable. Les opérateurs doivent mettre en place des stratégies d'automatisation pour maximiser la collecte tout en minimisant la détection. L'approche la plus courante utilise un framework C2 (Cobalt Strike, Sliver, Havoc) avec des scripts d'extraction déployés automatiquement sur chaque poste compromis via des mécanismes de post-exploitation scripté.

La collecte centralisée se fait généralement en deux phases. La première phase consiste à exfiltrer les fichiers bruts (Login Data, Local State, Master Keys DPAPI) de chaque poste vers un serveur de collection contrôlé par l'attaquant. Cette exfiltration utilise des canaux existants du C2 pour éviter de créer des connexions réseau additionnelles. La deuxième phase effectue le déchiffrement offline centralisé, soit avec les Master Keys extraites via LSASS dump sur chaque poste, soit globalement en utilisant la clé de backup DPAPI du domaine. Des scripts comme DonPAPI (Don't Put Passwords in AD) automatisent cette collecte à l'échelle du domaine via CrackMapExec ou NetExec : nxc smb 10.0.0.0/24 -u admin -p password -M donpapi. Cette approche permet de collecter en quelques heures l'intégralité des credentials navigateur de milliers de postes, produisant des bases de données de credentials qui alimentent directement les phases suivantes de l'opération.

Protections macOS et Linux : spécificités de la chaîne de déchiffrement

Si Windows et DPAPI concentrent l'essentiel des attaques documentées, les implémentations macOS et Linux de Chrome présentent leurs propres vulnérabilités. Sur macOS, Chrome stocke sa clé de chiffrement dans le Keychain système sous le nom "Chrome Safe Storage". L'accès à cette entrée nécessite une autorisation de l'utilisateur (dialogue de confirmation), mais un attaquant avec un accès root peut contourner cette restriction en accédant directement au fichier Keychain (~/Library/Keychains/login.keychain-db) et en le déchiffrant offline avec le mot de passe de l'utilisateur via l'outil chainbreaker.

Sur Linux, la situation est variable selon l'environnement de bureau. Avec GNOME et le Secret Service API, Chrome stocke la clé dans le keyring GNOME, protégée par le mot de passe de session de l'utilisateur. Le keyring est déchiffré automatiquement à la connexion de l'utilisateur, rendant la clé accessible à tout processus de la session. Avec KDE et KWallet, le mécanisme est similaire. En l'absence de keyring (serveurs headless, conteneurs, sessions SSH sans D-Bus), Chrome utilise un fallback avec une clé dérivée de la chaîne statique peanuts — un choix de design qui rend le chiffrement purement symbolique dans ces environnements. L'extraction sur Linux se fait via secretstorage en Python ou directement via D-Bus : dbus-send --session --dest=org.freedesktop.secrets. Les pentesters ciblant des environnements de développement Linux ou des postes de travail macOS doivent adapter leurs outils et techniques à ces spécificités.

Conclusion

Le vol de mots de passe Chrome demeure une menace majeure et persistante dans le paysage de la cybersécurité moderne. Malgré les améliorations successives apportées par Google — migration vers AES-256-GCM, introduction de l'App-Bound Encryption, renforcement de l'isolation des processus — le modèle de menace fondamental reste inchangé : un attaquant disposant d'un accès au contexte utilisateur Windows peut extraire l'intégralité des credentials stockés. Les outils offensifs évoluent constamment pour contourner chaque nouvelle protection, et les stealers-as-a-service démocratisent l'accès à ces techniques pour des acteurs à faible technicité.

La défense efficace repose sur une stratégie de défense en profondeur : interdiction du stockage de mots de passe dans le navigateur via GPO, déploiement d'un gestionnaire de mots de passe d'entreprise, monitoring actif des accès aux fichiers critiques, déploiement d'EDR avec des règles spécifiques au vol de credentials navigateur, et formation continue des utilisateurs. Les équipes Red Team doivent systématiquement inclure l'extraction Chrome dans leurs scénarios de test pour évaluer l'exposition réelle de l'organisation. Les équipes Blue Team doivent quant à elles développer des capacités de détection et de réponse rapide face à cette menace, en s'appuyant sur le framework MITRE ATT&CK et les indicateurs de compromission documentés. La sécurité des credentials navigateur n'est pas un problème isolé — elle s'inscrit dans une stratégie globale de protection des identités numériques et de gestion des accès privilégiés qui doit être traitée avec la même rigueur que la sécurité réseau ou la protection des endpoints. Pour approfondir le sujet, consultez notre article sur l'extraction de credentials Firefox via NSS qui complète cette analyse avec les spécificités du navigateur de Mozilla.