Supprimer malware WordPress : analyser les fichiers modifiés récemment

Quand un site WordPress se met à rediriger vers des pages bizarres, afficher des publicités intrusives, ou attaquer des visiteurs, la question devient vite urgente: comment supprimer le malware sans casser le site, et sans “effacer” un vrai besoin qui se cachait juste derrière. Dans la pratique, le chemin le plus efficace passe souvent par une analyse simple et très concrète: repérer les fichiers modifiés récemment.

Ce billet explique comment je procède, étape par étape, quand je dois supprimer malware WordPress tout en gardant la tête froide. L’idée n’est pas seulement de trouver “un fichier suspect”, mais de comprendre une chronologie, de vérifier l’intégrité, et de traiter les causes, pas uniquement les symptômes.

Le piège classique: supprimer sans comprendre

Le réflexe “je remplace tout WordPress” peut sembler propre, pourtant il masque parfois le vrai problème. Le malware peut être déjà dans une zone persistante, comme un plugin infecté, un thème modifié, un fichier dans wp-content, ou même un fichier ajouté avec un nom qui ressemble à un composant normal. Si on écrase le fichier apparent mais qu’on laisse derrière une porte d’accès (un compte admin créé, une tâche planifiée, un backdoor), l’infection revient.

Dans ce genre d’incident, j’ai vu des cas où l’équipe supprimait le script injecté dans un thème, mais la redirection continuait parce que le code avait été rechargé automatiquement par un script plus ancien, caché dans un dossier nommé au hasard. À l’inverse, j’ai aussi vu des interventions trop agressives qui ont supprimé des modifications légitimes, par exemple une bibliothèque utilisée par un thème enfant ou un script maison, ce qui a cassé des fonctionnalités ensuite.

L’analyse des fichiers modifiés récemment sert justement à éviter ces deux extrêmes: intervenir au bon endroit, et respecter les éléments qui ne sont pas la cause.

Où chercher, et pourquoi les “modifs récentes” sont un indicateur utile

WordPress vit dans un ensemble de répertoires et de composants. Les zones les plus “aimées” par les attaquants sont généralement celles où ils peuvent ajouter du code sans trop attirer l’attention, ou exploiter des points d’extension.

En pratique, la majorité des signatures “visibles” de compromission se retrouvera souvent dans:

• les dossiers de thèmes et plugins (surtout dans wp-content/themes et wp-content/plugins)
• les fichiers ajoutés dans wp-content (uploads, cache si le site en génère, bibliothèques temporaires)
• la racine WordPress ou des fichiers PHP inattendus dans des répertoires “non typiques”
• les fichiers qui changent après coup sans raison claire (par exemple juste après une maintenance, une mise à jour, ou une tentative d’exploitation)

Le principe est simple: si votre site n’a pas été déployé, mis à jour, ni configuré récemment, mais que des fichiers ont changé dans ces zones, alors il y a une piste.

Attention quand même au bruit. Les systèmes d’hébergement peuvent générer des caches, compresser des images, ou mettre à jour des fichiers de logs. Certains plugins changent des fichiers à des moments réguliers. Et sur des installations partiellement personnalisées, un thème enfant peut modifier des fichiers au déploiement, ou au premier chargement. Donc on ne conclut pas sur un timestamp isolé, on construit une chronologie.

Préparer l’analyse sans contaminer davantage

Avant de toucher au code, je préfère prendre une photo de l’état.

Si vous avez accès en SSH, c’est idéal. Sinon, un accès SFTP et des exports via l’interface du panneau d’hébergement peuvent faire le travail, mais l’ordre reste le même: figer, lister, comparer, puis seulement nettoyer.

Voici comment je m’organise, pour limiter les erreurs:

Je commence par une sauvegarde complète, au minimum des dossiers susceptibles d’être modifiés: wp-content et les fichiers PHP dans la racine (sans forcément tout republier, mais en gardant une copie). Ensuite je collecte une liste des fichiers modifiés récemment, avec leur chemin, leur taille, et leur date. Selon l’hébergement, on peut aussi récupérer la liste des comptes utilisateurs et vérifier la création récente.

Côté sécurité, si le site est en production et que l’attaque a déjà une portée, je place souvent le site derrière une page “maintenance” ou un blocage temporaire au niveau du serveur. Ce n’est pas pour “punir” le site, c’est pour empêcher des recharges automatiques de code pendant que je travaille.

Obtenir la liste des fichiers modifiés récemment

L’approche la plus efficace dépend de votre accès serveur. Si vous pouvez utiliser SSH, vous avez plusieurs options, mais l’objectif est identique: obtenir les fichiers triés par date de modification.

Sur un serveur Linux, on peut typiquement utiliser des commandes de type find pour lister les fichiers modifiés dans une fenêtre récente. L’idée est de regarder par tranches de temps, par exemple 24 heures, puis 7 jours, pour repérer ce qui “déborde” du calendrier normal. Sur un site peu mis à jour, même 7 jours peuvent être une bonne fenêtre, mais vous aurez plus de bruit.

Je conseille de ne pas se contenter d’une seule fenêtre. Un malware peut se déclencher après une phase de latence, ou après une première injection. Par exemple, des fichiers peuvent être déposés un jour, puis l’injection s’activer à la requête quelques jours plus tard.

Ensuite, je recoupe la liste avec les zones sensibles. En clair: je ne veux pas juste un mur de fichiers. Je veux rapidement isoler les chemins dans:

• wp-content/plugins/
• wp-content/themes/
• wp-content/uploads/ (moins pour du PHP, plus pour voir ce qui a bougé, mais certains malwares déposent des fichiers dans des sous-dossiers)
• la racine WordPress (/wp-admin, /wp-includes et les fichiers au niveau du public_html selon votre arborescence)
• les fichiers ou dossiers “bizarres” créés avec des noms qui ne correspondent à aucun composant habituel

Dans l’idéal, je garde cette liste telle quelle et je l’utilise tout au long de la procédure. Elle devient votre “chronologie d’incident”.

Repères utiles à examiner dans les timestamps

Un détail m’aide souvent à distinguer “travail normal” et “fichier posé à la hache”:

• des modifications en masse, très proches les unes des autres
• des changements uniquement dans une zone PHP (par exemple un plugin unique), alors que le reste de la stack n’a pas bougé
• des fichiers dont la date de modification correspond à une période où aucun déploiement n’a eu lieu
• des fichiers nouvellement créés avec une taille atypique (un script malveillant peut faire quelques centaines de lignes et varier beaucoup en taille)

Si vous gérez un CI/CD ou un processus de déploiement, recoupez avec les heures de déploiement. Si vous n’avez pas d’horodatage de déploiement, utilisez au moins votre historique d’actions humaines: mise à jour de plugins, installation d’un thème, modification de paramètres, accès à un compte admin.

Les signaux à repérer dans les fichiers modifiés

Une fois que vous avez la liste, l’étape la plus rentable est l’inspection ciblée. Je cherche des motifs répétitifs, un langage “pas naturel” pour votre stack, et des fonctions utilisées pour l’exécution.

Sans tomber dans une chasse aux sorcières, voici des signaux concrets que je regarde, généralement dans les fichiers PHP modifiés ou nouvellement ajoutés:

• des appels à eval, base64_decode, gzinflate, str_rot13, ou des décodages “en cascade”
• des chaînes longues encodées ou des sections de code “compressées” ou obfusquées
• des références à des actions réseau: curl_exec, file_get_contents vers une URL externe, fsockopen, stream_context_create
• la présence de fichiers qui ne devraient pas être là, par exemple des scripts en dossiers qui ne font pas sens, ou des fichiers PHP dans uploads
• des fonctions qui manipulent la sortie ou injectent du contenu dans la réponse (par exemple au niveau d’un hook ou d’un filtre WordPress)

Le point important: il ne suffit pas de repérer un mot dans un fichier. Je vérifie le contexte. Un base64_decode peut exister dans un plugin légitime (certains plugins compressent des données). Mais si vous voyez base64_decode combiné à un enchaînement qui aboutit à eval, là vous avez un signal beaucoup plus sérieux.

Analyser sans tout de suite supprimer: approche par comparaison

Là où beaucoup d’interventions se trompent, c’est qu’elles remplacent des fichiers sans vérifier l’écart. En pratique, vous pouvez souvent comparer votre fichier “modifié récemment” à la version attendue.

Deux cas:

1) fichier provenant d’un plugin ou d’un thème installé depuis le dépôt ou une source connue

Vous pouvez comparer au code de la version correspondante (même version exacte, même build). Si le plugin a été mis à jour récemment, la comparaison doit prendre en compte la version. Sinon, c’est un indicateur très fort.

2) fichier qui ne correspond à aucun composant standard

Là, il faut être encore plus prudent. S’il s’agit d’un fichier ajouté par le malware, le supprimer sans réfléchir peut être correct. Mais si votre site a des scripts internes ou des configurations personnalisées, mieux vaut confirmer la source avant d’effacer.

Dans mon workflow, je fais souvent un diff. Même sans outil sophistiqué, je peux ouvrir les fichiers et repérer les blocs nouveaux. Si vous observez un bloc placé au milieu d’un fichier propre, ou en bas avec une logique qui “intercepte” l’exécution, c’est généralement la partie malveillante. Je note alors les dépendances: un malware s’appuie parfois sur un fichier compagnon, sur une variable globale, ou sur une constante définie ailleurs.

Un exemple typique de scénario (et comment l’analyse le révèle)

Imaginons un site qui, depuis la veille, redirige une partie des visiteurs vers une page de phishing. Vous regardez dans la console serveur: les fichiers modifiés dans les dernières 24 heures incluent un seul fichier PHP dans wp-content/plugins/nomdumodule/ et deux fichiers dans un thème.

Je commence par ouvrir ces fichiers et je cherche les patterns décrits plus haut. Souvent, vous verrez une logique du type:

• une condition sur l’agent utilisateur ou l’IP
• une requête vers une URL externe pour récupérer du code
• l’injection d’un script dans le HTML via un hook

Ensuite je vérifie si ces fichiers sont utilisés au chargement normal. Pour WordPress, un plugin a un fichier principal, généralement nomduplugin.php à la racine du plugin. Si le fichier modifié n’est pas le principal, mais qu’il est chargé via require ou via un autoload, je remonte la chaîne de chargement.

Une fois que j’ai identifié le point d’entrée, je peux décider de l’action:

• remplacer le fichier du plugin par une version connue saine
• supprimer un fichier compagnon si c’est clairement un dépôt
• supprimer et reconfigurer le thème si la partie malveillante est intégrée dans un fichier de hook

Ce que je ne fais pas à ce stade: supprimer au hasard tout le dossier wp-content sans plan. Sur certains sites, wp-content contient des personnalisations et une grosse part de vos contenus. Si vous effacez trop large, vous risquez d’entrer dans une boucle de restauration délicate.

Étapes concrètes pour supprimer malware WordPress à partir de fichiers modifiés

Je vais décrire une séquence pratico-pratique. Elle marche bien pour la majorité des infections “classiques”, celles où l’attaque passe par des fichiers modifiés dans les plugins et thèmes.

1) Isoler les fichiers à risque, pas tout le site

Commencez par créer une liste restreinte des fichiers modifiés récemment, puis filtrez mentalement:

• fichiers dans wp-content/plugins et wp-content/themes
• fichiers PHP dans la racine ou dans des sous-dossiers inattendus
• fichiers nouveaux, surtout si leur nom ne ressemble pas à un composant normal
• fichiers dont la modification ne correspond à aucun déploiement ou action prévue

Si votre liste est énorme, réduisez la fenêtre temporelle. En général, plus vous élargissez, plus vous collectez du bruit.

2) Vérifier la cohérence avec votre historique

Si vous aviez un déploiement automatique, vous pouvez recouper avec les horaires. Un plugin peut modifier des fichiers lors de la génération de caches ou de mises en forme, mais rarement dans la racine d’un plugin ou en touchant des fichiers qui doivent rester statiques.

Ici, la chronologie est votre alliée. Un malware fait souvent des modifications en rafale.

3) Contrôler le contenu du code suspect

Ouvrez le ou les fichiers les plus critiques (ceux qui ressemblent à des points d’entrée). Cherchez les patterns d’obfuscation et de chargement externe. L’objectif est de confirmer que vous avez un vrai élément malveillant, pas une modification innocente.

4) Réparer en remplaçant les composants, puis nettoyer le point d’entrée

Le plus sûr, une fois confirmé, est souvent:

• remplacer le plugin ou le thème par une version propre
• supprimer les fichiers ajoutés si vous êtes sûr qu’ils n’appartiennent pas à votre stack
• reconfigurer si nécessaire les options du plugin

Ensuite seulement, vous vérifiez les comptes utilisateurs, les tâches planifiées, et les traces dans la configuration.

Voici la mini-checklist que j’utilise quand je suis en mode “urgence raisonnable”:

• Documenter la période exacte d’apparition du symptôme (redirection, pop-up, erreurs serveur)
• Identifier les fichiers PHP modifiés dans wp-content/plugins et wp-content/themes sur 24 à 72 heures
• Confirmer par lecture du code les indicateurs d’exécution (eval, encodage, appels réseau)
• Remplacer le plugin ou le thème concernés par une version connue saine, puis supprimer les fichiers clairement déposés

Cette approche évite de “nettoyer” sans corriger.

Vérifier les mécanismes persistants, même si vous trouvez le fichier

Il y a un point qui revient toujours. Même si vous repérez un fichier malveillant dans un plugin ou un thème, l’attaquant peut avoir mis en place une persistance ailleurs. Les fichiers récemment modifiés sont souvent la partie visible, mais pas forcément la racine.

Dans WordPress, les persistance fréquentes que j’inspecte après le nettoyage des fichiers:

• des comptes admin ajoutés récemment, ou des comptes avec des rôles élevés créés “à côté”
• des règles ou options stockées dans la base de données qui déclenchent du code
• des scripts via “cron” ou des tâches planifiées
• des modifications dans des fichiers de configuration du serveur ou des répertoires mal protégés

Je sais que l’utilisateur qui arrive en panique veut d’abord “effacer le fichier suspect”. C’est normal. Mais si vous skippez la persistance, vous risquez de voir l’infection revenir. Dans le meilleur des cas, elle revient immédiatement. Dans https://gardewp.fr/nettoyage-malware-wordpress/ le pire, elle revient après une mise à jour ou un pic de trafic.

Typologies de malwares, et erreurs fréquentes d’interprétation

Tous les malwares ne se ressemblent pas, et l’analyse par timestamp peut vous induire en erreur si vous classez trop vite.

Erreur 1: prendre le fichier le plus récent comme coupable unique

Le fichier le plus récent peut être le dernier maillon. Parfois, le malware charge dynamiquement du code depuis un endroit créé un peu plus tôt. Le fichier “plus ancien” est la vraie porte d’entrée, et le plus récent est juste une trace d’exécution.

Erreur 2: confondre cache et modification malveillante

Certains hébergeurs ou plugins modifient wp-content pour la performance. Des fichiers dans wp-content/cache ou des caches d’optimisation peuvent bouger souvent. En revanche, un fichier PHP dans uploads ou un fichier modifié dans le cœur d’un plugin, lui, n’est pas un symptôme “normal” pour beaucoup d’installations.

Erreur 3: remplacer sans vérifier les dépendances

Un thème enfant peut inclure un fichier qui a l’air suspect mais qui est en réalité une personnalisation. Si vous remplacez au hasard, vous cassez des fonctionnalités. Ici, la lecture rapide du diff fait gagner du temps.

Quand et comment basculer vers une analyse plus large

Parfois, vous regardez les fichiers modifiés récemment, et vous ne trouvez rien d’évident. Ce n’est pas rare non plus, surtout si:

• le malware est dans la base de données plutôt que dans des fichiers
• l’attaquant a compromis un compte, puis a injecté via une fonctionnalité de WordPress (menus, options, contenus, templates)
• l’infection a été supprimée une première fois, mais la persistance reste
• le site est “propagé” sans que vous voyez un fichier modifié, par exemple via une chaîne de redirections manipulée ailleurs

Dans ce cas, j’élargis l’analyse à:

• l’historique d’administration (connexion et modifications)
• la liste des plugins et thèmes, et leurs dates d’installation
• l’intégrité des fichiers WordPress (via une vérification de checksum, si vous avez un moyen fiable)
• les logs serveur et les erreurs 404 ou 500 inhabituelles

Je ne m’attends pas toujours à voir un fichier “évident”. Le bon réflexe est d’utiliser les fichiers modifiés comme un point de départ, pas comme preuve absolue.

Protéger après avoir supprim malware WordPress

Une fois que vous avez supprimé l’élément malveillant, la sécurité est rarement “terminée” tant que l’accès n’est pas durci.

Je fais deux actions en priorité, avant même de rouvrir complètement le site:

1) réviser les accès Je force une rotation des mots de passe des comptes à rôle élevé, et je vérifie que personne n’a un compte inattendu. Si vous utilisez 2FA, activez-le pour les comptes sensibles. Les attaques basées sur mot de passe restent fréquentes, et un malware n’est parfois que la conséquence d’une porte mal fermée.

2) réduire la surface d’entrée Je vérifie la liste des plugins et thèmes, je désactive ceux qui ne sont pas nécessaires, et je mets à jour le reste. Un plugin abandonné est un terrain facile. De même, je m’assure que les permissions de fichiers sont cohérentes, et que les uploads ne peuvent pas exécuter du code PHP.

Ces actions ne “suppriment” pas le malware, elles empêchent sa réapparition.

Un dernier point sur la méthode: agir vite, mais garder une trace

Dans les interventions d’urgence, la pression monte vite. On veut réparer, remettre en ligne, calmer la page “ça ne marche pas”. Pourtant, les décisions deviennent meilleures quand on garde une trace.

Je recommande de noter, au fur et à mesure:

• les fichiers que vous avez identifiés comme suspects
• la date et l’heure de la modification
• ce que vous avez remplacé et par quoi (source du code propre, version)
• ce que vous avez retiré (et pourquoi)
• ce qui a changé après coup (retour des redirections à la normale, diminution des erreurs, etc.)

Ce n’est pas du bureaucratique. C’est un filet de sécurité. Si quelque chose casse, vous saurez où revenir. Et si l’infection revient, vous pourrez comparer avec vos interventions précédentes au lieu de repartir de zéro.

Conclusion implicite: l’analyse des modifs récentes est une boussole

Analyser les fichiers modifiés récemment, c’est comme suivre des traces sur la neige. Ça ne vous dit pas automatiquement qui est coupable, mais ça réduit l’espace de recherche à une zone où le bon raisonnement a des chances de payer.

Si vous appliquez cette méthode https://gardewp.fr/ avec une lecture du code, une comparaison de versions, et une vérification des mécanismes persistants, vous augmentez fortement la probabilité de supprimer malware WordPress sans tourner en rond. Le plus important n’est pas de “faire disparaître un fichier”, c’est de remettre votre site dans un état cohérent, et de fermer les portes qui ont permis l’intrusion.