Quand un site WordPress se met à “faire quelque chose de bizarre”, la tentation est de lancer un scan, de supprimer ce qui ressort, puis de repartir comme si de rien n’était. Sur le terrain, ça marche parfois. Mais dans beaucoup de cas, le vrai sujet n’est pas seulement de supprimer une porte dérobée. Le sujet, c’est l’accès. Qui a pu entrer, par où, et ce qu’il a laissé derrière lui.
Cloisonner et minimiser les accès, pendant le nettoyage comme après la restauration, fait souvent la différence entre un site qui revient à la normale et un site qui “reinfeste” au bout de quelques jours. Je l’ai vu sur des environnements très différents, avec des contenus pour des TPE et avec des sites plus exposés, et dans chaque cas le fil conducteur est le même: https://gardewp.fr/nettoyage-malware-wordpress/ tant que le périmètre d’accès reste trop large, le risque de récidive reste élevé.
Le malware n’est pas toujours “dans WordPress”
On imagine souvent le malware comme un fichier PHP caché dans un thème ou dans /wp-content/uploads/. C’est vrai, mais c’est rarement l’histoire complète. Dans beaucoup de cas, l’infection se nourrit d’un angle mort.
Voici quelques scénarios qu’on rencontre fréquemment, sans que cela signifie qu’ils sont universels. Le plus classique est un compte administrateur compromis, parfois via un mot de passe réutilisé. Une fois connecté, l’attaquant peut installer un plugin, créer un utilisateur “discret”, modifier un modèle d’email, ou ajouter une règle de redirection. D’autres fois, le point d’entrée est externe à WordPress: une vieille version d’un composant, une configuration serveur trop ouverte, ou un script qui accepte des requêtes inutilement permissives.
J’ai déjà vu un cas où WordPress était sain au niveau des fichiers, mais où la compromission provenait d’un cron serveur déclenché par un utilisateur de déploiement. Le script écrivait ensuite une petite charge utile dans un dossier précis. Les scanners de fichiers n’ont rien trouvé tant qu’on n’a pas regardé l’exécution réelle, sur la durée.
Dans ce contexte, parler de “nettoyage malware WordPress” ne veut pas dire uniquement “supprimer du code”. Ça veut dire aussi retrouver le chemin d’accès et réduire la surface où une entrée future pourrait se produire.
Cloisonner avant de toucher aux fichiers
Avant toute action, je conseille de cloisonner la situation. Cloisonner, c’est empêcher l’incident de continuer à agir pendant que vous analysez.
Sur un site en production déjà compromis, chaque minute compte. Les charges utiles peuvent servir à pousser du spam, à injecter du contenu dans des pages indexées, ou à provoquer des redirections. Tant que le site reste pleinement joignable et modifiable par des comptes légitimes et compromis, l’attaquant peut continuer à renforcer son accès.
Le cloisonnement ne nécessite pas forcément un arrêt complet, même si un arrêt temporaire peut être la meilleure option quand le trafic est important et que la gravité est élevée. Dans la pratique, on vise souvent ces deux objectifs: limiter les moyens d’accès, et isoler l’environnement pendant l’inspection.
Concrètement, j’ai de bons retours avec une procédure “calme”:
- basculer le site vers un mode restreint (maintenance ou pages figées), couper les accès inutiles (par exemple l’accès direct à l’administration depuis l’internet si ce n’est pas nécessaire), travailler depuis une copie, pas sur la base de production.
Ce point est important. Manipuler une base et des fichiers directement sur la même instance qui vit encore le problème, c’est comme essayer de réparer une fuite d’eau tout en gardant le tuyau sous pression.
Minimiser les accès: une règle qui marche pour tout le reste
Minimiser les accès, c’est simple dans l’idée, difficile dans l’application au quotidien. Les équipes ont souvent des habitudes: plusieurs comptes administrateurs actifs, des rôles élevés partagés, des accès SSH trop ouverts, des déploiements directs depuis des postes non maîtrisés, et parfois des plugins installés “au cas où”.
Quand vous nettoyez, vous voulez casser la logique “l’attaquant peut revenir”. Pour ça, il faut réduire les chemins qui permettent d’obtenir des privilèges.
Le principe est le suivant: pendant le nettoyage, seuls quelques comptes doivent pouvoir faire des actions sensibles. Et une fois le site restauré, les actions sensibles doivent être limitées au minimum.
Ce n’est pas juste une sécurité “théorique”. Quand on cloisonne, on voit rapidement les détails qui comptent:
- des comptes dont la présence n’a pas de sens, des adresses email de réinitialisation non reconnues, des utilisateurs avec des rôles au-delà de ce qu’une équipe devrait avoir, des plugins installés récemment, puis désinstallés, mais dont la configuration a déjà persisté quelque part.
Détecter le point d’entrée sans s’aveugler
Après cloisonnement, l’étape suivante consiste à comprendre “comment l’attaquant est entré”. Si vous sautez cette étape, vous nettoyez peut-être bien, mais vous remettez en place les conditions de retour.
En pratique, je travaille en croisant plusieurs signaux:
- les logs d’accès serveur (HTTP, erreur, éventuellement WAF si vous en avez un), les logs d’authentification WordPress, les traces applicatives côté hosting, si elles existent, et un examen méthodique des changements récents (fichiers modifiés, plugin installés, utilisateurs créés).
Les logs sont souvent plus parlants que les scanners. Un scanner peut retrouver une signature, mais il ne répond pas toujours à la question “qui a déposé la charge utile et quand”.
Un exemple concret: sur un site où l’infection semblait “dans un plugin”, le scan trouvait un fichier douteux. En revanche, l’accès WordPress provenait d’un utilisateur spécifique, connecté depuis des plages d’IP atypiques, puis ayant modifié un plugin existant au lieu de l’installer. Le fichier semblait donc “venir” d’un plugin, mais l’opération réelle venait d’une session compromise.
C’est là que la minimisation des accès montre son intérêt. Si vous avez plusieurs comptes admin et si vous ne maîtrisez pas l’ensemble des identifiants, vous ne saurez pas quel compte a fait quoi.
Méthode: analyser, isoler, supprimer, puis durcir
Il y a un ordre qui évite beaucoup de rework. Je ne parle pas ici d’une recette magique, plutôt d’un enchaînement qui réduit le risque de supprimer une partie visible et de laisser une partie cachée.
1) Faire une copie Avant de supprimer quoi que ce soit, je copie l’ensemble du site (fichiers) et de la base. Idéalement, dans un environnement non exposé. Si vous n’avez pas d’environnement prêt, au moins une copie locale ou un dossier temporaire contrôlé.
2) Repérer les modifications Ensuite, je compare le “avant” et le “pendant”. Si vous avez une sauvegarde datée (même partielle), comparez-la avec l’état actuel. Si vous n’avez pas de sauvegarde, on regarde au minimum:
- fichiers modifiés récemment, dossiers nouvellement créés, bibliothèques et extensions ajoutées, changements dans wp-config.php (attention aux “peut-être” qui finissent par être des variations légitimes).
3) Valider la piste d’accès Je reviens sur les logs. L’objectif est de trouver la session compromise, l’IP, le moment. Ensuite, je corrèle avec ce qui a été modifié côté application. Ce n’est pas toujours direct, mais souvent suffisamment pour identifier la logique.
4) Nettoyer le code Quand la piste d’accès et la zone suspecte sont claires, je procède à la suppression ou au remplacement. Parfois le bon geste consiste à restaurer des dossiers complets à partir d’une version saine, plutôt que de supprimer quelques lignes à la main.
5) Remettre le site en service de façon restrictive Une fois le nettoyage effectué, je réactive progressivement. Par exemple, d’abord via un compte admin unique maîtrisé, ensuite en réouvrant les fonctionnalités externes.
Ce dernier point est souvent négligé. Un site peut être nettoyé, mais si vous réouvrez tout d’un coup, vous redonnez les mêmes conditions qui ont permis la compromission.
Les décisions qui changent tout: restauration vs “réparation au couteau”
On entend souvent “on va nettoyer les fichiers infectés”. Ça peut être acceptable si:
- vous avez une forte certitude sur la zone, vous avez identifié des signatures bien localisées, et vous pouvez prouver que rien d’autre n’a été altéré.
Mais dès qu’il y a incertitude, je privilégie la restauration à partir d’une sauvegarde propre, puis la reconstruction contrôlée des éléments légitimes. Même quand c’est plus long, ça réduit le risque de garder un résidu.
La règle que j’applique est pragmatique: si l’infection touche une logique d’accès, un plugin, un thème, des utilisateurs, et potentiellement la configuration, la restauration partielle n’est plus toujours suffisante.
Et attention au piège du “c’est bon, on a supprimé le fichier”. Si l’attaquant a créé un utilisateur, ou modifié une fonction via un fichier “proche” mais non identique, vous pouvez très facilement passer à côté du vrai vecteur.
Cloisonner l’administration: réduire le risque au quotidien
La cloison du nettoyage ne doit pas s’arrêter quand le site est “propre”. L’administration est le point le plus fréquent de re-entrée.
Minimiser les accès côté administration, ce n’est pas uniquement “changer le mot de passe”. C’est une stratégie de surface:
- limiter le nombre de comptes ayant des droits élevés, exiger des facteurs supplémentaires si vous pouvez, réduire les endroits où des identifiants peuvent être exposés, et encadrer les connexions depuis l’internet.
Il y a aussi un aspect pratique: beaucoup de réinstallations et de nettoyages se passent sur des machines où l’on ne maîtrise pas totalement l’hygiène. Un poste infecté, un navigateur compromis, un gestionnaire de mots de passe mal sécurisé, et l’incident revient malgré un site restauré.
Sur un projet, on avait fait un “nettoyage propre” un vendredi. Le lundi, retour au problème. Les fichiers étaient identiques, mais un compte avait re-généré une configuration via une connexion. On a fini par trouver un poste interne compromis, qui avait des sessions persistantes. C’est un scénario frustrant, mais il souligne la nécessité de cloisonner aussi côté humain.
Ce que je vérifie systématiquement sur les comptes admin
Voici une courte liste d’actions que j’applique en restant concret, sans dogme.
- vérifier les utilisateurs WordPress existants, et comparer avec les besoins réels de l’équipe supprimer ou désactiver tout compte admin non reconnu ou inutile changer tous les mots de passe, y compris ceux liés aux comptes de déploiement ou aux accès hébergeur contrôler les rôles et les capacités, surtout si des comptes “anciennement admin” existent encore imposer un second facteur pour les accès sensibles quand c’est possible
Les mots de passe: changer, oui, mais avec une cohérence
Changer les mots de passe est indispensable, mais il y a un piège classique. Si les mots de passe sont changés côté WordPress mais pas côté hébergement, ou pas côté SFTP, ou pas côté base de données, vous laissez une porte.
En pratique, je fais une approche cohérente:
- WordPress: comptes et mots de passe, plus suppression des comptes dormants, base de données: vérifier les identifiants, surtout si la compromission a pu concerner wp-config.php, serveur: recontrôler les clés SSH, les accès, et les utilisateurs de service, et ensuite seulement on parle de “plugins”.
Cette cohérence évite un cycle où vous nettoyez WordPress, puis vous découvrez que la base ou le serveur ont une configuration encore compromise. C’est plus rapide à éviter qu’à réparer.
Repenser les plugins et les thèmes: pas tous, mais les plus risqués
Quand un site est infecté, on se demande souvent “quels plugins supprimer”. La tentation est forte de tout désinstaller. C’est utile dans certains cas, mais ça peut aussi casser le site, et surtout ça ne répond pas à la question d’accès.
Je raisonne plutôt ainsi: certains plugins méritent une attention accrue, non pas parce qu’ils sont “mauvais” par nature, mais parce qu’ils exécutent du code côté serveur, manipulent des formulaires, ajoutent des endpoints, ou ont des possibilités de mise à jour peu encadrées.
Une bonne pratique est de tenir un inventaire des plugins utilisés et de supprimer ce qui n’a pas de rôle clair. Là encore, je reste pragmatique. Supprimer “tout” peut produire une panne fonctionnelle qui masque le fait que le problème de sécurité n’est pas réglé.
Lors du durcissement, je privilégie:
- mise à jour des plugins essentiels, suppression des plugins inutiles, et limitation de l’installation automatique ou des mises à jour non supervisées selon votre organisation.
Durcir WordPress sans casser la livraison
Le durcissement ne doit pas transformer votre site en chantier permanent. On veut un niveau de sécurité stable, pas une suite de réglages fragiles.
Je cible d’abord les points qui ont le meilleur rapport bénéfice risque.
Par exemple, si votre configuration le permet, limiter l’accès à wp-admin (et parfois à wp-login) est souvent un gain notable. Cela peut passer par des restrictions IP, ou par un accès via un réseau interne, ou via un proxy qui filtre. L’important n’est pas le mécanisme précis, c’est l’idée: réduire la surface accessible depuis l’extérieur.
Autre point utile: renforcer la gestion des sessions, éviter les connexions super longues avec des comptes partagés, et s’assurer que les droits administrateur restent limités.
Enfin, la surveillance compte. Un site restauré sans aucun monitoring, c’est un site qui peut réinfecter sans que vous le sachiez immédiatement. Quand vous faites du nettoyage malware WordPress, vous voulez des signaux tôt. Cela peut être aussi simple qu’un suivi d’erreurs, de changements de fichiers, et d’authentifications inhabituelles.
Minimiser les accès au niveau serveur: le “côté hébergement” compte
Beaucoup de compromissions WordPress sont facilitée par des paramètres serveur trop permissifs.
Je ne sais pas votre stack, donc je reste général, mais vous pouvez vérifier:
- qui a le droit de modifier les fichiers, si des comptes de déploiement ont des privilèges excessifs, si les permissions sont cohérentes (un dossier web qui accepte l’écriture de processus non nécessaires est une mauvaise nouvelle), et si des accès admin serveur sont exposés.
Sur un hébergement partagé, le contrôle peut être limité. Mais même dans ce contexte, les principes restent: réduire le nombre d’utilisateurs, limiter les accès réseau aux seules adresses nécessaires, et éviter de laisser des clés ou des mots de passe “prêts pour dépanner” qui finissent par être exploitables.
Vérifications post-nettoyage: prouver que le risque a diminué
Après restauration et durcissement, je fais des contrôles avant de considérer le dossier clos.
L’objectif est de vérifier deux choses: la stabilité et l’absence de persistance.
Stabilité veut dire que les pages chargent normalement, que les formulaires ne renvoient pas du contenu suspect, que les redirections ne changent pas. Absence de persistance veut dire que les mêmes vecteurs ne recréeront pas le problème sans interaction.
Une vérification pratique consiste à surveiller pendant quelques jours des signaux simples:
- nombre de tentatives de connexion, erreurs php inhabituelles, modifications de fichiers (ou au moins des heures de modification), et changements dans les plugins ou utilisateurs.
Il ne faut pas attendre des semaines si vous avez observé une infection active. Sur des cas réels, la “réapparition” peut se produire en quelques heures ou quelques jours si l’accès n’a pas été totalement fermé.
Cas limites: quand le cloisonnement devient votre meilleur allié
Il existe des cas où les décisions deviennent délicates.
Sauvegarde incertaine
Si votre sauvegarde “supposée propre” a peut-être été prise pendant la compromission, restaurer peut remettre le problème. Dans ce cas, la stratégie de cloisonnement et de preuve via logs et comparaisons de modifications est cruciale. Parfois la meilleure option est de restaurer uniquement certains composants connus et de reconstruire le reste.
Site très custom
Quand votre site a beaucoup de code sur mesure, restaurer des dossiers entiers peut être pénible. Là, une approche hybride fonctionne: restaurer WordPress core et nettoyer strictement les zones exposées, puis vérifier méticuleusement ce qui a été modifié dans vos éléments custom.
Équipe répartie et comptes nombreux
Minimiser les accès peut heurter l’organisation. Ce n’est pas un argument contre la minimisation, c’est un défi à résoudre. Si plusieurs personnes ont besoin d’accès, la solution passe par une gestion claire des rôles, une traçabilité, et une sécurisation des identifiants. Le but n’est pas d’empêcher l’équipe, c’est d’empêcher qu’un compte “trop large” devienne un vecteur.
Le détail qui revient souvent: traiter l’humain et le cycle
Le nettoyage est une opération technique. La persistance du risque est souvent organisationnelle.
Si vous avez un processus où:
- les mots de passe sont partagés, l’accès admin est accessible facilement, les plugins sont installés sans validation, et les mises à jour ne sont pas encadrées,
Vous donnez à un attaquant une autoroute. Même avec un site parfaitement nettoyé, vous gardez la structure qui permet la prochaine entrée.
De mon point de vue, c’est pour ça que cloisonner et minimiser les accès est une approche “transversale”. Elle touche les identifiants, les permissions, la façon de travailler sur le site, et la surveillance après incident.
Quand cette approche est en place, le nettoyage malware WordPress devient moins une course à la réparation et plus une démarche contrôlée. Vous savez quoi observer, quoi fermer, et comment revenir à un fonctionnement stable.
Un plan d’action simple pour démarrer maintenant
Sans transformer votre organisation du jour au lendemain, vous pouvez poser des bases solides. Je vous propose une approche en trois temps, qui s’adapte à la taille du site et au niveau d’urgence.
D’abord, cloisonnez immédiatement la production. Ensuite, identifiez le point d’entrée via logs et corrélations de changements. Enfin, refermez l’accès, c’est à dire comptes, rôles, permissions, et chemins d’administration.
Si vous ne retenez qu’une idée, gardez celle-ci: votre objectif n’est pas seulement de “supprimer la trace visible”. Votre objectif est de rendre la prochaine entrée beaucoup plus difficile que la dernière. C’est ce que j’observe, encore et encore, quand on passe du nettoyage à la prévention.