WordPress est solide, mais quand un site est compromis, le point de bascule se trouve souvent dans des fichiers PHP. Pas forcément ceux que l’on voit à l’écran. Parfois ce sont des fragments ajoutés quelque part, parfois un script “de porte dérobée” placé dans un endroit inattendu, parfois un fichier qui n’a rien à faire là, avec un nom banal. La bonne nouvelle, c’est qu’il existe des méthodes de détection assez fiables, à condition de travailler de façon méthodique, et de ne pas se contenter d’un “ça a l’air bizarre”.
L’objectif, ici, ce n’est pas seulement d’enlever le virus WordPress. C’est aussi de comprendre ce qui s’est passé, d’identifier les fichiers PHP suspects, de limiter la casse, et surtout de réduire le risque de récidive.
D’abord, vérifier les symptômes sans paniquer
Avant de plonger dans le code, prenez cinq à dix minutes pour observer ce qui se passe. Un site compromis a rarement un seul symptôme. Selon la manière dont l’attaque a été menée, vous verrez plutôt l’un de ces comportements, avec des variantes :
Le site redirige vers une URL inconnue, parfois uniquement selon la géolocalisation ou le navigateur. Une page “carte d’authentification” apparaît au lieu du contenu habituel, ou des formulaires renvoient vers des destinations inattendues. Vous remarquez une hausse soudaine du trafic sortant, des tentatives de connexion anormales, ou des requêtes web qui ne ressemblent pas à une navigation normale.
J’ai déjà vu des sites où l’infection était visible uniquement via les logs serveur, avec des appels à des scripts PHP qui renvoyaient des chaînes encodées, puis du JavaScript injecté en réponse. En public, le site semblait “presque normal”, quelques sections chargeaient mal, et il fallait comparer avec une page témoin saine.
Si vous avez accès, vérifiez aussi les traces d’activité dans WordPress : utilisateurs nouvellement créés, comptes avec rôles élevés, plugins ajoutés sans votre accord, thèmes modifiés, modifications de fichiers récents.
Le piège classique, c’est de se précipiter sur un seul plugin “suspect” et de supprimer. Sans analyse des fichiers PHP, vous pouvez effacer l’outil visible, mais laisser l’entrée, le mécanisme de persistance, ou un autre script caché.
Ce que “fichier PHP suspect” veut vraiment dire
Tous les fichiers PHP ne sont pas égaux face au risque. Dans une installation saine, on s’attend à trouver des fichiers PHP de WordPress à des endroits précis, et des fichiers PHP de plugins/thèmes aux emplacements habituels.
Un fichier PHP devient suspect quand, par exemple :
- Son contenu ne ressemble pas à du code métier attendu (trop d’obfuscation, variables et fonctions sans cohérence avec l’application). Il est présent dans un dossier qui n’est pas censé contenir de PHP (uploads, dossiers “cache” détournés, racines temporaires, répertoires de dépendances non destinés à l’exécution). Ses dates de modification ou de création sont incohérentes avec votre calendrier (plus récent que les mises à jour légitimes). Il charge du contenu distant, ou exécute du code extrait de requêtes HTTP, de chaînes encodées, ou de fichiers non déclarés.
Beaucoup d’attaques injectent une logique minimaliste, juste assez pour passer sous les radars. Elles peuvent inclure une chaîne encodée (base64, rot, gzinflate, strrev, concaténations) suivie d’un “eval” ou d’une exécution dynamique. Ce type de code n’a rien à faire dans un fichier de thème “normal”, sauf si vous avez une raison spécifique.
L’approche la plus efficace: comparer, dater, et inspecter
Pour détecter des fichiers PHP suspects, je recommande une approche en trois mouvements : comparaison entre un état sain (si vous en avez un) et l’état actuel, analyse des timestamps, puis inspection du contenu avec une grille simple.
Comparer avec une sauvegarde saine
La meilleure base de travail, c’est une sauvegarde antérieure à l’infection. Si vous n’avez pas de sauvegarde locale, regardez dans votre hébergement ou votre plugin de sauvegarde si vous pouvez restaurer un snapshot.
Ensuite, comparez la structure des fichiers. Même sans “diff” automatique parfait, vous pouvez repérer des fichiers ajoutés récemment, ou des dossiers nouveaux.
Dans un cas réel, nous avions un plugin censé contenir quelques fichiers. La comparaison a révélé un fichier PHP ajouté à la racine du plugin, nommé de façon générique, et pourtant il contenait des fonctions d’exécution dynamique. Le site redirigeait quelques URLs, mais le plugin “affichait” un comportement neutre en apparence.
Regarder les dates de modification côté serveur
Côté hébergement, utilisez un client FTP/SFTP ou un explorateur de fichiers pour repérer les dernières modifications. L’idée n’est pas d’accuser immédiatement un fichier, car une mise à jour légitime peut toucher plusieurs composants. Mais si vous voyez un fichier PHP dans un endroit étrange, modifié la veille de l’apparition des symptômes, c’est un signal.
Si vous avez un accès shell, faites attention à la notion de fuseau horaire et à l’heure de votre panneau de contrôle. La cohérence temporelle est ce qui rend l’analyse utile.
Inspecter le contenu sans tomber dans le piège de l’obfuscation
Quand vous ouvrez un fichier PHP suspect, cherchez d’abord les marqueurs typiques, pas l’esthétique. Certains signaux se répètent dans beaucoup de malwares WordPress :
Présence d’appels à eval, assert, preg replace avec le modificateur /e (très ancien mais encore vu), ou code qui reconstruit des segments pour les exécuter. Appels à des fonctions réseau ou d’accès distant comme fileget_contents avec une URL, curl, fopen sur une URL, ou include/require vers un chemin non maîtrisé. Chaînes encodées, puis décodeurs et exécution.
Parfois le code n’utilise même pas eval, il ne fait qu’injecter une charge utile via un include conditionnel. Donc le “contenu court” n’est pas une preuve d’innocence.
Où les attaques se cachent le plus souvent
Sans faire de promesses générales, il existe des schémas fréquents. Les attaquants exploitent des zones où l’administrateur ne pense pas à regarder régulièrement.
Racine et dossiers d’includes : on trouve parfois des ajouts dans des fichiers chargés au démarrage. Le but est d’exécuter une petite logique au moindre chargement d’une page WordPress.
Dossiers de thèmes et extensions : un thème ou un plugin peut être modifié de façon “propre” au début, puis appeler un script ailleurs, ou déclencher une action uniquement pour certains paramètres. C’est l’une des raisons pour lesquelles il faut inspecter le code réel, pas seulement la liste des plugins.
Dossiers liés aux médias : certaines familles d’infections tentent de placer du PHP dans des zones qui ne devraient contenir que des fichiers statiques. Cela peut rester inactif si la configuration serveur bloque l’exécution dans ces répertoires, mais si l’environnement a une configuration permissive, cela devient redoutable.
Gestion des fichiers uploads : même si WordPress stocke des médias en général, les chemins exacts et la configuration serveur jouent un rôle. Un fichier PHP mal placé peut rester visible mais jamais exécuté, jusqu’au jour où un réglage change.
Le bon réflexe consiste à faire l’inventaire des fichiers PHP présents dans des emplacements “non attendus” pour une installation WordPress classique.
Mettre en place un triage concret
Voici une façon pragmatique de procéder quand vous suspectez une infection PHP. L’idée est de filtrer vite, sans vous perdre dans des centaines de fichiers.
- Identifiez la date approximative d’apparition des symptômes, et notez-la. Repérez les fichiers PHP créés ou modifiés récemment, surtout dans des dossiers qui n’en contiennent pas d’habitude. Ouvrez chaque fichier suspect et cherchez des éléments comme eval, base64 decode, gzinflate, pregreplace avec des patterns qui servent à exécuter du code, ou des includes conditionnels bizarres. Vérifiez si un fichier suspect appelle une URL distante, charge du code depuis le web, ou écrit dans le système de fichiers. Comparez avec une sauvegarde ou une installation saine du même thème et des mêmes plugins, si vous pouvez.
Ce triage ne suffit pas à lui seul à “soigner”, mais il permet de concentrer l’effort sur les pièces qui comptent vraiment.
Exemples de signatures typiques dans du PHP compromis
Je décris ces signaux de manière pratique, sans vous donner une recette “copier-coller” de code malveillant. L’objectif est que vous puissiez reconnaître https://gardewp.fr/ des patterns.
1) Le fichier commence par une logique qui ne sert pas au thème ou au plugin, puis reconstruit une commande depuis une chaîne longue. Vous verrez souvent des concaténations, des fonctions de décode, et une exécution finale. Dans un contexte WordPress, une telle séquence est très rare.
2) Le fichier ne fait pas que “se rendre utile”, il cherche des conditions d’exécution. Par exemple, il peut vérifier un paramètre GET, une variable serveur, une présence de cookie, ou une comparaison d’IP. C’est une manière de limiter la détection pendant l’analyse.
3) Les fichiers “propres” mais appelés au mauvais moment. Un script peut être minuscule, et n’avoir presque rien en apparence, mais être inclus via un fichier principal déjà compromis. Dans ce cas, le vrai problème est ailleurs.
4) L’infection par modification des mécanismes de chargement. Parfois un fichier PHP modifie les hooks WordPress, ou réécrit certaines variables, puis fait un include vers un autre script. Si vous inspectez seulement le fichier visible, vous passez à côté de la partie qui persiste.
Vérifier la chaîne d’exécution, pas uniquement le fichier “bruyant”
Une question que j’utilise en audit, c’est : “Comment ce fichier est-il appelé ?”. Un fichier peut être suspect parce qu’il existe, mais il peut aussi être inoffensif s’il n’est jamais exécuté.
Pour comprendre la chaîne, repérez les inclusions et les références. Qui appelle le fichier PHP ? Est-ce via un hook, un include direct, un autoload, ou un chargement dynamique basé sur un paramètre ?
Quand vous trouvez une fonction comme require, include, ou des mécanismes d’automcharge, regardez les chemins. S’ils dépendent d’un paramètre utilisateur ou d’un contenu distant, c’est un gros drapeau rouge.
Dans une enquête récente, un fichier PHP semblait “juste” une page, avec un nom plutôt neutre. En retraçant l’appel, on a découvert que WordPress chargeait ce fichier via un autre script modifié qui interceptait une action. Tant que le lien d’exécution n’était pas compris, la suppression du “fichier final” n’avait aucun impact durable.
Séparer “compromis” et “dégât”: mesurer l’impact
Une infection peut être active ou dormante. Dormante signifie que le code est présent, mais n’est déclenché que sous certaines conditions. Mesurer l’impact, c’est important parce que ça guide la réponse.
Posez-vous des questions simples, en observant :
- Est-ce que le site redirige tout le temps, ou seulement sur certaines pages ? Est-ce que l’activité suspecte se produit juste après un chargement WordPress, ou après un clic spécifique ? Est-ce que des requêtes externes apparaissent dans les logs au moment précis où vous testez ?
Si vous avez accès aux logs serveur (souvent access.log et error.log), cherchez des patterns de requêtes vers des chemins PHP. Ce sont eux qui vous donnent la preuve d’exécution.
Précautions pendant la suppression des fichiers
Enlever virus WordPress en supprimant des fichiers est tentant, mais il faut éviter trois erreurs classiques.
La première, c’est de supprimer un fichier sans retirer le mécanisme qui l’appelle. Vous aurez l’impression d’avoir “nettoyé”, puis le site recommence à se dégrader, parfois avec des fichiers recréés.
La deuxième, c’est de supprimer un fichier au milieu d’un thème ou d’un plugin sans comprendre les dépendances. Vous risquez de casser le site, et de perdre un repère utile pour reconstruire l’état sain.
La troisième, c’est de ne pas traiter l’accès qui a permis l’infection. Un fichier PHP supprimé ne sert à rien si un compte compromis peut remettre le code à la prochaine heure.
Donc, après identification des fichiers PHP suspects, travaillez en miroir : nettoyage, puis correction de l’accès, puis validation.
Corriger aussi ce qui a permis l’infection
Les fichiers malveillants ne surgissent pas de nulle part. Souvent, l’attaque exploite un vecteur, par exemple un mot de passe faible, une session encore valide, une faille dans un plugin ou un thème, ou des permissions trop larges.
Je conseille de vérifier :
- Comptes administrateurs : suppression des comptes non reconnus et vérification de l’historique de création si disponible. Plugins et thèmes : mise à jour de tout ce qui est à jour, désactivation et retrait des éléments non nécessaires. Réglages de sécurité : limitations sur la tentative de connexion, contrôle des sessions, durcissement basique. Fichiers modifiés : surtout ceux qui ont des dates incohérentes.
Si vous avez été victime d’un accès via une API ou un point d’entrée, pensez aussi aux jetons et cookies persistants. Parfois il faut invalider les sessions pour empêcher le script de revenir avec le prochain chargement de WordPress.
Validation après nettoyage: le test réaliste, pas le test “à l’œil”
Après correction, ne vous contentez pas de vérifier que les pages s’affichent. Un malware peut laisser le contenu intact et garder une logique de redirection sur des conditions particulières.
Testez :
- Quelques pages de l’avant, mais aussi des pages d’administration si elles ne sont pas exposées. Les formulaires importants (connexion, contact si existant, recherche). Une navigation avec un navigateur différent, idéalement dans une fenêtre privée. L’absence de nouveaux fichiers PHP suspects, avec un contrôle de dates après 24 à 48 heures.
Si vous avez accès aux logs, c’est le moment de confirmer que les requêtes vers les chemins suspects n’apparaissent plus, ou chutent fortement.
Et si votre hébergement a des alertes sécurité, surveillez-les. L’idéal est d’avoir une boucle de retour rapide, car certaines infections reviennent après un délai, quand un autre composant tente une persistance.
Cas limites: code “bizarre” mais légitime
Il y a un risque à trop chercher. Parfois un fichier PHP peut sembler suspect parce qu’il est obfusqué, ou parce qu’il gère des conditions particulières, mais il appartient à un plugin légitime, ou à une bibliothèque de minification.
Un exemple courant : certains plugins de performance ou d’optimisation injectent du code conditionnel, utilisent parfois de l’encodage, ou gèrent des règles de filtrage. Cela ne veut pas dire qu’ils sont malveillants, mais cela impose une discipline : vérifier l’origine du code et sa cohérence avec la version de votre plugin.
Si vous pouvez, comparez avec les sources officielles du plugin ou du thème, ou au minimum avec votre copie saine connue. La différence entre “code obscur” et “code anormalement orienté exécution” se repère dans la structure globale : un plugin légitime reste souvent orienté logique applicative, tandis qu’un script malveillant a tendance à être orienté exécution, persistance et réseau.
Mettre la détection au service de la prévention
Une fois que vous avez géré l’urgence, la meilleure amélioration, c’est d’éviter que la prochaine infection vous trouve sans repères. Sans transformer votre site en laboratoire, vous pouvez mettre en place une hygiène utile.
Concrètement, gardez une stratégie de sauvegarde fiable et testez la restauration. Suivez les versions des thèmes et plugins, supprimez ce qui n’est plus utilisé, et limitez les permissions d’écriture quand c’est possible.
Et surtout, conservez un moyen simple d’inventorier les fichiers. Quand un site change “trop”, vous voulez le voir vite.
Quand demander une aide professionnelle
Si vous êtes face à une compromission lourde, surtout si vous suspectez un comportement persisté, du spam, ou une exfiltration, l’effort d’analyse peut dépasser le cadre du dépannage rapide.
Demandez de l’aide quand :
- Vous ne pouvez pas tracer la chaîne d’exécution des fichiers suspects. Vous observez une recréation de fichiers après nettoyage. Le site présente des comportements variés selon les conditions, et les logs sont difficiles à interpréter. Vous n’avez aucune sauvegarde exploitable avant l’incident.
Dans ces situations, un audit avec accès serveur, analyse de logs et contrôle d’intégrité permet d’éviter le “nettoyage à l’aveugle”.
Ce que vous devez retenir pour détecter des fichiers PHP suspects
Si je devais résumer une méthode de terrain, elle tiendrait en quelques idées très simples :
Inspectez les emplacements anormaux, regardez les dates, et examinez le code en cherchant la logique d’exécution dynamique et les appels réseau. Puis, reliez le fichier à ce qui l’appelle. Enfin, corrigez le vecteur d’accès, parce que le plus dangereux n’est pas le fichier, c’est la capacité à le réécrire.
En pratique, c’est ce fil logique qui fait la différence entre un site “qui paraît nettoyé” et un site réellement remis en sécurité, sans virus WordPress qui revient au prochain cycle d’activité.