Extraction Credentials Firefox : NSS, Key4.db et Exploits

Dans l'arsenal des techniques de Vitesse de cassage du mot de passe maître Firefox PBKDF2-SHA256 (10 000 itérations) — Comparaison matérielle CPU i9-13900K 24 cœurs / 32 threads ~50 K H/s ⏱ Mot de passe 8 car.: ~53 500 heures (~6 ans) GPU RTX 3090 10 496 cœurs CUDA ~1,5 M H/s ⏱ Mot de passe 8 car.: ~1 783 heures (~74 j) GPU RTX 4090 16 384 cœurs CUDA ~3 M H/s ⏱ Mot de passe 8 car.: ~891 heures (~37 j) 4× RTX 4090 65 536 cœurs CUDA ~12 M H/s ⏱ Mot de passe 8 car.: ~223 heures (~9,3 j) Cloud 8× A100 NVIDIA 80 Go HBM2e ~40 M H/s ⏱ Mot de passe 8 car.: ~67 heures (~2,8 j) 0 10M 20M 30M 40M Hachages par seconde (H/s) ℹ Hypothèse : mot de passe de 8 caractères alphanumériques (62⁸ ≈ 2,18 × 10¹⁴ combinaisons). Temps moyen = 50% de l'espace de recherche. Outil : hashcat mode 26100 (Mozilla key4.db). Valeurs approximatives. cracking-spraying">password attacks et cracking, l'extraction des credentials depuis les navigateurs web occupe une place prépondérante. Firefox, avec ses plus de 200 millions d'utilisateurs actifs, représente une cible de choix pour les attaquants comme pour les équipes Red Team. À la différence de Chrome qui s'appuie sur DPAPI, Firefox implémente son propre écosystème cryptographique via la bibliothèque NSS — une approche qui offre une portabilité multiplateforme mais introduit des vecteurs d'attaque spécifiques. La technique référencée T1555.003 dans le framework MITRE ATT&CK documente précisément ces méthodes d'extraction depuis les navigateurs. Comprendre en profondeur l'architecture de stockage de Firefox est un prérequis indispensable pour tout professionnel de la sécurité, qu'il opère en attaque ou en défense. Cet article constitue le volet Firefox de notre série dédiée au hacking des gestionnaires de mots de passe des navigateurs.

Architecture de stockage des credentials Firefox

L'architecture de stockage des credentials dans Firefox repose sur un ensemble de fichiers interdépendants localisés dans le répertoire de profil utilisateur. Sur Windows, ce profil se trouve généralement sous %APPDATA%\Mozilla\Firefox\Profiles\xxxxxxxx.default-release, sur Linux sous ~/.mozilla/firefox/xxxxxxxx.default-release, et sur macOS sous ~/Library/Application Support/Firefox/Profiles/. Le fichier profiles.ini à la racine du répertoire Mozilla permet d'identifier tous les profils configurés.

Le cœur du système s'articule autour de quatre fichiers principaux. Le fichier key4.db est une base SQLite contenant les clés de chiffrement maîtresses, protégées elles-mêmes par le Master Password ou par une chaîne vide par défaut. Le fichier logins.json stocke les couples identifiant/mot de passe sous forme chiffrée au format JSON. Le fichier cert9.db maintient le trust store des certificats, et le fichier signons.sqlite était utilisé dans les anciennes versions avant la migration vers logins.json.

Cette architecture est fondamentalement différente de celle de Chrome ou Edge. Là où les navigateurs Chromium délèguent la protection des secrets au système d'exploitation — DPAPI sous Windows, Keychain sous macOS — Firefox maintient une couche d'abstraction propre via NSS. Ce choix architectural a des implications majeures en termes de sécurité : d'un côté, il offre une protection indépendante du système, de l'autre, il permet l'extraction offline complète sans interaction avec les API du système d'exploitation hôte. Un attaquant qui exfiltre simplement le répertoire de profil dispose de tout le nécessaire pour déchiffrer les credentials.

La bibliothèque NSS : Network Security Services en détail

Network Security Services (NSS) est une bibliothèque cryptographique open-source développée par Mozilla, utilisée non seulement par Firefox mais également par Thunderbird, LibreOffice et de nombreux serveurs. Sa documentation officielle est disponible sur le wiki Mozilla NSS. NSS implémente les standards PKCS#11, S/MIME, TLS et CMS, fournissant une infrastructure cryptographique complète et indépendante de la plateforme.

Dans le contexte du stockage des credentials, NSS expose un module PKCS#11 softtoken (fichier softokn3.dll sous Windows, libsoftokn3.so sous Linux) qui gère les opérations de chiffrement et déchiffrement des secrets. Ce module interagit directement avec key4.db pour accéder aux clés maîtresses. L'API NSS fournit les fonctions PK11SDR_Decrypt() et PK11SDR_Encrypt() qui constituent les points d'entrée principaux pour manipuler les credentials chiffrés.

L'initialisation d'un contexte NSS requiert l'appel à NSS_Init(profile_path) qui charge le profil Firefox et ouvre les bases de données associées. Une fois le contexte initialisé, l'authentification via PK11_Authenticate() permet de déverrouiller le slot PKCS#11 avec le Master Password. Les stealers modernes chargent directement les DLL NSS en mémoire pour exploiter ces API sans dépendre d'une installation Firefox. Cette technique est documentée dans notre analyse des infostealers et la menace silencieuse du cybercrime.

L'architecture modulaire de NSS, bien que robuste du point de vue cryptographique, présente un talon d'Achille majeur : toute application capable de charger les bibliothèques NSS et d'accéder au profil peut déchiffrer les credentials, à condition de connaître le Master Password. Quand celui-ci est absent — ce qui est le cas par défaut — la protection s'effondre entièrement.

Structure du fichier key4.db : schéma SQLite et métadonnées

Le fichier key4.db est une base de données SQLite qui a remplacé l'ancien format Berkeley DB (key3.db) à partir de Firefox 58. Ce changement a simplifié considérablement l'extraction des clés pour les attaquants, SQLite étant un format universellement lisible. La structure interne comporte principalement deux tables : metaData et nssPrivate.

La table metaData contient les entrées critiques. L'entrée password stocke le hash de vérification du Master Password, composé d'un sel (entrySalt) et du résultat chiffré qui permet de vérifier si un mot de passe candidat est correct. L'entrée version indique la version du format de base. Pour inspecter cette structure, on utilise simplement sqlite3 key4.db "SELECT item1, item2 FROM metaData WHERE id = 'password';".

La table nssPrivate contient les clés privées chiffrées selon le standard PKCS#11. Chaque entrée stocke un attribut a11 contenant la clé chiffrée, et un attribut a102 contenant l'identifiant CKA_ID. L'extraction de ces données se fait via sqlite3 key4.db "SELECT a11, a102 FROM nssPrivate;". Les données retournées sont des blobs binaires encodés en ASN.1 DER, nécessitant un parsage spécifique.

Le format ASN.1 encapsule plusieurs informations : l'OID de l'algorithme de chiffrement, le sel utilisé pour la dérivation, le nombre d'itérations PBKDF2, et les données chiffrées elles-mêmes. Les versions récentes de Firefox (à partir de la version 72) utilisent SHA-256 avec AES-256-CBC comme algorithme par défaut, tandis que les versions antérieures utilisaient SHA-1 avec 3DES-CBC. Cette évolution complique légèrement le travail d'extraction car les outils doivent supporter les deux formats.

Le fichier logins.json : format et champs exploitables

Le fichier logins.json constitue la seconde pièce maîtresse du puzzle. Ce fichier JSON stocke l'ensemble des credentials sauvegardés par l'utilisateur, mais sous forme chiffrée. Chaque entrée contient plusieurs champs exploitables pour un attaquant. Le champ hostname révèle en clair le site web associé — une information déjà précieuse pour le renseignement. Les champs encryptedUsername et encryptedPassword contiennent les données chiffrées encodées en Base64.

D'autres champs fournissent des métadonnées intéressantes : timeCreated, timeLastUsed et timePasswordChanged sont des timestamps Unix en millisecondes qui permettent de reconstituer la chronologie d'utilisation. Le champ timesUsed indique le nombre de connexions automatiques effectuées. Le champ formSubmitURL précise l'URL du formulaire de soumission, potentiellement différente du hostname.

Les données chiffrées dans encryptedUsername et encryptedPassword suivent un format précis. Après décodage Base64, on obtient une structure ASN.1 contenant un OID identifiant l'algorithme SDR (Secret Decoder Ring) de NSS, suivi d'un vecteur d'initialisation (IV) et des données chiffrées proprement dites. Le déchiffrement nécessite la clé maîtresse extraite de key4.db, ce qui explique pourquoi les deux fichiers sont indispensables.

Un point souvent négligé concerne le fichier logins-backup.json, qui est automatiquement créé par Firefox comme copie de sauvegarde. Même si l'utilisateur supprime des entrées dans le gestionnaire, l'ancienne version peut persister dans le backup. Pour l'extraction forensique, il est donc crucial de collecter les deux fichiers. En contexte de réponse à incident, la comparaison entre les deux versions peut révéler des credentials supprimés par un attaquant pour couvrir ses traces, un élément pertinent pour les techniques de mouvement latéral.

cert9.db et le trust store Firefox : rôle dans l'extraction

Le fichier cert9.db est une base SQLite qui stocke les certificats de confiance et les certificats personnels de l'utilisateur. Bien qu'il ne contienne pas directement les mots de passe des sites web, son rôle dans l'écosystème de stockage des credentials Firefox est loin d'être négligeable. Les certificats clients stockés dans cert9.db peuvent servir à l'authentification sur des applications d'entreprise, des VPN ou des portails internes.

La structure de cert9.db comprend plusieurs tables dont nssPublic qui stocke les clés publiques et certificats, et des tables de métadonnées associées. Les certificats sont stockés au format DER encodé en ASN.1, avec leurs attributs PKCS#11 correspondants. L'extraction de ces certificats peut être réalisée via certutil -L -d sql:. si les outils NSS sont installés sur le système, ou par requête SQLite directe.

En contexte de pentest, l'exfiltration de cert9.db permet potentiellement de récupérer des certificats clients qui offrent un accès direct à des ressources protégées sans nécessiter de mot de passe. J'ai personnellement rencontré ce scénario lors d'un engagement où un certificat client stocké dans Firefox donnait accès à un portail d'administration réseau critique. La combinaison de cert9.db et key4.db permet de reconstituer un profil Firefox complet, incluant l'identité TLS du navigateur.

Pour le forensic, cert9.db offre également des informations précieuses sur les sites visités par l'utilisateur, les autorités de certification approuvées manuellement (indicateur potentiel d'interception TLS), et les exceptions de sécurité configurées. Ces métadonnées complètent le tableau dressé par logins.json et enrichissent considérablement la reconstitution d'activité. L'analyse combinée de ces fichiers s'inscrit dans les méthodologies de reverse engineering et d'analyse forensique.

Pour les équipes de réponse à incident, la vérification des certificats personnels dans cert9.db fait partie des étapes standard de triage. La commande certutil -L -d sql:/chemin/profil liste tous les certificats avec leurs niveaux de confiance. La présence de certificats racine inhabituels ou d'autorités de certification inconnues peut indiquer une compromission TLS antérieure ou l'installation d'un proxy d'interception. L'export des certificats clients pour analyse approfondie se réalise via pk12util -o export.p12 -d sql:/chemin/profil, permettant de déterminer si des certificats d'authentification ont été compromis et doivent être révoqués immédiatement auprès de l'autorité émettrice.

Chiffrement des mots de passe Firefox : 3DES-CBC et PKCS#11

Le mécanisme de chiffrement des credentials Firefox repose historiquement sur l'algorithme 3DES-CBC (Triple DES en mode Cipher Block Chaining), encapsulé dans le framework PKCS#11. Ce choix, hérité des débuts de NSS dans les années 2000, est aujourd'hui considéré comme obsolète par les standards cryptographiques modernes, bien que Mozilla ait progressivement migré vers AES-256-CBC dans les versions récentes.

Le processus de chiffrement suit un schéma en plusieurs étapes. D'abord, une clé maîtresse (Master Key) est générée aléatoirement et stockée dans key4.db, chiffrée par le Master Password via PBKDF2. Ensuite, cette clé maîtresse est utilisée pour chiffrer chaque credential via le mécanisme SDR (Secret Decoder Ring) de NSS. Le SDR encapsule les données dans une structure ASN.1 contenant l'OID 1.2.840.113549.3.7 pour 3DES-CBC, un vecteur d'initialisation de 8 octets, et le ciphertext paddé selon PKCS#7.

Le processus de déchiffrement inverse ces étapes : décodage Base64 du champ logins.json, parsage de la structure ASN.1, extraction de l'IV et du ciphertext, déchiffrement 3DES-CBC avec la clé maîtresse, et suppression du padding PKCS#7. La clé 3DES de 24 octets est dérivée de la clé maîtresse stockée dans key4.db, elle-même protégée par le Master Password.

L'utilisation de 3DES-CBC présente des faiblesses connues : une taille de bloc de 64 bits seulement, une vulnérabilité théorique aux attaques Sweet32 après 2^32 blocs, et une performance inférieure à AES. Mozilla a reconnu ces limitations et a introduit AES-256-CBC avec SHA-256 pour PBKDF2 dans Firefox 72+. Toutefois, pour des raisons de rétrocompatibilité, les profils existants conservent souvent l'ancien format 3DES, ce qui simplifie le travail des attaquants utilisant des outils qui ne supportent que ce format historique.

Le Master Password Firefox : mécanisme de dérivation PBKDF2

Le Master Password (désormais appelé Primary Password dans les versions récentes) est la seule ligne de défense réelle des credentials Firefox. Lorsqu'il est configuré, il protège la clé maîtresse stockée dans key4.db via un mécanisme de dérivation PBKDF2 (Password-Based Key Derivation Function 2). Ce mécanisme transforme le mot de passe de l'utilisateur en une clé de chiffrement en utilisant un sel aléatoire et un nombre d'itérations configurable.

Le processus de dérivation fonctionne ainsi : le Master Password est combiné avec un sel (globalSalt) stocké dans la table metaData de key4.db. Cette combinaison est passée à travers PBKDF2 avec SHA-256 (ou SHA-1 pour les anciens profils) sur un nombre d'itérations défini. Historiquement, Firefox utilisait un nombre d'itérations ridiculement bas — seulement 1 itération dans les versions antérieures à Firefox 72. Depuis, Mozilla a porté ce nombre à 10 000, ce qui reste modeste comparé aux recommandations OWASP de 600 000 itérations pour PBKDF2-SHA256.

La clé dérivée est ensuite utilisée pour déchiffrer l'entrée de vérification dans metaData et la clé maîtresse dans nssPrivate. Le mécanisme de vérification consiste à déchiffrer une valeur connue (le texte « password-check ») et à comparer le résultat. Si la vérification réussit, le Master Password est correct et le slot PKCS#11 est déverrouillé.

Le nombre d'itérations PBKDF2 relativement faible utilisé par Firefox, même dans les versions récentes, constitue une faiblesse significative. Avec 10 000 itérations, un GPU moderne peut tester des millions de candidats par seconde, rendant le brute-force viable pour des mots de passe de complexité moyenne. Cette réalité souligne l'importance d'un Master Password robuste — au minimum 16 caractères avec une entropie élevée — pour résister aux attaques par dictionnaire et par force brute.

Absence de Master Password : le scénario par défaut

Le constat le plus alarmant concernant la sécurité des credentials Firefox est que le Master Password n'est pas activé par défaut. Lors d'une installation standard, Firefox chiffre les mots de passe avec une clé maîtresse protégée par une chaîne vide. Autrement dit, n'importe quel processus disposant d'un accès en lecture au profil Firefox peut déchiffrer l'intégralité des credentials sans aucune authentification supplémentaire.

Ce choix de conception, motivé par l'ergonomie — Mozilla ne souhaite pas imposer un mot de passe supplémentaire à ses utilisateurs — a des conséquences désastreuses en termes de sécurité. Dans la grande majorité de mes missions de pentest, j'ai constaté que moins de 5 % des utilisateurs configurent un Master Password. Sur des parcs de plusieurs milliers de postes, cela signifie que l'extraction des credentials est quasi systématiquement triviale.

En pratique, l'absence de Master Password transforme l'extraction en une simple copie de fichiers. Un attaquant disposant d'un accès local — via un stealer, une session RDP compromise, ou un accès physique — n'a qu'à copier key4.db et logins.json pour obtenir tous les mots de passe en clair. Aucun cracking n'est nécessaire, aucune élévation de privilèges n'est requise au-delà de l'accès au profil utilisateur.

Cette situation est d'autant plus critique que Firefox ne propose aucun avertissement visible à l'utilisateur pour l'informer que ses mots de passe ne sont pas protégés par un Master Password. La seule indication est une case non cochée dans les paramètres de sécurité, que la plupart des utilisateurs ne consulteront jamais. Mozilla a amélioré la visibilité de cette option dans les versions récentes, mais le comportement par défaut reste inchangé, perpétuant une vulnérabilité structurelle qui profite massivement aux infostealers et aux campagnes de compromission de masse.

Le problème est encore aggravé dans les déploiements d'entreprise où les images systèmes standardisées incluent Firefox sans configuration de sécurité renforcée. Les administrateurs systèmes, pressés par les contraintes de temps et la priorité donnée à la productivité, déploient Firefox avec sa configuration par défaut sur des milliers de postes. Les utilisateurs, non sensibilisés à l'existence même de cette fonctionnalité, accumulent des dizaines voire des centaines de credentials dans un coffre-fort grand ouvert. Lors d'un audit de conformité pour une banque régionale, nous avons identifié que 2 847 postes sur 3 000 ne disposaient d'aucun Master Password Firefox, exposant collectivement plus de 45 000 couples identifiant-mot de passe incluant des accès aux systèmes bancaires internes.

Extraction avec firefox_decrypt : guide pas à pas

L'outil firefox_decrypt est la référence open-source pour l'extraction des credentials Firefox. Écrit en Python, il exploite directement les bibliothèques NSS installées sur le système pour déchiffrer les mots de passe. Son utilisation est remarquablement simple : python firefox_decrypt.py suffit pour extraire tous les credentials du profil par défaut sur la machine locale.

Pour une utilisation plus ciblée, plusieurs options sont disponibles. La commande python firefox_decrypt.py --profile /chemin/vers/profil permet de spécifier un profil particulier, ce qui est utile lors de l'analyse d'un profil exfiltré. L'option --format csv exporte les résultats au format CSV pour un traitement ultérieur. L'option --pass-prefix permet de filtrer les résultats par site web, et --tabular affiche les résultats sous forme de tableau lisible.

L'outil gère automatiquement la détection du format key4.db versus key3.db, la détection de la présence d'un Master Password (qu'il demandera interactivement), et le déchiffrement des deux formats cryptographiques (3DES-CBC et AES-256-CBC). En contexte de Red Team, firefox_decrypt est souvent intégré dans des scripts d'extraction post-exploitation qui collectent automatiquement les profils de tous les utilisateurs du système.

Une limitation notable de firefox_decrypt est sa dépendance aux bibliothèques NSS du système cible. Si Firefox n'est pas installé ou si les bibliothèques NSS ne sont pas disponibles, l'outil échouera. C'est pourquoi, en pratique, les opérateurs Red Team préfèrent souvent exfiltrer les fichiers du profil et utiliser des outils d'extraction offline comme firepwd.py qui réimplémentent le déchiffrement en Python pur, sans dépendance externe à NSS.

firepwd.py : déchiffrement offline des credentials

L'outil firepwd.py, développé par Louis Abraham, est un script Python autonome capable de déchiffrer les credentials Firefox sans aucune dépendance à la bibliothèque NSS. Cette caractéristique en fait l'outil de prédilection pour l'extraction offline sur une machine d'analyse, à partir de fichiers de profil exfiltrés. Il réimplémente intégralement les algorithmes cryptographiques de NSS en utilisant les bibliothèques Python standard (pyasn1, pycryptodome).

Son fonctionnement est direct : python firepwd.py -d /chemin/vers/profil analyse key4.db, extrait les clés, déchiffre la clé maîtresse (avec le Master Password si nécessaire), puis déchiffre chaque entrée de logins.json. Le script supporte les deux formats cryptographiques : l'ancien 3DES-CBC avec SHA-1 et le nouveau AES-256-CBC avec SHA-256, ce qui le rend compatible avec toutes les versions de Firefox depuis la migration vers key4.db.

En interne, firepwd.py effectue les opérations suivantes : lecture du globalSalt et de l'entrySalt depuis la table metaData de key4.db, dérivation de la clé via PBKDF2, déchiffrement de l'entrée de vérification pour confirmer le Master Password, extraction de la clé maîtresse depuis la table nssPrivate, puis itération sur chaque entrée de logins.json pour déchiffrer les noms d'utilisateur et mots de passe.

J'utilise firepwd.py quasi systématiquement en réponse à incident lorsque je dois analyser des profils Firefox collectés sur des postes compromis. L'avantage majeur est de pouvoir traiter les profils sur une station d'analyse isolée, sans risquer de contamination croisée. Le script produit une sortie claire avec les URLs, noms d'utilisateur et mots de passe en clair, facilement intégrable dans un rapport d'incident. Pour les cas où un Master Password est configuré, firepwd.py accepte le mot de passe en paramètre via -p "masterpassword".

Dumpzilla : extraction forensique complète du profil

Dumpzilla est un outil forensique Python spécifiquement conçu pour l'extraction exhaustive de données depuis les profils Firefox et Thunderbird. Contrairement à firefox_decrypt qui se concentre sur les credentials, Dumpzilla extrait l'ensemble des artefacts du navigateur : historique de navigation, cookies, formulaires, sessions, téléchargements, favoris, extensions installées, et bien sûr les mots de passe stockés.

L'utilisation de Dumpzilla pour l'extraction des mots de passe s'effectue via python dumpzilla.py /chemin/profil --Passwords. L'outil supporte de nombreuses options de filtrage : --Cookies --Domain "example.com" pour cibler un domaine spécifique, --History --Regex "bank" pour rechercher des patterns dans l'historique, ou --All pour une extraction complète.

En contexte forensique, Dumpzilla excelle par sa capacité à corréler les différentes sources de données. Par exemple, il peut identifier que l'utilisateur a visité un site bancaire (historique), y a stocké un mot de passe (logins.json), et possède un cookie de session encore valide (cookies.sqlite). Cette corrélation est inestimable lors de la reconstitution d'une chronologie d'incident.

L'outil est pré-installé dans les distributions forensiques comme SIFT et CAINE, et fait partie de la boîte à outils standard de Kali Linux. Son intégration dans des workflows automatisés de réponse à incident est facilitée par sa capacité à produire des sorties structurées. Lors d'un engagement récent de forensic sur un parc compromis par un stealer, j'ai utilisé Dumpzilla en mode batch pour traiter simultanément les profils de 200 postes, identifiant en moins d'une heure les comptes les plus critiques compromis et permettant une réponse rapide de révocation des credentials.

LaZagne : module Firefox et extraction automatisée

LaZagne est un framework d'extraction de credentials multi-applications, largement utilisé en pentest et par les malwares. Son module Firefox implémente l'extraction complète des credentials en utilisant soit les bibliothèques NSS du système, soit une implémentation Python pure en fallback. La commande lazagne.exe browsers -firefox sous Windows ou python laZagne.py browsers -firefox sous Linux lance l'extraction ciblée.

Le module Firefox de LaZagne détecte automatiquement tous les profils Firefox de l'utilisateur courant, identifie la version du format key4.db, et procède au déchiffrement. En mode administrateur, l'outil peut extraire les credentials de tous les utilisateurs du système en parcourant les profils de chaque compte. L'option -oJ produit une sortie JSON structurée, idéale pour l'intégration dans des frameworks C2.

Ce qui distingue LaZagne dans le paysage des outils d'extraction, c'est sa polyvalence. Au-delà de Firefox, il extrait les credentials de Chrome, Opera, les clients mail, les clients FTP, les bases de données, les clients SSH, et de nombreuses autres applications. Cette capacité d'extraction multi-cible en fait un outil de prédilection pour les opérations Red Team où la collecte rapide de l'ensemble des secrets d'un poste est prioritaire.

LaZagne est également intégré nativement dans plusieurs frameworks de post-exploitation, notamment Empire et Covenant. Son code source est régulièrement intégré dans des stealers malveillants — une réalité qui souligne le lien étroit entre outils offensifs légitimes et malwares. Les techniques d'extraction automatisée sont détaillées dans notre article sur l'analyse des stealers RedLine, Raccoon et Lumma, où LaZagne est cité comme source d'inspiration pour de nombreuses familles de malwares.

Extraction manuelle via Python et bibliothèque NSS

Pour les opérateurs avancés qui souhaitent un contrôle total sur le processus d'extraction, l'implémentation manuelle via Python et l'API NSS offre une flexibilité maximale. L'approche consiste à charger dynamiquement les bibliothèques NSS via ctypes et à appeler directement les fonctions de déchiffrement. Sous Windows, le code charge nss3.dll depuis le répertoire d'installation Firefox ; sous Linux, libnss3.so est accessible via le système.

Le processus commence par l'initialisation du contexte NSS : NSS_Init(profile_path.encode()), suivi du déverrouillage du slot avec PK11_GetInternalKeySlot() et PK11_Authenticate(slot, True, None). La fonction clé est PK11SDR_Decrypt() qui prend en entrée un SECItem contenant les données chiffrées Base64-décodées et retourne les données en clair.

Cette approche manuelle est particulièrement utile pour créer des implants personnalisés qui s'intègrent dans un framework C2 spécifique, ou pour développer des modules d'extraction adaptés à des contextes particuliers. Elle permet également de contourner les signatures antivirus qui détectent les outils standards comme LaZagne ou firefox_decrypt, en obfusquant le code et en le compilant en exécutable autonome.

Un point technique important : les structures SECItem et les types PKCS#11 doivent être déclarés correctement via ctypes pour éviter les corruptions mémoire. Le type SECItem est une structure C contenant trois champs : type (unsigned int), data (pointeur vers char), et len (unsigned int). Une erreur dans l'alignement de ces structures peut provoquer un crash du processus. La gestion des erreurs via PR_GetError() est essentielle pour diagnostiquer les échecs d'authentification ou les profils corrompus. Ces techniques d'interaction bas niveau avec les bibliothèques système sont abordées dans notre guide sur les buffer overflow et la corruption mémoire.

Brute-force du Master Password : hashcat et John the Ripper

Lorsqu'un Master Password est configuré, l'attaque par brute-force devient nécessaire. Hashcat supporte le format Firefox Master Password via le mode -m 26100 (Mozilla key4.db) pour les profils récents utilisant PBKDF2-SHA256, et -m 26000 pour les profils plus anciens utilisant SHA-1. La première étape consiste à extraire le hash depuis key4.db dans un format compatible.

L'extraction du hash pour Hashcat nécessite de récupérer le globalSalt, l'entrySalt, le nombre d'itérations et les données chiffrées de vérification depuis la table metaData de key4.db. Le script mozilla2hashcat.py automatise cette extraction : python mozilla2hashcat.py key4.db produit un hash au format $mozilla$*SHA256*iterations*globalSalt*entrySalt*encryptedData directement ingérable par Hashcat.

L'attaque elle-même se lance classiquement : hashcat -m 26100 hash.txt wordlist.txt -r rules/best64.rule pour une attaque par dictionnaire avec règles de transformation. Les règles dive.rule ou OneRuleToRuleThemAll.rule sont particulièrement efficaces contre les mots de passe humains. Avec 10 000 itérations PBKDF2, un GPU RTX 4090 atteint environ 200 000 candidats par seconde, permettant d'épuiser un dictionnaire de 14 millions d'entrées (comme rockyou) en moins d'une minute.

John the Ripper offre une alternative avec son format mozilla. La commande mozilla2john.py key4.db > hash.txt extrait le hash, puis john --format=mozilla hash.txt --wordlist=rockyou.txt lance l'attaque. John offre l'avantage d'un mode incrémental sophistiqué et d'une gestion native des règles de Markov pour les attaques probabilistes. Pour les deux outils, les stratégies de password cracking avancé s'appliquent directement au Master Password Firefox.

Optimisation GPU du cracking Master Password

L'optimisation du cracking GPU pour le Master Password Firefox nécessite une compréhension fine des paramètres de performance. Le facteur limitant est le nombre d'itérations PBKDF2 : à 10 000 itérations avec SHA-256, chaque test de candidat nécessite 10 000 calculs de hash SHA-256, ce qui réduit considérablement le débit par rapport à un hash simple comme MD5 ou NTLM.

Sur Hashcat, les paramètres de workload influencent directement les performances. L'option -w 3 (workload profile high) maximise l'utilisation GPU au détriment de la réactivité du système. L'option -O active les kernels optimisés qui peuvent doubler les performances pour certains modes. Pour les systèmes multi-GPU, l'option -d 1,2 spécifie les devices à utiliser, et --force peut être nécessaire sur certaines configurations.

Les benchmarks sur différentes architectures GPU donnent des ordres de grandeur utiles : une RTX 3080 atteint environ 120 000 H/s en mode 26100, une RTX 4090 environ 200 000 H/s, et un cluster de 8 A100 peut dépasser 1 500 000 H/s. Ces chiffres signifient qu'un mot de passe de 8 caractères alphanumériques (environ 47 bits d'entropie) peut être cracké en quelques jours sur un GPU domestique haut de gamme. Un mot de passe de 12 caractères avec symboles résiste plusieurs années.

Pour les anciens profils utilisant SHA-1 avec 1 seule itération (mode 26000), la situation est radicalement différente : les performances atteignent plusieurs milliards de candidats par seconde, rendant le cracking quasi instantané pour tout mot de passe raisonnable. C'est pourquoi la migration vers un profil récent avec PBKDF2-SHA256 et un nombre d'itérations élevé est une recommandation critique. L'identification de la version du format est donc la première étape de toute campagne de cracking ciblant Firefox.

Attaques sur les profils Firefox : localisation et exfiltration

L'exfiltration du profil Firefox constitue souvent la première phase d'une attaque ciblant les credentials. La localisation des profils varie selon le système d'exploitation mais suit des conventions prévisibles. Sous Windows, le fichier %APPDATA%\Mozilla\Firefox\profiles.ini liste tous les profils configurés avec leurs chemins. Sous Linux, ~/.mozilla/firefox/profiles.ini joue le même rôle. Un script d'énumération simple peut identifier tous les profils de tous les utilisateurs du système.

La taille minimale des fichiers à exfiltrer est remarquablement faible : key4.db pèse généralement entre 200 Ko et 1 Mo, et logins.json dépasse rarement quelques dizaines de Ko. Cette empreinte réduite rend l'exfiltration quasi indétectable dans un flux réseau normal. Les techniques d'exfiltration courantes incluent l'encodage Base64 dans des requêtes DNS, l'upload via HTTPS vers un serveur C2, ou l'intégration dans le trafic légitime d'une application autorisée.

En contexte d'intrusion avancée, les attaquants utilisent des techniques sophistiquées pour accéder aux profils verrouillés. Sur un poste Windows où l'utilisateur est connecté, l'accès au profil est direct via le contexte de l'utilisateur courant. Sur un serveur compromis, l'accès aux profils d'autres utilisateurs nécessite une escalade de privilèges pour obtenir un accès administrateur ou SYSTEM. Les techniques de token impersonation ou de RunAs permettent ensuite d'accéder aux profils de chaque utilisateur.

Un vecteur souvent négligé concerne les sauvegardes et les partages réseau. Les profils Firefox peuvent se retrouver dans des sauvegardes automatiques, des snapshots de VM, des dossiers de migration utilisateur, ou même des partages réseau mal configurés. Lors d'un audit, j'ai découvert un partage SMB contenant les profils Firefox de 300 utilisateurs, résultat d'un script de migration mal sécurisé — une mine d'or pour un attaquant.

Firefox Sync : exploitation du compte Mozilla

Firefox Sync est le service de synchronisation de Mozilla qui permet de partager les données du navigateur entre plusieurs appareils. Les credentials synchronisés sont chiffrés de bout en bout via le protocole Sync 1.5, utilisant les clés dérivées du mot de passe du compte Mozilla. Cependant, la compromission du compte Mozilla ouvre un vecteur d'attaque redoutable permettant d'accéder à l'ensemble des credentials synchronisés.

Le protocole de synchronisation utilise une dérivation de clé basée sur HKDF et scrypt depuis le mot de passe du compte. Les données sont chiffrées avec AES-256-CBC avant transmission aux serveurs Mozilla. En théorie, même Mozilla ne peut pas déchiffrer les données synchronisées. En pratique, un attaquant qui compromet le compte Mozilla — par phishing, credential stuffing, ou interception du token d'authentification — peut initier une synchronisation sur un profil qu'il contrôle et récupérer les credentials.

La technique d'attaque consiste à : premièrement, obtenir les identifiants du compte Mozilla (via phishing ou extraction depuis un autre appareil synchronisé). Deuxièmement, configurer un profil Firefox local avec ce compte. Troisièmement, activer la synchronisation et attendre que les credentials soient téléchargés. Les mots de passe apparaissent alors dans le gestionnaire local et peuvent être extraits avec les outils précédemment décrits.

Une variante plus sophistiquée exploite les tokens de session Firefox Sync stockés localement. Le fichier weave/credentials.json dans le profil contient des tokens qui peuvent être réutilisés pour accéder à l'API Sync sans connaître le mot de passe du compte. Ces tokens ont une durée de vie limitée mais peuvent être rafraîchis automatiquement tant que la session est active. L'interception de ces tokens sur un poste compromis permet un accès persistant aux credentials synchronisés.

L'authentification à deux facteurs (2FA) sur le compte Mozilla constitue une protection efficace contre cette classe d'attaque. Cependant, si l'attaquant dispose d'un accès au poste de travail où Firefox Sync est déjà configuré et actif, le token de session local suffit pour accéder aux données synchronisées sans nécessiter de réauthentification 2FA. Cette distinction est cruciale : la 2FA protège contre la compromission distante du compte Mozilla, mais pas contre l'extraction locale sur un poste déjà synchronisé. Les cookies de session Firefox Sync, stockés dans le profil local, sont donc des artefacts de haute valeur pour un attaquant ayant obtenu un accès initial au système.

Exploitation des sauvegardes et profils multiples

Firefox maintient un système de gestion de profils multiples souvent sous-estimé en termes de surface d'attaque. Le Profile Manager, accessible via firefox -ProfileManager, permet de créer, supprimer et gérer plusieurs profils indépendants. Chaque profil dispose de son propre jeu de fichiers key4.db et logins.json, potentiellement avec des Master Passwords différents ou — plus fréquemment — sans Master Password du tout.

Le fichier profiles.ini centralise la configuration de tous les profils et constitue le point d'entrée pour l'énumération. Sa structure est simple : chaque section [Profile0], [Profile1], etc., contient le nom du profil, son chemin relatif ou absolu, et un flag indiquant s'il s'agit du profil par défaut. L'analyse de ce fichier permet d'identifier rapidement tous les jeux de credentials disponibles sur le système.

Les sauvegardes Firefox constituent un vecteur d'exploitation particulièrement intéressant. Firefox Refresh (anciennement Reset) crée une copie complète de l'ancien profil dans un dossier Old Firefox Data sur le bureau. Ce dossier contient une copie intégrale des credentials, souvent oubliée par l'utilisateur et jamais supprimée. De même, les outils de migration entre navigateurs ou entre machines peuvent laisser des copies des fichiers de profil dans des emplacements non protégés.

En environnement d'entreprise, les solutions de sauvegarde centralisée (Veeam, Acronis, Windows Backup) capturent régulièrement les profils Firefox dans leurs images système. Un attaquant ayant accès au serveur de sauvegarde peut restaurer sélectivement les profils Firefox et extraire les credentials sans jamais toucher aux postes de travail. Cette technique est particulièrement discrète et difficile à détecter par les solutions EDR.

CVE notables du gestionnaire de mots de passe Firefox

L'historique des vulnérabilités du gestionnaire de mots de passe Firefox révèle des failles récurrentes qui ont permis des extractions non autorisées. La CVE-2019-11733 est sans doute la plus emblématique : elle permettait de contourner le Master Password pour accéder aux credentials stockés en exploitant une fenêtre de dialogue de copie de mot de passe qui ne vérifiait pas l'authentification. Cette vulnérabilité affectait Firefox 68 et a été corrigée dans Firefox 68.0.2.

La CVE-2020-6817 affectait le module d'auto-remplissage (autofill) des formulaires. Un site web malveillant pouvait créer des champs de formulaire invisibles qui déclenchaient le remplissage automatique, exfiltrant les credentials via JavaScript sans interaction utilisateur. Cette catégorie de vulnérabilités, bien que corrigée, rappelle que le remplissage automatique est intrinsèquement risqué.

Plus récemment, la CVE-2022-22747 affectait le traitement des certificats dans NSS et pouvait mener à un crash exploitable lors du parsing de certificats malformés. Bien que cette CVE ne cible pas directement les mots de passe, elle illustre la surface d'attaque de la bibliothèque NSS qui sous-tend le gestionnaire de credentials. La CVE-2023-44488 affectait quant à elle le mécanisme de mise à jour de Firefox, permettant potentiellement l'injection d'un profil malveillant.

Ces vulnérabilités soulignent un point important : même avec un Master Password configuré, des failles dans le code du gestionnaire peuvent permettre l'extraction. La veille CVE sur les composants Firefox et NSS est donc indispensable pour les équipes de sécurité. Le framework MITRE ATT&CK documente ces techniques et fournit des recommandations de détection actualisées pour chaque nouveau vecteur identifié.

Vulnérabilités de la bibliothèque NSS : historique critique

La bibliothèque NSS, en tant que composant cryptographique critique, a connu des vulnérabilités sévères au fil des années. La plus dévastatrice est sans conteste la CVE-2021-43527, surnommée « BigSig », une vulnérabilité de heap overflow dans le traitement des signatures DER-encoded. Cette faille permettait l'exécution de code arbitraire simplement en présentant un certificat malformé, affectant toutes les applications utilisant NSS pour la vérification de signatures, y compris Thunderbird, LibreOffice et les serveurs Apache avec mod_nss.

La CVE-2017-5461 constituait un autre cas critique : un out-of-bounds write dans le parsing des certificats Base64 de NSS. Exploitable à distance via un certificat TLS malveillant, cette vulnérabilité permettait le crash du navigateur et potentiellement l'exécution de code. La CVE-2016-2834 affectait quant à elle les fonctions de vérification de certificats, permettant de contourner les validations et d'effectuer des attaques man-in-the-middle.

Plus pertinent pour l'extraction de credentials, la CVE-2017-11695 à CVE-2017-11698 formaient un ensemble de quatre vulnérabilités dans le module de stockage sécurisé (softokn3) de NSS. Ces failles affectaient directement les opérations PKCS#11 utilisées pour le chiffrement et le déchiffrement des credentials. Leur exploitation pouvait permettre de corrompre la base de données des clés ou de contourner les vérifications d'intégrité.

La documentation technique complète de NSS est disponible sur la documentation source de Firefox. L'historique des vulnérabilités NSS démontre que la complexité de cette bibliothèque — plus de 500 000 lignes de code C — constitue une surface d'attaque significative. Les failles de type memory corruption dans NSS sont particulièrement dangereuses car elles peuvent être exploitées via des vecteurs réseau (certificats TLS) sans nécessiter d'accès local au système.

Stealers ciblant Firefox : RedLine, Raccoon, Lumma

Les infostealers constituent la menace la plus concrète et la plus massive pour les credentials Firefox. Les trois familles dominantes — RedLine, Raccoon et Lumma — intègrent toutes des modules d'extraction Firefox sophistiqués. Selon les données de télémétrie disponibles, ces stealers sont responsables de plus de 75 % des extractions de credentials de navigateurs observées en 2024.

RedLine Stealer, actif depuis 2020, implémente l'extraction Firefox en chargeant dynamiquement les DLL NSS depuis le répertoire d'installation Firefox. Son module browser extrait key4.db et logins.json, initialise le contexte NSS, et déchiffre les credentials en mémoire avant de les exfiltrer vers le serveur C2. RedLine gère automatiquement les profils multiples et la présence ou absence de Master Password.

Raccoon Stealer (v2) adopte une approche similaire mais implémente en plus une extraction offline basée sur une réimplémentation des algorithmes NSS en C++, similaire à firepwd.py. Cette double approche lui confère une résilience accrue : si les DLL NSS ne sont pas disponibles, l'extraction se fait par calcul direct. Raccoon cible également les données de Firefox Sync et les cookies de session pour maximiser l'impact.

Lumma Stealer, le plus récent des trois, se distingue par sa capacité à extraire les credentials même lorsque Firefox est en cours d'exécution, en accédant aux fichiers verrouillés via la technique de shadow copy sous Windows ou par lecture directe du fichier malgré le lock (les bases SQLite permettent la lecture concurrente). Lumma implémente également une obfuscation poussée de ses modules d'extraction pour échapper aux détections EDR. L'analyse détaillée de ces familles est traitée dans notre article dédié aux infostealers et la menace silencieuse du cybercrime.

Techniques d'extraction sans écriture disque (fileless)

Les techniques d'extraction fileless représentent l'état de l'art en matière d'évasion des solutions de sécurité. Le principe fondamental est d'éviter toute écriture de fichier sur le disque — pas de script Python déposé, pas d'exécutable suspect, pas de fichier temporaire — en opérant exclusivement en mémoire. Cette approche complique considérablement la détection par les antivirus traditionnels et les solutions EDR basées sur la surveillance du système de fichiers.

La technique la plus courante sous Windows consiste à utiliser PowerShell pour charger les DLL NSS directement en mémoire via réflexion. Le code charge nss3.dll dans l'espace d'adressage du processus PowerShell, résout les exports nécessaires (NSS_Init, PK11SDR_Decrypt), lit les fichiers key4.db et logins.json en mémoire, et effectue le déchiffrement sans jamais écrire de fichier intermédiaire. Le résultat est exfiltré directement via le canal C2.

Sous Linux, une approche similaire utilise Python (généralement disponible nativement) avec ctypes pour charger libnss3.so. L'avantage sous Linux est que Python et les bibliothèques NSS sont quasi systématiquement présents sur les systèmes où Firefox est installé. L'extraction peut être réalisée en une seule commande pipe via python3 -c "import ctypes; ..." sans aucun fichier sur disque.

Les techniques fileless avancées utilisent des canaux d'injection de processus pour opérer dans le contexte d'un processus légitime. L'injection dans le processus Firefox lui-même est particulièrement élégante : NSS est déjà chargé et initialisé, le slot PKCS#11 est potentiellement déjà déverrouillé, et l'activité cryptographique se fond dans le comportement normal du navigateur. Les techniques de reverse engineering permettent d'analyser ces méthodes d'injection en détail.

Firefox sur Linux : particularités et vecteurs d'attaque

L'extraction des credentials Firefox sur Linux présente des particularités significatives par rapport à Windows. Premièrement, les profils sont stockés sous ~/.mozilla/firefox/ avec des permissions Unix standard — typiquement 700 sur le répertoire de profil. Contrairement à Windows où DPAPI offre une couche de protection additionnelle pour certains navigateurs, Firefox sur Linux ne bénéficie d'aucune protection au-delà des permissions du système de fichiers et du Master Password optionnel.

Les distributions Linux modernes utilisant Snap ou Flatpak pour installer Firefox introduisent une complication supplémentaire. Le profil Firefox Snap se trouve sous ~/snap/firefox/common/.mozilla/firefox/, tandis que le profil Flatpak est sous ~/.var/app/org.mozilla.firefox/.mozilla/firefox/. Un script d'extraction doit vérifier ces trois emplacements potentiels. De plus, le sandboxing Snap et Flatpak peut limiter l'accès direct aux bibliothèques NSS système, nécessitant d'utiliser les bibliothèques intégrées au package.

Sur les serveurs Linux, Firefox est parfois installé pour des tâches d'administration web, créant une surface d'attaque inattendue. Les profils Firefox de l'utilisateur root, accessibles uniquement via une escalade de privilèges, peuvent contenir des credentials d'administration d'infrastructure critique — panels de gestion d'hyperviseurs, interfaces de stockage, consoles cloud. C'est un scénario que je rencontre fréquemment lors d'audits d'infrastructure.

Un vecteur d'attaque spécifique à Linux concerne les fichiers core dump. Si Firefox crash (ou est forcé à crasher) sans configuration ulimit -c 0, un core dump peut être généré contenant les credentials déchiffrés en mémoire. L'analyse de ce core dump avec strings ou gdb peut révéler des mots de passe en clair. Cette technique est particulièrement pertinente dans le contexte de l'escalade de privilèges sous Linux où l'accès aux core dumps d'autres utilisateurs peut être un vecteur d'extraction.

Firefox sur macOS : Keychain interaction et extraction

Sur macOS, Firefox maintient son indépendance vis-à-vis du Keychain système, contrairement à Safari et Chrome qui y stockent leurs secrets. Les profils sont localisés sous ~/Library/Application Support/Firefox/Profiles/. Cette indépendance signifie que les protections macOS spécifiques — Gatekeeper, SIP, le Keychain avec authentification biométrique — ne s'appliquent pas directement aux credentials Firefox.

L'extraction sur macOS suit le même processus que sur les autres plateformes : copie de key4.db et logins.json, puis déchiffrement via firepwd.py ou firefox_decrypt. Cependant, macOS introduit des mécanismes de protection complémentaires. Le TCC (Transparency, Consent and Control) peut bloquer l'accès au répertoire du profil Firefox depuis un terminal non autorisé. Un attaquant doit soit obtenir un full disk access (FDA), soit exploiter un bypass TCC pour accéder au profil.

Les malwares ciblant macOS, comme XCSSET ou Atomic Stealer, intègrent des techniques spécifiques pour contourner TCC et accéder aux profils Firefox. XCSSET exploitait des vulnérabilités dans les autorisations des applications développeur pour hériter de l'accès full disk. Atomic Stealer utilise des prompt système falsifiés pour tromper l'utilisateur en accordant les permissions nécessaires. Ces techniques démontrent que la sécurité de Firefox sur macOS repose en partie sur les défenses du système d'exploitation.

Un point spécifique à macOS concerne les sauvegardes Time Machine. Les profils Firefox sont automatiquement inclus dans les sauvegardes, créant des copies historiques potentiellement exploitables. Un attaquant ayant accès au volume Time Machine peut restaurer des profils anciens, qui pourraient contenir des credentials différents ou un Master Password plus faible. La commande tmutil listbackups permet d'identifier les sauvegardes disponibles et de cibler les profils historiques.

Détection des tentatives d'extraction Firefox

La détection des tentatives d'extraction de credentials Firefox repose sur la surveillance de plusieurs indicateurs à différents niveaux. Au niveau du système de fichiers, l'accès aux fichiers key4.db et logins.json par un processus autre que Firefox lui-même constitue un signal fort. Les solutions EDR peuvent monitorer les opérations de lecture sur ces fichiers via les API de surveillance — FileSystemWatcher sous Windows, inotify ou fanotify sous Linux, FSEvents sous macOS.

Les règles YARA constituent un mécanisme de détection complémentaire efficace. Des signatures ciblant les strings caractéristiques des outils d'extraction — « PK11SDR_Decrypt », « NSS_Init », « signons.sqlite », « logins.json » — dans des processus suspects permettent d'identifier les stealers et les scripts d'extraction. Les règles Sigma pour les SIEM peuvent détecter des patterns comportementaux comme l'exécution de Python avec des arguments contenant des chemins vers les profils Firefox.

Au niveau réseau, l'exfiltration des fichiers de profil peut être détectée par l'analyse du trafic sortant. Les solutions DLP (Data Loss Prevention) peuvent identifier les signatures des fichiers SQLite et JSON contenant les structures caractéristiques de key4.db et logins.json. La détection par entropie peut également identifier les données chiffrées Base64 caractéristiques des credentials Firefox dans le trafic réseau.

Sysmon sous Windows offre des capacités de détection granulaires via l'événement ID 11 (FileCreate) pour la copie des fichiers de profil, l'événement ID 7 (ImageLoad) pour le chargement des DLL NSS par des processus non-Firefox, et l'événement ID 1 (ProcessCreate) pour l'exécution de scripts d'extraction connus. Une configuration Sysmon ciblée sur ces événements fournit une télémétrie précieuse pour la détection précoce des tentatives d'extraction.

Contre-mesures et hardening du profil Firefox

Le durcissement du profil Firefox contre l'extraction de credentials nécessite une approche multicouche. La première mesure, et la plus critique, est l'activation du Primary Password (ex Master Password) avec un mot de passe robuste d'au moins 16 caractères incluant majuscules, minuscules, chiffres et symboles. Cette activation se fait via about:preferences#privacy > section Identifiants et mots de passe > « Utiliser un mot de passe principal ».

En environnement d'entreprise, les stratégies de groupe (GPO) et les fichiers policies.json permettent d'imposer des configurations de sécurité. Le fichier policies.json placé dans le répertoire d'installation Firefox (distribution/policies.json) permet de désactiver le gestionnaire de mots de passe natif ("PasswordManagerEnabled": false), de forcer l'utilisation d'un gestionnaire externe, et de bloquer la synchronisation ("DisableFirefoxAccounts": true).

La protection du répertoire de profil au niveau du système d'exploitation est complémentaire. Sous Windows, les ACL restrictives sur le dossier de profil peuvent empêcher l'accès par des processus non autorisés. Sous Linux, le montage du répertoire de profil avec l'option noexec et des permissions strictes (700) limite la surface d'attaque. L'utilisation de solutions de chiffrement de disque complet (BitLocker, LUKS) protège contre l'extraction physique.

La migration vers un gestionnaire de mots de passe dédié (Bitwarden, 1Password, KeePass) constitue la recommandation ultime. Ces solutions offrent un chiffrement plus robuste, une protection anti-keylogger, une synchronisation sécurisée, et une architecture de sécurité en profondeur que le gestionnaire natif de Firefox ne peut égaler. La suppression des mots de passe du gestionnaire Firefox après migration est impérative — sans oublier de supprimer également le fichier logins-backup.json qui conserve une copie des credentials.

Comparatif des outils d'extraction Firefox

Ce comparatif met en évidence les compromis entre chaque outil. firepwd.py est l'outil le plus polyvalent pour l'extraction offline grâce à son indépendance vis-à-vis de NSS. firefox_decrypt reste la référence pour l'extraction locale rapide quand les bibliothèques NSS sont disponibles. LaZagne excelle dans les scénarios d'extraction multi-applications. Les outils de cracking (Hashcat, John) sont indispensables uniquement lorsqu'un Master Password est configuré.

Le choix de l'outil dépend du contexte opérationnel : en Red Team avec accès local, firefox_decrypt ou LaZagne offrent la rapidité nécessaire. En forensic sur profils exfiltrés, firepwd.py est incontournable. En analyse de malware, la compréhension de l'extraction manuelle via ctypes permet de reproduire et comprendre le comportement des stealers analysés.

Implications forensiques et chaîne de preuve

L'extraction des credentials Firefox dans un contexte forensique impose des contraintes strictes de préservation de la chaîne de preuve. La première règle est l'acquisition d'une image forensique du disque avant toute manipulation. Les fichiers key4.db, logins.json, cert9.db et cookies.sqlite doivent être extraits depuis cette image, jamais depuis le système live, pour garantir l'intégrité des preuves. Chaque fichier extrait doit être accompagné de son empreinte SHA-256 documentée.

L'analyse des métadonnées temporelles des fichiers de profil fournit des informations cruciales pour la reconstruction de la timeline d'un incident. Les timestamps de logins.json (timeCreated, timeLastUsed, timePasswordChanged) permettent d'identifier quand un credential a été sauvegardé et utilisé pour la dernière fois. La corrélation avec les logs système et les artefacts réseau permet de déterminer si un credential extrait a été utilisé par l'attaquant pour un mouvement latéral.

L'utilisation de Write Blockers matériels ou logiciels lors de l'acquisition est indispensable pour garantir l'admissibilité des preuves en justice. Les outils comme FTK Imager ou dc3dd permettent une acquisition conforme aux standards forensiques. L'analyse ultérieure doit être réalisée sur une copie de travail, jamais sur l'image originale. La documentation de chaque étape — outil utilisé, version, paramètres, résultats — constitue le rapport forensique qui sera présenté en cas de procédure judiciaire.

Un aspect souvent négligé concerne la volatilité des preuves. Les credentials déchiffrés en mémoire par Firefox sont présents dans le processus firefox.exe et peuvent être récupérés via un dump mémoire (volatility, winpmem). Sur un système live, la capture de la mémoire du processus Firefox peut révéler des credentials qui ne sont plus présents dans logins.json (supprimés mais toujours en cache mémoire). Cette analyse de mémoire volatile complète utilement l'analyse des fichiers sur disque.

Recommandations pour les équipes Red Team

Pour les équipes Red Team, l'extraction des credentials Firefox s'intègre dans une méthodologie structurée de post-exploitation. La première recommandation est d'automatiser l'énumération et l'extraction dès l'obtention d'un accès initial. Un script de collecte doit identifier tous les profils Firefox de tous les utilisateurs accessibles, copier les fichiers nécessaires (key4.db, logins.json, cert9.db, cookies.sqlite), et tenter le déchiffrement immédiat sans Master Password.

La priorisation des cibles est essentielle dans un engagement à grande échelle. Les profils des comptes administrateurs, des équipes IT, et des cadres dirigeants sont prioritaires car ils contiennent potentiellement des credentials d'accès à l'infrastructure critique. L'analyse des hostnames dans logins.json — même sans déchiffrer les mots de passe — révèle les services utilisés et permet d'identifier les cibles de valeur (VPN, cloud, administration).

En termes d'OPSEC, l'extraction doit minimiser les artefacts laissés sur le système. L'utilisation de techniques fileless, l'évitement de l'écriture de fichiers temporaires, et l'exfiltration via des canaux couverts sont des pratiques standard. La modification des timestamps d'accès aux fichiers du profil (timestomping) peut être envisagée pour retarder la détection, bien que cette pratique soit elle-même détectable par analyse forensique avancée.

Enfin, les credentials extraits de Firefox doivent être corrélés avec les credentials obtenus d'autres sources — Chrome, gestionnaires de mots de passe, fichiers de configuration — pour identifier les réutilisations de mots de passe. Un mot de passe Firefox réutilisé comme mot de passe de domaine Active Directory constitue une découverte critique. L'intégration des résultats dans un framework comme Bloodhound permet de visualiser les chemins d'attaque ouverts par les credentials extraits et de planifier efficacement le mouvement latéral.

FAQ : questions fréquentes sur l'extraction Firefox

Intégration dans les frameworks C2 et post-exploitation

L'extraction des credentials Firefox est systématiquement intégrée dans les frameworks de commande et contrôle (C2) utilisés en Red Team. Cobalt Strike propose l'extraction via des BOF (Beacon Object Files) qui chargent les DLL NSS en mémoire dans le contexte du beacon. Le module chromium-and-firefox-credentials réalise une extraction complète sans écriture sur disque, en utilisant l'injection de code dans le processus cible pour accéder aux fichiers verrouillés.

Metasploit intègre le module post/multi/gather/firefox_creds qui automatise la collecte des fichiers de profil sur les cibles compromises. Ce module supporte Windows, Linux et macOS, identifie automatiquement les profils, et télécharge les fichiers nécessaires vers la machine de l'attaquant pour un déchiffrement local. L'option DECRYPT permet un déchiffrement direct sur la cible si les bibliothèques NSS sont disponibles.

Sliver, framework C2 open-source en Go, propose des extensions similaires via son système de plugins. L'avantage de Sliver réside dans sa capacité à compiler des implants statiques incluant une implémentation Go des algorithmes de déchiffrement NSS, éliminant toute dépendance externe. Empire, Covenant et Mythic proposent également des modules d'extraction Firefox, chacun avec ses particularités en termes d'OPSEC et de détection.

L'intégration dans ces frameworks permet une extraction à grande échelle lors d'engagements Red Team impliquant des centaines de postes. Un script de post-exploitation peut itérer sur toutes les sessions actives, exécuter l'extraction en parallèle, et centraliser les résultats dans une base de données consultable. La corrélation automatique des credentials extraits avec les comptes Active Directory identifie instantanément les opportunités de mouvement latéral et d'escalade de privilèges.

Analyse comportementale et machine learning pour la détection

Au-delà des signatures statiques, les approches comportementales et le machine learning offrent des capacités de détection avancées contre l'extraction de credentials Firefox. Les modèles de détection comportementale analysent les patterns d'accès aux fichiers de profil : un processus légitime accède à key4.db avec un pattern prévisible (ouverture, lectures séquentielles, fermeture), tandis qu'un outil d'extraction présente un pattern distinct (ouverture, lecture complète rapide, pas de réécriture).

Les solutions EDR modernes comme CrowdStrike Falcon, Microsoft Defender for Endpoint et SentinelOne intègrent des moteurs de détection spécifiques pour la collecte de credentials de navigateurs. Ces moteurs surveillent les appels API liés au chargement des bibliothèques NSS par des processus non-navigateur, les accès aux fichiers de profil Firefox par des processus suspects, et les patterns d'exfiltration réseau associés au vol de credentials.

La création de honeypots Firefox constitue une technique de détection proactive ingénieuse. En déployant des profils Firefox factices contenant des credentials canari — des identifiants uniques qui déclenchent une alerte lorsqu'ils sont utilisés — les équipes de sécurité peuvent détecter les tentatives d'extraction avec une grande fiabilité. Chaque credential canari est associé à un service de monitoring qui alerte en temps réel lors de toute tentative de connexion.

L'analyse des journaux Windows Event Log fournit également des indicateurs précieux. L'événement 4663 (tentative d'accès à un objet) configuré sur les fichiers de profil Firefox, combiné avec l'événement 4688 (création de processus) pour corréler le processus accédant, permet de construire des règles de détection robustes. Sous Linux, auditd avec des règles ciblant les fichiers ~/.mozilla/firefox/*/key4.db offre une capacité équivalente de surveillance et d'alerte.

En synthèse, le paysage de l'extraction des credentials Firefox évolue continuellement. Les évolutions récentes de Mozilla — renforcement du PBKDF2, migration vers AES-256-CBC, introduction du sandboxing RLBox pour NSS — améliorent progressivement la posture de sécurité. Cependant, la rétrocompatibilité avec les anciens profils et le maintien du Master Password comme option facultative perpétuent les faiblesses fondamentales exploitées depuis plus d'une décennie. La communauté offensive continue de développer de nouvelles techniques d'extraction, notamment via l'exploitation des extensions WebExtensions ayant accès aux API de stockage et via les techniques d'injection dans le processus de rendu Firefox utilisant les API de débogage à distance. La course entre attaquants et défenseurs sur ce terrain reste intensément active, et la veille technique constante demeure indispensable pour tout professionnel de la cybersécurité.

Conclusion

L'extraction des credentials Firefox représente un domaine technique à la croisée de la cryptographie appliquée, de l'exploitation post-compromise et de la forensique numérique. L'architecture de stockage de Firefox, articulée autour de NSS, key4.db et logins.json, offre une portabilité multiplateforme qui constitue simultanément sa force et sa faiblesse principale. La possibilité d'une extraction offline complète, sans interaction avec le système d'exploitation hôte, différencie fondamentalement Firefox des navigateurs Chromium dans le paysage des menaces.

L'absence de Master Password par défaut reste la vulnérabilité structurelle la plus impactante. Malgré les améliorations successives — migration vers AES-256-CBC, augmentation des itérations PBKDF2, introduction du Primary Password — la réalité du terrain montre que l'immense majorité des utilisateurs et des déploiements d'entreprise ne configurent pas cette protection essentielle. Les stealers comme RedLine, Raccoon et Lumma exploitent massivement cette faiblesse, compromettant des millions de credentials chaque année.

Pour les professionnels de la sécurité, la maîtrise des techniques d'extraction Firefox est indispensable, tant en attaque qu'en défense. Les équipes Red Team doivent intégrer ces techniques dans leurs playbooks de post-exploitation. Les équipes Blue Team doivent déployer les mécanismes de détection appropriés — monitoring des accès aux fichiers de profil, règles YARA ciblées, surveillance du chargement des DLL NSS. Les équipes forensiques doivent maîtriser les outils d'analyse pour reconstituer les timelines d'incident à partir des artefacts Firefox.

La recommandation ultime demeure la migration vers un gestionnaire de mots de passe dédié, offrant une architecture de sécurité en profondeur que le gestionnaire natif de Firefox ne peut structurellement pas fournir. En attendant cette migration, l'activation du Primary Password avec un mot de passe robuste, combinée au chiffrement intégral du disque et à une surveillance active des endpoints, constitue la meilleure défense disponible contre cette menace omniprésente.