Quand un site WordPress se met à servir des pages bizarres, redirige vers des domaines inconnus, ou alourdit soudainement le serveur, la première urgence n’est pas “tout casser” à l’aveugle. La vraie urgence, c’est de reprendre la maîtrise, et surtout de comprendre ce qui a réellement été modifié. Le nettoyage avance par étapes, et sans un suivi clair de la progression, on finit souvent par croire que c’est réglé alors qu’un mécanisme persistant continue de réinfecter.
Dans cet article, je parle du suivi concret pendant le nettoyage, pas seulement des outils. L’objectif est simple: savoir à chaque moment où on en est, ce qu’on a prouvé, ce qu’on n’a pas encore prouvé, et quelles vérifications font gagner le temps.
Les symptômes ne suffisent pas, et c’est le premier piège
Avant même de lancer un scanner malware WordPress, j’ai pris l’habitude de noter les symptômes observés. Pas pour “faire joli”, mais pour disposer d’un fil conducteur pendant le nettoyage. Une redirection peut venir d’un fichier modifié, d’une injection dans un thème, d’un plugin compromis, d’une règle au niveau du serveur, ou d’un cache empoisonné.
Si vous partez dans tous les sens, vous risquez de remplacer un fichier propre tout en laissant intact un point d’entrée ailleurs. Et si le site se met à redevenir normal juste après une action, ça ne veut pas dire que l’infection est morte. Ça peut aussi vouloir dire que vous avez frappé une partie visible, mais pas la persistance.
Une pratique utile consiste à figer un instantané de l’avant. Même sans être expert en forensics, on peut collecter suffisamment d’indices pour suivre la progression:
- quels domaines sont visés par les redirections quelles pages ou routes déclenchent le comportement à quelle fréquence ça arrive, et si c’est lié à un profil utilisateur quel navigateur semble afficher le problème en premier si le serveur montre une hausse anormale du trafic ou des erreurs 404
Ce relevé sert ensuite à valider le résultat. Et surtout, il donne un repère temporel: “voilà ce que je voyais au moment où j’ai commencé”.
Préparer le terrain, sinon le suivi devient impossible
La progression du nettoyage dépend énormément de la préparation. Si vous n’avez pas un cadre minimal, le “tracking” devient une impression vague. J’ai vu des cas où l’équipe a supprimé dix fichiers, puis a dû recommencer parce qu’elle n’avait aucune idée des modifications réalisées dans quel ordre.
Avant de nettoyer, je recommande de:
1) confirmer que vous avez un accès fiable aux fichiers et à la configuration (FTP/SFTP, SSH si possible, panneau d’administration, base de données) 2) sauvegarder les éléments susceptibles d’être modifiés, idéalement un snapshot ou une sauvegarde de répertoires critiques et de la base 3) relever la version de WordPress, des thèmes et des plugins, parce que certaines traces de compromission ressemblent à des mises à jour ratées 4) décider d’un périmètre de travail: “je nettoie d’abord, je durcis ensuite”, ou l’inverse
La sauvegarde n’est pas un détail. Si vous pouvez revenir en arrière, vous pouvez aussi avancer plus vite, car vous acceptez de tester des hypothèses. Sans retour possible, la progression devient prudente, lente, et parfois incohérente.
“Scanner malware WordPress” : utiliser l’outil, mais suivre ses signaux
Les scanners sont utiles, mais ils ont des limites. Certains cataloguent des signatures connues, d’autres détectent des patterns, d’autres encore repèrent des incohérences. Le point crucial, c’est de suivre non seulement le verdict final, mais aussi ce que l’outil montre pendant l’exécution.
D’expérience, on progresse mieux quand on traite le scan comme une étape d’observation, pas comme un oracle. Vous voulez deux choses:
- une liste de zones suspectes (fichiers, chemins, fonctions, scripts) un ordre de priorité logique, pour ne pas s’attaquer à tout en même temps
Selon le scanner, vous verrez parfois des résultats “high” puis des “medium”, ou des fichiers “infectés” et des fichiers “modifiés”. La nuance compte. Un fichier marqué modifié peut contenir une vraie modification malveillante, ou bien une modification légitime qui a été faite au mauvais moment (migration, mise à jour interrompue, déploiement manuel). La progression du nettoyage se fait alors par recoupement.
Un bon réflexe: ne lancez pas le scanner en dernier. Lancez-le, puis utilisez ses résultats comme carte. Ensuite, nettoyez une zone, rescanez, et vérifiez si la même alerte revient. Si elle revient, c’est un indice que le point persistant est ailleurs, ou que vous avez supprimé le symptôme mais pas la source.
Définir ce que “progrès” veut dire
Le mot “progrès” est trompeur. Nettoyer ne consiste pas uniquement à supprimer. Souvent, il faut aussi valider, reconstruire, comparer, et vérifier que l’entrée de la compromission n’est plus active.
Pour suivre la progression de manière utile, je m’appuie sur trois critères, qu’on peut mesurer au fil des étapes:
1) la diminution des anomalies repérées (moins d’alertes, moins de fichiers suspects) 2) la disparition des comportements observés côté navigateur (redirections, scripts injectés, charge CPU anormale) 3) la stabilité après un délai (quand vous nettoyez une persistance, le site ne “doit” pas redevenir infecté au prochain chargement ou après un intervalle court)
Le critère (3) est celui qu’on sous-estime. On a souvent envie de valider tout de suite après un premier scan. Pourtant, certains malwares se réactivent après un délai, ou au prochain appel à une route précise. Donc la progression réelle se juge aussi sur la répétition des tests.
Construire une chronologie de nettoyage, même simple
Même si vous n’êtes pas en équipe incident, une chronologie vous évite les erreurs bêtes. Quand je travaille sur un site compromis, je garde un journal de bord, un fichier texte ou une note dans un gestionnaire de tickets. À https://gardewp.fr/nettoyage-malware-wordpress/ minima, je note l’heure, l’action, et le résultat.
Pourquoi? Parce que vous allez devoir répondre à ces questions rapidement:
- Est-ce que le scanner a changé de comportement après une modification? Est-ce que la page redevenue saine correspond à une suppression précise? Est-ce qu’un nouveau scan a “réapparu” des signatures dans des fichiers déjà traités?
Sans chronologie, vous perdez le fil. Avec une chronologie, vous pouvez analyser ce qui marche, et surtout ce qui ne marche pas.
Nettoyage par niveaux : fichiers, base, puis configuration
Dans WordPress, les points d’entrée typiques se répartissent souvent entre fichiers, base de données, et configuration. La logique du suivi consiste à traiter par niveaux et à rescanner entre chaque niveau.
Voici une manière pratique d’organiser la progression, sans transformer ça en usine:
- Au niveau fichiers: thèmes, plugins, uploads, fichiers racine (et ce qui est en dehors de WordPress si votre environnement mélange plusieurs applis). Au niveau base: options, tables de type wp options, wpmuoptions si réseau, posts et meta si l’injection s’est faite via contenu ou champs. Au niveau configuration: .htaccess, règles serveur, variables liées au cache, cron WordPress, tâches système, et user agents ou paramètres de redirection.
Le piège courant, c’est de ne traiter que les fichiers visibles, alors que l’injection est stockée dans des options ou dans des meta. Inversement, on voit parfois des gens nettoyer uniquement la base, puis oublier un script présent dans un thème enfant ou dans un plugin “actif” mais discret.
Observer les retours du scan après chaque action
Le cœur de votre question est le suivi de la progression du nettoyage. Concrètement, comment savoir si vous avancez?
La méthode la plus fiable consiste à relier chaque action à un signal de contrôle. Le signal de contrôle, c’est soit le scanner, soit le test navigateur, soit les logs serveur. En pratique, je fais souvent “scanner puis test”, puis je répète.
Quand un scan se termine et affiche de nouvelles alertes, il faut savoir les interpréter. Une alerte peut être:
- un faux positif, auquel cas elle ne doit pas revenir après mise à jour et comparaison une détection d’un code légitime, souvent liée à un pattern commun une persistance, auquel cas elle revient systématiquement malgré les suppressions
Pour visualiser une grille de décision simple, voilà comment j’interprète typiquement les résultats après une phase de nettoyage. Cette grille n’est pas une vérité universelle, mais elle structure la progression:
- Si le scan ne remonte plus les mêmes fichiers, et que les pages rechargent correctement après un cycle “froid” (cache vidé), je considère que cette phase est probablement valide. Si le scan remonte des fichiers différents mais avec le même comportement global (redirection identique), je traite ça comme un déplacement de la compromission, pas comme une résolution. Si les alertes persistent sur des chemins déjà supprimés, je suspecte un outil ou une tâche qui régénère les fichiers, ou un reste de persistance via base ou cron. Si le site semble propre mais que la charge serveur repart à la hausse à des moments spécifiques, je suspecte un script déclenché par intervalle ou par une requête précise. Si le scan améliore partiellement mais qu’une signature revient avec une variante du code, je reviens à la comparaison de contenu, pour repérer l’emplacement exact du “pivot”.
Ce genre d’interprétation transforme un “résultat de scan” en progression réelle, parce que vous évitez de vous raconter une histoire au premier scan rassurant.
Exemple concret : quand le scan dit “ok” mais que le comportement revient
Je pense à un cas assez typique: le scanner annonce que les fichiers suspects dans un thème ont été supprimés. Le site revient à un rendu normal pendant quelques minutes. L’équipe valide, puis plus tard, la redirection vers une page externe apparaît de nouveau, mais uniquement sur une catégorie de pages, pas sur toutes.
Le détail qui a fait gagner du temps: le comportement revenait après un certain type de requête, pas “au hasard”. Après rescan, une alerte différente apparaît, mais elle pointe vers un fichier situé dans un sous-dossier moins évident. En clair, la persistance n’était pas exactement au même endroit que la partie visible du chargement initial.
Dans ce scénario, la progression était illusoire tant qu’on n’avait pas corrélé le retour du comportement à la chronologie des actions. Le nettoyage n’était pas fini, il était juste en pause, le temps que la persistance reprenne.
Ce type de situation arrive souvent quand une compromission s’appuie sur plusieurs points, par exemple:
- injection dans une option pour réécrire un fichier base qui reconstitue du code cron qui redéploie un composant plugin “nettoyé” mais encore présent dans une version compromise ailleurs (cache d’asset, cache opcode, ou fichier généré)
Vérifications ciblées côté navigateur (et pas seulement “ça charge”)
Le navigateur est un outil de diagnostic, pas un simple test de “bonne humeur”. Si le site charge, mais que des scripts indésirables s’exécutent encore, vous ne le verrez pas forcément sans outils de développement.
Vous pouvez faire des tests assez concrets:
- Recharger la page après vidage du cache navigateur, et idéalement sur une session différente. Observer les redirections: est-ce instantané, ou après un délai? Surveiller le chargement de scripts inattendus dans le panneau réseau (même sans connaître chaque lib JavaScript, vous repérez vite des domaines externes non habituels). Vérifier les pages publiques et les pages connectées séparément. Parfois, l’injection cible seulement les utilisateurs connectés.
Ces tests ne remplacent pas le scan, mais ils servent de contrôle de progression. Un nettoyage peut être “complet” côté fichiers et encore incomplet côté base, et inversement.
Résoudre la persistance : cron, utilisateurs, et tâches invisibles
Quand la progression stagne, c’est souvent parce que la persistance est encore active. Dans WordPress, on se focalise sur les fichiers, mais les compromissions sérieuses s’appuient aussi sur des mécanismes “propres”:
- tâches planifiées (WordPress cron, ou cron système) utilisateurs administrateurs ajoutés, avec des rôles et des capacités atypiques thèmes ou plugins activés qui affichent une charge utile sous une condition précise webhooks, ou intégrations externes qui réécrivent du contenu
Le suivi doit donc inclure une vérification fonctionnelle, pas seulement une vérification statique.
Si vous avez accès à wp-cron, vérifiez s’il se déclenche et ce qu’il exécute, surtout après un scan. Si un malware a mis un hook qui régénère un fichier à chaque intervalle, vous aurez un schéma clair: rescan, suppression, puis réapparition.
Comparaison et reconstruction : quand “nettoyer” ne suffit plus
Il arrive que le scan identifie des fichiers suspects, mais que vous ne soyez pas certain de l’intégrité de l’ensemble. Dans ces cas, une reconstruction par téléchargement de versions propres (WordPress, thèmes, plugins) devient une étape de progression logique.
C’est plus long, mais c’est parfois plus rapide qu’un nettoyage au cas par cas. Surtout si:
- vous suspectez plusieurs modifications dans un même composant vous n’avez pas de baseline fiable (quels fichiers étaient présents avant) vous constatez des variations entre scans
La progression se mesure alors différemment. Vous ne suivez plus seulement “moins d’alertes”, vous suivez “un arbre de fichiers cohérent avec des sources propres”. Cette cohérence réduit la place pour les surprises.
Où regarder dans les logs, et quoi chercher
Les logs sont souvent la partie la plus “ingrate” du diagnostic, mais ils donnent des réponses très concrètes sur la progression. Je ne parle pas de lire des milliers de lignes sans but, je parle d’orienter la lecture vers ce qui vous dit “ça repart”.
Selon votre hébergement, vous pouvez avoir des logs d’accès (web server), des logs PHP, et parfois des logs applicatifs. Les signaux typiques:
- pics de requêtes sur des URLs qui n’existent pas normalement requêtes vers des fichiers bizarres dans des répertoires non attendus erreurs PHP répétées liées à des scripts de chargement redirections qui reviennent avec les mêmes paramètres
Pendant le nettoyage, vous pouvez faire un test simple: après chaque phase, déclenchez vous-même un chargement de la page concernée depuis un poste de test, puis regardez si de nouvelles requêtes suspectes apparaissent. Si elles reviennent au même pattern, votre progression n’a pas atteint la persistance.
Un schéma mental pour ne pas perdre le fil
À force, on finit par avoir un schéma mental assez stable. Il ne tient pas en une méthode magique, mais en une discipline de suivi.
Je garde cette logique:
- une hypothèse (ce qui est compromis) une action (supprimer, remplacer, corriger) un contrôle (scan et comportement) une décision (valider, re-cibler, reconstruire)
Si vous sautez l’étape contrôle, vous perdez la progression. Si vous sautez la décision et que vous continuez “au même rythme” alors que le contrôle échoue, vous perdez du temps et vous augmentez la confusion.
Faire un dernier scan, mais avec un critère de fin
Le dernier scan est tentant. On a envie de cocher la case, fermer le ticket, et passer à autre chose. Le bon réflexe est de définir un critère de fin réaliste.
Le critère que je privilégie ressemble à ceci: le comportement redevient normal sur les pages concernées, le scan ne remonte plus les mêmes zones, et le résultat tient après un petit délai, pas juste quelques minutes.
Un délai court peut déjà être parlant si la persistance est immédiate. Pour des cas plus lents, je préfère attendre plus longtemps quand c’est faisable, ou au minimum vérifier que rien ne “réécrit” après une nouvelle série de requêtes. Le bon sens ici dépend du site, du trafic, et du type de compromission.
Il faut aussi prévoir l’après: même quand le site est propre, vous voulez éviter une réinfection. Sinon, vous aurez l’impression d’avoir “terminé” alors que vous avez juste ralenti le problème.
Durcissement après nettoyage, pour protéger la progression future
Le durcissement n’est pas le sujet principal, mais il impacte directement la progression de nettoyage, car il réduit les retours en arrière. Sans mesures minimales, vous risquez de nettoyer à nouveau le même type de problème.
Sans vous noyer dans la théorie, les points qui aident vraiment sont souvent:
- limiter les plugins à l’essentiel mettre à jour thèmes et plugins, puis contrôler ce qui est vraiment nécessaire supprimer les utilisateurs inutiles et verrouiller ce qui dépasse les besoins contrôler les permissions et l’accès aux fichiers vérifier l’ordonnancement des mises à jour et la qualité des sources
Ce n’est pas glamour, mais c’est ce qui transforme un nettoyage en amélioration durable.
Revenir sur les résultats: ce que vous devez pouvoir expliquer
Quand le nettoyage est terminé, il y a un bénéfice souvent sous-estimé: pouvoir raconter ce que vous avez trouvé et ce que vous avez fait, avec des preuves simples. Si vous travaillez en interne ou avec un prestataire, cette traçabilité évite les discussions infinies.
Concrètement, vous devriez pouvoir pointer:
- les zones où le code malveillant a été détecté ce qui a été modifié ou supprimé quels contrôles ont confirmé la disparition du comportement quelles mesures ont empêché une réapparition immédiate
Cette capacité à “expliquer” est la différence entre un nettoyage qui semble aller mieux et un nettoyage terminé.
Mini-plan de suivi pendant la phase critique
Si vous voulez une méthode de suivi courte, centrée sur la progression, voici une manière de travailler sans listes interminables:
Commencez par relever les symptômes et figer un état de référence, lancez un scan (scanner malware WordPress si c’est l’outil que vous utilisez), puis attaquez une zone bien définie. Après cette action, rescanez et refaites les tests navigateur sur les pages affectées. Si ça revient, ne recommencez pas au hasard, cherchez le mécanisme de persistance, souvent cron, base, ou régénération de fichiers. Quand les alertes se stabilisent et que le comportement reste sain sur plusieurs rechargements et quelques variations de session, vous pouvez passer à une phase de reconstruction plus large, surtout si vous avez des doutes sur l’intégrité globale des composants.
Si vous gardez cette discipline, votre progression ne sera plus un “sentiment”. Elle deviendra un enchaînement d’actions et de contrôles qui vous dit, étape par étape, où vous êtes.
Dernier point qui sauve des heures : ne pas “mélanger” les environnements
Un piège final que je vois souvent: nettoyer sur la base de test, puis valider sur la base de production (ou l’inverse). Ou encore: tester avec le cache de votre navigateur, pendant que la production sert encore des assets générés avant la suppression.
Si possible, maintenez une cohérence entre environnement de nettoyage et environnement de test. Quand ce n’est pas possible, notez quel environnement vous vérifiez et ce qui a été purgé. Le suivi de progression souffre énormément quand les repères changent.
Un site WordPress compromis ne se “répare” pas d’un coup. Il se remet en ordre, puis il se prouve. Et le scanner, les scans successifs et les tests navigateur ne valent que si vous les reliez à une chronologie claire. C’est ça, suivre la progression du nettoyage: transformer des résultats techniques en décision, et des décisions en preuve.