Analyser un e-mail de phishing, la méthode pas à pas

Le phishing reste la porte d’entrée la plus courante des intrusions, et le signalement d’un « mail bizarre » est l’une des tâches les plus fréquentes d’un analyste SOC. La difficulté n’est pas technique : c’est de traiter chaque message avec la même méthode, sans se laisser guider par l’intuition ni par l’urgence que le mail cherche justement à créer.

Voici la démarche que j’applique. Les adresses, domaines et IP des exemples sont fictifs (domaines en .example, adresses réservées à la documentation).

1. Se mettre en sécurité avant tout

Avant d’analyser, on évite de transformer l’analyse en incident.

• Ne cliquez sur rien et n’ouvrez aucune pièce jointe sur un poste de travail normal.
• Récupérez le message complet, pas une capture d’écran : le fichier .eml ou .msg contient les en-têtes, indispensables à l’analyse. Dans la plupart des messageries, c’est « Afficher l’original » ou « Enregistrer sous ».
• Travaillez dans un environnement isolé : une machine virtuelle sans accès aux ressources internes, ou un bac à sable en ligne.
• Notez l’heure et la source : qui a signalé le message, à quelle heure, et combien de personnes l’ont reçu.

2. Lire les en-têtes

Le corps du message se falsifie facilement. Les en-têtes, eux, racontent le trajet réel. Voici un extrait d’exemple :

Return-Path: <bounce@mailer.lookalike-bank.example>
Received: from mail-out.lookalike-bank.example (unknown [203.0.113.45])
        by mx.entreprise.example with ESMTP; Tue, 13 Oct 2026 08:02:11 +0200
Authentication-Results: mx.entreprise.example;
        spf=pass smtp.mailfrom=mailer.lookalike-bank.example;
        dkim=pass header.d=lookalike-bank.example;
        dmarc=pass header.from=lookalike-bank.example
From: "Service Sécurité" <securite@lookalike-bank.example>
Reply-To: <support-urgent@freemail.example>
To: <victime@entreprise.example>
Subject: [Action requise] Votre compte sera suspendu

Les points à vérifier, dans l’ordre :

1. L’expéditeur affiché et l’expéditeur réel. Comparez From, Return-Path et Reply-To. Ici, une réponse partirait vers une boîte gratuite sans rapport avec l’organisation censée écrire : c’est un signal fort.
2. La chaîne Received. Elle se lit de bas en haut : la ligne la plus basse est le premier serveur qui a pris le message. Cherchez les IP d’origine et les incohérences.
3. Le résultat d’authentification. C’est là que l’on comprend les trois mécanismes.

Dans l’exemple, tout est en pass. Pourtant, le message est frauduleux : l’attaquant a acheté un domaine ressemblant à celui d’une banque et a correctement configuré SPF, DKIM et DMARC. Un pass prouve que l’expéditeur contrôle le domaine, pas que le domaine est légitime. C’est l’erreur d’analyse la plus fréquente.

Vous pouvez inspecter la politique publiée d’un domaine :

dig +short TXT lookalike-bank.example            # enregistrement SPF
dig +short TXT _dmarc.lookalike-bank.example     # politique DMARC
whois lookalike-bank.example                     # ancienneté et titulaire du domaine

Un domaine enregistré depuis quelques jours est un indice supplémentaire.

3. Examiner le contenu

Les liens. Regardez l’adresse réelle derrière le texte du lien, sans cliquer. Méfiez-vous des domaines proches de la marque imitée (rn au lieu de m, lettres d’un autre alphabet, sous-domaine trompeur comme banque.verification-compte.example), des raccourcisseurs et des redirections. Pour voir où mène un lien sans l’ouvrir dans un navigateur, utilisez un service d’analyse d’URL comme urlscan.io, ou un bac à sable.

Les pièces jointes. Calculez d’abord l’empreinte, puis cherchez-la sans ouvrir le fichier :

sha256sum facture.docm
file facture.docm
olevba facture.docm      # (oletools) extrait et signale les macros suspectes

Les formats à risque sont les documents Office avec macros (.docm, .xlsm), les archives, les raccourcis .lnk, les fichiers .html joints et les PDF contenant des liens. L’empreinte peut être soumise à VirusTotal ou MalwareBazaar : si elle est déjà connue, vous gagnez du temps.

Les variantes. Pensez aussi aux QR codes dans l’image du message (ils contournent l’analyse des liens) et aux messages sans lien ni pièce jointe qui poussent à répondre ou à appeler un numéro.

4. Extraire les indicateurs

Listez ce qui permettra de chercher et de bloquer. Pour les partager sans risque, on les « défange » : https:// devient hxxps:// et les points sont protégés par des crochets.

5. Corréler avec le renseignement

Un indicateur isolé dit peu. Cherchez-le dans votre base de renseignement (MISP, OpenCTI) et dans les sources publiques : est-il lié à une campagne connue ? D’autres domaines partagent-ils la même IP, le même certificat, le même gabarit de page ? Ce pivot transforme un message en campagne, et permet de bloquer les prochains avant leur arrivée.

6. Mesurer l’impact et répondre

C’est ici que l’analyse devient une réponse à incident.

1. Qui a reçu le message ? Recherchez dans la messagerie tous les messages du même expéditeur, du même objet ou avec la même pièce jointe.
2. Qui a cliqué ou ouvert ? Croisez les journaux du proxy ou du DNS avec les domaines extraits, et les journaux de la messagerie.
3. Y a-t-il eu saisie d’identifiants ? Si oui, considérez le compte comme compromis : réinitialisez le mot de passe, révoquez les sessions actives, vérifiez les méthodes d’authentification et les règles de transfert de messages, et examinez les journaux de connexion (par exemple ceux d’Entra ID) à la recherche de connexions inhabituelles.
4. Contenez. Bloquez le domaine et l’URL au niveau du proxy ou du DNS, supprimez le message des boîtes aux lettres concernées, et ajoutez les indicateurs à votre SIEM.
5. Prévenez. Un retour clair à l’utilisateur qui a signalé le message encourage les signalements suivants.

7. Documenter

Un bon compte rendu tient en une page :

• Résumé : ce qui s’est passé, impact et statut ;
• Chronologie : réception, signalement, analyse, actions ;
• Analyse : en-têtes, liens, pièces jointes ;
• Indicateurs : tableau défangé ;
• Techniques ATT&CK : T1566.001 (pièce jointe), T1566.002 (lien), T1204 (exécution par l’utilisateur), T1078 (comptes valides) si des identifiants ont été utilisés ;
• Actions et recommandations : blocages réalisés, améliorations proposées.

Checklist

• Message récupéré en entier, analysé en environnement isolé
• From, Return-Path, Reply-To comparés
• Chaîne Received lue de bas en haut
• SPF, DKIM, DMARC interprétés (sans conclure sur un simple pass)
• Domaine : ancienneté et ressemblance avec une marque
• Liens et pièces jointes analysés sans ouverture directe
• Indicateurs extraits, défangés et recherchés dans le SIEM
• Destinataires et clics identifiés, comptes concernés traités
• Blocages en place, compte rendu rédigé

Pour mettre ces notions en pratique sur un cas contrôlé, je les ai reliées à ma simulation de phishing avec GoPhish, qui traite la même chaîne côté attaque puis côté défense.