Changer d'hébergeur avec un site encore infecté : pourquoi ça échoue

Le réflexe « nouveau serveur = page blanche »

Migrer un site piraté « pour être tranquille » est le geste que l’on nous demande le plus après la réinstall. L’idée : l’hébergeur actuel est pourri, le voisin est sale, le support est lent, ailleurs ce sera neuf. Ailleurs, le Duplicator / All-in-One / tar du home contient les mêmes PHP. Le serveur neuf exécute le même payload. Vous avez payé une migration pour une réinfection à H+2, parfois une IP neuve déjà signalée le soir.

Changer d’hébergeur ne traite pas une extension vulnérable, un admin fantôme, un mot de passe réemployé. Ça change l’adresse IP et la facture. L’attaquant, lui, a encore le même login si vous n’avez pas tourné, ou le même dropper dans `mu-plugins` si vous avez tout copié.

Donc : la migration n’est pas un nettoyage. C’est un déménagement. On ne déménage pas une fuite de plomb sans la réparer. On répare, on emporte un carton propre, on change les serrures (secrets), on ferme l’ancienne porte (ancien FTP, anciens DNS TTL).

• Sale → neuf = sale ailleurs, souvent plus visible (scans à l’arrivée).
• Propre → neuf = parfois utile (IP, isolation, support).
• Neuf d’abord « on nettoiera après » = deux incidents, deux tickets.

Ce qui voyage dans le zip de migration

Les outils de migration sont conçus pour tout prendre : dotfiles, crons parfois, `wp-config`, uploads, plugins nuls, `old.zip` à la racine. C’est leur métier. C’est aussi le métier du malware de se faire emporter. Un Duplicator « installer.php » laissé public après coup est une porte en plus, neuve.

Les sauvegardes cPanel « full account » emportent mails, cron, parfois les clés SSH du home. Restaurer un full account chez le suivant, c’est recoller l’attaquant. Migrez vhost + base nettoyés, pas le compte entier « pour ne rien oublier ».

Les secrets dans `wp-config` voyagent. Considérez-les lus. Nouveaux mots de passe SQL et salts chez le nouveau, pas un copier-coller du fichier d’avant « ça marchera plus vite ».

Pourquoi le nouvel hébergeur suspend plus vite

Beaucoup scannent à l’arrivée (Imunify, Clam, leurs règles). Un PHP connu sur une IP neuve, c’est un ticket abuse immédiat, sans historique de « client depuis 2016 ». L’ancien hébergeur vous laissait parfois 48 h. Le nouveau coupe le soir. Vous voilà sans l’ancien (déjà résilié) et sans le nouveau. Classic.

L’IP neuve d’un VPS « clean » n’a pas de réputation. Un mailer pirate qui part à H+1 la grille. Vous ajoutez un problème mail à un problème web.

Si vous migrez pour fuir une suspension, le nouvel abuse verra le même motif dès que le fichier répondra 200. Vous n’avez pas fui. Vous avez transféré le dossier, plus mal.

Les journaux que vous laissez derrière

L’ancien access.log datant le premier hit, l’email d’abus, l’archive : une fois le compte clôturé, souvent inaccessibles. Migrez après avoir téléchargé ces pièces, pas après un « résiliez tout de suite ». Preuves.

L’assureur et Google se moquent que vous soyez chez X ou Y. Ils veulent l’état et les dates. Un déménagement précipité les efface.

Gardez l’ancien compte en lecture, payé un mois de plus si besoin, le temps du constat et du suivi 30 jours. C’est moins cher qu’un trou de preuves.

Quand migrer a vraiment du sens

Après nettoyage : isolation pourrie (voisin, pas de cage), IP déjà sur des listes mail, support abuse inexistant, PHP figé en 7.0, besoin de SSH réel. Là, un hébergeur plus sain est un durcissement, pas une fuite.

Pendant : seulement si l’ancien refuse toute archive et wipe dans l’heure — et encore, vous emportez ce que vous avez, vous nettoyez chez le nouveau avant le DNS public. Cas extrême, écrit, pas un ressenti « ils sont nuls ».

Ne migrez pas pour « échapper à Chrome ». Safe Browsing suit le domaine, pas l’IP. Cadenas et site dangereux : le certificat neuf n’y change rien non plus.

Ordre utile : propre, puis DNS, puis secrets encore

1) Nettoyage et constat sur l’actuel (ou sur une copie hors ligne). 2) Tree propre poussé chez le nouveau, test sur hosts / URL temporaire. 3) Vérifs mobile, `site:` n’est pas encore le nouveau. 4) DNS. 5) Tous les secrets de nouveau (l’ancien panel peut encore vivre). 6) Cron et FTP de l’ancien désactivés. 7) Surveillance des deux IP quelques jours.

Inverser 1 et 4, c’est le scénario d’échec. Inverser 5, c’est l’attaquant qui a encore l’ancien panel et réécrit un A record — plus rare, pas théorique si le DNS est chez l’hébergeur ancien.

TTL : baissez-le la veille d’une migration propre, pas au milieu d’une attaque « pour switcher vite » sans tree propre.

L’ancien serveur n’est pas mort tout de suite

Les bots tapent encore l’ancienne IP. Un vhost par défaut peut servir un autre site, ou votre old tree si vous n’avez pas vidé. Un cron de l’ancien box peut encore frapper une URL ou un mail. Coupez PHP, cron, FTP, puis résiliez.

Les emails MX : si vous ne migrez que le web, bien. Si vous migrez tout, les relais ouverts de l’ancien compte restent un sujet jusqu’à clôture.

Documentez la date de bascule. Utile pour lire les logs des deux bords. Utile pour l’assurance.

Checklist de bascule (après, pas avant)

Tree propre vérifié, secrets neufs, 2FA, pas d’installer.php public, cron listée, autres domaines du nouveau compte inspectés (ne pas poser un site propre à côté d’un addon déjà sale — vous recommencez l’histoire chez le nouveau). DNS, certificats, Search Console (propriété toujours valide), pubs.

Si le motif de départ était l’isolation : vérifiez que le nouveau cage bien les users PHP. Sinon vous avez payé un carton.

L’ordre global de l’incident reste premiers gestes. La migration est un chapitre optionnel, à la fin.