Webmail Roundcube ou Horde piraté en même temps que le site

Pourquoi le webmail tombe avec le site

Sur un mutualisé, le panel, le FTP et Roundcube partagent souvent le même secret, ou un secret voisin écrit dans un email à l'agence. Qui a lu `wp-config` a parfois aussi lu un mot de passe de boîte stocké dans un plugin SMTP. Ce n'est pas « Horde qui a une faille » à chaque fois : c'est la réutilisation.

Il existe aussi des failles webmail, patchées par l'hébergeur à son rythme. Vous n'avez pas à les reproduire. Vous avez à constater : connexions hors vos horaires, pays inconnus, règles que personne n'a créées, brouillons étranges. Le journal IMAP / auth de l'hébergeur tranche mieux qu'un antivirus de poste.

Un site propre avec une boîte encore ouverte, c'est un canal de reset pour tout le reste : registrar, Stripe, Search Console. On ferme les boîtes dans la même fenêtre que le panel, pas « la semaine prochaine ».

Ce qu'on ouvre avant de changer les mots de passe

Changez trop tôt, et vous perdez l'écran des règles et des appareils. Ouvrez chaque interface (Roundcube, Horde, SOGo, webmail propriétaire) : filtres, réexpédition, réponses automatiques, carnet d'adresses récemment modifié, identités d'expéditeur. Capturez. Puis seulement, changez le mot de passe.

Cherchez une réexpédition vers une adresse personnelle que vous ne reconnaissez pas, un filtre « si objet contient facture alors supprimer », une identité qui envoie sous le nom du gérant depuis un autre domaine. Ce sont des persistances. Elles survivent au mot de passe.

Si vous n'avez plus l'accès webmail, passez par le panel d'hébergement : réinitialisation, liste des comptes, parfois un export des filtres. Ne recréez pas toutes les boîtes à l'aveugle : vous détruisez la preuve et les archives utiles à un constat.

• Filtres et transfert, dans chaque compte.
• Identités et signatures.
• Appareils et sessions IMAP listés par l'hébergeur s'ils existent.

Toutes les boîtes, pas seulement contact@

Les attaquants préfèrent les boîtes à fort privilège : direction, compta, « admin@ », l'adresse du webmaster. Une alias oubliée `info@` qui atterrit dans la même boîte suffit. Inventoriez depuis le panel, pas depuis le souvenir.

Les boîtes de l'agence ou du freelance encore actives sont des portes. Désactivez-les ou changez-les, même si « on en a besoin pour un redirect ». Un redirect se fait au niveau serveur, sans laisser un mot de passe ancien vivant.

Les listes de diffusion internes et les adresses de tickets (support@) reçoivent souvent des pièces jointes : factures, CNI clients. Si elles ont été ouvertes, le volet données s'ouvre, indépendamment du défacement du site.

Règles, filtres et identités d'envoi

Une règle « tout transférer vers Gmail » est le détail qui prolonge l'incident d'un mois. Elle est traitée dans règles de transfert ; ici, le point est de ne pas s'arrêter à Roundcube. Horde a ses filtres. Le panel a parfois une réexpédition globale par compte, invisible dans le webmail.

Les identités permettent d'envoyer avec un From usurpée en interne (un commercial qui « est » le gérant). Après incident, alignez les From sur les boîtes réelles et retirez les identités inconnues.

Videz les brouillons suspects et les messages en file d'attente côté serveur si l'hébergeur le permet. Ne renvoyez pas la file « pour voir » : ce peut être la queue de spam. Voir bounces en masse.

Double authentification côté hébergeur

Beaucoup d'hébergeurs proposent une 2FA sur le panel, rarement sur chaque boîte IMAP. Activez ce qui existe. Ça ne remplace pas un mot de passe unique par boîte, et ça n'efface pas une règle déjà posée.

Si l'hébergeur n'offre rien sur le webmail, réduisez la surface : interdisez l'accès webmail depuis l'étranger si le panel le permet, ou basculez la messagerie critique vers un prestataire qui a la 2FA (Workspace, Microsoft 365) — après l'incident, pas pendant la file de spam.

La 2FA du CMS est un autre sujet (admin CMS). Ici, c'est le compte qui ouvre Roundcube et le FTP.

Sessions et appareils déjà connectés

Un mot de passe nouveau avec Outlook, le téléphone du gérant et le portable d'un stagiaire encore connectés en IMAP, c'est un théâtre. Déconnectez les sessions, régénérez les mots de passe d'application, retirez les comptes des logiciels de messagerie que vous ne contrôlez plus.

Les clients lourds gardent une copie locale. Ce n'est pas grave. Ce qui l'est : un Outlook chez un prestataire qui continue de se synchroniser. Demandez une confirmation écrite que le compte a été retiré.

Si des clés SMTP du site pointaient vers cette boîte, révoquez-les. Le CMS renverra des erreurs le temps de reconfigurer : c'est préférable à un second envoi frauduleux.

Lien avec le site et le SMTP

WordPress, PrestaShop, les formulaires : cherchez l'adresse et le mot de passe SMTP en clair dans les extensions. C'est souvent ainsi que le site et le webmail tombent ensemble. Après rotation, mettez un mot de passe d'application, pas le mot de passe de la boîte humaine.

Une backdoor PHP peut relire la nouvelle config et renvoyer. Le nettoyage fichiers et le chantier webmail se terminent le même jour, ou la porte réécrit le SMTP dans la nuit.

Testez un envoi légitime unique (reset, devis) après coupure de la source, pas une newsletter. La délivrabilité se joue ensuite, pas avec une file de rattrapage.

Preuves et suite RGPD

Conservez hors serveur : captures des règles, journaux d'auth, liste des IP de connexion, date de rotation. Réinstaller le webmail « pour être sûr » les détruit. Ces pièces servent à l'assureur et, si des messages clients ont été lus, au constat de fuite.

N'écrivez pas aux personnes « votre boîte chez nous a été lue » si vous parlez de votre propre messagerie interne. Distinguez : vos boîtes pro vs la table clients du site. Les obligations ne sont pas les mêmes. En cas de doute, le constat technique d'abord, la phrase ensuite.

Vous pouvez créer un compte pour faire reprendre le site ; le webmail reste votre périmètre registrar / hébergeur. Un prestataire sérieux ne « s'occupe pas de la CNIL à votre place ».

• Captures avant rotation des mots de passe.
• Journaux d'auth demandés à l'hébergeur.
• Inventaire des boîtes et alias.