Fichiers de messagerie et analyse des en-têtes

Les courriels constituent des éléments de preuve des communications : qui prétend avoir écrit à qui, quand, par quels systèmes et avec quelles pièces jointes. Sur un terminal, ils se trouvent dans des fichiers de boîte aux lettres qui conservent les messages longtemps après que l’utilisateur les croit supprimés, et chaque message reçu comporte un en-tête qui consigne son parcours. Cette leçon présente les formats de boîte aux lettres présents sur les ordinateurs Windows, la persistance des messages supprimés et la lecture d’un en-tête pour déterminer l’adresse IP d’origine, indiquer des heures fiables en UTC et évaluer l’authenticité de l’expéditeur.

Stockage des courriels sur le terminal

Fichiers PST et OST d’Outlook

Un PST (Personal Storage Table) est un fichier de boîte aux lettres d’Outlook classique. Outlook 2003 a introduit le PST Unicode, qui a supprimé la limite de 2 GB de l’ancien format ANSI ; la taille maximale par défaut est de 50 GB à partir d’Outlook 2010. Chaque fichier PST et OST commence par la signature de 4 octets !BDN (21 42 44 4E) à l’offset 0. À l’offset 8, la signature client SM désigne un PST et SO un OST ; la version sur 2 octets à l’offset 10 vaut 14 ou 15 dans un fichier ANSI, tandis que les fichiers Unicode utilisent 23 ou une valeur supérieure (les fichiers OST à partir d’Outlook 2013 affichent couramment 36, une variante avec des pages de 4 KB). Un « mot de passe » PST ne chiffre pas les données : le contenu est tout au plus masqué par un encodage réversible que les outils d’analyse annulent sans le mot de passe.

Un OST est le cache hors connexion d’une boîte aux lettres Exchange ou Microsoft 365 en mode Exchange mis en cache. Il est lié au profil et au compte Outlook ; Outlook ne l’ouvre donc pas comme un fichier autonome, mais les outils d’analyse forensique le lisent directement. Un OST peut encore contenir des éléments supprimés depuis du serveur si le client n’a pas effectué de synchronisation avant la collecte ou si les données subsistent dans des blocs non alloués. Il peut aussi être incomplet, car le cache peut ne couvrir qu’une période récente définie par un curseur de synchronisation.

Le nouvel Outlook pour Windows stocke les données différemment et n’utilise pas les fichiers OST comme Outlook classique ; vérifiez donc quel client était utilisé avant de conclure à l’absence d’un cache de boîte aux lettres. La leçon 4.5 traite des traces de messagerie web et de comptes cloud.

Profils Thunderbird

Thunderbird conserve tout sous %APPDATA%\Thunderbird\Profiles\<profile>\. Les comptes POP et locaux se trouvent dans Mail\, les comptes IMAP dans ImapMail\<server>\. Chaque dossier correspond à un fichier MBOX sans extension (Inbox, Sent), dans lequel chaque message commence par une ligne de séparation débutant par From (Thunderbird écrit From - suivi d’une date). Les sous-dossiers se trouvent dans un répertoire portant le suffixe .sbd. Chaque MBOX est accompagné d’un fichier .msf, un index (récapitulatif) que Thunderbird peut reconstruire ; il ne s’agit donc pas du fichier de stockage des messages. Un message supprimé est d’abord uniquement marqué comme supprimé (bit 0x0008 dans l’en-tête X-Mozilla-Status) et reste dans le MBOX jusqu’à ce que le dossier soit compacté. Le profil contient également global-messages-db.sqlite, l’index de recherche, qui conserve les objets, les participants et le texte indexé du corps des messages et peut ne pas refléter immédiatement les suppressions récentes. Les profils configurés pour utiliser le format facultatif maildir stockent quant à eux un fichier par message.

Messages individuels : EML et MSG

Un fichier EML contient un message au format texte RFC 5322, avec son en-tête et son corps MIME exactement tels qu’ils ont été transmis. Un fichier MSG contient un élément Outlook unique enregistré sous forme de fichier composé OLE (signature D0 CF 11 E0 A1 B1 1A E1). Ses propriétés sont des flux nommés __substg1.0_<tag><type> ; l’en-tête Internet d’origine d’un message reçu est la propriété 0x007D, recherchez donc le flux __substg1.0_007D001F (007D001E lorsque la chaîne est stockée en ANSI).

Messages supprimés

La suppression dans Outlook se déroule en plusieurs étapes. Une suppression normale déplace l’élément vers Éléments supprimés, qui reste un dossier ordinaire. Le fait de vider ce dossier ou d’utiliser Maj+Suppr retire l’élément de l’arborescence des dossiers ; pour les boîtes aux lettres Exchange et Microsoft 365, le serveur le conserve ensuite dans le dossier Éléments récupérables pendant une période de rétention. Il s’agit d’une source côté serveur qui nécessite une demande légale ou une exportation du locataire, plutôt qu’une collecte sur le terminal. À l’intérieur du PST ou de l’OST, les blocs libérés ne sont pas effacés immédiatement ; les outils d’analyse peuvent donc récupérer des éléments supprimés et orphelins dans l’espace non alloué du PST. L’outil open source pffexport de libpff peut exporter les éléments récupérés en même temps que les éléments normaux ; readpst convertit le contenu PST en fichiers MBOX ou EML ; les visionneuses PST commerciales et les suites d’analyse forensique des courriels font de même avec une interface graphique, et une copie de travail d’un profil Thunderbird peut être examinée dans Thunderbird lui-même. Indiquez toujours quelle méthode a permis d’obtenir chaque message.

Lecture de l’en-tête

La RFC 5322 définit l’en-tête du message. La plupart des champs sont renseignés par le client de l’expéditeur et ne prouvent rien quant à l’origine.

La chaîne Received

Chaque serveur qui accepte le message ajoute un en-tête Received en tête ; le saut le plus récent apparaît donc en premier et le parcours se lit de bas en haut. Une ligne type se présente sous la forme from <claimed host> (<reverse DNS> [<IP>]) by <receiving host> with <protocol> id <queue ID>; <date>. Le nom après from est celui annoncé par le système qui se connecte et peut être quelconque ; l’adresse IP entre crochets a été consignée par le serveur de réception à partir de la connexion TCP. Le terme désignant le protocole vous en dit davantage : ESMTPS signifie TLS, et ESMTPSA indique que le client s’est authentifié, ce qui repère le saut de soumission.

Repérez la frontière de confiance : l’en-tête Received le plus bas rédigé par un serveur auquel vous faites confiance, normalement le MX de l’organisation destinataire. L’adresse IP qu’il a consignée est fiable. Tout ce qui se trouve en dessous a été rédigé par des systèmes hors de votre contrôle et peut être falsifié ; traitez donc toute adresse IP d’origine qui y figure comme une piste à corroborer, par exemple avec les journaux du fournisseur. Convertissez l’heure de chaque saut en UTC, calculez les délais et vérifiez que les heures sont croissantes ; un délai négatif de quelques secondes correspond à une dérive d’horloge, tandis que des minutes ou des heures indiquent une horloge incorrecte, un message mis en file d’attente ou un en-tête falsifié.

Résultats d’authentification : SPF, DKIM, DMARC et ARC

Le serveur du destinataire consigne ses vérifications dans Authentication-Results (ou dans l’ancien en-tête Received-SPF).

• SPF vérifie si l’adresse IP qui se connecte est autorisée à envoyer pour le domaine de l’expéditeur d’enveloppe, indiqué par spf=pass smtp.mailfrom=<address>. Cela ne dit rien sur le champ From visible.
• DKIM vérifie une signature dans DKIM-Signature, où d= est le domaine signataire et s= le sélecteur ; la clé publique est publiée à l’emplacement <selector>._domainkey.<domain>. Le résultat est dkim=pass ou dkim=fail avec header.d=.
• DMARC ne réussit que si SPF ou DKIM réussit et que le domaine concerné est aligné sur le domaine du champ From. C’est le seul des trois qui protège l’adresse que voit l’utilisateur.
• Les en-têtes ARC (ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results, numérotés i=1, i=2…) préservent les résultats antérieurs lorsqu’une liste de diffusion ou un service de transfert modifie le message.

Les indicateurs d’hameçonnage sont un nom d’affichage qui imite une marque alors que l’adresse diffère, des champs From, Return-Path et Reply-To appartenant à des domaines différents, ainsi que dmarc=fail.

Exemple détaillé : un message d’hameçonnage

Un utilisateur de corp.example a reçu un message qui semble provenir d’une banque. L’en-tête contient, de haut en bas :

Parcourez la chaîne de bas en haut et convertissez les heures. UTC = heure locale moins le décalage.

Les heures progressent de façon cohérente et le parcours complet a pris 41 s. L’en-tête Date se convertit en 09:06:10 + 3 h = 12:06:10Z, soit 7 min 48 s avant la soumission : il s’agit d’une valeur côté expéditeur provenant d’un message mis en file d’attente ou d’une horloge décalée, et non d’une heure à indiquer comme heure de réception.

Frontière de confiance. R2 est le premier en-tête rédigé par le propre MX du destinataire ; la source consignée de manière fiable est donc 198.51.100.27. R3 et R4 ont été rédigés par l’infrastructure de l’expéditeur ; R4 désigne 203.0.113.45 comme le client qui s’est authentifié (ESMTPSA), apparemment depuis une adresse privée derrière un NAT (HELO [192.168.1.23]). Présentez-la comme l’adresse IP d’origine déclarée, à corroborer auprès du fournisseur de bank-secure.example.

Verdicts. SPF et DKIM réussissent tous les deux, mais pour bank-secure.example. DMARC échoue, car aucun des deux domaines n’est aligné sur bank.example dans From, et la politique p=none de la banque a laissé passer le message. Avec des réponses détournées vers une adresse de messagerie gratuite et un Message-ID provenant d’un VPS d’hébergement, la conclusion est la suivante : expéditeur usurpé, envoi via une infrastructure contrôlée par l’attaquant, réception par l’organisation à 2026-03-03T12:14:37Z.

Structure MIME et empreintes des pièces jointes

Un message contenant des pièces jointes est généralement de type multipart/mixed : une partie est un multipart/alternative imbriqué contenant des versions text/plain et text/html du corps, et chaque partie supplémentaire est une pièce jointe avec Content-Disposition: attachment; filename="invoice.pdf". Les parties sont séparées par la chaîne boundary déclarée dans Content-Type. Les pièces jointes binaires utilisent Content-Transfer-Encoding: base64, où chaque groupe de 4 caractères encode 3 octets, sur des lignes de 76 caractères au maximum. Calculez l’empreinte des octets décodés, jamais celle du texte base64 : une partie PDF commençant par JVBERi0xLjcK se décode en %PDF-1.7 suivi d’un saut de ligne, et seule l’empreinte SHA-256 du fichier décodé correspondra à une copie trouvée ailleurs, par exemple dans le dossier Téléchargements ou dans le dossier temporaire sécurisé d’Outlook (son chemin figure dans la valeur de registre OutlookSecureTempFolder).

Points clés pour l’examen : Attendez-vous à devoir lire une chaîne Received de bas en haut, convertir en UTC les heures des sauts ayant des décalages différents et choisir entre l’heure de réception fiable et l’en-tête Date. Soyez prêt à identifier la première adresse IP fiable, à expliquer pourquoi SPF et DKIM peuvent réussir alors que DMARC échoue, et à calculer l’empreinte d’une pièce jointe décodée. Connaissez la signature !BDN, les chemins par défaut des fichiers PST et OST, et le fait que Thunderbird conserve dans le MBOX les messages marqués comme supprimés jusqu’au compactage.

Points essentiels

• Les fichiers PST et OST commencent par !BDN ; l’OST est un cache lié à un profil qui peut contenir des éléments déjà supprimés sur le serveur, et les éléments supprimés peuvent être récupérés dans les blocs non alloués du PST.
• Thunderbird stocke un fichier MBOX par dossier, avec des index .msf et global-messages-db.sqlite ; les messages supprimés restent dans le MBOX jusqu’au compactage.
• Les en-têtes Received sont ajoutés en tête ; lisez-les donc de bas en haut et ne faites confiance qu’aux sauts rédigés par vos propres serveurs.
• Indiquez comme heure de réception l’heure Received du serveur de confiance en UTC ; l’en-tête Date est une déclaration de l’expéditeur.
• DMARC lie SPF ou DKIM au domaine visible du champ From ; la réussite de SPF et DKIM pour un autre domaine n’authentifie pas l’expéditeur.
• Calculez l’empreinte des pièces jointes après décodage base64.