Webmail et comptes cloud sur le poste de travail

Une grande partie des échanges actuels par e-mail, du partage de fichiers et de la messagerie se déroule dans un onglet de navigateur ou un client de bureau léger, tandis que le contenu reste sur les serveurs du fournisseur. Cette leçon montre ce qu’un examinateur peut néanmoins apprendre sur les comptes de webmail, de stockage cloud, de messagerie et de réseaux sociaux à partir d’un seul poste de travail Windows : quels comptes existent, qui les a utilisés et quand, ainsi que des fragments de contenu. Elle définit également la limite au-delà de laquelle le poste de travail ne suffit plus et où les données du fournisseur, obtenues dans le cadre d’une procédure légale ou avec le consentement du titulaire, doivent prendre le relais.

Ce que le poste de travail peut et ne peut pas montrer

Avec un client de messagerie local, la boîte aux lettres se trouve sur le disque (leçon 4.4). Avec le webmail, ce n’est pas le cas : le navigateur ne télécharge que les parties de la boîte aux lettres que l’utilisateur consulte, les conserve souvent en mémoire ou dans des caches de courte durée, puis les supprime. Le poste de travail répond donc bien à trois questions : si un compte a été utilisé sur cet ordinateur, par quel utilisateur Windows et avec quel profil de navigateur, et quand. Il ne répond que partiellement à une quatrième question, quel contenu : objets des messages, aperçus, pièces jointes téléchargées et fragments en cache. Les boîtes aux lettres complètes, les éléments supprimés côté fournisseur, les connexions depuis d’autres appareils et les adresses IP se trouvent chez le fournisseur.

Identification des comptes

Commencez par répertorier toutes les identités de compte présentes sur le système, puis rattachez chacune d’elles à un profil utilisateur Windows.

Profils de navigateur

Les navigateurs basés sur Chromium (Chrome, Edge, Brave et autres) conservent un dossier par profil, par exemple %LOCALAPPDATA%\Google\Chrome\User Data\Default ou ...\Microsoft\Edge\User Data\Profile 1 (la leçon 4.1 présente cette organisation).

• Preferences (un fichier JSON dans le dossier du profil) contient un tableau account_info pour le compte avec lequel le profil de navigateur est connecté. Dans Chrome, chaque entrée contient email, gaia (l’identifiant numérique du compte Google, qui ne change pas lorsque l’adresse change), full_name et des champs associés.
• Local State (un niveau au-dessus, dans User Data) contient profile.info_cache, qui répertorie chaque dossier de profil avec son nom d’affichage et, pour les profils connectés, le nom d’utilisateur du compte.
• Edge utilise les mêmes fichiers. Ses profils sont connectés avec un compte Microsoft ou un compte professionnel ou scolaire (Entra ID). Un compte Microsoft peut utiliser n’importe quelle adresse e-mail comme nom d’utilisateur, y compris une adresse chez un autre fournisseur. Une adresse dans account_info d’Edge désigne donc le compte de connexion au navigateur, et pas nécessairement une boîte aux lettres utilisée dans un onglet.

Identifiants de connexion enregistrés, saisie automatique et cookies

• Identifiants de connexion enregistrés. Le fichier Login Data de Chromium (SQLite, table logins) stocke origin_url, username_value, date_created, date_last_used et times_used en clair ; seul password_value est chiffré (sous Windows, avec une clé protégée par DPAPI, l’API de protection des données qui lie les secrets aux informations d’ouverture de session de l’utilisateur). Le fichier logins.json de Firefox conserve hostname en clair, mais chiffre à la fois le nom d’utilisateur et le mot de passe avec des clés contenues dans key4.db. Dans les deux cas, la liste des sites pour lesquels des identifiants de connexion sont enregistrés est lisible sans accéder à un mot de passe.
• Saisie automatique et historique des formulaires. Le fichier Web Data de Chromium (table autofill : name, value, count, date_created, date_last_used) et le fichier formhistory.sqlite de Firefox (table moz_formhistory) enregistrent les valeurs saisies dans les formulaires, notamment les adresses e-mail saisies dans les champs de connexion.
• Cookies par hôte. Le fichier Network\Cookies de Chromium et le fichier cookies.sqlite de Firefox indiquent quels hôtes ont défini des cookies, les noms des cookies et leurs dates de création et de dernier accès. Les cookies d’authentification (souvent appelés, de manière imprécise, cookies de session, bien que la plupart soient persistants) indiquent une session connectée ; Google, par exemple, définit des cookies nommés SID, HSID et SAPISID sur .google.com pour les utilisateurs connectés. Les noms, les hôtes et les horodatages suffisent ; vous n’avez pas besoin des valeurs et ne devez pas les utiliser.

Identités au niveau de Windows

• Compte Microsoft lié à Windows. La valeur InternetUserName de la ruche SAM fournit l’adresse e-mail (leçon 2.2).
• Jonction à Entra ID. Sur un système en fonctionnement, dsregcmd /status indique AzureAdJoined, le nom du locataire et l’identifiant de l’appareil. Hors ligne, la ruche SYSTEM conserve les informations de jonction sous ControlSet001\Control\CloudDomainJoin, où des sous-clés telles que JoinInfo et TenantInfo contiennent des valeurs comprenant l’identifiant du locataire et, sur de nombreux systèmes, l’adresse e-mail de l’utilisateur qui a joint l’appareil.
• Clés d’identité Microsoft. HKCU\Software\Microsoft\IdentityCRL, utilisée par les composants de connexion aux comptes Microsoft, comporte souvent des sous-clés portant l’adresse du compte comme nom. Office stocke les identités connectées sous HKCU\Software\Microsoft\Office\16.0\Common\Identity\Identities, avec une sous-clé par identité contenant des valeurs telles que EmailAddress et ProviderId, qui distingue un compte Microsoft personnel d’un compte professionnel ou scolaire.
• Gestionnaire d’informations d’identification. Les informations d’identification Windows et web enregistrées se trouvent dans %LOCALAPPDATA%\Microsoft\Credentials et %APPDATA%\Microsoft\Credentials (un fichier protégé par DPAPI par entrée), ainsi que dans %LOCALAPPDATA%\Microsoft\Vault\<GUID>\ (Policy.vpol et des fichiers .vcrd). Hors ligne, vous voyez que des entrées existent, quand les fichiers ont été écrits et quelle clé principale DPAPI protège chacune d’elles ; les noms des cibles et les secrets se trouvent à l’intérieur des données protégées. Lors d’un triage autorisé sur un système en fonctionnement, cmdkey /list affiche les noms des cibles. Le déchiffrement des éléments protégés par DPAPI nécessite le mot de passe de l’utilisateur (ou des éléments de clé qui en sont dérivés) ou la clé de sauvegarde DPAPI du domaine, et doit être explicitement couvert par votre autorisation.

Traces de webmail

URL et titres de pages

Les URL de l’historique révèlent des actions. Gmail place la vue dans le fragment d’URL : mail.google.com/mail/u/0/#inbox, #sent, #inbox/<thread id>, et ?compose=new lorsqu’une fenêtre de rédaction s’ouvre. Le segment u/N correspond à la position du compte dans la session multicomptes de ce navigateur (0 est le premier compte connecté), et non à une propriété fixe du compte. Outlook sur le web utilise des chemins sous /mail/ qui nomment le dossier (par exemple inbox ou sentitems) et /mail/deeplink/compose pour un nouveau message, sur outlook.live.com (personnel) ou outlook.office.com (professionnel ou scolaire). Les titres de pages dans la base de données de l’historique indiquent souvent le dossier ou l’objet d’un message ouvert, et les titres Gmail ont souvent inclus l’adresse du compte. Les fournisseurs modifient ces formats sans préavis : considérez les URL et les titres comme des indices à corroborer, et non comme des preuves. Une visite du dossier Messages envoyés montre que le dossier a été consulté, et non qu’un message a été envoyé.

Cache, téléchargements et notifications

• Cache. Des fragments du JSON et du HTML récupérés par l’application web peuvent subsister dans le cache du navigateur (leçon 4.3) : objets des messages, adresses des expéditeurs, extraits.
• Pièces jointes téléchargées. Les pièces jointes enregistrées dans Téléchargements conservent un flux Zone.Identifier dont les champs ReferrerUrl et HostUrl enregistrent la provenance du fichier (leçon 1.4). Les pièces jointes Gmail sont servies depuis mail-attachment.googleusercontent.com, et l’URL elle-même contient un segment u/N. La table des téléchargements du navigateur ajoute les heures de début et de fin.
• Notifications. Si l’utilisateur a autorisé les notifications de bureau, les notifications contextuelles de nouveaux messages sont enregistrées dans wpndatabase.db (leçon 2.8), où le champ XML Payload contient souvent l’expéditeur, l’objet et la première ligne, avec ArrivalTime au format FILETIME.

Stockage des applications web

Les applications web conservent des données hors ligne dans le profil : IndexedDB (Chromium : IndexedDB\https_mail.google.com_0.indexeddb.leveldb ; Firefox : storage\default\https+++mail.google.com\idb\, SQLite), Local Storage (Local Storage\leveldb) et Service Worker CacheStorage (Service Worker\CacheStorage). IndexedDB et Local Storage de Chromium utilisent LevelDB, un système de stockage clé-valeur composé de fichiers .log et .ldb dans lesquels les enregistrements remplacés peuvent subsister jusqu’au compactage. L’organisation des données est propre à chaque application et change selon les versions ; utilisez donc un analyseur compatible avec LevelDB (par exemple la bibliothèque gratuite ccl_chromium_reader) et lisez les enregistrements plutôt que de vous attendre à trouver une boîte aux lettres. Lorsque la messagerie hors ligne est activée, de nombreux corps de messages peuvent y subsister.

Applications de bureau de messagerie et de collaboration

La plupart des clients de messagerie de bureau sont des applications web intégrées dans une enveloppe (Electron ou WebView2) et laissent les mêmes types de données de stockage. Slack conserve un profil de type Chromium sous %APPDATA%\Slack, avec IndexedDB, Local Storage (LevelDB) et un cache. Le nouveau client Microsoft Teams est une application empaquetée dont les données se trouvent sous %LOCALAPPDATA%\Packages\MSTeams_8wekyb3d8bbwe, notamment un profil WebView2 dont IndexedDB utilise LevelDB ; le client classique utilisait %APPDATA%\Microsoft\Teams. WhatsApp Desktop est désormais également une application empaquetée sous %LOCALAPPDATA%\Packages, avec des bases de données locales et des caches de médias ; ses formats changent selon les versions et peuvent être chiffrés. Dans tous les cas, attendez-vous à un historique partiel en cache, et non à une archive complète.

La limite juridique et éthique

Les mots de passe, cookies et jetons enregistrés peuvent permettre d’ouvrir un compte en ligne. Les utiliser pour se connecter, ou réutiliser un cookie dans un autre navigateur, est hors du périmètre d’un examen du poste de travail, sauf si votre autorisation le couvre explicitement. Cela donne accès à des données hébergées sur les serveurs d’un tiers, peut modifier ces données (indicateurs de lecture, enregistrements de dernière connexion, alertes de sécurité) et peut rendre vos éléments de preuve irrecevables. Procédez plutôt comme suit :

• Documentez ce que montre le poste de travail : identités, hôtes, horodatages, chemins de fichiers, empreintes et captures d’écran des enregistrements analysés, conformément aux exigences de documentation de la norme ISO/IEC 27037.
• Envoyez rapidement une demande de conservation au fournisseur afin que les données du compte soient conservées pendant la préparation de la procédure formelle.
• Obtenez la communication des données du fournisseur dans le cadre d’une procédure légale : données d’abonné et de compte, adresses IP et heures de connexion, appareils et contenu.
• Avec le consentement du titulaire, demandez-lui d’effectuer un export Google Takeout ou un export de compte Microsoft en votre présence ; consignez les étapes, puis calculez l’empreinte de l’archive et conservez-la.

Exemple détaillé : le webmail personnel d’ana

Une collecte de triage comprend C:\Users\ana\AppData\Local\Microsoft\Edge\User Data\Default.

1. Identité. Preferences → account_info[0].email = ana.costa.personal@gmail.example. Puisqu’il s’agit d’Edge, c’est le nom de connexion au navigateur ; il suggère l’utilisation du compte de webmail portant la même adresse, sans la prouver.
2. Historique. Les tables urls et visits montrent https://mail.google.com/mail/u/1/#inbox?compose=new avec visit_time 13417797340000000 et https://mail.google.com/mail/u/1/#sent avec visit_time 13417797487000000, intitulé "Messages envoyés - ana.costa.personal@gmail.example - Gmail". Les horodatages Chromium sont exprimés en microsecondes depuis 1601-01-01 UTC : 13417797487000000 ÷ 1 000 000 = 13 417 797 487 s ; moins 11 644 473 600 = 1 773 323 887 secondes Unix = 2026-03-12T13:58:07Z. La visite de rédaction se convertit de la même manière en 13:55:40Z, soit 2 min 27 s plus tôt. Le titre relie u/1 à l’adresse dans cette session.
3. Téléchargement. C:\Users\ana\Downloads\price-list-2026.xlsx contient ZoneId=3, ReferrerUrl=https://mail.google.com/ et HostUrl=https://mail-attachment.googleusercontent.com/attachment/u/1/?…. La table des téléchargements indique une heure de fin de 14:02:13Z, soit 4 min 6 s après la consultation du dossier Messages envoyés. Le segment u/1 correspond à la même position de compte.
4. Notification. wpndatabase.db contient une notification contextuelle d’Edge dont la charge utile indique "Marco Ruiz · Re: liste de prix · Merci, bien reçu". ArrivalTime = 134177980110000000 (unités de 100 ns depuis 1601) : ÷ 10 000 000 = 13 417 798 011 s ; moins 11 644 473 600 = 1 773 324 411 = 2026-03-12T14:06:51Z.

Vue d’ensemble du compte. L’utilisateur Windows ana, avec le profil Edge Default, a utilisé le compte Gmail ana.costa.personal@gmail.example (deuxième compte de la session) entre 13:55:40Z et au moins 14:06:51Z le 12 mars 2026 : une fenêtre de rédaction a été ouverte, le dossier Messages envoyés a été consulté, une pièce jointe a été téléchargée et une notification ressemblant à une réponse est arrivée. Auprès du fournisseur, vous devez obtenir le message envoyé lui-même (destinataires, contenu, pièce jointe, en-têtes), le fil complet avec Marco Ruiz, les adresses IP et les appareils de connexion pour cette journée, les coordonnées de l’abonné et les informations de récupération prouvant qui contrôle le compte, ainsi que l’identité du compte u/0.

Points clés pour l’examen : Préparez-vous à nommer le fichier et le champ qui identifient un compte connecté au navigateur (account_info dans Preferences), à convertir une valeur Chromium ou FILETIME en UTC et à lire le champ HostUrl d’un flux Zone.Identifier pour indiquer qu’une pièce jointe provient d’un webmail. Sachez à quelles questions seul le fournisseur peut répondre, en particulier concernant les adresses IP de connexion et le contenu complet, et retenez que se connecter avec des informations d’identification ou des cookies récupérés sort du périmètre d’un examen du poste de travail, sauf autorisation explicite.

Points essentiels

• Le poste de travail montre qu’un compte a été utilisé, avec quel profil Windows et quel profil de navigateur, et quand ; le contenu est partiel et les données côté fournisseur restent chez le fournisseur.
• Identifiez les comptes à partir de account_info dans Preferences, de Local State, des origines des identifiants de connexion enregistrés, de la saisie automatique, des hôtes des cookies, de InternetUserName dans SAM, de CloudDomainJoin et des clés Office Identity.
• Les URL de webmail, les positions u/N et les titres de pages sont des indices à corroborer avec les téléchargements, Zone.Identifier et les notifications contextuelles ; les formats changent sans préavis.
• IndexedDB et Local Storage dans les navigateurs basés sur Chromium et les applications Electron ou WebView2 utilisent LevelDB avec une organisation propre à chaque application.
• N’utilisez jamais d’informations d’identification ou de cookies enregistrés pour accéder à un compte en ligne sans autorisation explicite ; conservez les éléments, documentez-les et demandez les données au fournisseur.