Spear phishing (harponnage) : reconnaître une attaque ciblée

Le spear phishing, ou harponnage, est un hameçonnage taillé pour une seule cible : le message cite votre hiérarchie, un dossier réel et tombe au bon moment. La graphie exacte est « spear phishing » (spear, le harpon), et non « spearing phishing », mais les deux requêtes désignent la même attaque.

Hameçonnage de masse ou harponnage : la différence tient au ciblage

Un hameçonnage classique part à cent mille exemplaires avec le même prétexte bancaire et un taux de réussite ridicule qui suffit quand même à l'attaquant. Le spear phishing part à un destinataire, parfois trois personnes du même service, et le prétexte est vrai : la facture existe, le fournisseur existe, l'échéance est la bonne. Celui qui écrit a lu vos mentions légales, votre page équipe, le profil LinkedIn de la personne qu'il imite et le communiqué où vous annonciez le rachat en cours.

Le terme français recommandé par la Commission d'enrichissement de la langue française est harponnage. Vous croiserez aussi whaling quand la cible est un dirigeant, et FOVI (faux ordre de virement) ou BEC (Business Email Compromise) quand l'objectif final est un virement. Techniquement, ce sont des déclinaisons du même schéma : un message plausible, une demande urgente, un canal de vérification que la victime ne prend pas.

À ne pas confondre avec le vishing, qui passe par téléphone, ni avec le catfishing, qui construit une fausse identité sur des semaines pour un rapport affectif ou financier. Le harponnage vise un acte unique, souvent dans les 48 heures qui suivent le premier message.

Ce que l’attaquant sait de vous avant d’écrire la première ligne

La phase de reconnaissance ne demande aucun outil offensif. Votre site publie l'organigramme, les greffes publient les statuts, les réponses automatiques d'absence donnent le nom du remplaçant et son adresse, et un dépôt Git oublié laisse fuiter un fichier de configuration avec des adresses internes. Rien de tout cela n'est illégal à consulter, ce qui rend la préparation invisible.

Le volet technique tient en deux requêtes DNS. `dig +short MX exemple.fr` révèle l'hébergeur de messagerie : une réponse contenant `aspmx.l.google.com` signale Google Workspace, une réponse en `exemple-fr.mail.protection.outlook.com` signale Microsoft 365. L'attaquant sait alors quelle fausse page de connexion copier, au pixel près. Puis `dig +short TXT _dmarc.exemple.fr` : si la politique publiée est `p=none`, il peut usurper votre domaine directement sans acheter quoi que ce soit.

Le message final n'a plus rien d'un mail frauduleux générique. Il reprend la signature maison, l'objet d'un fil réel, et arrive un vendredi à 17 h 40 parce que c'est le moment où personne ne décroche pour vérifier.

• Sources ouvertes : site vitrine, page équipe, LinkedIn, communiqués de presse, annuaires d'entreprises
• Réponses automatiques d'absence, qui livrent un nom, une adresse de substitution et une date de retour
• Enregistrements DNS publics : MX pour l'hébergeur, TXT `_dmarc` pour la politique, SPF pour les prestataires autorisés
• Fuites de données antérieures, qui fournissent l'adresse exacte et parfois un ancien mot de passe cité en gage de crédibilité

Falsifier l’expéditeur : cinq méthodes et ce qui les trahit

La plus efficace n'est pas la plus sophistiquée. Sur mobile, la plupart des clients de messagerie n'affichent que le nom d'affichage : écrire `From: "Marie Rousseau (Direction)" ` suffit à faire passer le message, parce que l'adresse réelle reste repliée derrière le nom.

Le cas le plus difficile est le dernier du tableau. Quand le compte du fournisseur a réellement été compromis, l'attaquant répond dans un fil existant, depuis la vraie adresse, avec l'historique complet cité en dessous. Aucune vérification d'en-tête ne détecte quoi que ce soit. Seul le contenu alerte : un RIB qui change, une demande de paiement anticipé, une pièce jointe dans un format inhabituel.

Méthode	Ce que vous voyez	Ce qui la trahit
Nom d'affichage falsifié	Directeur financier	L'adresse réelle, une fois le nom déplié
Domaine sosie	exemp1e.fr, exemple-fr.com, exemple.co	Un caractère ou un TLD de différence, domaine enregistré récemment
Homoglyphe Unicode	exemple.fr, visuellement identique	Le « а » cyrillique (U+0430) ; le label apparaît en `xn--` dans les en-têtes bruts (punycode, RFC 3492)
Reply-To divergent	Expéditeur légitime dans le From	Le champ Reply-To pointe vers un autre domaine
Compte réellement compromis	L'adresse authentique, dans un fil réel	Rien dans les en-têtes : seuls un RIB modifié ou une urgence inhabituelle alertent

Pourquoi SPF, DKIM et DMARC laissent passer le harponnage

Les trois mécanismes servent, mais ils ne répondent pas à la question que vous vous posez. SPF (RFC 7208) valide l'adresse d'enveloppe `MAIL FROM` définie par le protocole SMTP (RFC 5321). L'adresse que votre client affiche est le champ `From` de l'en-tête, défini par un autre document, la RFC 5322. Deux champs distincts, que rien n'oblige à correspondre. DKIM (RFC 6376) signe le message avec une clé publiée dans `selecteur._domainkey.domaine`, avec un minimum de 1024 bits et 2048 recommandés depuis la RFC 8301.

DMARC (RFC 7489) raccorde les deux au domaine visible par le principe d'alignement, et publie sa politique dans un TXT sur `_dmarc.domaine` : `p=none`, `p=quarantine` ou `p=reject`, avec un alignement relâché par défaut (`aspf=r`, `adkim=r`). Beaucoup d'organisations en restent à `p=none` pendant des années, ce qui revient à observer sans rien bloquer.

Le point mort est ailleurs. Si l'attaquant enregistre `exempl3.fr`, publie son propre SPF, sa propre clé DKIM et même `p=reject`, son message est authentifié dans les règles. Vos filtres verront ceci dans l'en-tête `Authentication-Results` (RFC 8601) : `spf=pass smtp.mailfrom=compta@exempl3.fr; dkim=pass header.d=exempl3.fr; dmarc=pass header.from=exempl3.fr`. Trois `pass`, et une escroquerie complète. Ces protocoles prouvent qu'un message vient bien du domaine annoncé ; ils ne disent rien de l'honnêteté de ce domaine.

Le scénario inverse existe aussi et mérite d'être lu correctement : `spf=pass` accompagné de `dmarc=fail` signifie que le serveur émetteur était autorisé pour l'enveloppe, mais que le domaine affiché dans le `From` ne correspond pas. C'est la signature typique d'une usurpation directe.

Vérifier un message douteux, puis fermer la porte

Trois minutes suffisent pour trancher la plupart des cas. Ouvrez la source du message (Gmail : « Afficher l'original » ; Outlook : Fichier puis Propriétés) et lisez l'en-tête `Authentication-Results` avant le nom affiché. Comparez ensuite le domaine caractère par caractère et cherchez la chaîne `xn--`, qui signe un caractère non latin. Un `whois exemple.fr | grep -iE 'creat'` finit le travail : un domaine créé il y a huit jours qui réclame un virement de 40 000 euros ne demande pas d'analyse supplémentaire.

Pour tout ce qui touche à un paiement ou à un changement de coordonnées bancaires, la règle qui fonctionne n'est pas technique. Vous rappelez l'expéditeur sur un numéro que vous connaissiez déjà, pas celui figurant dans le message. Cette procédure de double validation arrête les FOVI que le filtrage laisse passer.

Côté comptes, le facteur d'authentification compte plus que sa présence. Les proxys d'hameçonnage en temps réel relaient un code TOTP (RFC 6238) ou un SMS en quelques secondes, et volent le cookie de session dans la foulée. Une clé FIDO2 ou WebAuthn ne se laisse pas relayer : la signature est liée à l'origine du site, donc `exempl3.fr` n'obtient aucune assertion valide. La signature S/MIME des messages internes ajoute un repère visuel stable pour les échanges sensibles.

Si le mot de passe a déjà été saisi, l'ordre des gestes est fixe : changer le mot de passe depuis un autre appareil, révoquer toutes les sessions actives, révoquer les jetons OAuth accordés à des applications tierces, puis inspecter les règles de la boîte de réception. Les intrusions BEC créent presque systématiquement une règle discrète qui déplace ou supprime les messages contenant « facture » ou « RIB », pour que la victime ne voie jamais la réponse du vrai fournisseur.

• Lire `Authentication-Results` dans la source brute du message, pas le nom affiché
• Comparer le domaine caractère par caractère et repérer un préfixe `xn--`
• Contrôler l'âge du domaine avec `whois` (champ `created:` chez l'AFNIC, `Creation Date:` sur les gTLD)
• Vérifier que `Reply-To` et `Return-Path` pointent vers le même domaine que le `From`
• Rappeler l'expéditeur sur un numéro connu avant tout paiement ou changement de RIB
• Signaler le message sur signal-spam.fr, et l'incident sur cybermalveillance.gouv.fr (33700 pour les SMS)

Questions fréquentes

On écrit « spear phishing » ou « spearing phishing » ?

La forme correcte est spear phishing, littéralement hameçonnage au harpon. « Spearing phishing » est une déformation courante en français, sans conséquence sur le sens : les deux renvoient à la même attaque ciblée. Le terme officiel français est harponnage.

Un message qui affiche spf=pass, dkim=pass et dmarc=pass est-il sûr ?

Non. Ces trois résultats prouvent que le message vient bien du domaine inscrit dans le champ From, rien d'autre. Un attaquant qui enregistre un domaine sosie publie ses propres enregistrements SPF, DKIM et DMARC en dix minutes et obtient trois pass. La vérification porte sur l'origine, jamais sur l'intention.

Comment savoir si un mail vient réellement de mon dirigeant ?

En sortant du canal utilisé par le message. Un appel sur un numéro déjà enregistré dans vos contacts, ou une confirmation sur la messagerie interne de l'entreprise, règle la question. Répondre au mail ne prouve rien : le champ Reply-To peut renvoyer vers la boîte de l'attaquant.

La double authentification protège-t-elle du spear phishing ?

Partiellement. Un code TOTP ou un SMS peut être relayé en direct par un proxy d'hameçonnage qui vous affiche la vraie page de connexion et récupère au passage le cookie de session. Une clé FIDO2 ou WebAuthn résiste, parce que la signature est liée au nom de domaine du site légitime et ne fonctionne pas sur un domaine sosie.

J’ai cliqué et saisi mes identifiants, que faire dans l’heure ?

Changer le mot de passe depuis un autre appareil, révoquer les sessions actives et les jetons OAuth des applications tierces, puis vérifier les règles de la boîte de réception et les redirections automatiques laissées par l'attaquant. Prévenir la banque si un paiement était en cours, signaler sur cybermalveillance.gouv.fr et déposer plainte.

Quelle différence entre spear phishing, whaling et FOVI ?

Le spear phishing désigne la méthode : un message ciblé et documenté. Le whaling précise la cible, un dirigeant ou un mandataire social. Le FOVI, ou BEC, désigne l'objectif, obtenir un virement ou un changement de coordonnées bancaires. Une même attaque peut relever des trois à la fois.

À lire aussi

catfishing · 2fa · cheval de troie · chiffrement email

Testez vos connaissances