Le domaine est usurpé : la réponse à incident, étape par étape

Les premières heures : collecter les preuves, mesurer l'ampleur

La tentation des premières heures est d'agir tout de suite sur le DNS. Le bon ordre est inverse : d'abord figer les preuves et prendre la mesure, ensuite traiter — quelques heures de collecte n'aggravent pas l'incident, mais des preuves perdues ne se recréent pas.

Les preuves. Ce qui compte, ce sont des exemplaires complets des messages frauduleux, en-têtes inclus — pas des captures d'écran. Le réflexe utile : demander aux destinataires qui se plaignent de renvoyer le message en pièce jointe (format .eml), car un transfert simple détruit les en-têtes d'origine. Dans chaque exemplaire, trois éléments se relèvent : la chaîne Received (le chemin réel du message), le champ Authentication-Results (les verdicts SPF, DKIM, DMARC du récepteur), et les URL ou pièces jointes du contenu, qui serviront aux signalements. Les rapports agrégés de la période se conservent également, ainsi qu'une main courante horodatée : qui a vu quoi, quand, et ce qui a été décidé.

L'ampleur. Les plaintes racontent des anecdotes ; les rapports agrégés donnent la seule vue d'ensemble. Ils répondent aux questions qui structurent la réponse : depuis quand la campagne tourne-t-elle ? Depuis quelles adresses IP, en quel volume, vers quels fournisseurs de réception ? Vise-t-elle le domaine principal ou un sous-domaine ? Un pic de dix messages en échec n'appelle pas la même réponse qu'une vague de cent mille. C'est cette mesure qui calibre toute la suite — y compris la communication.

Le traitement : l'incident est l'argument de l'enforcement

Pour une usurpation directe, le traitement de fond tient en une phrase : faire passer la politique DMARC du domaine à l'application. Un domaine en p=none observe et ne bloque rien ; les messages frauduleux continuent d'arriver dans les boîtes. Si l'organisation vivait avec un projet « un jour, p=reject » sans date, l'incident vient de fournir la date.

L'accélération ne dispense pas de méthode. Avant de durcir, les rapports agrégés doivent confirmer que les sources légitimes — plateforme marketing, facturation, messagerie d'entreprise — passent SPF ou DKIM avec alignement : durcir à l'aveugle bloquerait le courrier légitime en pleine crise, le pire moment. Mais en situation d'incident, le calendrier se compresse : passage rapide à p=quarantine pour envoyer le flux frauduleux en spam, puis à p=reject dès que les rapports confirment que les vraies sources tiennent. Le standard courant (DMARCbis) fournit les outils de cette progression : le mode test t=y pour signaler une politique en rodage, la balise sp= pour couvrir les sous-domaines, et np= pour fermer d'office les sous-domaines inexistants, cible fréquente des attaquants. La méthode complète, hors contexte d'urgence, est déroulée dans atteindre p=reject sans casser les emails.

Une honnêteté s'impose : DMARC ne bloque que l'usurpation directe, et seulement chez les récepteurs qui l'évaluent — la quasi-totalité des grandes boîtes grand public, une partie seulement des serveurs d'entreprise. Et si le domaine était déjà en p=reject au moment des faits, le diagnostic change : soit la campagne passe par un domaine cousin (retour à la qualification), soit un message frauduleux qui passe DKIM révèle une compromission de clé — le sujet de l'hygiène des secrets ci-dessous.

Communiquer : en interne, aux clients, à la banque, à la justice

Une usurpation attaque la confiance plus que l'infrastructure ; la communication fait donc partie du traitement, graduée selon la gravité.

En interne d'abord. Le support et l'accueil doivent être briefés avant que les appels n'arrivent : une réponse type, factuelle, qui reconnaît la campagne en cours et indique comment reconnaître les messages authentiques. La direction s'informe tôt — surtout si des paiements sont en jeu.

Les clients et partenaires ensuite, si la campagne les vise. L'avertissement part par un canal distinct du canal usurpé quand c'est possible, sans lien cliquable (un avertissement bourré de liens ressemble à du phishing), avec deux messages simples : l'entreprise ne demande jamais tel type d'action par email, et tout message douteux se vérifie par un canal connu.

La banque, sans délai, si la campagne porte sur des virements ou des factures — c'est le scénario de la fraude au président et du faux RIB. Si un paiement frauduleux est déjà parti chez un destinataire trompé, chaque heure compte pour une tentative de rappel des fonds.

La justice et les autorités, selon la gravité. Une vague de phishing générique se signale (en France, sur la plateforme dédiée cybermalveillance.gouv.fr) ; un préjudice financier ou une atteinte caractérisée à la marque justifie un dépôt de plainte, que le dossier de preuves constitué plus haut rendra recevable. Point RGPD souvent mal compris : l'usurpation du domaine, à elle seule, n'est pas une violation de données personnelles de l'organisation usurpée — la notification à la CNIL sous 72 heures ne s'impose que si l'incident révèle une compromission interne (boîte piratée, base de contacts exfiltrée).

L'hygiène des secrets après l'incident

Une question technique décide de cette étape : les messages frauduleux passaient-ils DKIM avec un sélecteur légitime du domaine ? Si oui, l'affaire dépasse l'usurpation — une clé privée a fuité, ou un système autorisé à signer est compromis. La rotation d'urgence s'impose : nouvelle clé sous un nouveau sélecteur, bascule de la signature, puis révocation de l'ancien sélecteur par la publication d'un enregistrement p= vide, qui invalide toute signature s'en réclamant.

Même sans preuve de fuite, un incident sérieux justifie une revue des secrets qui gouvernent l'identité d'envoi : clés privées DKIM, identifiants du compte DNS (qui permet de publier ou saboter SPF, DKIM et DMARC), jetons d'API des plateformes d'envoi, mots de passe SMTP. Un accès DNS compromis est le scénario le plus grave — l'attaquant y publie ses propres enregistrements et signe « légitimement ». Si une compromission interne est suspectée, tous ces secrets tournent, en commençant par ceux dont les rapports montrent qu'ils ont pu servir.

DMARC.com est édité par Hucency, spécialiste de la cybersécurité ; pour centraliser ce type de secrets — clés privées DKIM, identifiants DNS, jetons d'API — et en orchestrer la rotation après un incident, il y a Hucency Vault. Une réponse à incident sans coffre se termine trop souvent par des clés régénérées… stockées au même endroit que celles qui ont fui.

La sortie d'incident : surveillance, post-mortem, trajectoire

Un incident ne se termine pas quand les plaintes cessent ; il se termine quand trois choses sont en place.

La surveillance renforcée. Les campagnes reviennent — même infrastructure, nouveau prétexte. Pendant plusieurs semaines, les rapports agrégés se relisent à cadence rapprochée, avec une alerte sur toute nouvelle source inconnue. La baisse du volume en échec DMARC après le passage en application est aussi la métrique de succès : elle documente, chiffres à l'appui, que le traitement a porté.

Le post-mortem. Une page suffit : chronologie, vecteur, ampleur mesurée, ce qui a fonctionné, ce qui a manqué. Dans la plupart des cas, la conclusion tient en une ligne — le domaine est resté des années en p=none, et l'incident n'a fait qu'exploiter une porte connue et laissée ouverte. Ce constat, daté et partagé, est ce qui empêche le retour au statu quo une fois l'émotion retombée.

La trajectoire. La politique durcie pendant la crise devient l'état permanent : p=reject sur le domaine, sous-domaines couverts, domaines dormants verrouillés. Reste à vérifier régulièrement que la protection tient — la démarche décrite dans tester si un domaine est usurpable transforme ce contrôle en routine, au même titre que la revue des domaines cousins nouvellement déposés autour de la marque.

En résumé

Une usurpation de domaine se reconnaît à la convergence de trois signaux — plaintes de destinataires, explosion des échecs DMARC dans les rapports agrégés, retours NDR en masse. La qualification décide de tout : l'usurpation directe se traite par DMARC, le domaine cousin par le retrait et la plainte. Les premières heures servent à figer les preuves (messages complets en .eml, en-têtes, rapports) et à mesurer l'ampleur ; le traitement de fond consiste à accélérer vers l'application — p=quarantine puis p=reject — en s'appuyant sur les rapports pour ne rien casser. La communication se gradue de l'interne à la plainte, la rotation des clés DKIM et des identifiants DNS s'impose au moindre doute de compromission, et la sortie d'incident combine surveillance renforcée, post-mortem écrit et politique durcie à demeure.

Le premier réflexe, avant même le premier signalement, se joue en quelques minutes : une analyse DMARC gratuite montre si le domaine bloque réellement l'usurpation directe ou n'en a que l'apparence. Et pour suivre les rapports agrégés, détecter la prochaine campagne et piloter la trajectoire vers p=reject, la création d'un compte met en place la surveillance qui manquait au moment de l'incident.