Forensique navigateur sous Windows : Chrome, Edge, Firefox

Ce guide vous apprend à reconstituer ce qu'un utilisateur Windows a fait dans Chrome, Edge et Firefox : quelles pages il a visitées et comment il y est arrivé, ce qu'il a téléchargé et où, sur quels comptes il était connecté et quels onglets étaient ouverts. Vous verrez où chaque navigateur range ses données, comment convertir ses horodatages et comment récupérer les enregistrements que l'utilisateur a tenté d'effacer.

Pourquoi les navigateurs méritent leur propre méthode

Dans la plupart des intrusions et des affaires internes, le navigateur est le début ou la fin de l'histoire : le lien de phishing, le téléchargement malveillant, la session webmail, l'envoi vers un site de partage de fichiers. Ses données comptent aussi parmi les traces d'activité les plus détaillées du système, avec un horodatage par visite et des chaînes de référents que les artefacts du registre ne fournissent jamais. La fiche des artefacts navigateur liste les fichiers ; ce guide explique comment les exploiter dans une investigation.

Deux familles couvrent presque tout ce que vous rencontrerez sous Windows :

• Chromium : Google Chrome, Microsoft Edge (depuis 2020), Brave, Opera, Vivaldi. Même arborescence, mêmes schémas SQLite, même format d'horodatage.
• Firefox (Gecko) : ses propres bases SQLite, des fichiers JSON compressés dans un conteneur LZ4 propre à Mozilla, et une autre époque de référence.

Emplacement des profils

Énumérez chaque profil de chaque navigateur installé, pour chaque utilisateur. Le fichier Local State de Chrome contient une section profile.info_cache qui associe chaque dossier de profil à son nom affiché et au compte Google connecté, ce qui compte lorsqu'un utilisateur garde un profil « perso » à part.

Collecter sans perdre de données

Les navigateurs gardent leurs bases ouvertes, et les modifications récentes ne se trouvent souvent que dans le journal WAL SQLite ou dans le journal de rollback. Fermez le navigateur si vous maîtrisez le poste, ou copiez via un cliché instantané. Collectez toujours les fichiers compagnons (-wal, -shm, -journal) avec chaque base, et travaillez sur des copies : ouvrir l'original dans un navigateur SQLite peut déclencher un checkpoint du WAL et détruire justement les enregistrements recherchés.

# Profils Chromium et Firefox complets, fichiers compagnons compris
robocopy "C:\Users\jdoe\AppData\Local\Google\Chrome\User Data" E:\case\chrome /E /COPY:DAT /XD "Cache" "Code Cache" "GPUCache"
robocopy "C:\Users\jdoe\AppData\Local\Microsoft\Edge\User Data" E:\case\edge /E /COPY:DAT /XD "Cache" "Code Cache" "GPUCache"
robocopy "C:\Users\jdoe\AppData\Roaming\Mozilla\Firefox" E:\case\firefox /E /COPY:DAT

Retirez les exclusions /XD si le cache compte pour l'affaire. Les cibles KAPE WebBrowsers et BrowserCache font la même chose pour tous les utilisateurs (voir acquisition et triage).

Chromium : la base History

History est le cœur de tout examen Chromium. Les tables les plus utiles :

Horodatages : le temps WebKit

Chromium stocke le temps WebKit : des microsecondes depuis le 1er janvier 1601 UTC. Multipliez par 10 pour obtenir un FILETIME, ou convertissez directement en SQLite :

SELECT datetime(v.visit_time/1000000-11644473600,'unixepoch') AS visit_utc,
       u.url, u.title,
       v.transition & 0xFF AS core_transition,
       v.from_visit, v.visit_duration/1000000.0 AS seconds
FROM visits v JOIN urls u ON u.id = v.url
ORDER BY v.visit_time;

L'octet de poids faible de transition donne le type principal : 0 lien, 1 saisie, 2 favori automatique, 3 sous-cadre automatique, 5 généré (suggestion de la barre d'adresse), 7 envoi de formulaire, 8 rechargement, etc. Les bits supérieurs sont des qualificatifs, comme les marqueurs de redirection. Une transition « saisie » vers un domaine de phishing ne raconte pas la même histoire qu'un clic depuis le webmail, et remonter from_visit reconstitue le chemin exact suivi par l'utilisateur.

Téléchargements

SELECT datetime(start_time/1000000-11644473600,'unixepoch') AS start_utc,
       datetime(end_time/1000000-11644473600,'unixepoch')   AS end_utc,
       target_path, received_bytes, total_bytes, state, danger_type, opened,
       tab_url, referrer
FROM downloads ORDER BY start_time;

Joignez downloads_url_chains sur id pour voir chaque saut ; la dernière URL de la chaîne est la source réelle du fichier, souvent un CDN ou un bucket de stockage plutôt que la page vue par l'utilisateur. opened = 1 signifie que le fichier a été ouvert depuis l'interface de téléchargement du navigateur, pas qu'il n'a jamais été lancé autrement.

Visites synchronisées

Avec la synchronisation activée, les visites faites sur un téléphone ou un autre PC arrivent dans History avec la même structure que les visites locales. Vérifiez visit_source et recoupez avec une trace locale (un fichier sur disque, les octets SRUM du navigateur, des journaux DNS ou proxy) avant d'affirmer que le suspect était devant ce clavier pour une visite donnée.

Chromium : le reste du profil

Cookies, Login Data et chiffrement

Sous Windows, Chromium chiffre les valeurs des cookies et les mots de passe enregistrés avec une clé AES stockée dans Local State sous os_crypt.encrypted_key, elle-même protégée par la clé maîtresse DPAPI de l'utilisateur. Les valeurs préfixées v10 suivent ce schéma. Depuis Chrome 127, Google a ajouté l'App-Bound Encryption : les valeurs préfixées v20 dépendent d'une clé également protégée par un service de niveau SYSTEM, si bien que la clé DPAPI de l'utilisateur ne suffit plus hors ligne. Edge et les autres navigateurs Chromium l'ont adoptée à des dates et à des degrés différents : vérifiez les préfixes dans vos données au lieu de supposer. Le déchiffrement, lorsqu'il est autorisé et faisable, est traité dans la forensique de l'accès aux identifiants.

Dans la plupart des affaires, les valeurs ne sont pas nécessaires. host_key, name, creation_utc et last_access_utc montrent déjà qu'une session existait avec un webmail, un stockage cloud ou un portail d'administration, et quand elle a servi pour la dernière fois.

Extensions

Les extensions malveillantes ou détournées sont un vrai vecteur d'accès initial et de vol de données. Listez chaque dossier sous Extensions, lisez les permissions et host_permissions de chaque manifest.json, et récupérez la date et la source d'installation dans le bloc extensions.settings de Preferences ou Secure Preferences. Une extension installée hors du store, ou avec de larges permissions d'hôte le même jour qu'un téléchargement suspect, mérite un examen approfondi.

Données propres à Edge

Edge ajoute ses propres magasins à la structure Chromium. Collections\collectionsSQLite contient les éléments enregistrés par l'utilisateur dans Collections (URL, titre, date de création) : c'est une sélection volontaire, pas une navigation passive. Edge conserve aussi des données du mode IE et, sur des systèmes anciens ou mis à niveau, vous trouverez parfois encore la base ESE WebCacheV01.dat d'Internet Explorer et de l'ancien Edge EdgeHTML.

Firefox

Firefox utilise le PRTime : des microsecondes depuis le 1er janvier 1970 UTC. Parmi les valeurs de visit_type : 1 lien, 2 saisie, 3 favori, 5 et 6 redirections permanente et temporaire, 7 téléchargement et 9 rechargement.

SELECT datetime(h.visit_date/1000000,'unixepoch') AS visit_utc,
       p.url, p.title, h.visit_type, h.from_visit
FROM moz_historyvisits h JOIN moz_places p ON p.id = h.place_id
ORDER BY h.visit_date;

Les téléchargements sont enregistrés comme annotations dans moz_annos (downloads/destinationFileURI et downloads/metaData), rattachées à l'URL source dans moz_places.

Décompresser sessionstore

Les fichiers .jsonlz4 sont du JSON placé dans le conteneur mozLz40 de Mozilla : un magic de 8 octets, la taille décompressée sur 4 octets, puis un bloc LZ4. Quelques lignes de Python suffisent :

import json, lz4.block, sys
data = open(sys.argv[1], "rb").read()
assert data[:8] == b"mozLz40\0"
session = json.loads(lz4.block.decompress(data[8:]))
for win in session.get("windows", []):
    for tab in win.get("tabs", []):
        for entry in tab.get("entries", []):
            print(entry.get("url"), entry.get("title"))

Les fichiers de session sont précieux après un effacement de l'historique ou quand l'utilisateur naviguait avec l'historique désactivé : ils montrent ce qui était ouvert, y compris les onglets fermés encore restaurables.

Récupérer les enregistrements supprimés

« Effacer les données de navigation » et les suppressions ponctuelles retirent des lignes, mais SQLite efface rarement les octets immédiatement. Cherchez dans cet ordre :

1. WAL et journal : le -wal peut contenir d'anciennes versions de pages, y compris des lignes supprimées depuis le dernier checkpoint. Analysez-le avant de le fusionner.
2. Pages libres et freeblocks de la base : exploitez-les avec un outil compatible SQLite comme FQLite ou les fonctions de carving des suites commerciales (file carving).
3. Magasins annexes : Favicons, Top Sites, Shortcuts, le cache et les fichiers de session conservent des URL indépendamment de History.
4. Clichés instantanés de volume : d'anciennes copies du profil entier.
5. L'espace non alloué, le pagefile et la mémoire, pour les chaînes d'URL.

Un profil dont History est presque vide alors que Favicons, les cookies et le cache sont pleins signale clairement un effacement sélectif, qui constitue en soi une constatation pour la partie anti-forensique de votre rapport.

Traces de la navigation privée

Les fenêtres Incognito et privées n'écrivent ni historique, ni cookies, ni session dans le profil. Ce qui reste :

• Les fichiers téléchargés, avec un flux Zone.Identifier. Chromium omettrait le HostUrl pour les téléchargements faits en Incognito : attendez-vous alors à un simple ZoneId=3.
• L'utilisation réseau SRUM du processus du navigateur, heure par heure (forensique SRUM).
• Des URL et fragments de pages en RAM, dans pagefile.sys et hiberfil.sys (forensique de la mémoire).
• Le cache du client DNS sur un système allumé (ipconfig /displaydns, collecté pendant la réponse à chaud).
• Des fichiers LNK et des Jump Lists si l'utilisateur a ouvert les fichiers téléchargés.

Relier les téléchargements aux fichiers sur disque

Pour chaque ligne de téléchargement, vérifiez le fichier situé à target_path et lisez sa Mark of the Web, stockée dans un flux de données alternatif :

Get-Content -Path "C:\Users\jdoe\Downloads\invoice.iso" -Stream Zone.Identifier
# [ZoneTransfer]
# ZoneId=3
# ReferrerUrl=https://mail.example.com/
# HostUrl=https://files.example.net/dl/invoice.iso

Faire correspondre HostUrl avec la dernière entrée de downloads_url_chains prouve la provenance même si l'historique a été effacé. Suivez ensuite le fichier dans les artefacts d'exécution et les archives, comme décrit dans l'accès initial par phishing.

Outils

• Hindsight : analyse un profil Chromium entier (historique, téléchargements, cookies, saisie automatique, préférences, extensions, cache, LevelDB) sous forme de chronologie.
• SQLECmd et ses maps pour les bases Chromium et Firefox ; DB Browser for SQLite pour les requêtes manuelles sur des copies.
• NirSoft BrowsingHistoryView, ChromeCacheView et MozillaCacheView pour une revue rapide.
• Plaso pour intégrer les événements navigateur à une super-chronologie.
• Pour un fichier isolé, l'outil gratuit Browser Forensics ouvre History, places.sqlite et les bases associées directement dans le navigateur, côté client.

hindsight.exe -i "E:\case\chrome\Default" -o E:\out\chrome_default -f xlsx
SQLECmd.exe -d E:\case --csv E:\out\sqlite

Pièges

• Mauvaise époque. WebKit compte depuis 1601, PRTime depuis 1970, les deux en microsecondes. Une date en 1970 ou dans un futur lointain trahit une mauvaise conversion.
• Heure locale ou UTC. Tous les horodatages navigateur sont en UTC ; vérifiez ce qu'affiche votre outil (voir UTC et heure locale).
• last_visit_time n'est pas chaque visite. Utilisez visits ou moz_historyvisits pour la séquence complète.
• Une visite n'est pas une lecture. Redirections, pop-ups, préchargement, cadres et synchronisation créent tous des entrées. Vérifiez transition, visit_duration et les indices de focus.
• Ouvrir la base originale. Cela peut déclencher un checkpoint et faire perdre le WAL. Travaillez toujours sur des copies.
• Ne regarder que Default. Plusieurs profils et plusieurs navigateurs sont la norme.
• Croire que 90 jours sont la limite. Chromium purge l'historique après environ 90 jours, mais téléchargements, cookies, Favicons et clichés instantanés remontent souvent plus loin.

Checklist de la méthode

1. Lister les utilisateurs, les navigateurs installés et chaque profil (Local State, profiles.ini).
2. Collecter chaque profil avec ses fichiers -wal, -shm et -journal, plus Local State, depuis un cliché instantané ou navigateur fermé.
3. Analyser avec Hindsight ou SQLECmd ; interroger directement visits, downloads et moz_historyvisits sur la fenêtre clé.
4. Reconstituer les chaînes de navigation avec from_visit et transition / visit_type.
5. Faire correspondre les téléchargements aux fichiers sur disque et à leurs flux Zone.Identifier.
6. Examiner cookies, identifiants de Login Data, sessions, extensions et Collections Edge pour les comptes et l'intention.
7. Récupérer les données effacées dans le WAL, les pages libres, les magasins annexes et les clichés instantanés.
8. Recouper avec SRUM, les fichiers LNK, les Jump Lists et les artefacts d'activité utilisateur, puis placer chaque événement sur une chronologie unique en UTC.