Des emails d'hameçonnage envoyés avec votre nom de domaine

Deux incidents qui se ressemblent

Le destinataire voit votre nom, parfois votre logo, et une adresse du type contact@votre-domaine.fr. Il conclut que « vous avez été piraté ». C'est parfois vrai. Ce n'est pas toujours le site qui a poussé le message. Distinguer les deux change l'ordre des gestes, le ticket hébergeur, et ce que vous devez à la CNIL si des données ont circulé.

Si le site a envoyé, il reste une porte : formulaire détourné, script PHP, compte SMTP du CMS, cron. Tant que cette porte écrit, chaque nouvelle vague aggrave la réputation du domaine. Si quelqu'un usurpe sans toucher votre hébergement, changer le mot de passe WordPress ne sert à rien : le levier est le DNS, surtout un SPF trop large.

Les deux peuvent coexister. Un attaquant qui a le FTP peut aussi envoyer, puis, une fois éjecté, continuer à usurper grâce à un `+all` oublié. On tranche avec des preuves, pas avec une impression.

• Site expéditeur : traces dans la file mail, PHP mail(), SMTP du CMS.
• Usurpation : en-têtes d'un serveur inconnu, SPF qui autorise trop.
• Mixte : les deux preuves en même temps.

Ce que disent les réponses des destinataires

Demandez une capture avec les en-têtes complets, pas seulement le corps. Dans Gmail : trois points, « Afficher l'original ». Dans Outlook : options du message, en-têtes Internet. Sans ça, vous débattez d'un logo.

La ligne Received et le champ Return-Path disent qui a vraiment poussé le message. Une IP de votre hébergeur ou de votre ESP, c'est votre infrastructure. Une IP d'un VPS inconnu avec un SPF « softfail » ou « none », c'est de l'usurpation. Un alignement DKIM sur un autre domaine pointe souvent vers un kit d'hameçonnage qui n'a jamais touché votre FTP.

Notez l'heure, l'objet, et l'URL demandée dans le mail. Si cette URL est sur votre domaine, vous avez aussi un kit d'hameçonnage hébergé : on coupe cette page d'abord.

Lire les journaux d'envoi, pas la boîte

Votre webmail ne contient pas les messages frauduleux : ils n'ont jamais transité par la boîte « contact ». Ils sont partis du PHP, d'un relais SMTP configuré dans le CMS, ou d'un compte de newsletter dont la clé a fuité. Le journal utile est celui de l'hébergeur (Exim, Postfix, file d'envoi cPanel) et celui de l'ESP si vous en utilisez un.

Demandez une extraction horodatée : volume par heure, destinataires, script ou utilisateur système qui a appelé l'envoi. Un pic à 3 h du matin depuis `wp-cron.php` ou depuis un fichier isolé à la racine est un diagnostic, pas une théorie. Copiez ce journal hors du serveur : une réinstallation le détruit.

Si la file est vide et que les en-têtes montrent un autre serveur, arrêtez de chercher un « virus mail » dans Roundcube. Passez au DNS. Le guide emails en spam détaille l'ordre listes / authentification une fois la source identifiée.

SPF trop ouvert : l'usurpation sans pirater le site

Un enregistrement SPF qui se termine par `+all` ou `?all`, ou qui inclut des plages entières « au cas où », autorise n'importe qui à parler en votre nom aux yeux de beaucoup de filtres. L'attaquant n'a pas besoin du FTP. Il a besoin que votre domaine existe et que le SPF soit laxiste.

Ne serrez pas SPF, DKIM et DMARC au milieu du chaos si vous n'êtes pas sûr de tous vos expéditeurs légitimes (boutique, factures, outil RH, agence). Un `reject` trop tôt jette aussi les confirmations de commande. On dresse la liste des vrais relais, on coupe le script s'il y en a un, puis on durcit. Les rapports DMARC aident à voir qui envoie encore.

Vérifiez aussi que personne n'a ajouté un include inconnu dans le SPF pendant l'incident. C'est rare, mais c'est un détournement DNS, pas un simple oubli.

• Inventaire : qui a le droit d'envoyer (hébergeur, ESP, CRM, caisse).
• Retrait des includes morts ou inconnus.
• Durcissement une fois la liste stable, pas la première heure.

Couper la source si c'est le site

Si les journaux montrent un envoi depuis le compte d'hébergement, l'urgence n'est pas de « réchauffer » le domaine. C'est d'arrêter la pompe. Désactivez le formulaire fautif, le plugin de contact, le SMTP du CMS, les crons inconnus. Changez le mot de passe du panel, puis FTP, puis la boîte utilisée par le site.

Cherchez ensuite la porte dérobée : un fichier qui réécrit le script d'envoi dès que vous l'enlevez. Sans ça, la file se remplit à nouveau dans la nuit. Interdire PHP dans les uploads et passer les dossiers en 755/644 réduit la surface ; ça ne remplace pas la comparaison aux fichiers d'origine.

Révoquez les clés SMTP, Brevo, Mailgun, Amazon SES liées au site. Une clé oubliée continue d'envoyer avec votre nom après un nettoyage « réussi » de WordPress.

Ce qu'il faut dire aux clients qui rappellent

Une phrase factuelle suffit : vous avez connaissance de messages usurpés ou partis à votre insu ; ne cliquez pas ; changez le mot de passe s'ils ont saisi quelque chose ; vous travaillez à couper la source. N'affirmez pas « notre site n'a jamais été touché » tant que les journaux ne sont pas lus. N'affirmez pas non plus « toutes vos données ont fuité ».

Si le mail demandait un mot de passe, un RIB ou une carte, orientez vers une vérification hors lien (rappel sur le numéro habituel, espace client connu). Gardez les captures : elles servent à l'hébergeur, parfois à une plainte ou à l'assureur.

Un communiqué long sur les réseaux crée plus de copies du kit qu'il n'en retire. Un email aux clients réguliers, daté, sans jargon, fait le travail.

Listes noires et délivrabilité ensuite

Une fois la source coupée, regardez les listes (Spamhaus, URIBL, listes Microsoft) et les rejets 550. Déposez les recours avec une date et une cause traitée, pas avec « on a changé le mot de passe ». Gmail et Outlook ne se lèvent pas à la même vitesse : voir Gmail rejette le domaine et Outlook en indésirables.

Ne changez pas d'adresse d'expéditeur toutes les heures pour « passer ». Vous brûlez un second identifiant et vous apprenez rien sur la réputation du premier. Le réchauffement commence après, avec de vrais messages, à bas volume.

Ce qui prolonge l'usurpation

Un SPF laissé en `+all` « le temps que ça se calme ». Une règle de transfert oubliée dans une boîte. Un webhook newsletter encore actif. Un sous-domaine créé « pour les devis » qui hérite de la mauvaise réputation du racine. Ce sont ces détails, plus que le premier mail, qui font un dossier de trois semaines.

Surveillez sept à trente jours : volume d'envoi, nouveaux fichiers à la racine, rapports DMARC. Si les RUA montrent encore des IP inconnues après durcissement, l'usurpation continue — ce n'est plus le site, c'est le DNS ou un relais que vous n'avez pas retiré.

Vous pouvez déclarer le site sans donner d'accès tout de suite. En attendant : captures d'en-têtes, journal d'envoi, copie du SPF actuel. Ces trois pièces suffisent à trancher le diagnostic.

• Pas de nouveau sous-domaine « pour passer les filtres ».
• Pas de newsletter de rattrapage le lendemain.
• Pas de DMARC reject le jour J si la carte des expéditeurs est floue.