Analyser un phishing : du message à l'infrastructure

Un e-mail de phishing ressemble à une lettre anonyme. Pourtant, il sème des indices partout : des tampons sur l'enveloppe, une adresse de réponse, un lien vers un site qui doit bien être hébergé quelque part. Avec un peu de méthode, on peut remonter de ces indices jusqu'aux entreprises qui louent, souvent sans le savoir, leurs machines à l'arnaqueur. Et ce sont elles qui peuvent tout couper. Voici l'enquête, étape par étape : lire l'en-tête, suivre les pistes jusqu'à l'infrastructure, puis choisir à qui signaler quoi.

Récupérer l'en-tête complet : l'enveloppe du message

Ce que la messagerie affiche (l'expéditeur, l'objet, le texte) n'est que la lettre. Tout autour, il existe une enveloppe invisible : l'en-tête, des dizaines de lignes techniques ajoutées au fil du trajet. C'est là que se cachent les indices. Pour l'afficher :

• Gmail : le menu ⋮ du message, puis « Afficher l'original » ;
• Outlook : le menu … du message, puis l'option qui affiche les détails ou la source du message ;
• Apple Mail : le menu Présentation, puis Message et l'affichage de tous les en-têtes ;
• Thunderbird : le raccourci Ctrl+U (Cmd+U sur Mac), qui ouvre la source du message.

Astuce : on ne « transfère » pas le message pour l'analyser. Le transfert fabrique un nouvel e-mail, avec un nouvel en-tête, et les indices d'origine disparaissent. On copie plutôt la source complète, ou on enregistre le message en fichier .eml.

Les lignes Received : les tampons de la poste

Parmi toutes ces lignes, les plus précieuses commencent par Received:. Chaque serveur qui prend le message en charge y ajoute la sienne, tout en haut de la pile, comme un bureau de poste qui tamponne l'enveloppe à chaque passage. Le trajet complet d'un e-mail est raconté dans le guide Comment un e-mail voyage de l'expéditeur au destinataire.

Voici un en-tête simplifié, comme on en trouve dans un vrai phishing :

Received: from mx1.provider.example (mx1.provider.example [192.0.2.10])
        by mailbox.provider.example; Tue, 15 Sep 2026 09:14:05 +0200
Received: from vps-4411.host.example (vps-4411.host.example [203.0.113.45])
        by mx1.provider.example with ESMTPS; Tue, 15 Sep 2026 09:14:03 +0200
Received: from mail.mybank.example (unknown [10.0.0.7])
        by vps-4411.host.example; Tue, 15 Sep 2026 07:13:58 +0000
Authentication-Results: mx1.provider.example;
        spf=pass smtp.mailfrom=parcel-mail.example; dkim=none;
        dmarc=fail header.from=mybank.example
Return-Path: <bounce@parcel-mail.example>
From: "Ma Banque" <security@mybank.example>
Reply-To: mybank.support@freemail.example
Subject: Votre compte sera suspendu sous 24 h

Chaque ligne Received se lit comme une petite phrase : « reçu de (from) telle machine, par (by) tel serveur, à telle date ». Juste après from, on trouve le nom que la machine a annoncé en se présentant, sans aucune vérification. Entre parenthèses, on trouve ce que le serveur qui reçoit a réellement constaté : l'adresse IP de la machine en face de lui, entre crochets.

Lire de bas en haut… mais faire confiance de haut en bas

Puisque chaque serveur ajoute sa ligne au-dessus des précédentes, l'histoire se lit de bas en haut : la ligne du bas raconte le départ, celle du haut l'arrivée dans notre boîte. Dans l'exemple, le message part d'une machine qui se dit « mail.mybank.example », passe par vps-4411.host.example, puis entre chez notre messagerie.

Mais toutes les lignes ne se valent pas. Une ligne est toujours écrite par le serveur qui reçoit. Celles du haut sont donc écrites par notre propre messagerie : on peut leur faire confiance. Celles du bas ont été écrites avant que le message n'arrive chez nous, peut-être par la machine de l'arnaqueur, qui peut y mettre ce qu'elle veut. C'est comme un colis : les tampons de notre bureau de poste sont fiables, les étiquettes collées avant le départ ne prouvent rien.

La méthode est donc simple : on part du haut, et on descend tant que les lignes sont écrites par notre messagerie. On s'arrête sur la ligne d'entrée, celle où notre messagerie reçoit le message d'une machine extérieure. L'IP entre crochets sur cette ligne, ici 203.0.113.45, est l'indice le plus solide de tout l'en-tête : c'est la machine qui a réellement remis le message. C'est précisément celle que Baitback recherche.

Et la ligne du bas ? Elle prétend que le message vient de « mail.mybank.example », depuis l'adresse 10.0.0.7, une adresse privée qui n'existe pas sur Internet. Elle a été écrite par vps-4411 lui-même : c'est une fausse piste, posée exprès.

Ce qui est fiable, ce qui peut être falsifié

Dans l'exemple, Authentication-Results est très bavard. spf=pass dit que le serveur avait bien le droit d'envoyer… pour parcel-mail.example, le domaine de l'enveloppe, pas pour la banque. dmarc=fail dit que l'adresse affichée mybank.example ne correspond à rien de vérifié : le « De : » est faux. Pourquoi le message est-il arrivé quand même ? C'est tout le sujet du guide Un e-mail peut mentir… même quand les contrôles disent « OK ».

De l'IP à l'opérateur : à qui appartient cette adresse ?

Une adresse IP, c'est l'adresse postale d'une machine sur Internet. Comme les adresses postales, elles sont distribuées par grands blocs. Cinq registres régionaux s'en occupent : RIPE NCC (Europe et Moyen-Orient), ARIN (Amérique du Nord), APNIC (Asie-Pacifique), LACNIC (Amérique latine) et AFRINIC (Afrique). Ils confient ces blocs à des opérateurs, qui les louent à leurs clients.

Ces blocs sont regroupés en réseaux, chacun identifié par un numéro : l'ASN, par exemple AS64500. Si l'IP est l'adresse de la maison, l'ASN est le quartier, et il désigne l'opérateur qui l'administre et y fait circuler le trafic.

Pour savoir qui se cache derrière une IP, on interroge l'annuaire de ces registres avec une recherche WHOIS, ou avec sa version moderne, RDAP. Beaucoup de sites gratuits le font en un clic. En ligne de commande, cela donne par exemple (extrait simplifié) :

$ whois 203.0.113.45
inetnum:        203.0.113.0 - 203.0.113.255
netname:        HOST-EXAMPLE-VPS
org-name:       Host Example SAS
country:        FR
abuse-mailbox:  abuse@host.example
origin:         AS64500

Trois informations comptent : qui (le nom de l'organisation), où (le pays, utile pour savoir quelles lois s'appliquent) et surtout l'adresse abuse, la boîte officielle qui reçoit les signalements d'abus. Le nom inverse de l'IP, ici vps-4411.host.example, donne souvent un indice de plus : « vps » annonce un serveur virtuel loué.

Un piège classique : l'opérateur du réseau n'est pas toujours l'hébergeur final. Un gros opérateur peut louer un bloc d'adresses à un revendeur, qui loue lui-même des serveurs à ses clients. Le WHOIS affiche alors un petit bloc au nom du revendeur, avec sa propre adresse abuse. C'est lui qu'on contacte en premier : c'est le plus proche de la machine.

Suivre les autres pistes : l'expéditeur, le lien, le DNS

L'IP d'envoi n'est qu'un fil. Un phishing en laisse d'autres, et chacun mène à un acteur différent.

La piste de l'expéditeur

On regarde les domaines qui apparaissent dans From, Return-Path et Reply-To :

• une messagerie gratuite (du type Gmail ou Outlook.com) : l'acteur est le fournisseur, qui peut fermer le compte. C'est particulièrement utile pour le Reply-To, la boîte où atterrissent les réponses des victimes ;
• un domaine créé pour l'occasion : on cherche son registrar, la société qui l'a vendu, avec une recherche RDAP ou WHOIS sur le domaine, par exemple sur lookup.icann.org. On y lit aussi la date de création : un domaine « bancaire » né il y a trois jours est un très mauvais signe ;
• le vrai domaine d'une marque, usurpé : la marque n'y est pour rien, elle n'a pas envoyé le message. On peut la prévenir si elle propose une adresse de signalement du phishing.

La piste du lien

Le lien du message mène à la page piégée, qui doit bien être hébergée quelque part. On ne clique pas : on copie l'adresse (clic droit, « copier le lien »). Le nom qui compte est le domaine, juste avant le premier « / » qui suit https:// ; tout ce qui est à gauche est choisi librement par l'arnaqueur. Les liens passent souvent par plusieurs redirections : Baitback les suit à notre place et affiche la chaîne complète. Pour les liens cachés dans une image, voir le guide Quishing : quand le phishing se cache derrière un QR code.

La piste du DNS

Le DNS, l'annuaire d'Internet, dit où se trouve chaque morceau d'un domaine. Trois questions suffisent :

$ dig +short A  secure-login.example    # l'IP du site web (parfois un CDN)
$ dig +short MX secure-login.example    # les serveurs qui reçoivent ses e-mails
$ dig +short NS secure-login.example    # qui gère son annuaire DNS

L'IP du site passe ensuite par la même moulinette que l'IP d'envoi : WHOIS, ASN, opérateur, adresse abuse. Et un domaine sans aucun serveur de messagerie qui prétend nous écrire mérite un coup d'œil : voir Le champ MX du DNS : un signe de confiance ?

Pourquoi on trouve toujours plusieurs prestataires

À la fin de l'enquête, on se retrouve rarement avec un seul nom. C'est normal : une campagne de phishing ressemble à un déménagement fait uniquement avec des locations. Le nom de domaine est acheté chez un registrar, son DNS est géré par un autre, la page est posée sur un serveur loué ailleurs et cachée derrière un CDN, les e-mails partent d'un troisième serveur (voir Phishing : comment les arnaqueurs font passer leurs e-mails), et les réponses arrivent dans une boîte gratuite.

Les arnaqueurs ont de bonnes raisons de tout éparpiller : chaque service coûte peu, souvent payé avec des moyens volés ; si un prestataire coupe, les autres continuent de tourner ; et un CDN placé devant le site masque l'adresse du vrai serveur. Bonne nouvelle : chaque prestataire est aussi un levier. Plus on en prévient, plus vite la campagne s'effondre.

Une IP n'est pas un coupable

Tentation fréquente : trouver l'IP, lire le nom d'une entreprise ou d'un pays, et conclure « ce sont eux ». C'est presque toujours faux. L'IP désigne la dernière machine qui a remis le message, pas la personne derrière le clavier. Cette machine peut être :

• un serveur loué pour quelques jours par l'arnaqueur, le cas le plus simple ;
• le serveur d'un grand fournisseur de messagerie, si l'arnaqueur y a ouvert ou volé un compte : l'IP est alors celle du fournisseur, qui n'y est pour rien mais peut fermer le compte ;
• un site ou un ordinateur piraté, dont le propriétaire est lui-même victime ;
• un VPN ou un relais, qui masque la vraie connexion.

La bonne question n'est donc pas « qui est coupable ? » mais « qui peut agir sur cette machine ? ». C'est à cet acteur-là qu'on écrit. On ne contacte jamais l'arnaqueur, on ne « riposte » pas, et on n'accuse pas publiquement une entreprise dont le serveur a pu être détourné.

Domaine ou serveur : l'enseigne et l'immeuble

Pour savoir qui fait quoi, une image aide beaucoup. Imaginons une fausse agence bancaire dans une rue :

• le nom de domaine est l'enseigne au-dessus de la porte, et le registrar l'organisme qui a loué ce nom : il peut décrocher l'enseigne ;
• le serveur est l'immeuble où se trouve la fausse agence, et l'hébergeur son propriétaire : il peut mettre le locataire dehors ;
• l'adresse IP est l'adresse postale inscrite sur la plaque ;
• le CDN est un accueil installé devant l'entrée : les visiteurs parlent à l'accueil, qui fait passer les demandes à l'immeuble. De la rue, on ne voit que lui.

Couper le serveur retire la page, mais l'arnaqueur peut faire pointer son domaine vers un autre serveur en quelques minutes. Suspendre le domaine, à l'inverse, rend inutiles tous les liens déjà envoyés, même si le serveur tourne encore. Les deux se complètent.

Le cas du CDN

Si le WHOIS de l'IP du site renvoie un nom comme Cloudflare, Akamai ou Fastly, ce n'est presque jamais l'hébergeur : c'est l'accueil. Le CDN accepte les signalements, peut afficher une page d'avertissement aux visiteurs et transmet la plainte à l'hébergeur réel, dont il connaît l'adresse. Cloudflare, par exemple, propose un formulaire dédié sur abuse.cloudflare.com. On signale aussi au registrar du domaine, qui, lui, n'est pas caché par le CDN.

Le cas du serveur compromis

Une adresse du type https://boulangerie-dupont.example/wp-content/uploads/x/login.php trahit souvent un site piraté. Le domaine existe depuis des années et appartient à un vrai commerce ; la page piégée a été glissée dans un recoin. Ici, demander la suspension du domaine serait injuste et inefficace : on prévient l'hébergeur, et le propriétaire du site si on trouve son contact, en donnant l'adresse exacte de la page. Même logique pour un e-mail parti d'une vraie boîte piratée : on prévient le fournisseur, qui peut bloquer le compte et le rendre à son propriétaire.

Qui contacter selon la situation

En France, par exemple, on peut aussi transmettre l'e-mail à Signal Spam et signaler l'escroquerie sur PHAROS. Ces plateformes servent surtout aux statistiques et aux enquêtes : elles ne coupent pas un serveur dans l'heure, mais elles gardent une trace officielle.

Construire sa chaîne de signalement

Tout signaler en vrac, à tout le monde, marche mal. On procède plutôt dans l'ordre, du plus urgent au plus durable :

1. Arrêter les dégâts : la page piégée (hébergeur ou CDN) et les listes de blocage des navigateurs. Chaque heure compte : c'est dans les premières heures qu'une campagne fait le plus de victimes.
2. Couper le nom : le registrar du domaine, pour rendre inutiles les liens déjà envoyés.
3. Couper l'envoi : l'hébergeur de l'IP d'envoi, et le fournisseur de la boîte Reply-To.
4. Laisser une trace : les plateformes officielles, pour les enquêtes.

Un bon signalement est court et vérifiable. Il contient :

• l'en-tête complet du message, pas seulement une capture d'écran ;
• l'élément précis qui concerne ce destinataire : l'IP pour l'hébergeur, le domaine pour le registrar, l'adresse exacte de la page pour l'hébergeur du site ;
• la date et l'heure, avec le fuseau horaire ;
• des liens désarmés, écrits par exemple hxxps://secure-login[.]example, pour que personne ne clique par erreur.

C'est exactement le travail que fait Baitback : on colle la source de l'e-mail, l'outil lit les lignes Received, retrouve le serveur d'envoi, son hébergeur et son adresse de signalement, vérifie SPF, DKIM et DMARC, suit les liens et leurs redirections, puis prépare les messages de signalement prêts à envoyer. L'enquête de ce guide, en quelques secondes.