Nettoyer WordPress ou restaurer une sauvegarde saine ?

Après un piratage WordPress, restaurer la dernière sauvegarde ou supprimer les fichiers suspects semble être la voie la plus rapide. Pourtant, ces deux réponses peuvent échouer si la date de compromission est inconnue, si la sauvegarde contient déjà une porte dérobée ou si la cause initiale reste active. La bonne stratégie dépend du niveau de confiance que permettent les fichiers, la base, les journaux et l’historique des changements.

Pour relier ce guide à une mise en œuvre concrète, consultez l’intervention sur un site WordPress piraté : cette page précise les prérequis du diagnostic, du confinement et de la remise en service.

Commencer par un diagnostic autorisé

L’analyse doit être réalisée avec l’autorisation du propriétaire et sur un périmètre écrit : site, domaines, hébergement, base, sauvegardes et services liés. Conservez l’état compromis avant toute suppression, ainsi que les journaux encore disponibles. Cette copie ne doit pas être exposée au public. Elle permet de comparer les versions, de rechercher des persistances et de documenter les décisions.

Établissez une chronologie à partir des premiers symptômes, des alertes, des connexions, des mises à jour et des modifications légitimes. Une date d’apparition visible n’est pas forcément la date de l’intrusion. Un attaquant peut rester discret avant d’activer une redirection ou une campagne d’envoi.

Quand le nettoyage peut être envisagé

Le nettoyage consiste à identifier et retirer les modifications malveillantes tout en conservant les données et développements légitimes. Il peut être pertinent lorsque le périmètre est bien connu, que les journaux sont exploitables et que les composants officiels peuvent être comparés à des sources fiables. Le cœur WordPress, les thèmes et extensions standards peuvent souvent être remplacés par leurs versions authentiques plutôt que corrigés fichier par fichier.

Les zones personnalisées demandent davantage d’attention : thème enfant, plugin métier, médias, configuration serveur et contenu stocké en base. Il faut aussi contrôler les administrateurs, sessions, clés de sécurité, tâches planifiées, règles de réécriture, fichiers chargés automatiquement et autres sites du compte. Retirer un fichier visible sans supprimer la persistance conduit souvent à une réapparition.

Quand préférer une restauration

Une restauration peut réduire l’incertitude si une sauvegarde complète, isolée et antérieure à la compromission probable existe. Elle doit inclure les fichiers et la base dans des versions cohérentes. Avant de basculer, restaurez-la dans un environnement isolé, contrôlez les comptes, recherchez les éléments suspects et vérifiez les parcours essentiels.

Il faut ensuite réintégrer avec prudence les données légitimes créées après la sauvegarde : commandes, formulaires, contenus ou comptes clients. Copier toute la base récente dans l’ancienne installation pourrait réintroduire la compromission. Le choix des données à reprendre dépend du fonctionnement du site et mérite une procédure documentée.

Quand reconstruire sur une base propre

La reconstruction devient préférable lorsque l’origine et l’étendue restent opaques, que les sauvegardes sont douteuses ou que le site dépend de composants abandonnés. Elle consiste à installer un socle propre, récupérer seulement les données validées et réimplémenter les fonctions nécessaires. Cette approche demande plus de travail, mais évite de fonder la reprise sur une installation dont l’intégrité ne peut pas être raisonnablement établie.

Reconstruire ne signifie pas importer automatiquement tout le dossier des médias ou la totalité de la base. Chaque source doit être examinée, nettoyée et testée. Les secrets sont renouvelés, les droits recalibrés et les composants inutiles écartés.

Comparer les options avec des critères explicites

• Traçabilité : les journaux permettent-ils de dater et comprendre l’incident ?
• Sauvegardes : sont-elles complètes, isolées, testables et suffisamment anciennes ?
• Personnalisation : quelle quantité de code ou de données ne peut pas être recréée depuis une source fiable ?
• Activité récente : quelles données métier doivent être récupérées sans réintroduire le risque ?
• Maintenabilité : les versions de PHP, WordPress et des extensions peuvent-elles être mises à jour ?
• Risque accepté : quel niveau d’incertitude est compatible avec l’usage du site ?

Erreurs à éviter pendant la reprise

• Écraser immédiatement l’environnement compromis et perdre les preuves.
• Choisir une sauvegarde uniquement parce qu’elle est la plus récente.
• Réutiliser les mêmes mots de passe, clés API ou secrets WordPress.
• Oublier le compte d’hébergement, les tâches cron ou les sites voisins.
• Remettre le site en ligne après un simple contrôle de la page d’accueil.
• Présenter un scan sans alerte comme une garantie de propreté.

Checklist avant la remise en production

• Autorisation, périmètre et responsables confirmés.
• État initial, base et journaux conservés hors production.
• Option de reprise choisie et raisons documentées.
• Composants installés depuis des sources maîtrisées et mis à jour.
• Comptes, sessions, secrets, cron et règles serveur contrôlés.
• Formulaires, paiements, e-mails et fonctions métier testés.
• Plan de retour arrière disponible.
• Surveillance et contrôles postérieurs à la bascule organisés.

Obtenir un plan de remédiation adapté

Nettoyage, restauration et reconstruction ne sont pas des promesses de résultat interchangeables. Le choix doit être justifié par les éléments disponibles et le risque accepté. AdnProg peut cadrer cette décision dans le cadre d’une intervention sur site WordPress piraté, sans promettre une récupération totale ni une absence absolue de persistance.