Nettoyage fichiers infectés WordPress : comment vérifier l’intégrité après le piratage

Quand un site WordPress est piraté, on a souvent deux réflexes opposés. Le premier consiste à “tout effacer et remettre propre”, comme si l’on réparait une simple armoire abîmée. Le second consiste à tout analyser longuement, au point de laisser le site en ligne plus longtemps que nécessaire. Dans la pratique, le bon tempo se situe entre les deux, avec une priorité très concrète: restaurer un état sain, puis vérifier que les fichiers, les bases et la configuration n’ont pas gardé d’odeur d’infection.

Le nettoyage des fichiers infectés WordPress n’est pas juste une question de suppression. Le vrai enjeu, c’est l’intégrité. Est-ce que le site est bien reparti sur une version saine, ou bien avez-vous simplement retiré ce qui était visible, tout en laissant des portes dérobées en place? Les attaques modernes se cachent parfois dans des fichiers “invisibles” pour un œil humain, dans des dépendances, dans des lignes ajoutées à des endroits inattendus, ou dans des mécanismes de persistance qui survivent au “copier-coller”.

Je vais détailler une méthode de vérification solide, réaliste, et surtout applicable même quand vous n’avez pas toutes les certitudes sur l’origine du piratage.

Les bonnes questions avant de toucher aux fichiers

Avant de lancer le nettoyage, il faut clarifier ce que vous cherchez. Dans un scénario classique, l’attaquant tente un ou plusieurs objectifs: injecter du contenu malveillant dans le front, rediriger des visiteurs, déposer un webshell, voler des identifiants, ou créer une persistance côté serveur. Chaque objectif laisse des traces différentes.

Un point que j’ai vu revenir souvent: les propriétaires de sites remplacent “les fichiers qui semblent bizarres”, puis pensent que c’est terminé. Or, si l’infection a aussi touché la base de données, ou les thèmes et plugins utilisés, vous pouvez revenir à un site “fonctionnel” qui reste pourtant dangereux. À l’inverse, si l’attaquant n’a touché que quelques fichiers, une restauration complète peut être inutile, mais elle peut aussi masquer une autre compromission en vous donnant un faux sentiment de sécurité.

Prenez donc https://gardewp.fr/nettoyage-malware-wordpress/ cinq minutes pour répondre, au moins mentalement, à ces questions:

Le piratage a-t-il déclenché des redirections, des popups, ou un contenu en page qui n’était pas là avant? Le serveur affiche-t-il encore des erreurs étranges, ou des requêtes inhabituelles dans les logs? Les identifiants administrateur sont-ils compromis, ou pensez-vous seulement à une altération du code? Avez-vous accès à une sauvegarde “avant incident” datée de manière fiable?

Sans ces repères, vous nettoyez à l’aveugle. Avec eux, vous pouvez décider où investir du temps: fichiers, base, configuration, et aussi compte utilisateurs.

Construire une base de travail: sauvegarde, isolement, et ordre des opérations

Le nettoyage doit être fait dans un ordre qui réduit les risques de destruction accidentelle. Quand vous commencez à modifier, vous perdez des preuves. Et sans preuves, vous pouvez difficilement prouver la cause, ni savoir ce qui a été réellement supprimé.

Ma recommandation de base: travaillez sur une copie, pas sur le site en production. Si vous n’avez qu’un seul environnement, mettez le site en mode maintenance et isolez-le. Vous pouvez ensuite agir en “forensique légère”: récupérer, comparer, et seulement ensuite supprimer.

Concrètement, vous voulez au moins trois éléments:

Une copie complète du dossier WordPress et du contenu des répertoires sensibles (thèmes, plugins, fichiers de configuration). Une copie de la base de données (même si vous devez la restaurer plus tard). Un inventaire de la version WordPress, des thèmes, des plugins, et des fichiers modifiés récemment.

Ce dernier point paraît administratif, mais il change tout. Quand un attaquant injecte du code, il modifie parfois la date de modification, parfois non. Avoir votre “photo” des versions avant incident aide à détecter les anomalies.

L’inspection des fichiers: repérer, puis vérifier l’origine

Le nettoyage fichiers infectés WordPress ressemble souvent à une chasse aux “fichiers récents” dans cPanel ou dans un gestionnaire FTP. C’est une piste utile, mais pas une méthode de vérité. Un attaquant peut modifier un fichier ancien, masquer son code dans des fichiers qui ont l’air légitimes, ou s’appuyer sur des mécanismes qui ne changent que rarement les dates.

Pour une vérification de l’intégrité, vous cherchez des signaux précis:

Présence de code PHP qui n’existe pas dans la version officielle du thème/plugin. Fonctions “classiques” d’obfuscation (base64, gzinflate, eval avec concaténation, appel dynamique de fonctions). Entrées suspectes dans des fichiers de type configuration (par exemple des lignes ajoutées dans wp-config.php). Fichiers nouveaux dans des répertoires inattendus (par exemple uploads avec des scripts dans des sous-dossiers). Modifications dans des fichiers qui sont chargés au runtime, comme index.php, certains fichiers du thème actif, ou des fichiers d’amorçage.

Mais au-delà du repérage, le point central est la validation.

Comparaison avec une source saine

La comparaison avec une version “saine” est probablement votre meilleur ami. Idéalement, téléchargez la version WordPress correspondant exactement à ce que vous aviez avant incident, ainsi que les thèmes et plugins officiels aux versions exactes. Ensuite, comparez vos fichiers.

Ce que vous voulez éviter: remplacer “au hasard” des fichiers en pensant qu’ils sont propres. Les différences entre versions peuvent ressembler à des anomalies sans l’être.

Si vous utilisez un outil de comparaison (diff), cherchez surtout à comprendre ce que l’attaquant a ajouté. Parfois, ce n’est pas un script complet, mais une ou deux lignes qui changent tout. Une ligne de plus, dans un fichier déjà modifié, peut suffire à recharger du code à chaque visite.

Attention aux plugins “légitimes”

Il existe un cas qui fait perdre du temps: un plugin peut être compromis ou simplement remplacé par une version modifiée. Dans ce cas, l’erreur n’est pas seulement de “nettoyer le code”, c’est de rétablir la source correcte.

Si vous n’avez pas la version exacte avant incident, vous pouvez tomber dans une mauvaise restauration. Par exemple, vous remettez une version plus récente qui introduit des différences et casse une fonctionnalité. L’intégrité, ici, ce n’est pas “revenir à un dossier propre”, c’est “revenir à l’ensemble cohérent qui correspond à votre état d’avant”.

Dans un atelier, je me suis retrouvé devant un site où le propriétaire avait “corrigé” un thème en remplaçant un dossier complet, puis a découvert que deux plugins étaient aussi remplacés par des clones. Le site semblait visuellement identique, mais les formulaires envoyaient des données à une autre destination. Sans comparaison systématique, le problème restait caché.

Vérifier l’intégrité après le piratage, côté WordPress

Une fois le code remplacé, vous devez vérifier que l’état final est cohérent. Beaucoup de gens valident en ouvrant le site dans leur navigateur. C’est insuffisant. Un site peut afficher une page “normale” tout en restant compromis.

Contrôles sur wp-config.php et la structure

Commencez par les fichiers qui pilotent le comportement de WordPress et l’accès au serveur. Wp-config.php est un point critique: même une petite altération peut changer le chargement de fichiers, modifier des constantes, ou détourner des chemins.

Inspectez aussi les fichiers racine qui déclenchent des inclusions. Index.php, le htaccess (s’il existe) et certains fichiers de configuration serveur côté htaccess ou nginx (si vous gérez) peuvent contenir des règles de redirection ou des injections.

La logique est simple: vous cherchez des changements qui n’ont aucun rapport avec votre fonctionnement habituel.

Vérifier thèmes et plugins actifs

WordPress charge surtout ce qui est actif. Si l’infection vient d’un plugin, restaurer uniquement des fichiers non actifs laisse une porte ouverte. Inversement, certains thèmes peuvent être infectés mais pas forcément “candidats” évidents.

Votre vérification doit inclure:

Le thème actif: fichiers principaux (index.php, functions.php, template parts). Les plugins actifs: surtout ceux qui touchent à l’affichage, aux formulaires, à la sécurité, ou aux téléchargements. Les fichiers contenus dans des dossiers de cache ou de styles compilés, qui peuvent contenir du code généré si le système a été trompé.

Vérifier les utilisateurs et rôles

Même si vous nettoyez les fichiers, un piratage peut passer par un compte administrateur ajouté ou un rôle élevé. Le site peut être “propre” au niveau du code et rester compromis, car l’attaquant peut réinjecter du code à la prochaine occasion.

Regardez la liste des utilisateurs, identifiez ceux qui ont été créés récemment, et vérifiez les last login. Si vous avez un doute, supprimez les comptes non attendus et changez les mots de passe de tous les comptes admin, puis appliquez une politique de rotation.

Une pratique saine consiste à désactiver tous les plugins, puis à les réactiver un par un en surveillant le comportement. C’est plus long, mais c’est très parlant: vous pouvez associer un changement à un composant.

Vérifier l’intégrité côté base de données: où l’attaque se cache souvent

Beaucoup d’infections ne sont pas dans les fichiers au sens strict, ou pas uniquement. Elles peuvent modifier des données en base: options, contenus injectés, pages “fantômes”, entrées dans des champs qui servent à afficher du HTML, ou paramètres de configuration.

La base de données est aussi le lieu où des attaques peuvent persister via des options “serialisées”. Ce sont des structures de données, souvent encodées, qui peuvent contenir du code ou des templates injectés.

Ce qu’il faut contrôler dans la base

Sans être exhaustif, je cible généralement trois familles d’éléments:

Options et paramètres liés au site, à l’apparence, aux redirections ou au contenu affiché. Contenu de publications ou de pages, surtout si des pages semblent normales mais contiennent du code discret dans les blocs. Table de formulaires ou d’extensions, si vous utilisez des modules qui sauvegardent du HTML ou des templates.

Le point délicat: vous devez distinguer une modification malveillante d’un contenu volontaire. Si votre site a des rédacteurs et un process normal, vous devez connaître ce qui a été publié juste avant l’incident.

Réconciliation base et fichiers

Une méthode pratique consiste à comparer une sauvegarde d’avant incident avec la base actuelle. Si vous avez accès à une backup datée, vous pouvez:

Restaurer la base complète, puis rebrancher le code propre. Ou, si vous ne pouvez pas tout restaurer, comparer les options critiques et les contenus récents.

Quand je n’ai pas de sauvegarde avant incident, je fais l’inverse: je “congèle” l’environnement, je restaure WordPress et les composants à une base saine, puis j’inspecte la base pour les anomalies à la source.

Dans tous les cas, l’objectif est le même: s’assurer que la base ne contient pas une logique ou un contenu qui recrée l’infection, même si les fichiers ont l’air sains.

Contrôle des traces serveur: logs, requêtes, et cohérence du trafic

Les fichiers et la base ne racontent pas tout. Le serveur, lui, a des traces. Sans exagérer, un contrôle simple des logs peut vous dire si l’attaque a continué après le nettoyage, ou si elle provenait d’une voie encore active.

Selon votre hébergement, vous avez accès à:

logs d’accès web (Apache ou nginx): pages demandées, User-Agent, chaînes de requêtes inhabituelles. logs d’erreur: traces d’inclusions, erreurs PHP, timeouts. logs applicatifs si votre hébergeur les propose. métriques de firewall ou WAF, si présent.

Vous ne cherchez pas forcément “une ligne exacte” qui prouve l’infection. Vous cherchez plutôt la persistance: des requêtes répétées vers des fichiers inconnus, des appels à des endpoints qui ne correspondent à rien sur votre site, ou une hausse après restauration.

Un test simple de “persistance”

Après avoir restauré, laissez le site isolé ou en maintenance, puis testez:

Accès navigateur sur quelques pages connues Chargement de formulaires ou pages qui déclenchent du JS ou des requêtes Utilisation d’un outil de test d’intégrité ou de scans de sécurité côté client

Si vous observez des requêtes vers des fichiers ou scripts qui n’ont aucune raison d’exister, c’est un signal d’alerte. Parfois, l’infection est déclenchée seulement par des conditions, comme des paramètres de query string ou certains User-Agents.

Méthode opérationnelle: vérifier l’intégrité sans se perdre

Voici une approche structurée, mais pas rigide. L’idée est d’atteindre un état “bénéfice rapide, preuves solides” sans transformer votre incident en chantier infini.

Checklist de vérification après restauration

Vérifier que wp-config.php ne contient que les constantes attendues, sans lignes additionnelles non expliquées. Comparer thème actif et plugins actifs avec leurs versions saines correspondantes (diff sur les fichiers principaux). Contrôler la liste des utilisateurs WordPress, supprimer les comptes inattendus et réinitialiser tous les mots de passe admin. Inspecter la base pour les pages ou options modifiées récemment, notamment celles qui contiennent du HTML ou des données injectées. Surveiller les logs pendant 24 à 48 heures après retour en ligne, pour confirmer l’absence de requêtes répétées vers des endpoints inconnus.

C’est volontairement court. Les étapes longues sont remplacées par des actions qui donnent des preuves.

Cas fréquents d’intégrité “faussement bonne”

On croit parfois avoir terminé, parce que le site s’affiche correctement. Puis un jour, un nouvel incident arrive, ou un changement discret réapparaît.

Les redirections qui reviennent via htaccess

Un htaccess compromis peut rester actif, même si WordPress est restauré. Typiquement, des règles de redirection peuvent pointer vers une URL malveillante, ou servir du code qui déclenche des actions selon des conditions.

Si vous restaurez WordPress mais oubliez le niveau serveur, vous repartez avec le vecteur.

L’upload de fichiers malveillants dans wp-content/uploads

Les attaques peuvent déposer des fichiers dans uploads. Souvent, l’utilisateur n’y prête pas attention car le dossier contient déjà des images. Le problème, c’est quand un script PHP se glisse dans un endroit où il n’est pas censé être exécuté, ou quand des fichiers masqués sont utilisés dans un mécanisme de chargement dynamique.

Même après nettoyage, ces fichiers peuvent rester si vous n’avez pas fait une revue et une suppression des éléments anormaux.

La persistance via un cron ou une tâche planifiée

Selon l’hébergement, il peut y avoir des tâches planifiées au niveau serveur ou côté WordPress. L’infection peut créer un cron qui réinjecte du code ou télécharge une charge utile.

Dans ce cas, vous nettoyez une fois, puis l’attaque revient.

C’est aussi pour cela que les logs sont importants: si l’activité reprend après une période calme, vous devez enquêter sur les mécanismes d’exécution planifiée.

Remettre le site en ligne: le retour progressif

Le retour en production mérite une méthode. Si vous remettez tout d’un coup, vous perdez la capacité de corréler un problème à un changement précis.

Je procède souvent comme suit: je réactive d’abord le strict minimum, je teste, puis j’élargis. Cela réduit le temps où le site peut être exploité, tout en identifiant plus vite la source si quelque chose se réactive.

Si vous avez un WAF ou un firewall, durcissez-le pendant la période de stabilisation. Si vous n’en avez pas, vous pouvez au moins appliquer des restrictions d’accès à l’espace admin (IP whitelist le temps du tri, ou désactivation temporaire de l’accès public au login si possible).

Un petit plan de retour en sécurité

Mettre en maintenance ou sous restriction l’accès public Valider que WordPress, thème actif et plugins actifs fonctionnent sans anomalies Observer les logs Réactiver progressivement ce qui a été coupé (plugins, fonctionnalités, formulaires)

Je sais que ça paraît “organisationnel”, mais ce sont des minutes gagnées quand vous devez isoler un composant fautif.

Comment éviter la recontamination: ce qui change après un incident

Après un nettoyage, la tentation est de “revenir comme avant”. C’est rarement la meilleure option. L’objectif n’est pas seulement de supprimer l’infection, c’est de réduire les voies d’entrée.

Sans faire de promesse magique, quelques axes fonctionnent bien en pratique:

Mettre à jour WordPress, thèmes, plugins, surtout ceux actifs. Une mise à jour “pas totale” peut laisser la faille. Supprimer les thèmes et plugins inutiles. Moins de surface, moins de vecteurs. Renforcer les mots de passe, limiter le nombre de comptes admin, imposer le changement après incident. Vérifier la sécurité du compte d’hébergement si vous avez un accès direct aux fichiers et à la base.

Et surtout, gardez un historique. Une sauvegarde régulière et datée, stockée hors serveur, rend le nettoyage beaucoup moins psychologique et beaucoup plus factuel.

À propos des scans de sécurité: utiles, mais pas suffisants

Les outils de scanning automatisés peuvent détecter des signatures connues et parfois des anomalies de fichiers. Ils sont très utiles pour gagner du temps sur “ce qui est évident”. Mais ils ne remplacent pas une vérification d’intégrité.

Deux raisons simples:

Un scan peut manquer une variante nouvelle, surtout si l’attaque est obfusquée. Un scan peut signaler un fichier “modifié”, sans pouvoir dire si c’est malveillant ou juste une modification légitime.

Dans un projet récent, un scan remontait plusieurs faux positifs sur un plugin de traduction. Le fichier était bien celui d’origine, mais l’outil interprétait un en-tête ou une structure comme suspecte. Heureusement, la comparaison avec la version saine a tranché rapidement.

Mon conseil: utilisez les scans comme boussole, pas comme verdict.

Quand il vaut mieux restaurer “à la racine” plutôt que bricoler

Parfois, la quantité d’incertitude dépasse le coût d’une restauration complète. Si:

vous n’avez pas de sauvegarde exploitable avant incident, vous n’êtes pas certain de la source des plugins et thèmes, les logs montrent une activité continue et répétée, vous observez des modifications qui se réintroduisent,

Alors une restauration à partir d’une base saine, suivie d’une reconstruction contrôlée, est souvent plus rapide au total que de corriger un puzzle.

Le vrai coût n’est pas le temps passé. C’est le stress de laisser une question ouverte. Une intégrité vérifiée, même au prix de quelques heures de reconstruction, vaut mieux qu’un site “qui marche” mais “qui inquiète”.

Le point final: votre preuve d’intégrité doit être plus forte que “ça a l’air propre”

Au moment où vous concluez votre chantier, évitez la validation “au feeling”. Une preuve d’intégrité consiste plutôt à pouvoir dire: j’ai remplacé les composants à leur version saine, j’ai vérifié les zones critiques, j’ai contrôlé la base et les utilisateurs, puis j’ai surveillé la persistance.

Si vous pouvez résumer vos actions en quelques constats concrets, vous êtes sur une trajectoire solide. Par exemple, “aucun fichier inconnu n’est présent dans la racine”, “thème et plugins actifs correspondent aux versions attendues”, “aucun utilisateur administrateur nouveau après restauration”, “les logs cessent les requêtes suspectes”.

C’est cette mécanique qui transforme le nettoyage fichiers infectés WordPress en opération maîtrisée.

Et si vous souhaitez une règle simple à garder en tête: dès qu’un doute subsiste sur un composant, traitez-le comme compromis. En sécurité, ce n’est pas la meilleure humeur qui décide, c’est la cohérence des vérifications.

Si vous me décrivez votre contexte (version WordPress, type d’attaque observée, présence ou non de sauvegarde, hébergeur, et ce que vous avez déjà remplacé), je peux vous proposer une stratégie de vérification plus ciblée, sans multiplier les opérations inutiles.