Règles de transfert ajoutées dans une boîte : l'attaquant lit encore

Pourquoi le mot de passe ne suffit pas

Changer le secret ferme les nouvelles connexions. Une règle déjà enregistrée s'exécute côté serveur, sans mot de passe, à chaque message. C'est le mécanisme légitime de l'absence : l'attaquant l'a juste pointé vers lui.

Les dossiers que nous reprenons ont souvent « tout changé » le dimanche et découvert le transfert le jeudi, quand un client parle d'un échange que le gérant n'a jamais vu. Quatre jours de correspondance lue, parfois des pièces (RIB, contrats).

Le même principe vaut pour les délégués Outlook, les « send as », les filtres Horde, la réexpédition cPanel. Un seul endroit propre ne suffit pas. Voir aussi webmail piraté.

Où les règles se cachent

Webmail (Roundcube filtres, Horde, SOGo). Panel d'hébergement : « redirect », « forwarders », parfois au niveau du domaine entier. Microsoft 365 : règles de la boîte, règles de l'organisation, boîte partagée, transport. Google Workspace : filtres, délégation, routage. Un ESP de newsletter n'est pas une règle IMAP, mais un webhook ou un utilisateur inconnu produit le même effet.

Cherchez les destinataires que vous ne payez pas, les conditions trop larges (« tous les messages »), les suppressions silencieuses après copie. Une règle qui archive puis efface masque l'incident dans la boîte visible.

Les identités d'envoi et les réponses automatiques sont le cousin : elles ne transfèrent pas, elles parlent à votre place. Retirez-les dans la même passe.

• Filtres webmail de chaque compte.
• Forwarders du panel, y compris alias.
• Règles 365 / Workspace, y compris admin.

L'ordre : capturer, puis couper, puis tourner

Capture d'écran avec l'adresse de destination visible, horodatée. Export si l'outil le permet. Puis suppression ou désactivation de la règle. Puis mot de passe, révocation des sessions, 2FA si elle existe. Inverser laisse une fenêtre où la règle se recrée, ou vous verrouille hors de la preuve.

Si la destination est une adresse encore sous votre contrôle (test, ancienne agence), traitez-la comme compromise : l'attaquant a pu la créer. Ne « gardez pas le transfert pour voir arriver les copies ». Vous prolongez l'exfiltration.

Documentez dans le constat : quelles boîtes, quelle fenêtre, quel type de messages. C'est ce paragraphe qui sert ensuite, pas le souvenir.

Alias, listes et comptes oubliés

Un forwarder `*` ou une boîte `backup@` créée en 2019 n'apparaît pas dans le quotidien. Inventaire panel, pas mémoire. Les listes de diffusion qui explosent vers dix personnes incluent parfois une adresse pirate ajoutée comme membre.

Les comptes « prestataire » encore actifs sont des règles humaines : ils ouvrent la boîte sans filtre. Retirez l'accès, ne vous contentez pas d'un nouveau mot de passe envoyé par email sur la même boîte.

Après un MX détourné, des règles peuvent avoir été posées sur l'infrastructure pirate : vous ne les verrez pas dans votre Roundcube actuel. Notez la fenêtre MX dans le constat.

Ce que l'attaquant continue de voir

Resets de mots de passe, factures, échanges RH, pièces d'identité clients jointes « en attendant le portail ». Tant que le transfert vit, chaque jour ajoute de la matière. C'est pour cela que ce détail prolonge l'incident plus qu'un fichier spam à la racine déjà retiré.

Si des données de tiers ont transité, le volet RGPD s'ouvre : pas parce que le site a été défiguré, parce que la messagerie a fuité. N'affirmez pas l'absence de lecture : vous voyez au mieux la règle, pas le journal du Gmail distant.

Changez les mots de passe des services dont le reset est passé par ces boîtes pendant la fenêtre. Registrar et banque en priorité.

Clients lourds et téléphones

Outlook, Apple Mail, le téléphone du comptable : une règle serveur est distincte d'une règle locale. Les deux existent. Demandez à chacun de vérifier « règles » et « réexpédition » dans le logiciel, puis de se reconnecter après rotation.

Les mots de passe d'application et les comptes IMAP laissés chez un freelance se comportent comme une règle : le flux continue. Révoquez, confirmez par écrit le retrait.

Ne renvoyez pas toute la boîte « pour resynchroniser » vers un nouvel outil pendant que des forwarders vivent encore. Vous dupliquez la fuite.

Lien avec MX, SPF et le site

Une règle n'explique pas un SPF ouvert ni un site qui envoie. Ce sont trois pompes. On les ferme toutes. Un transfert + un script PHP, c'est de la correspondance lue et du spam sortant. Voir phishing depuis le domaine.

Le SMTP du CMS qui utilise la boîte transférée continue d'exfiltrer les copies des messages transactionnels. Révoquez la clé, posez un secret d'application neuf après nettoyage du site.

La délivrabilité (réchauffer) attend que les pompes soient fermées. Une règle active n'est pas un sujet de warmup, c'est de l'exfiltration en cours.

Preuve, CNIL et assurance

Stockez les captures hors du serveur mail. Une réinstallation webmail les efface. Elles servent à l'assureur, à une plainte, au délai de 72 h si une violation est confirmée.

La notification CNIL, si elle est due, vous incombe. Le prestataire décrit la règle et la fenêtre, il ne déclare pas à votre place. Dix lignes dans le registre valent mieux qu'un oubli dans six mois.

Déclarer le site pour le volet fichiers ; le volet boîtes reste le vôtre à inventorier. Les deux se recollent dans le même constat si les données se mêlent.

• Captures avant suppression.
• Liste des boîtes parcourues (même « rien trouvé »).
• Fenêtre estimée (premier mail manquant / date de règle).