Pourquoi sauvegarder un site déjà piraté (et où stocker la copie)

Pourquoi copier un site déjà sale

On sauvegarde un site déjà piraté pour trois raisons, aucune n’étant « restaurer tout à l’identique demain matin ». Première : la preuve. Assureur, Google, parfois CNIL, parfois un client qui demande ce qui s’est passé. Un zip horodaté vaut plus qu’un récit. Deuxième : le filet. Pendant le nettoyage on casse un thème, on retire un fichier de trop ; la copie permet de récupérer un contenu légitime. Troisième : la comparaison. Sans l’état infecté sous la main, on ne sait plus ce qui a été ajouté.

Le réflexe inverse — « je ne veux pas garder le virus » — conduit à tout effacer, puis à tout réinstaller, puis à se réinfecter avec une sauvegarde Updraft déjà contaminée. L’infection n’est pas une moisissure qui gagne le disque dur de votre PC si vous ne l’exécutez pas. Un zip stocké, ce n’est pas un serveur qui tourne.

Copiez avant de changer les fichiers, avant de lancer un cleaner, avant de restaurer. Après, ce n’est plus l’état de l’incident, c’est l’état de votre intervention. Pour la chronologie, c’est trop tard.

• Preuve : horodatage, contenu servi, comptes présents.
• Filet : récupérer une page, un média, un réglage.
• Comparaison : diff avec le cœur officiel ou une vieille archive propre.

Ce que « sauvegarde site piraté » veut dire concrètement

Deux objets distincts. L’archive de constat : fichiers + base tels qu’ils sont maintenant, plus les logs si vous les avez. L’archive de reprise : une sauvegarde antérieure dont vous aurez vérifié qu’elle ne contient pas encore le backdoor. On fabrique la première tout de suite. On cherche la seconde ensuite, en remontant dans le temps.

Sur un mutualisé, « copier le site » veut dire le répertoire du vhost (souvent `www/`, `public_html/`, ou un sous-dossier de domaine) et un dump SQL. Pas seulement `wp-content`. Le cœur modifié, le `.htaccess`, les mu-plugins, `wp-config.php` : c’est là que tiennent les portes. Oublier la base, c’est oublier les options qui injectent un JavaScript à chaque page.

Nommez l’archive avec la date et l’heure (`2026-08-27-1430-constat.zip`). Rangez à côté un fichier texte : ce que vous voyiez, URL, message hébergeur. Dans six mois, vous ne saurez plus lequel des trois zips est le bon.

La liste des éléments à emporter

Fichiers : tout le document root, y compris les dossiers cachés (`.htaccess`, `.user.ini`, `.env`). Sur WordPress, `wp-content/mu-plugins` et `wp-content/uploads` autant que les thèmes. Sur PrestaShop, `modules/` et `override/` autant que `img/`. Un oubli fréquent : un addon domain ou un vieux `old/` à côté du site « officiel ».

Base : export via phpMyAdmin, WP-CLI, ou l’outil du panel. Si la base fait plusieurs gigas, exportez au moins les tables d’options, d’utilisateurs, et les tables qui stockent le HTML des pages. Un dump partiel vaut mieux que rien, documentez ce qui manque.

À côté : captures d’écran (barre d’adresse), email d’abus, liste des comptes FTP/admin vus à cet instant, extrait de cron (`crontab -l` ou l’onglet Tâches du panel). Ces pièces ne sont pas dans le zip du site ; si vous ne les prenez pas maintenant, elles changent.

• Document root complet, fichiers dot inclus.
• Dump SQL (ou tables critiques si le volume bloque).
• Logs accès / erreurs / FTP / mail si encore disponibles.
• Liste des utilisateurs panel, FTP, CMS.
• Crons et variables d’environnement visibles.

Où stocker : hors compte, hors même machine

Pas dans `public_html/backup.zip`. Un zip public se télécharge, et un rançongiciel ou un second passage efface le compte entier. Pas uniquement sur le même serveur dans un dossier « privé » : la suspension, le wipe, ou le quota vous le retirent. Téléchargez sur un poste qui n’exécute pas le PHP, ou vers un stockage objet / un disque externe.

Chiffrez si la base contient des clients (zip mot de passé, ou volume chiffré). C’est une copie de données personnelles. La perdre sur une clé USB dans un train, c’est un second incident. Limitez les copies : constat + une réplication, pas six partages WeTransfer oubliés.

Si vous travaillez avec un prestataire, envoyez un lien temporaire, pas une pièce jointe de 4 Go dans la messagerie du domaine — messagerie qui peut être coupée avec le site. Le périmètre fuite de données commence parfois à cette archive mal rangée.

FTP coupé : faire produire l’archive

Ticket support, phrase utile : « Compte suspendu ou FTP injoignable, merci de générer une archive complète du vhost et un dump de la base, et de me indiquer le motif / le chemin signalé. Adresse de secours : … ». Vous demandez une copie, pas la réouverture. Les deux dans le même message noient la demande.

OVH, o2switch, LWS, PlanetHoster fournissent en général un backup panel ou une archive à la demande, avec un délai de quelques heures à un jour ouvré. Traitez ce fichier comme un constat, pas comme une source de restauration immédiate. Remettre l’archive telle quelle replace le site à l’heure de la suspension, infection comprise.

Si le support envoie un lien valable 24 h, téléchargez tout de suite. Ces liens expirent, et une relance « vous pouvez renvoyer le zip » passe en bas de file. Vérifiez que l’archive n’est pas vide (taille, présence de `wp-config` ou `app/etc`).

Les journaux partent dans le même sac

Access.log, error.log PHP, logs FTP, journal d’envoi mail, parfois `modsec`. Ils datent le premier hit, l’outil utilisé (adminer, upload, xmlrpc), l’IP. Réinstaller le CMS les laisse en place parfois, reformater le compte ou changer d’hébergeur les détruit toujours.

Sur mutualisé, la rétention est courte : 24 h à 7 jours. Copiez le jour même. Si l’hébergeur dit « on n’a plus les logs », notez-le dans le constat : c’est une limite, pas une preuve d’absence d’intrusion.

Ces fichiers servent aussi à répondre au ticket d’abus : « le chemin cité apparaît dans l’error.log à telle heure, retiré depuis ». Sans log, il reste le fichier et votre parole.

Combien de temps garder cette copie

Le temps du dossier + le délai de l’assureur (souvent deux ans pour un sinistre, lisez le contrat) + le délai utile CNIL si des données sont en jeu. En pratique, beaucoup d’agences gardent 24 mois puis détruisent. Documentez la destruction.

Garder « au cas où » sur le bureau du stagiaire n’est pas une politique. Un dossier chiffré, un responsable, une date de revue. La copie infectée n’est pas un environnement de préproduction : ne la déployez pas « pour tester » sur un serveur public.

Les captures et les emails d’abus prennent peu de place : ceux-là, gardez-les plus longtemps que le zip de 8 Go si vous devez arbitrer l’espace.

Ce que cette archive ne permet pas

Elle ne prouve pas à elle seule l’identité de l’attaquant. Elle ne remplace pas une sauvegarde propre. Elle ne dit pas si des données ont quitté le serveur (un SELECT ne laisse pas toujours de trace). Elle ne lève pas une blacklist. Elle ne dispense pas de changer les mots de passe.

Elle peut contenir des secrets en clair (`wp-config`, `.env`, clés Stripe). Traitez-la comme un coffre, pas comme une pièce jointe de suivi de projet. Si vous l’envoyez à trois prestataires « pour devis », révoquez les clés ensuite.

Pour la restauration, lisez restaurer une sauvegarde après piratage : on remonte jusqu’à un point propre, on compare, on ne réinjecte pas le constat sur le serveur de prod.

Trois erreurs qui rendent la copie inutile

Zip incomplet : seulement le thème, ou seulement `wp-content`, sans `wp-config` ni `.htaccess`. On ne peut plus expliquer l’entrée. Deuxième : copie après le cleaner. Les dates ont bougé, des fichiers ont disparu, le constat décrit votre nuit, pas l’attaque. Troisième : unique exemplaire laissé sur le compte suspendu, puis wipe sur demande du support.

Une quatrième, fréquente chez les pressés : restaurer cette copie « pour que le site revive » le soir même. Vous venez de reconstruire la scène de crime en production. Les visiteurs revoient le payload, Safe Browsing recrawl, l’hébergeur resuspend.

L’ordre utile reste celui des premiers gestes : constater, copier hors serveur, panel, ticket. La copie est l’étape 2, pas l’étape « remise en ligne ».