Un domaine oublié peut permettre l’usurpation de vos emails

Un de vos clients reçoit un courriel. Il porte le nom de votre dernière campagne commerciale, il est propre, il annonce un changement de coordonnées bancaires. Le client appelle. Vous faites vérifier les accès à votre messagerie : aucun compte compromis, aucune connexion suspecte. Soulagement. Pourtant, l’adresse affichée dans ce message appartient bien à un domaine que votre entreprise détient. Exemple fictif, scénario banal.

Le soulagement est une erreur. Personne n’est entré chez vous, parce que personne n’avait besoin d’entrer : un nom de domaine que vous possédez sans l’avoir jamais protégé, n’importe qui peut l’emprunter pour écrire à vos clients en votre nom. Un domaine oublié n’est pas un détail d’intendance, c’est une signature en blanc.

J’ai écrit dns-posture, un outil publié sur npm dont le code est public sur GitHub, parce que je retrouvais ce problème dans presque tous les portefeuilles de domaines que j’ai eus sous les yeux. Il aide une équipe technique à passer en revue ses domaines chez OVHcloud et Cloudflare, à repérer les protections manquantes et à verrouiller les noms qui ne doivent envoyer aucun message. Mais l’outil vient après. Avant, il faut comprendre pourquoi le dirigeant s’est trompé de question.

Le dirigeant a vérifié ses mots de passe parce que c’est la seule image qu’il a d’une attaque : quelqu’un qui force une porte. Mais un courriel n’a pas besoin de porte. L’expéditeur écrit l’adresse qu’il veut dans le champ « De ». Le serveur qui reçoit le message ne peut pas déduire de ce seul champ que l’envoi est légitime. Les règles publiées par le propriétaire du domaine lui donnent des moyens de le vérifier. Vous avez le titre de propriété ; vous n’avez pas mis de serrure.

Qui laisse un domaine sans serrure ? Tout le monde. Le nom réservé pour un lancement qui n’a jamais eu lieu. Le domaine de la marque rachetée, conservé « au cas où ». Celui que l’agence a pris pour une campagne et que personne n’a repris quand le contrat s’est terminé. Et, plus gênant, le domaine principal lui-même, que la direction suppose protégé parce qu’il fonctionne. Qu’un domaine reçoive bien ses courriels ne dit rien de ce qu’il a déclaré sur ceux qui ont le droit d’en envoyer. L’inverse existe aussi : certains fournisseurs configurent déjà une partie des protections. On ne le sait qu’en regardant la configuration réelle, pas la facture du registrar.

Dans notre histoire, le client a reconnu le nom de la campagne. C’est cette reconnaissance que le faux message est venu emprunter. Votre notoriété travaille pour l’attaquant tant que vos domaines ne travaillent pas pour vous.

Le DNS est l’annuaire technique de votre domaine. C’est aussi l’endroit où vous publiez, pour tous les serveurs de messagerie du monde, les règles qui leur permettent de juger un courriel qui prétend venir de chez vous. Trois mécanismes, une phrase chacun. SPF liste les serveurs autorisés à envoyer en votre nom. DKIM appose une signature au message, que le destinataire peut vérifier. DMARC relie ces deux vérifications au domaine affiché dans l’adresse de l’expéditeur, et dit au destinataire quoi faire quand ça ne colle pas : rien, mettre en quarantaine, ou rejeter.

L’ANSSI décrit ces mécanismes au chapitre 5.4 de son guide d’interconnexion à Internet. Pour une messagerie en service, sa recommandation R48 prévoit une phase d’observation avant une politique DMARC stricte : on regarde d’abord qui envoie légitimement, on rejette ensuite. C’est sage. Un rejet trop précoce, et ce sont vos propres factures que les destinataires refusent.

Mais pour le domaine de campagne de notre PME, c’est bien plus simple, et c’est ce que la plupart des équipes oublient de regarder. Ce domaine ne doit envoyer aucun courriel. Jamais. Il n’y a donc rien à observer : on publie une règle SPF qui n’autorise aucun serveur, et une politique DMARC qui demande le rejet de tout message qui échoue. Trois lignes. À partir de là, les destinataires qui appliquent ces règles ont enfin un critère pour jeter le faux message. Le domaine qui envoie les vraies factures, lui, demande un travail plus patient avec le fournisseur de messagerie et chaque application qui expédie légitimement. Mais les domaines muets, vous pouvez les fermer ce mois-ci.

L’usurpation que nous venons de fermer sert à tout : du spam, une fausse page de connexion, une demande de paiement rendue crédible. Une attaque ciblée y ajoute le nom d’un de vos collaborateurs, un numéro de commande réel et le bon moment dans une relation commerciale. Le soin de la mise en scène ne change rien au fond : il faut vérifier l’expéditeur.

Les règles DNS ferment une porte, pas toutes. Elles ne protègent pas contre un compte réellement piraté, qui envoie depuis vos serveurs autorisés. Elles ne protègent pas contre un domaine ressemblant, avec une lettre de différence, que l’attaquant achète pour quelques euros. Elles ne filtrent pas le spam qui arrive dans vos boîtes. L’authentification des comptes, le filtrage des messages et, surtout, la vérification d’un changement bancaire par un autre canal, un appel au numéro que vous aviez déjà, restent des sujets de sécurité opérationnelle à part entière.

Dans notre histoire, c’est donc le processus de paiement qui doit sauver le client, pas l’apparence du courriel. La protection du domaine lui donne un signal de plus. Elle ne le dispense pas de décrocher son téléphone.

Deux décisions, pas dix. Fermer explicitement l’envoi sur chaque domaine qui ne doit rien envoyer. Faire passer en revue les expéditeurs autorisés sur la messagerie active, avec la phase d’observation que recommande l’ANSSI. À partir de là, chaque nom que vous détenez a un périmètre de protection connu, quel que soit son usage commercial, ou son absence d’usage.

C’est pour la première décision que dns-posture existe. Il dresse l’inventaire, évalue la configuration de chaque domaine et produit un rapport lisible par quelqu’un qui ne lit pas le DNS : quels noms ont été relus, quels contrôles échouent, quelles corrections l’équipe propose. Vous pouvez alors attribuer un responsable et une échéance, comme pour n’importe quel sujet de gouvernance technique. Pour un domaine sans envoi légitime, l’outil prépare les changements, conserve une sauvegarde, n’écrit qu’à la demande explicite et relit le résultat chez le fournisseur. S’il détecte une activité de messagerie, il refuse de durcir par défaut : casser vos factures n’est pas une correction. Il ne configure pas la signature DKIM d’une messagerie active, et un rapport sur le DNS reste un rapport sur une partie de votre sécurité. Le projet est indépendant ; citer l’ANSSI donne un cadre de lecture, pas un tampon.

Dans notre scénario, aucun compte compromis n’était nécessaire pour emprunter le nom de la campagne. C’est cette confiance dans le nom affiché que je veux faire examiner, avant le prochain changement de coordonnées bancaires.

La suite logique, c’est de ne pas perdre cette visibilité quand les prestataires et les projets changent. Je la décris dans l’audit des noms de domaine, de l’inventaire au rapport de suivi. L’équipe trouvera le package npm et sa documentation sur GitHub pour reproduire la démarche.