Restaurer un site WordPress après un piratage : la procédure complète

Restaurer un site WordPress après un piratage : la procédure complète

Un site WordPress piraté se restaure en cinq phases : diagnostic de l'infection, isolation, investigation des logs, nettoyage ou restauration depuis une sauvegarde saine, puis durcissement. Le choix entre nettoyer et restaurer dépend de trois critères — l'ancienneté de votre dernière sauvegarde saine, l'étendue de l'infection et le périmètre touché — que l'arbre de décision de cet article tranche.

Ce guide s'adresse aux responsables techniques qui gèrent un parc de sites. Il donne les commandes de détection, l'ordre des opérations et les critères objectifs pour décider vite, sans réinstaller à l'aveugle.

Identifier le type et l'étendue du piratage

Avant de toucher au site, qualifiez l'incident. La documentation officielle de WordPress parle d'indicateurs de compromission : mise en liste noire par Google, hébergeur qui coupe le compte, envoi de spam, création de comptes administrateurs inconnus, redirections inattendues. Notez l'heure, le fuseau et vos dernières actions — plugin installé, thème modifié. Ces notes deviennent votre rapport d'incident.

Backdoor, spam SEO, malware, défiguration

Quatre familles couvrent la majorité des cas. La défiguration remplace la page d'accueil par un message : visible, mais souvent superficielle. Le spam SEO injecte des liens et des pages cachées pour détourner votre référencement. Le malware sert du code malveillant aux visiteurs. La backdoor est la plus sournoise : un fichier qui redonne l'accès au pirate même après nettoyage. Un incident combine souvent plusieurs familles.

Scanner avant d'agir

Croisez deux angles de scan. Un scanner applicatif comme Wordfence ou le plugin Sucuri inspecte les fichiers depuis l'intérieur ; un scanner externe analyse le rendu public et la réputation du domaine. Le scan de sécurité gratuit de Sentinelo donne un premier verdict sans installer de plugin sur un site déjà compromis. Aucun scanner n'est complet seul : c'est leur croisement qui réduit les angles morts.

Phase 1 : isoler et communiquer (0-1 h)

Coupez d'abord la propagation. Activez le mode maintenance pour fermer le site aux visiteurs et stopper la diffusion de code malveillant. Prévenez votre hébergeur : sur un hébergement mutualisé, l'attaque peut dépasser votre seul site. Prévenez aussi le client, en factuel — ce qui est constaté, ce qui est en cours, le délai estimé. Pas d'alarmisme, une action par phrase.

Changez immédiatement les accès sensibles : wp-admin, FTP/SFTP, base de données, panneau d'hébergement. Forcez la déconnexion de toutes les sessions en régénérant les clés secrètes du fichier wp-config.php. Vous changerez les mots de passe une seconde fois une fois le site propre.

Phase 2 : investiguer (1-4 h)

Avant de nettoyer, conservez les preuves. L'ANSSI, via cybermalveillance.gouv.fr, recommande de récupérer les journaux du pare-feu, du proxy et des serveurs touchés — utiles pour comprendre l'attaque et pour un éventuel dépôt de plainte. Faites une copie de l'état infecté avant toute modification : même mauvaise, cette copie servira de référence.

Lire les logs et trouver le vecteur d'entrée

Le vecteur se lit dans les logs d'accès. Cherchez les requêtes POST vers des fichiers PHP inhabituels, les pics depuis une même adresse IP, les appels à des fichiers que vous ne reconnaissez pas :

• grep -E "POST " /var/log/nginx/access.log — isole les requêtes POST
• grep -ri "wp-login.php" /var/log/nginx/access.log — repère le bruteforce sur l'authentification

Un pic de POST sur wp-login.php pointe vers une attaque par force brute ; une requête POST vers un fichier du dossier uploads trahit presque toujours une backdoor déjà en place.

Lister les fichiers modifiés récemment

Les fichiers touchés portent une date de modification récente. Depuis la racine du site :

• find . -type f -mtime -7 -ls — liste les fichiers modifiés depuis sept jours
• find wp-content/uploads -name "*.php" — un fichier PHP dans uploads est anormal
• grep -rl --include=*.php "base64_decode\|eval(\|gzinflate" . — repère les motifs classiques d'obfuscation

Recoupez toujours : un fichier modifié récemment, contenant du code encodé et jamais légitime à cet emplacement, est un suspect sérieux. Les fichiers .htaccess, index.php, header.php, footer.php et functions.php sont les cibles les plus fréquentes.

Nettoyer ou restaurer : trois critères tranchent.

Nettoyer ou restaurer : l'arbre de décision

C'est le choix qui détermine tout le reste. Plutôt que de trancher à l'instinct, évaluez trois critères : l'ancienneté de votre dernière sauvegarde saine, l'étendue de l'infection et le périmètre touché.

Critère	Plutôt nettoyer	Plutôt restaurer
Sauvegarde saine	Aucune sauvegarde fiable antérieure à l'infection	Sauvegarde vérifiée datant d'avant la compromission
Étendue	Quelques fichiers isolés, backdoor localisée	Core, thème et base de données atteints
Périmètre	Un seul site concerné	Plusieurs sites d'un même hébergement
Contenu récent	Commandes ou articles créés depuis la sauvegarde	Peu de contenu produit depuis la sauvegarde

Règle simple : une sauvegarde saine et récente l'emporte presque toujours. Restaurer est plus rapide et plus sûr que traquer chaque fichier à la main. Le nettoyage manuel reste réservé aux cas sans sauvegarde exploitable.

Restaurer depuis une sauvegarde saine

Un point critique, souligné par cybermalveillance.gouv.fr : une sauvegarde postérieure au piratage est elle-même suspecte. Choisissez une archive antérieure à la date de compromission repérée en phase 2. Restaurez l'ensemble — fichiers et base de données — puis corrigez la faille d'entrée avant toute remise en ligne, sans quoi le site sera repris aussitôt. Appliquez enfin toutes les mises à jour : l'ancienne version est probablement ce qui a ouvert la porte.

La sauvegarde managée de Sentinelo conserve plusieurs générations d'archives — 7 quotidiennes, 4 hebdomadaires, 12 mensuelles et 1 annuelle sur 24 mois — ce qui permet de remonter à un point sain même quand l'infection est passée inaperçue plusieurs semaines.

Nettoyer manuellement sans sauvegarde récente

Sans sauvegarde exploitable, le nettoyage suit un ordre précis. Réinstallez le core WordPress dans la même version en remplaçant les dossiers /wp-admin et /wp-includes par FTP, jamais par le bouton de réinstallation de l'admin, qui n'écrase pas les fichiers ajoutés par le pirate. Réinstallez thèmes et extensions depuis leurs sources officielles. Inspectez wp-content, le fichier wp-config.php et chaque .htaccess, qui hébergent souvent la backdoor. Supprimez tout compte administrateur inconnu.

Pour comparer vos fichiers à l'original et repérer les écarts, le gestionnaire de versions aide : la documentation officielle recommande de comparer l'installation aux fichiers du dépôt WordPress. Voir la procédure de détection et correction des plugins vulnérables pour traiter le vecteur le plus courant.

Phase 4 : durcir après l'incident

Un site nettoyé n'est pas encore un site sûr. Faites tourner tous les mots de passe une seconde fois, maintenant que l'infection est écartée, et imposez l'authentification à deux facteurs sur les comptes administrateurs. Supprimez les extensions et thèmes inutilisés : chaque composant dormant est une surface d'attaque. Vérifiez les droits de fichiers et désactivez l'édition de code depuis l'admin. Côté serveur, restreignez l'accès à wp-login.php et aux fichiers sensibles via la configuration Nginx. La méthode d'audit et de durcissement WordPress pour agences détaille ce passage. La brique sécurité de Sentinelo applique 19 contrôles sur WordPress, croisés avec la base WPScan, pour surveiller ce durcissement dans le temps.

Phase 5 : le post-mortem client

Clôturez l'incident par un compte rendu court et honnête : ce qui s'est passé, le vecteur identifié, les données éventuellement exposées et les mesures prises pour éviter la récidive. Si des données personnelles ont fuité, la notification à la CNIL peut être obligatoire. Ce document rassure le client et nourrit votre plan de reprise. Pour le structurer, le modèle de rapport mensuel de maintenance fournit une trame directement réutilisable pour le compte rendu d'incident.

Remettre en ligne sans rejouer l'incident

Un piratage se solde rarement par une perte totale quand la procédure est suivie dans l'ordre : qualifier, isoler, investiguer, décider, durcir. Le vrai filet de sécurité reste la sauvegarde vérifiée et antérieure à l'infection — celle qui transforme une crise de plusieurs jours en une restauration de quelques heures. Mettez en place des sauvegardes chiffrées et vérifiées avant le prochain incident, pas pendant.