Restaurer une sauvegarde après piratage : les 4 pièges

Le réflexe « dernière sauvegarde »

Restaurer une sauvegarde après piratage paraît le geste le plus sûr : on « annule ». Sur les dossiers que nous reprenons, c’est l’un des deux accélérateurs de réinfection, avec la suppression au hasard. La sauvegarde de 3 h du matin a été prise pendant que le backdoor était en place. Updraft, All-in-One, Jetpack, backup cPanel : l’outil ne trie pas le propre et le sale.

Ce que vous voulez, ce n’est pas « hier ». C’est « avant l’entrée ». Hier, l’attaquant avait déjà un mu-plugin, un utilisateur `wp_admin`, une option `siteurl` retouchée, ou un cron. Remettre hier, c’est lui rendre les clés et lui offrir un site de nouveau joignable — parfois après que l’hébergeur vient juste de suspendre.

Donc on ne restore pas pour se rassurer. On restore quand on a un candidat daté, ouvert, comparé, et un plan pour refermer la faille qui a servi. Sinon on copie l’état actuel (constat) et on nettoie à partir du cœur officiel, pas à partir d’un zip de la veille.

• Constater et copier l’état infecté d’abord.
• Lister les sauvegardes avec leurs dates, pas « la dernière ».
• Ouvrir avant d’appliquer.
• Refermer l’entrée après, pas « on verra si ça revient ».

Piège 1 — le backup est déjà infecté

Les signes dans l’archive : un PHP à la racine qui n’existe pas dans le zip WordPress officiel, un `wp-content/mu-plugins` que vous n’avez jamais créé, un `index.php` de thème plus lourd que l’original, une table `wp_options` avec un `autoload` qui contient un `eval` ou un `<script src="https://…">` inconnu. Ouvrez le zip sur le PC, sans l’envoyer sur le serveur.

Comparez les dates internes. Si `wp-includes/canonical.php` a été modifié le même jour que vos premiers titres en japonais, le cœur dans le backup n’est pas le cœur. Une sauvegarde Updraft infectée est un cas banal : le plugin a fait son travail, il a photographié le crime.

Les sauvegardes « incrémentales » trompent : elles rejouent les fichiers changés, donc le payload, plus efficacement encore. Une full hebdomadaire plus ancienne, même incomplète sur le contenu, est parfois plus saine que l’incrémental de la nuit dernière.

Piège 2 — restaurer sans ouvrir l’archive

Le bouton « Restore » du panel ou du plugin n’affiche pas un diff. Il écrase. Dix minutes plus tard le site « marche », la redirection mobile aussi. Vous avez perdu l’état intermédiaire (celui que vous aviez commencé à nettoyer) et vous n’avez plus le constat si vous n’aviez pas copié ailleurs.

Minimum avant clic : extraire, chercher `eval(`, `base64_decode(`, `gzinflate(`, des `assert(`, des domaines que vous ne connaissez pas dans les `.js` du thème, des utilisateurs SQL en trop. Ce n’est pas un audit complet ; c’est un filtre qui évite le pire. Si vous ne savez pas lire ça, ne restorez pas : déléguez ou nettoyez à partir des zips officiels du CMS.

Vérifiez aussi que l’archive est celle du bon site. Sur un compte multi-domaines, le mauvais dossier restauré au mauvais endroit crée un mélange (vieux PrestaShop dans un WordPress) qui ressemble à une catastrophe plus grave que le piratage.

Piège 3 — écraser les journaux et le constat

Une restauration cPanel « compte entier » peut remplacer les logs, les mails, les crons, les comptes FTP. Vous perdez la chronologie et parfois l’utilisateur panel que l’attaquant avait ajouté — donc la preuve, et parfois le seul accès qui vous restait si vous n’aviez pas noté les identifiants.

Restaurez le vhost et la base, pas forcément le compte entier, sauf si vous savez ce que le curseur inclut. Demandez à l’hébergeur la liste : `home`, `www`, `sql`, `mail`, `cron`. Décochez mail et logs si vous les avez déjà copiés et que vous voulez les garder.

Le constat (zip hors serveur) doit exister avant tout restore. C’est le filet si le restore se passe mal, et la pièce pour l’assurance.

Piège 4 — remettre les mots de passe d’avant

L’archive contient `wp-config.php`, `.env`, parfois un fichier de mots de passe d’admin dans un vieux ticket. Restaurer, c’est remettre le secret que l’attaquant a déjà lu. Changez panel et FTP avant le restore, puis CMS et base après, comme dans l’ordre des mots de passe.

Les Application Passwords WordPress, les clés WooCommerce, les webservice PrestaShop : ils sont dans la base. Un restore les ressuscite. Révoquez après coup, pas « si on y pense ».

Si vous aviez enfin un admin propre et que le restore ramène `hackadmin`, vous venez de vous fermer wp-admin. Gardez un accès panel et un utilisateur SQL à vous, hors archive, avant de lancer le job.

Comment dater un point encore propre

Remontez aux premiers signaux : premier titre étranger dans Search Console (couverture, dates), premier email d’abus, première date de fichier PHP inconnu, premier utilisateur fantôme. La sauvegarde utile est antérieure au plus ancien de ces signaux, avec une marge. Une attaque peut dormir : un shell déposé en mars, utilisé en juin.

S’il n’y a aucune sauvegarde antérieure, n’inventez pas. Repartez des zips officiels (cœur, extensions, thème parent), réimportez contenus depuis l’état actuel après nettoyage, pas l’inverse. C’est plus long qu’un bouton Restore. C’est plus court qu’une troisième réinfection.

Pour un site rarement modifié, une archive à J-30 est souvent saine. Pour une boutique qui reçoit des modules chaque semaine, J-30 peut déjà être sale. La date seule ne décide pas : l’ouverture de l’archive décide.

• Plus ancien signal (Google, abus, fichier, compte) = borne haute.
• Ouvrir deux sauvegardes (borne et une plus vieille) et comparer.
• Si aucune n’est propre : cœur officiel + contenus nettoyés.

Restauration partielle plutôt que rewind total

On restore souvent trop large. Une home défigurée : le template ou la page, pas tout `wp-content`. Un `.htaccess` pirate : ce fichier, après avoir recopié vos permaliens. Une table `wp_options` injectée : cette table, ou mieux, la ligne, pas un dump d’il y a six mois qui efface les commandes WooCommerce.

Les commandes, les contenus, les médias récents sont dans l’état actuel. Les perdre pour « être sûr » coûte plus cher que l’incident. D’où la copie de constat avant toute tentative : vous pourrez extraire une table ou un dossier uploads propre à la main.

Sur PrestaShop, un rewind complet fait perdre stocks et commandes. Comparez `modules/` au zip de la version, retirez l’override sale, gardez `img/` et la base après audit des employés et du JavaScript de checkout.

Après le restore : l’entrée est toujours là

Si l’attaquant est passé par une extension jamais mise à jour, le restore ramène l’extension vulnérable. Si c’est un mot de passe faible, il est encore faible — ou de nouveau l’ancien. Si c’est le voisin de compte, le restore du seul site ne change rien. Le bouton Restore ne ferme aucune porte.

Enchaînez : mots de passe panel déjà changés, comptes CMS, clés, mise à jour ou retrait de l’entrée, scan des autres sites du compte, cron, mu-plugins. Surveillez `site:` et les dates de fichiers 48 h puis sept jours. Une backdoor oubliée réécrit le payload le soir même.

Si le restore a été fait trop tôt et que ça a recommencé : ne restorez pas une troisième fois la même archive. Revenez au constat, changez de méthode. Les premiers gestes reprennent l’ordre sans le rewind magique.