Un site WordPress piraté, ce n’est pas seulement du spam en page d’accueil ou une alerte de navigateur. Les dégâts les plus graves sont souvent invisibles à l’œil nu : des portes dérobées discrètes, parfois une poignée de lignes de code, qui permettent au pirate de revenir quand il veut, même après une restauration en apparence réussie.
Quand on gère des sites WordPress en production, on finit par voir un schéma récurrent. On nettoie un site à la va‑vite, on supprime les fichiers manifestement infectés, on change quelques mots de passe, tout semble rentrer dans l’ordre. Puis, deux jours ou deux semaines plus tard, le même site se remet à envoyer du spam ou redirige à nouveau vers un site douteux. Neuf fois sur dix, c’est parce qu’une backdoor est restée en place.
Cet article se concentre sur ce point précis : comment repérer, avec méthode, ces portes dérobées dans un contexte d’urgence WordPress piraté, quand le temps est compté et que le site doit revenir en ligne sans perdre de données.
Ce qu’est réellement une backdoor WordPress
Sur WordPress, une backdoor est un morceau de code, souvent en PHP, conçu pour donner au pirate un accès persistant à votre site, même si vous changez les identifiants ou corrigez la faille initiale. Elle peut permettre, selon son niveau de sophistication, d’exécuter n’importe quelle commande PHP, d’uploader des fichiers, de modifier la base de données, ou simplement de réactiver d’autres morceaux de malware à la demande.
Sur le terrain, ces portes dérobées prennent des formes variées :
- un fichier PHP isolé avec un nom qui ressemble à un fichier système, une fonction ajoutée dans un fichier légitime comme wp-config.php, du code noyé dans un plugin ou un thème, parfois protégé par plusieurs couches d’obfuscation, un webshell qui permet au pirate de naviguer dans votre hébergement comme dans un gestionnaire de fichiers.
La plupart du temps, les backdoors sont conçues pour être discrètes plutôt qu’agressives. C’est ce qui les rend difficiles à repérer quand on a la tête dans le guidon.
Avant de chercher la backdoor : stabiliser la situation
Quand on intervient en urgence sur un WordPress piraté, la tentation est de commencer immédiatement à supprimer des fichiers suspects. C’est compréhensible, mais risqué. Une approche structurée permet de gagner du temps sur la durée, et surtout d’éviter de casser définitivement le site ou de perdre des preuves importantes.
Je recommande systématiquement de suivre cette courte séquence avant toute chasse aux backdoors :
Mettre le site en mode maintenance ou restreindre l’accès par IP, pour limiter les dégâts et éviter que Google continue d’indexer des pages infectées. Faire une sauvegarde complète des fichiers et de la base de données, même si tout semble compromis. Cette copie servira soit à une analyse plus poussée, soit de preuve pour un éventuel prestataire sécurité ou hébergeur. Vérifier auprès de l’hébergeur si des alertes existent déjà, et si d’autres sites sur le même compte sont touchés. Une backdoor est souvent utilisée pour se déplacer latéralement sur le serveur. Changer immédiatement les mots de passe les plus sensibles : accès FTP / SFTP, panel d’hébergement, back‑office administrateur WordPress, compte de la base de données si possible.Une fois ce socle posé, on peut attaquer la partie la plus délicate : la recherche méthodique des portes dérobées.
Comment les backdoors WordPress se cachent dans les fichiers
Les développeurs de malware WordPress savent très bien comment les administrateurs réagissent en situation d’urgence. Ils savent que le réflexe consiste à regarder les fichiers récemment modifiés, surtout dans wp-content. Du coup, les portes dérobées les plus efficaces exploitent des recoins moins évidents.
Les fichiers système de base
Les répertoires racine de WordPress, comme la racine du site elle‑même, contiennent une poignée de fichiers PHP clés : index.php, wp-config.php, wp-settings.php, wp-load.php, etc. Les pirates les aiment beaucoup, parce qu’ils sont presque toujours chargés sur chaque requête.
Dans wp-config.php, on voit souvent apparaître de courtes sections supplémentaires, par exemple au tout début du fichier, avant la déclaration de la variable $table_prefix, ou tout en bas, après la ligne qui mentionne "C’est tout, ne touchez pas à ce qui suit". Un code malveillant à cet endroit profite du fait que WordPress va charger ce fichier à chaque visite.
L’expérience montre que de nombreux administrateurs n’osent pas toucher à ces fichiers, par peur de casser le site. Les pirates le savent et en profitent. C’est donc un des premiers endroits à examiner dès qu’une urgence WordPress piraté est signalée.
Plugins et thèmes : la cachette favorite
Le dossier wp-content/plugins est un terrain de jeu privilégié. On y trouve deux grands types de backdoors.
D’abord, des plugins pirates complets, avec un nom qui ressemble à un plugin légitime, parfois en copiant même le header d’un vrai plugin. Par exemple, un "hello-dolly" qui ne vient pas du dépôt officiel, ou un plugin avec un nom générique du type "wp-security", "seo-boost" ou "cache-performance" que personne ne se rappelle avoir installé.
Ensuite, des fichiers ajoutés à un plugin existant, ou des modifications dans un fichier de ce plugin. Un cas fréquent consiste à insérer, dans la première ou la dernière ligne d’un fichier de plugin, un eval(base64_decode('…')) ou une fonction custom obfusquée qui appelle un code externe.
Les thèmes ne sont pas épargnés. Le thème actif, mais aussi d’anciens thèmes laissés en place, peuvent héberger du code malveillant dans functions.php, header.php, footer.php ou 404.php. Un pirate peut par exemple utiliser la page 404 pour exécuter discrètement des commandes lorsqu’il reçoit une requête avec un certain paramètre.
Le dossier uploads, souvent sous‑estimé
On pense rarement à chercher des scripts PHP dans wp-content/uploads. Pourtant, c’est l’un des endroits préférés des webshells, parce que de nombreux sites autorisent l’upload de fichiers, parfois avec une validation insuffisante.
On trouve alors des fichiers comme image.php renommés en .jpg mais avec un type MIME contourné, ou des fichiers placés dans un sous‑dossier année/mois avec un nom qui ressemble à celui des photos du site. Un rapide examen local révèle qu’il s’agit d’un script complet offrant au pirate une interface d’administration occulte.
Certains hébergeurs désactivent l’exécution de PHP dans uploads, mais c’est loin d’être systématique. Sur des hébergements mutualisés anciens, cette simple précaution est parfois absente, ce qui ouvre un boulevard aux backdoors.
Indices concrets que vous avez encore une backdoor
Plusieurs signaux faibles indiquent que la compromission n’est pas entièrement résolue. Lorsqu’on gère une urgence WordPress piraté, ces symptômes doivent immédiatement faire penser à la présence d’une porte dérobée.
Premier cas typique : vous nettoyez les fichiers infectés identifiés par un scanner, la situation se calme, puis dans les heures qui suivent des fichiers réapparaissent comme par magie, avec des dates de modification très récentes. Cela signifie souvent qu’un script encore en place automatise le ré‑upload ou la ré‑écriture des fichiers infectés.
Second cas fréquent : la modification de fichiers se produit à des heures où personne ne se connecte au back‑office. Sur certains hébergements, on peut consulter les logs FTP ou SFTP pour voir si des connexions suspectes ont eu lieu. S’il n’y en a pas, mais que des fichiers PHP changent malgré tout, c’est que la modification se fait depuis l’intérieur du site lui‑même, via une backdoor qui écrit sur le système de fichiers.
Autre indice : l’apparition de requêtes étranges dans les logs web, visant toujours les mêmes fichiers avec des paramètres très longs, souvent en POST, ou des user‑agents exotiques. Une backdoor très utilisée laisse ce genre de traces, parce que le pirate ou ses scripts automatisés l’appellent régulièrement.
Enfin, si Google Search Console ou d’autres outils signalent régulièrement de nouvelles URLs malveillantes même après nettoyage, c’est presque toujours le signe qu’un code serveur réinjecte à la volée des pages créées dynamiquement. Dans ce cas, la backdoor ne se contente pas de fichiers, elle agit aussi côté base de données.
Méthode structurée pour repérer les backdoors
La chasse aux backdoors n’est pas un exercice de clic au hasard dans un explorateur de fichiers. Une méthode, même simple, fait la différence entre un nettoyage durable et une fausse impression de sécurité.
Voici une approche en cinq étapes qui fonctionne bien, même sous pression.
Télécharger une copie complète des fichiers sur un poste local pour analyse. Travailler via un simple éditeur FTP limite la visibilité et multiplie les erreurs. Vérifier tous les fichiers dans la racine WordPress et les comparer à une version officielle de WordPress de la même version. Tout fichier en plus ou modifié, à part wp-config.php et éventuellement .htaccess, mérite un examen attentif. Examiner les plugins installés et les comparer à leurs versions officielles (via le dépôt WordPress ou des archives). Les différences inattendues, surtout en haut et en bas des fichiers PHP, sont suspectes. Parcourir les thèmes, en commençant par le thème actif, en cherchant les fonctions inconnues, les longs blocs de code obfusqué, ou les includes vers des fichiers qui n’ont rien à faire là. Traquer tout fichier PHP dans le dossier uploads, ainsi que les fichiers au nom étrange dans wp-content, par exemple très courts ou très longs, ou avec des combinaisons de lettres peu naturelles.Même avec cette méthode, il est facile de passer à côté d’une backdoor bien cachée. Les pirates ont l’habitude de répartir le code en plusieurs fichiers et d’utiliser des noms de variables trompeurs pour se fondre dans le décor.
Utiliser intelligemment les outils de scan
Les scanners de sécurité, qu’ils soient fournis par l’hébergeur, intégrés sous forme de plugin ou exécutés à part, sont utiles mais imperfectibles. Ils détectent assez bien les signatures connues, moins bien les codes obfusqués sur mesure.
Pour gagner du temps, certains outils permettent une recherche par motif sur l’ensemble des fichiers. On peut ainsi faire ressortir des éléments typiques des backdoors, comme les fonctions eval, assert, base64 decode, gzinflate, pregreplace avec le modificateur /e (sur les anciennes versions de PHP), ou encore les encodages hexadécimaux.
Il ne s’agit pas de supprimer systématiquement tout ce qui contient ces chaînes, plusieurs plugins légitimes les utilisent encore. En revanche, elles permettent de cibler plus rapidement les fichiers qui méritent un examen manuel approfondi.
Un autre point important consiste à regarder les permissions des fichiers. Des fichiers PHP avec des droits d’écriture trop larges (par exemple 666) dans des endroits où ils ne devraient pas être modifiés indiquent que le pirate a peut‑être laissé une porte ouverte pour réécrire le code à la volée.
Les scanners côté hébergeur sont utiles pour avoir une vue plus large, surtout si plusieurs sites partagent le même compte. Si un autre site présent sur le même hébergement est compromis, il peut servir de point d’appui pour réinjecter du code malveillant dans votre WordPress, même après nettoyage.
Inspection ciblée de la base de données
Une backdoor ne se limite pas forcément aux fichiers. Sur WordPress, certaines sont partiellement ou totalement stockées dans la base de données, souvent dans les tables d’options ou de contenu.
Dans la table wp_options, on trouve parfois des options aux noms étranges qui contiennent des blocs de code encodés, ou des URLs pointant vers des scripts externes. Des options autoloaded à "yes" qui ne devraient pas l’être peuvent aussi servir à exécuter du code à chaque chargement de WordPress.
Le contenu des articles et des pages peut également cacher des scripts, en particulier dans les champs personnalisés ou dans des shortcodes obscurs. J’ai déjà vu des backdoors déclenchées via un shortcode ajouté dans une page 100 % légitime, ce qui rend l’analyse plus compliquée, car le code principal est dans un plugin mais reste inactif tant que le shortcode n’est pas appelé.
Les tâches planifiées, via wp_cron, méritent une inspection lorsque le site se réinfecte régulièrement à intervalles fixes. Une tâche cron malveillante peut se charger, par exemple, de réécrire un fichier infecté toutes les nuits à 3 heures, juste après un backup automatique, ce qui rend la cause plus difficile à remonter.
Check‑list rapide pour une situation d’urgence
Quand on est face à un client paniqué ou à un site vitrine qui ne peut pas se permettre de rester hors ligne, il est utile d’avoir une check‑list courte en tête. Sans transformer tout l’article en pas‑à‑pas, voici un rappel structuré qui aide à ne pas oublier les points critiques.
Liste 1 : priorités dans les premières heures
Isoler le site (maintenance, restriction IP ou désactivation temporaire) pour limiter l’impact. Sauvegarder l’ensemble des fichiers et la base de données avant tout nettoyage. Changer tous les accès critiques : FTP/SFTP, hébergeur, admin WordPress, base de données. Scanner rapidement l’arborescence à la recherche de fichiers suspects dans la racine, wp-content, uploads. Signaler l’incident à l’hébergeur si nécessaire, surtout si l’IP ou le domaine sont déjà blacklistés.Cette liste ne remplace pas une analyse détaillée, mais elle évite les erreurs irréversibles du type "nettoyage sans sauvegarde" ou "remise en ligne d’un site encore ouvert comme une passoire".
Pièges classiques lors de la suppression des backdoors
Le réflexe le plus courant, quand on trouve un fichier suspect, est de l’ouvrir, de supprimer le code qui semble malveillant, puis de sauvegarder. C’est parfois suffisant, mais souvent incomplet.
Premier piège : ne pas vérifier la totalité du fichier. Beaucoup de backdoors insèrent un code malveillant au début, puis un second bloc plus discret au milieu ou à la fin. Un balayage rapide peut faire rater ces duplications.
Deuxième piège : oublier les inclusions indirectes. Un fichier qui a l’air propre peut simplement inclure un fichier caché situé dans un répertoire inattendu. Si l’on se contente de supprimer le fichier directement visible, l’inclusion d’un autre script malveillant reste en place et sera réactivée dès la prochaine requête.
Troisième erreur fréquente : supprimer des fichiers sans tenir compte de leur rôle réel. Sur un thème sur‑mesure ou un plugin peu documenté, il est tentant d’effacer tout ce qui paraît étrange. On casse alors des fonctionnalités légitimes, ce qui complique le redémarrage. Dans ces cas, comparer avec une sauvegarde ancienne saine du site, si elle existe, est précieux.
Enfin, beaucoup surestiment la capacité des plugins de sécurité à tout résoudre. Un plugin peut aider à identifier et parfois neutraliser une backdoor simple, mais il ne remplace pas une inspection manuelle, surtout quand le pirate a déjà eu le temps d’installer plusieurs points d’accès.
Stratégie de nettoyage durable plutôt que bricolage
Une fois les backdoors identifiées et supprimées, la question clé est : comment s’assurer que l’attaque ne sera pas réactivée dans une semaine ou un mois. Là encore, l’expérience montre que les retours de flamme sont fréquents lorsque l’on se contente d’un nettoyage superficiel.
Une approche raisonnable consiste à repartir sur des fichiers WordPress, plugins et thèmes neufs autant que possible. Pour WordPress lui‑même, on peut remplacer l’intégralité des fichiers par une archive officielle, à l’exception de wp-config.php et du dossier wp-content. Pour les plugins, les réinstaller depuis le dépôt plutôt que de tenter de "réparer" des fichiers modifiés réduit fortement le risque de laisser traîner une backdoor.
Les thèmes posent plus de difficultés, surtout lorsqu’il s’agit de thèmes premium lourdement modifiés. Dans ce cas, il peut être nécessaire de comparer les fichiers actuels à une archive propre, et de reporter manuellement les modifications légitimes dans une version saine plutôt que l’inverse.
La base de données doit être revue avec attention, en particulier les options et les tâches planifiées. Supprimer ce qui est clairement malveillant, documenter les changements, et si possible faire valider la configuration par une personne qui connaît bien WordPress aide à repartir sur de bonnes bases.
Enfin, un suivi sur quelques jours reste recommandé. Surveiller les fichiers modifiés récemment, consulter les https://gardewp.fr/site-wordpress-pirate/ logs d’accès, et vérifier que rien ne réapparaît permet de confirmer que les backdoors ont bien été éradiquées.
Prévenir la réapparition des backdoors
Une urgence WordPress piraté révèle presque toujours des faiblesses préexistantes : version obsolète, plugins abandonnés, hébergement peu cloisonné, absence de sauvegardes sérieuses. Une fois la crise passée, il est logique d’investir un peu de temps pour réduire la surface d’attaque.
Les bonnes pratiques de base sont connues, mais rarement appliquées avec rigueur : mises à jour régulières, suppression des plugins et thèmes inutilisés, utilisation de mots de passe longs, activation de l’authentification à deux facteurs sur le back‑office, limitation des comptes administrateurs, restriction des droits d’écriture là où c’est possible.
Sur des environnements partagés, segmenter les sites sur des comptes distincts ou des conteneurs séparés réduit le risque qu’une backdoor sur un site permette de compromettre tous les autres. C’est un investissement organisationnel plus qu’une question de plugin, mais lors d’incidents répétés, c’est souvent le point qui fait la différence.
Enfin, disposer d’une vraie stratégie de sauvegarde, testée, change complètement la dynamique lors de la prochaine urgence. Pouvoir restaurer un snapshot propre daté d’avant la compromission, puis analyser tranquillement la version infectée en parallèle, enlève une grande partie de la pression et permet un travail de recherche de backdoors plus serein.
Quand faire appel à un spécialiste sécurité
Tout le monde n’a pas le temps ni l’envie de devenir expert en backdoors WordPress. Dès que l’incident touche un site e‑commerce, des données sensibles, ou qu’il se répète malgré plusieurs tentatives de nettoyage, l’intervention d’un spécialiste sécurité se justifie pleinement.
Un professionnel expérimenté ne se contente pas de supprimer quelques fichiers. Il analyse les schémas d’accès, les failles initiales, les mouvements latéraux éventuels, et met souvent en place une surveillance plus fine pour les semaines suivantes. Il sait aussi documenter l’incident, ce qui est important si l’on doit répondre à des obligations légales ou contractuelles.
Même si l’on préfère gérer soi‑même le quotidien, disposer d’un contact de confiance pour les situations d’urgence WordPress piraté apporte un filet de sécurité précieux. La chasse aux portes dérobées est un exercice où l’expérience directe compte beaucoup, et où les erreurs se paient cher lorsque le pirate a déjà pris ses habitudes dans votre environnement.
En traitant sérieusement la question des backdoors, on passe d’une logique de "pompiers" qui courent après des symptômes à une approche plus structurée de la sécurité WordPress. Les attaques ne disparaîtront pas, mais leur impact sera bien moindre si chaque incident est l’occasion de traquer, comprendre et supprimer ces accès persistants, plutôt que de simplement masquer leurs effets visibles.