Spear-phishing : la mécanique d’une attaque ciblée et ce qui l’arrête

Phishing, spear-phishing, whaling, BEC : où passe la frontière

Le phishing de masse envoie le même texte à des dizaines de milliers d'adresses et vit sur le taux de réponse. Le spear-phishing fonctionne à l'envers : un message, une cible, un prétexte bâti sur des éléments vérifiables. Le nom de votre comptable, la référence de la facture ouverte, le prestataire que vous avez réglé le mois dernier.

La confusion la plus tenace concerne le BEC (Business Email Compromise, la fraude au président en français administratif). Le spear-phishing désigne une technique d'envoi. Le BEC désigne un objectif financier : faire partir un virement, faire changer un RIB fournisseur. Un BEC démarre presque toujours par du spear-phishing, la réciproque est fausse, beaucoup de campagnes ciblées cherchent un accès durable et pas un paiement immédiat.

Le rapport IC3 2023 du FBI recense 21 489 plaintes pour BEC et plus de 2,9 milliards de dollars de pertes déclarées. Ce chiffre se lit avec précaution : il ne couvre que les signalements volontaires reçus aux États-Unis, donc il minore la réalité au lieu de la mesurer.

Terme	Nombre de cibles	Personnalisation	Objectif le plus fréquent
Phishing	Des milliers	Nulle ou générique	Identifiants bancaires, comptes grand public
Spear-phishing	Une à quelques dizaines	Nom, poste, dossier en cours	Accès à un compte, dépôt d'un implant
Whaling	Un dirigeant	Très forte, contexte juridique ou financier	Validation d'une opération sensible
BEC	Comptabilité ou direction	Forte, parfois depuis une boîte déjà compromise	Virement détourné, changement de RIB

La phase de reconnaissance, celle que personne ne voit

Avant le premier e-mail, l'attaquant passe des heures à lire. Vos mentions légales donnent le gérant et l'adresse. LinkedIn donne l'organigramme et les arrivées récentes, plus faciles à tromper. Un message d'absence automatique renvoyé par un salarié donne le nom du remplaçant et la date de retour. Les métadonnées d'un PDF publié sur votre site donnent parfois le nom d'utilisateur Windows et la version d'Office.

La partie réseau est encore plus rentable. Une seule requête suffit à savoir chez qui votre messagerie est hébergée : dig +short MX exemple.fr. Si la réponse ressemble à exemple-fr.mail.protection.outlook.com, la cible est sur Microsoft 365, et la fausse page de connexion sera une copie de login.microsoftonline.com plutôt qu'un formulaire générique. Un enregistrement en aspmx.l.google.com oriente vers Google Workspace.

Le domaine sosie se prépare en dernier. Un whois exemple-fr.com qui renvoie une Creation Date vieille de trois jours est un signal fort. Depuis l'entrée en application du RGPD, les coordonnées du titulaire sont masquées chez la plupart des registres, mais les dates de création et d'expiration restent publiques, et elles suffisent.

• Nom, fonction et hiérarchie directe de la cible, récupérés sur les réseaux professionnels
• Format des adresses internes (prenom.nom@, initiale+nom@), déduit d'une seule adresse publique
• Hébergeur de messagerie, via les enregistrements MX du domaine
• Politique DMARC publiée, via dig +short TXT _dmarc.exemple.fr : une politique p=none indique que l'usurpation directe du domaine passera
• Prestataires et clients cités dans les communiqués, qui fournissent le prétexte de la facture
• Modèle de signature et charte graphique, copiés depuis n'importe quel échange antérieur

Lire l’en-tête plutôt que le corps du message

Le corps du message est écrit pour vous convaincre, l'en-tête est écrit par des machines. C'est là qu'il faut regarder. Dans un client web, la fonction s'appelle « Afficher l'original » chez Google et « Propriétés du message » chez Outlook.

La ligne à trouver est Authentication-Results, normalisée par la RFC 8601. Elle résume trois vérifications distinctes : SPF (RFC 7208) valide l'adresse IP émettrice pour le domaine d'enveloppe, DKIM (RFC 6376) valide une signature cryptographique posée par le domaine signataire, DMARC (RFC 7489) exige en plus que l'un des deux corresponde au domaine affiché dans le champ From. Une combinaison spf=pass suivie de dmarc=fail est le cas classique : le serveur d'envoi était bien autorisé pour son propre domaine, mais ce domaine n'a rien à voir avec l'expéditeur que vous voyez à l'écran.

Le nom d'affichage n'est authentifié par rien. Un attaquant peut écrire « Direction Financière » dans le champ From et poser derrière une adresse jetable, et la plupart des clients mobiles n'affichent que le nom. Contrôlez toujours l'adresse complète, puis le champ Reply-To : un From en directeur@entreprise.fr couplé à un Reply-To en directeur.entreprise@gmail.com est un aveu.

Les lignes Received se lisent de bas en haut et contiennent l'adresse IP du premier serveur émetteur. Un whois de cette IP et son ASN vous disent si le message est parti d'un opérateur résidentiel étranger ou d'un serveur d'envoi légitime. Deux réserves : seules les lignes ajoutées par votre propre infrastructure sont fiables, celles du dessus peuvent être fabriquées, et une IP appartenant à une plateforme d'e-mailing connue ne prouve rien, ces plateformes ont toutes une offre gratuite.

• Adresse complète de l'expéditeur, pas le nom affiché
• Divergence entre From et Reply-To
• Résultat dmarc= dans Authentication-Results
• Domaine en xn--, préfixe qui signale un nom en punycode et donc des caractères non latins imitant l'alphabet romain
• Date de création du domaine expéditeur, via whois
• IP source de la première ligne Received, et l'ASN auquel elle appartient

Ce qui bloque réellement une attaque ciblée

Publier un DMARC en p=reject empêche qu'on usurpe votre domaine pour écrire à vos clients. Cela ne protège pas vos salariés d'un domaine voisin qui aura, lui aussi, son SPF propre et son DMARC valide. Les deux problèmes sont distincts et demandent deux réponses.

Sur SPF, une limite technique se retourne souvent contre les équipes : la RFC 7208 plafonne à dix le nombre de requêtes DNS déclenchées par l'évaluation d'un enregistrement, mécanismes include compris. Au-delà, le résultat bascule en permerror et l'alignement DMARC tombe pour vos messages légitimes. Comptez vos include avant d'ajouter le onzième prestataire.

Le second facteur mérite une distinction nette. Un code TOTP à six chiffres ou un SMS se relaie en temps réel : l'attaquant place un proxy entre vous et le vrai site, vous saisissez le code sur sa page, il le rejoue dans la seconde et récupère le cookie de session. Une clé FIDO2 ou une passkey WebAuthn ne se relaie pas, parce que la signature produite est liée à l'origine du site qui la demande. Un domaine sosie n'obtient donc aucune assertion exploitable. C'est la seule différence qui tienne face à ce scénario.

Pour surveiller les domaines sosies, exploitez les journaux de Certificate Transparency (RFC 6962, mise à jour par la RFC 9162). Un attaquant qui veut du HTTPS sur son faux domaine doit obtenir un certificat, et ce certificat est journalisé publiquement. Une alerte sur les variantes de votre marque via crt.sh vous prévient souvent avant le premier envoi.

Reste la mesure la moins technique et la plus rentable : toute modification de coordonnées bancaires se confirme par un canal différent, sur un numéro déjà connu, jamais sur celui indiqué dans le message.

Après le clic : les quinze premières minutes

Changer le mot de passe ne suffit pas. Si l'attaque a transité par un proxy adverse, ce qui a été volé est le cookie de session, valide indépendamment du mot de passe. Il faut révoquer les sessions actives et les jetons de rafraîchissement, sinon l'accès reste ouvert.

Inspectez ensuite les règles de la boîte aux lettres. La persistance la plus courante après un compromis de messagerie est une règle discrète qui déplace tout message contenant « facture », « RIB » ou le nom du comptable vers un dossier peu consulté, le temps que la fraude aboutisse. Vérifiez aussi les délégations et les applications OAuth autorisées, puis les journaux de connexion : une authentification réussie depuis une IP située dans un pays où vous n'avez aucune activité date l'intrusion.

Côté déclaration, cybermalveillance.gouv.fr oriente les entreprises et les particuliers, signal-spam.fr collecte les messages frauduleux, et un dépôt de plainte reste nécessaire pour toute tentative de virement. Si le virement est parti, contactez la banque dans l'heure : une demande de rappel de fonds a des chances réelles tant que l'argent n'a pas été retiré du compte destinataire.

Questions fréquentes

Comment vérifier qu’un e-mail vient vraiment de mon directeur ?

Ouvrez l'en-tête complet et cherchez la ligne Authentication-Results. Si dmarc affiche fail alors que le champ From montre votre domaine interne, le message est usurpé. Ensuite, comparez l'adresse complète (pas le nom affiché) et le champ Reply-To. En dernier recours, appelez le numéro que vous avez déjà dans votre répertoire, jamais celui écrit dans le message.

SPF, DKIM et DMARC suffisent-ils à arrêter le spear-phishing ?

Non. Ces trois mécanismes empêchent qu'on écrive en se faisant passer pour votre domaine exact. Ils ne font rien contre un domaine acheté la veille, qui publie son propre SPF et signe correctement ses messages : techniquement, tout est valide, seule l'orthographe du nom diffère. La surveillance des dépôts de domaines proches et l'authentification résistante au relais complètent le dispositif.

Le spear-phishing passe-t-il uniquement par e-mail ?

Non. Le même travail de reconnaissance alimente des SMS (smishing), des messages LinkedIn ou Teams, et des appels téléphoniques (vishing). Le canal vocal est devenu plus dangereux depuis que quelques secondes d'enregistrement public suffisent à cloner une voix. La contre-mesure ne change pas : rappeler sur un numéro connu à l'avance.

Peut-on remonter à l’attaquant grâce à l’adresse IP du message ?

Rarement jusqu'à une personne. L'IP de la première ligne Received identifie un serveur, souvent un VPS loué avec une carte volée, un relais compromis ou une plateforme d'envoi mutualisée. Elle sert à l'enquête et au blocage, elle ne désigne pas un responsable. Seuls le fournisseur d'hébergement et l'autorité judiciaire peuvent aller plus loin.

Quelle différence entre spear-phishing et whaling ?

Le whaling est un spear-phishing dont la cible est un dirigeant ou un membre du comité de direction. Le prétexte y est généralement juridique ou financier (assignation, audit, opération confidentielle) et la préparation plus longue, parce que le gain attendu est plus élevé. La technique sous-jacente est identique.

Testez vos connaissances

À lire aussi

authentification a deux facteurs 2fa · chiffrement email · attaque man in the middle · cheval de troie