Quand on parle de “désinfection WordPress”, on imagine souvent un fichier PHP malicieux bien visible, un script qui affiche un lien ou une charge utile claire. La réalité, sur les sites qui ont déjà passé plusieurs semaines ou mois sous attaque, est plus sournoise. Très souvent, l’infection se cache derrière de l’obfuscation et du code chiffré, parfois juste assez pour https://gardewp.fr/nettoyage-malware-wordpress/ passer les contrôles humains, mais suffisamment pour agir.
J’ai vu des cas où une intrusion ne laissait presque aucune trace dans les pages publiques. Le site semblait “fonctionner normalement”. Puis, en explorant le dossier des thèmes et des extensions, on trouvait des morceaux de PHP déguisés, des chaînes en base64, des fonctions bizarres, puis un appel à eval() ou à une décompression avant exécution. Le site n’était pas “hacké à l’écran”. Il était hacké à l’intérieur, au moment où WordPress charge un fichier, ou au moment précis où quelqu’un demande une page.
L’objectif de cet article est simple et concret : comprendre comment l’obfuscation et le code chiffré sont utilisés, comment les repérer avec méthode, et comment faire une désinfection WordPress propre, sans laisser des bombes à retardement.
Pourquoi l’obfuscation finit par aggraver le problème
L’obfuscation n’est pas un gadget. C’est une couche de camouflage. L’attaquant transforme un script lisible en un bloc difficile à analyser, soit en encodant des données (base64, rot13, caractères échappés), soit en compressant, soit en réassemblant du code au runtime.
Dans WordPress, ce mécanisme a un avantage tactique : il réduit la probabilité de détection par des contrôles simples. Un scan “à l’œil” ou un grep léger peut ne rien trouver, surtout si l’attaquant a réparti https://gardewp.fr/ les morceaux, ou s’il n’injecte pas un payload complet mais une simple routine de déchiffrement qui récupère la suite ailleurs.
Le point que je répète à mes clients quand c’est leur premier incident : une obfuscation réussie ne veut pas dire “pas d’infection”. Ça veut dire “infection plus difficile à éradiquer”.
Les formes d’obfuscation les plus courantes dans WordPress
Chaque incident a sa signature, mais on retrouve des schémas récurrents. Les attaquants cherchent à déclencher une exécution discrète, souvent dans des fichiers qui WordPress charge déjà.
On voit régulièrement :
- du PHP qui “recompose” du code via eval() des données encodées puis décodées au chargement des patterns de type “décompression puis exécution” des charges qui s’exécutent uniquement sous certaines conditions, par exemple sur une URI précise, sur un user agent particulier, ou après un délai
Dans la pratique, j’ai remarqué deux grandes catégories.
La première, c’est le “fichier parasite dans un endroit plausible”. L’attaquant ne met pas forcément le code dans un fichier au hasard. Il le glisse dans un thème ou une extension, souvent dans un fichier que l’équipe n’édite jamais. Par exemple, des variantes de index.php, functions.php, ou des fichiers inclus depuis un hook.
La seconde, c’est le “mécanisme d’exécution conditionnelle”. Le code chiffré peut ne s’activer qu’en cas d’accès à une page spécifique, ou quand certains paramètres sont présents. Résultat : même si vous inspectez le site en navigation normale, vous ne verrez rien.
Le piège du “on a supprimé ce qu’on a vu”
Beaucoup de désinfections échouent au même endroit : elles se contentent de retirer le morceau le plus évident. Or, l’obfuscation peut masquer la logique complète. Vous retirez le symptôme, mais pas la rampe d’accès.
Dans un cas typique, un fichier obfusqué contient une routine de décodage, mais la partie réellement dangereuse est parfois :
- dans une autre fonction appelée ailleurs dans une variable construite à partir de fragments dans un script récupéré à la volée depuis un domaine distant
Donc oui, on peut “nettoyer un fichier”. Mais si la logique s’appuie sur un autre fichier ou un autre répertoire, le site reste compromis.
La règle simple que j’applique en intervention : si un composant est chiffré, il est suspect par définition. Même si le décodage ne produit pas immédiatement du code visible, vous devez traiter le fichier comme une source d’exécution.
Signaux d’alerte concrets (sans se raconter d’histoires)
Quand vous cherchez de l’obfuscation et du code chiffré, vous avez besoin d’indices qui ne demandent pas d’être dev PHP expert. Les patterns ci-dessous reviennent souvent. Ce ne sont pas des “preuves absolues”, mais ce sont de très bons déclencheurs de contrôle.
Signaux qui doivent vous pousser à ouvrir le fichier
- Présence de eval(, assert(, preg_replace avec le mode /e (sur des versions plus anciennes), ou d’appels qui assemblent du code à l’exécution Données encodées massives (base64, échappement étrange de caractères) suivies d’un décodage puis d’un traitement Séquences du type “décompression” suivies d’un include ou d’une exécution Fichiers avec une structure très différente du reste du thème ou de l’extension, même si “ça reste dans le PHP” Changements de taille et de date de modification incohérents, surtout dans des thèmes et plugins rarement mis à jour
Je préfère parler de déclencheurs plutôt que de diagnostic automatique. Une vraie désinfection, c’est une décision informée, pas un match de signatures.
Où se cache généralement l’obfuscation
Le réflexe “chercher dans le dossier wp-content” est bon, mais incomplet. Les attaques qui utilisent de l’obfuscation exploitent souvent des emplacements où WordPress charge du code, soit directement, soit indirectement.
Les emplacements les plus fréquents, que vous devez vérifier en priorité :
- wp-content/plugins/ : les plugins compromis sont fréquents, surtout ceux installés depuis longtemps ou rarement mis à jour wp-content/themes/ : un thème modifié, ou un thème “semi-légal” qui charge un fichier de façon détournée wp-content/uploads/ : moins fréquent pour l’exécution directe, mais parfois des scripts y sont déposés, ou des fichiers “contenant du code” sont présents Fichiers racine : selon la charge utile, un script peut être injecté dans des fichiers que WordPress lit au démarrage Répertoires cachés ou noms atypiques : certains malwares créent des dossiers aux noms peu intuitifs pour éviter les inspections
Le point important : l’obfuscation peut aussi être dans un endroit “sûr” mais inclus par un fichier compromis. Autrement dit, vous devez aussi comprendre le chemin d’exécution, pas seulement l’emplacement.
Méthode de désinfection : traiter l’infection comme un graphe, pas une chasse au fichier
Je sais, ça ressemble à une consigne d’ingénieur. Mais, sur le terrain, c’est une façon de réduire les allers-retours.
Au lieu de “je supprime un fichier suspect”, je pense “quels fichiers déclenchent quoi ?”. WordPress est un moteur de chargement. Si vous identifiez : 1) le point d’entrée (fichier chargé) 2) le mécanisme d’obfuscation (décodage, déchiffrement) 3) la sortie (exécution, inclusion, récupération distante)
Alors vous pouvez retirer la source d’exécution sans casser le site, et sans laisser de logique cachée.
Concrètement, quand je tombe sur un bloc encodé, je ne “le décodage à l’aveugle” dans un premier temps. Je me contente d’analyser la forme, puis je vérifie le reste du contexte : où le fichier est inclus, quelles fonctions sont appelées, et si la chaîne est utilisée pour construire un chemin, une URL, ou du code PHP.
Cette discipline évite les erreurs qui arrivent vite : supprimer une dépendance nécessaire à l’activité légitime d’un plugin, alors que le vrai malware était ailleurs, ou retirer une partie du déchiffrement sans neutraliser l’exécution.
Désinfection WordPress : actions immédiates sans improvisation
Quand un client signale des redirections, des pages transformées, une hausse de spam, ou une alerte de sécurité, je commence par figer la situation. Pas pour “être prudent”. Pour limiter la propagation et préserver les éléments utiles.
Voici la mini check-list que j’utilise. Elle reste volontairement courte, parce que le risque principal, c’est de perdre du temps dans des manipulations sans preuve.
- Mettre le site en mode maintenance si la charge est active (ou bloquer temporairement l’accès public) Désactiver provisoirement les plugins et thèmes récemment modifiés ou installés (et ceux inconnus) Faire une copie complète du répertoire concerné, y compris les fichiers de configuration utiles Rechercher les fichiers récemment modifiés dans wp-content et les fichiers racine liés au chargement Conserver les extraits suspects (copie texte) avant suppression, pour documenter et valider
Une fois ce socle posé, la désinfection devient un travail de reconstruction contrôlée.
Comment analyser du code chiffré ou obfusqué sans exécuter le malware
Le réflexe dangereux, c’est “je lance le fichier pour voir ce qu’il fait”. Sur un incident réel, je préfère éviter toute exécution côté serveur tant que ce n’est pas isolé.
Voici l’approche que je recommande, surtout quand le code contient des routines de déchiffrement :
1) Lire le fichier comme un document d’entrée
Cherchez les appels à eval, à include, à require, aux fonctions de décompression, aux décodages de chaînes, aux transformations sur des variables.2) Localiser les “jonctions”
Le code chiffré produit souvent du texte, puis ce texte est exécuté, inclus, ou envoyé en requête HTTP. Si vous trouvez la variable finale, vous avez la sortie du mécanisme.3) Vérifier si des dépendances externes existent
Même en restant prudent, cherchez des indices d’URL, de domaines, ou de chemins vers d’autres fichiers PHP. Parfois la partie chiffrée est juste une commande d’amorçage.4) Comparer avec une version connue
Si le plugin ou le thème existe dans l’écosystème officiel, une comparaison avec une version standard est souvent le plus efficace. On ne parle pas de “preuve juridique”, mais de validation opérationnelle.Le but n’est pas de déchiffrer tout le bloc à chaque fois. Le but est d’établir que le mécanisme sert à exécuter quelque chose hors de l’intention légitime.
Pourquoi “supprimer l’obfuscation” n’est pas toujours possible
Beaucoup de tutos proposent de “décoder base64, retirer l’obfuscation, remettre le code propre”. Sur WordPress, ce n’est presque jamais réaliste.
Pourquoi ? Parce que le code chiffré peut être :
- fragmenté construit au runtime chargé de manière conditionnelle dépendant de variables, de fichiers, et parfois de requêtes externes
Le résultat pratique est que vous n’avez pas un “code normal” à récupérer. Vous avez une charge. La désinfection consiste donc à neutraliser le point d’exécution et à remplacer ce qui est modifié par une version saine.
Dans mon expérience, l’idée de “nettoyer l’obfuscation” mène à deux risques :
- casser le plugin ou le thème si vous supprimez un morceau non malveillant mais nécessaire laisser une variante du mécanisme activée ailleurs
La voie la plus fiable reste souvent la réinstallation contrôlée du composant compromis, depuis une source sûre, après reconstruction.
Réinstaller proprement : le plan qui limite les erreurs
La désinfection ne signifie pas “patcher au hasard”. Sur les composants WordPress compromis, la méthode la plus robuste est souvent :
- identifier exactement quel thème ou quel plugin a été modifié supprimer le composant le réinstaller depuis une source fiable vérifier le site en conditions réelles
Cette approche est plus lourde qu’un simple effacement, mais elle limite l’erreur humaine. Si vous avez déjà observé de l’obfuscation, c’est rarement un ajout bénin.
Dans certains cas, vous ne pouvez pas reconstruire facilement (plugin custom, thème sur mesure). Là, il faut une logique de réparation, par exemple comparaison avec un historique propre, ou restauration depuis un dépôt interne.
Et si le malware est “dans la configuration” ?
Il arrive que la logique d’injection ne soit pas dans un plugin ou un thème, mais dans des fichiers de configuration ou des scripts ajoutés à la racine, parfois associés à un paramétrage qui déclenche des inclusions.
Quand c’est le cas, la désinfection doit être plus stricte. Je traite alors les fichiers racine modifiés comme des éléments à reconstruire. Et si l’accès au code est resté ouvert après l’incident, je mets aussi le focus sur la compromission d’accès :
- comptes WordPress créés ou modifiés clés API ou identifiants dans des scripts utilisateurs “fantômes” dans WordPress erreurs d’accès côté serveur
Sans cette étape, vous pouvez parfaitement “nettoyer” une fois et être re-compromis très vite.
Un exemple de démarche sur un cas typique
Je repense à un site qui ne donnait pas de symptômes forts. Les redirections étaient sporadiques, sur certaines URL. Les logs serveur montraient des requêtes répétées, mais pas assez pour convaincre d’un remplacement complet.
En examinant les fichiers modifiés dans wp-content, j’ai trouvé un plugin qui n’avait pas été mis à jour depuis des mois. Dans un fichier PHP, une section ressemblait à un bloc base64 énorme, suivie d’une fonction qui reconstruisait du PHP. L’étape suivante a été de regarder dans quel fichier WordPress importait ce code. Le plugin avait une routine qui s’exécutait sur init, puis appelait une logique de décodage.
Ce qu’on a fait n’a pas été “déobfusquer et nettoyer”. On a :
- documenté les fichiers modifiés remplacé le plugin par une version propre vérifié que la routine d’injection n’existait plus réinitialisé les identifiants et changé les mots de passe durci l’accès aux fichiers (au niveau des droits et de la discipline de déploiement)
Résultat : plus de déclenchement sporadique. Le site a retrouvé un comportement stable.
Ce type d’histoire illustre bien le point clé : si le code est obfusqué et chiffré, il n’est pas “juste embêtant”. Il est conçu pour échapper à la lecture et rester actif.
Vérifier que la désinfection a réellement tenu
Après nettoyage, beaucoup de gens valident “ça a l’air bon” en ouvrant deux pages. C’est une validation faible.
Je préfère une validation en deux temps :
- vérifier l’absence de mécanismes d’exécution suspects dans les fichiers vérifier le comportement via des parcours utilisateur et quelques URL à risque
Selon votre environnement, les tests incluent aussi :
- un contrôle des redirections une vérification du rendu sur des pages attendues un contrôle des entrées utilisateur et des formulaires, car certaines charges injectent du code dans des sorties HTML
Il y a aussi un test pragmatique que je fais souvent : comparer les fichiers et tailles d’un composant reconstruit à ce que vous attendez d’une installation standard. Si des écarts apparaissent, vous n’êtes pas “revenu à zéro”, vous êtes dans une zone grise.
Les limites et les pièges à connaître
Il existe des cas où même une méthode robuste demande du jugement.
Vous pouvez supprimer un faux positif
Un plugin “legit” peut contenir des chaînes encodées, parfois pour des raisons de compression, de compatibilité ou de chargement de ressources. Si vous retirez un bloc sans comprendre, vous cassez le site.
C’est pour ça que je distingue déclencheurs et preuve. L’obfuscation seule ne suffit pas. C’est l’usage, le contexte d’exécution et la présence de fonctions dangereuses qui font basculer.
Vous pouvez rater un fichier généré
Certains plugins génèrent des fichiers en fonction de cache, de minification, ou de build. En cas d’incident, un attaquant peut aussi générer un artefact qui change de façon dynamique.
La solution n’est pas de “supprimer tout le cache”. C’est de comprendre quels dossiers sont générés légitimement, puis d’aligner avec vos habitudes de déploiement.
Vous pouvez reconstruire le site, mais garder l’accès compromis
Même avec une désinfection parfaite sur le code, si un compte a été volé, si une clé SSH reste en place, ou si l’accès FTP est resté trop ouvert, l’attaquant revient. Dans ce scénario, l’obfuscation réapparaît ailleurs, sous une nouvelle forme.
C’est là que la sécurité applicative et la sécurité d’accès doivent être traitées ensemble.
Durcir après désinfection : éviter que l’obfuscation revienne
La désinfection supprime l’intrusion, mais elle ne remplace pas les conditions qui l’ont rendue possible.
Le durcissement le plus utile, dans l’ordre que je privilégie, consiste à réduire :
- les surfaces d’entrée les chances que des comptes restent faibles les modifications non tracées l’exposition à des thèmes et plugins non maintenus
Je ne vais pas transformer ça en liste exhaustive, parce que chaque stack a ses contraintes. Mais je peux dire ce que j’ai vu fonctionner de façon réaliste sur des environnements WordPress.
Premièrement, contrôler les plugins et thèmes installés, surtout ceux qui ne sont plus maintenus. Deuxièmement, réduire la permissivité des droits fichiers. Troisièmement, mettre en place une procédure de mise à jour claire, avec un historique et un rollback possible.
Sur des sites qui ont eu une première désinfection WordPress, le retour d’obfuscation vient souvent de la même cause : un composant compromis ou un accès trop facile.
Quand il faut passer le relais à une restauration complète
Il y a un moment où “désinfecter fichier par fichier” devient une perte de temps.
Je le recommande quand :
- trop de dossiers sont touchés, avec des traces dans plusieurs plugins et thèmes les fichiers de configuration et la racine sont modifiés les logs indiquent une activité continue ou une persistance il n’y a pas de sauvegarde fiable avant incident, et les changements sont difficiles à retracer
Dans ces cas, une restauration depuis une sauvegarde saine, suivie d’un durcissement, est souvent le chemin le plus court. Ce n’est pas un aveu d’échec, c’est une stratégie de maîtrise.
Checklist de validation finale (courte, orientée action)
Cette seconde liste sert uniquement à cadrer le contrôle après désinfection. Elle est courte, parce que le but n’est pas de multiplier les contrôles, mais de les rendre efficaces.
- Vérifier que les plugins et thèmes “réinstallés” ne contiennent plus de blocs obfusqués ou de routines d’exécution suspectes Confirmer qu’aucun fichier PHP nouveau ou modifié n’apparaît dans les emplacements attendus après plusieurs heures de fonctionnement Contrôler les redirections et le rendu sur des URL clés, y compris celles qui étaient touchées Réinitialiser mots de passe et tokens, et vérifier qu’aucun compte WordPress non attendu n’existe Consigner ce qui a été fait, avec une trace des composants remplacés et des dates
Ce dernier point paraît administratif, mais il est précieux. Quand un incident revient, vous voulez pouvoir prouver ce qui a été neutralisé, et ce qui reste à traiter.
Ce que “supprimer l’obfuscation et le code chiffré” signifie vraiment
Dans le jargon des interventions, on résume souvent par “on supprime l’obfuscation”. En pratique, la suppression correcte consiste à retirer la source d’exécution qui contient l’obfuscation. Cela implique :
- neutraliser le point d’entrée qui déclenche la déchiffrement remplacer le code modifié par une version saine vérifier que la logique conditionnelle n’existe plus s’assurer que l’accès à l’environnement ne permet pas un retour
Si vous faites uniquement “du nettoyage visible”, vous risquez de laisser une seconde étape. Si vous refaites proprement le composant compromis et que vous contrôlez l’accès, vous supprimez le moteur, pas seulement l’habillage.
C’est la différence entre une désinfection de surface et une désinfection qui tient.