Un plugin PBN WordPress dépose deux webshells par une injection SQL

Montrer le sommaire Cacher le sommaire

• Comment repérer une injection de backlinks PBN sur votre site WordPress
• Pourquoi des attaquants stockent des webshells dans la base de données
• Quels signes chercher dans la base de données pour détecter un webshell
• Comment nettoyer un site infecté sans aggraver la situation
• Quelles erreurs courantes empêchent une détection rapide
• Quels outils et requêtes pour investiguer efficacement
• Quelles mesures empêcheront ce type d’attaque à l’avenir
• Que faire si vous découvrez un plugin factice nommé de type PBN
• FAQ

Sur WordPress, les attaques modernes ne se contentent plus de déposer des fichiers visibles dans wp-content. Elles combinent plugins factices, serveurs de commande à distance et webshells dissimulés directement dans la base de données pour rester invisibles aux scanners classiques et monétiser le site via des réseaux de blogs privés ou l’affiliation.

Comment repérer une injection de backlinks PBN sur votre site WordPress

Une injection PBN se remarque rarement à l’œil nu sur le frontend. Le trafic et la mise en page restent généralement intacts, mais le code source des pages contient des liens sortants cachés ou des scripts injectés dans le <footer> ou avant la balise de fermeture </body>. Sur des sites compromis, vous verrez souvent :

• des scripts externes chargés depuis des domaines inconnus ;
• du contenu HTML ou JS inséré dynamiquement après le rendu côté serveur ;
• anomalies dans le rapport de liens sortants de Google Search Console.

Un bon réflexe est d’inspecter le code source rendu sur plusieurs pages et sous plusieurs user agents. Les attaquants testent parfois les réponses selon le User-Agent pour contourner des filtres ou des services de sécurité.

Pourquoi des attaquants stockent des webshells dans la base de données

Placer du code PHP malveillant dans wp_posts ou d’autres tables est une tactique payante pour eux. Les scanners se concentrent sur le système de fichiers et négligent souvent la base de données, créant une « zone aveugle ». De plus, du code stocké en BDD peut être exécuté via une vulnérabilité de thème ou plugin, ce qui évite d’avoir à déposer des fichiers sur disque et facilite la persistance.

En pratique, cela permet à l’attaquant de disposer d’un gestionnaire de fichiers accessible via HTTP qui offre les mêmes capacités qu’un accès SSH : lire des fichiers sensibles, modifier des scripts, récupérer des mots de passe et se déplacer lateralement sur l’hébergement.

Quels signes chercher dans la base de données pour détecter un webshell

Interroger la base est souvent plus efficace que l’analyse des fichiers. Cherchez des contenus qui ne sont pas des articles classiques mais qui contiennent du PHP, des fonctions d’écriture ou d’exécution, ou des séquences encodées. Exemple de requête utile adaptée à de nombreux environnements :

SELECT ID, post_title, post_type

FROM wp_posts

WHERE post_content LIKE '%<?php%' 

   OR post_content LIKE '%eval(%' 

   OR post_content LIKE '%base64_decode(%' 

   OR post_content LIKE '%file_put_contents%';

Ne vous contentez pas d’une seule recherche. Les attaquants utilisent parfois des techniques de contournement comme l’encodage base64, des morceaux de code fragmentés ou des fonctions noyées dans des commentaires. Une inspection manuelle des résultats est indispensable.

Comment nettoyer un site infecté sans aggraver la situation

La tentation de supprimer tout fichier suspect immédiatement est compréhensible mais risquée. Voici une séquence souvent plus sûre et éprouvée par les équipes d’intervention :

• prendre une sauvegarde complète avant toute modification ;
• isoler le site du trafic public pour éviter la propagation ;
• extraire et analyser les entrées de la base de données identifiées ;
• supprimer ou neutraliser les webshells en base puis vérifier les dépendances ;
• changer tous les mots de passe et clés d’accès après le nettoyage.

Supprimer un plugin malveillant du dossier wp-content/plugins n’est qu’une étape. Si des shells sont en base, l’attaquant conserve un point d’accès. C’est pourquoi il faut combiner suppression de fichiers, purge de BDD et rotation des identifiants.

Quelles erreurs courantes empêchent une détection rapide

En mission, on observe souvent des pratiques qui facilitent la compromission ou retardent sa découverte. Les plus fréquentes :

• ne pas auditer les tables WordPress pour du contenu non éditorial ;
• faire confiance aux seules signatures antivirus pour valider l’intégrité ;
• laisser des comptes administrateur inactifs ou des autorisations excessives ;
• ne pas surveiller les requêtes sortantes sur le serveur.

Le faux sentiment de sécurité vient souvent d’outils configurés de manière superficielle. Par exemple, un plugin de sécurité peut ignorer les requêtes sortantes ou ne pas consulter la base de données.

Quels outils et requêtes pour investiguer efficacement

Quelques commandes simples et outils open source accélèrent l’enquête. En complément de la requête SQL précédente, vérifiez :

Indicateur	Action recommandée
POSTs sortants vers domaines inconnus	inspecter les fichiers PHP et le WP cron pour les appels externes
Entrées wp_posts contenant PHP	exporter, analyser et supprimer après sauvegarde
Nouveaux comptes admin	valider l’origine et révoquer si suspect

Outils recommandés en pratique : un accès SSH pour greps rapides, MySQL client pour requêtes directes, et un scanner de conformité WordPress pour recenser les fichiers modifiés. N’oubliez pas d’examiner les logs du serveur web pour détecter des patterns de commande.

Quelles mesures empêcheront ce type d’attaque à l’avenir

La sécurité efficace combine prévention, détection et réponse. Au-delà des mises à jour régulières, adoptez ces bonnes pratiques :

• restreindre l’édition de fichiers dans l’administration WordPress ;
• implémenter une protection WAF qui filtre les requêtes sortantes suspectes ;
• mettre en place une surveillance régulière des tables critiques de la BDD ;
• activer l’authentification forte pour tous les comptes à privilèges.

En pratique, un pare-feu applicatif peut bloquer les beacons vers une infrastructure C2 qui tente d’injecter du contenu, tandis que la rotation des clés et mots de passe supprime l’accès persistant si des identifiants ont été exfiltrés.

Que faire si vous découvrez un plugin factice nommé de type PBN

Si vous tombez sur un plugin au nom lisse promettant une « intégration PBN » ou des solutions SEO douteuses soyez prudent. Voici une liste d’étapes pratiques :

• désactivez immédiatement le plugin et déplacez son dossier hors du site ;
• recherchez toute communication réseau provenant du site vers des domaines inconnus ;
• interrogez la base pour du contenu contenant du PHP et exportez ces enregistrements ;
• auditez les logs pour identifier la date et la méthode d’injection.

Ne restaurez pas de sauvegardes antérieures sans vérifier la racine de la compromission. Une sauvegarde peut déjà contenir des backdoors.

FAQ

Comment savoir si mon site a des webshells en base
Recherchez dans wp_posts et autres tables du contenu contenant <?php, eval(, base64_decode( ou fonctions d’écriture comme file_put_contents. Inspectez manuellement les résultats.

Est-ce suffisant de supprimer le plugin malveillant
Non. Si la compromission a créé des entrées en base ou modifié d’autres fichiers, l’attaquant peut rester présent. Il faut auditer la base, les comptes et les logs.

Quels logs consulter en priorité
les logs d’accès et d’erreur du serveur web, les logs PHP-FPM et, si possible, les logs réseau sortants. Ils montrent les requêtes vers des C2 et les patterns d’exfiltration.

Puis-je automatiser la détection des éléments suspects en base
Oui avec des requêtes SQL régulières et des règles SIEM. Mais complétez par des revues manuelles et des alertes sur les changements inattendus dans les tables critiques.

Un pare-feu peut-il bloquer ce type d’attaque
Un WAF bien configuré réduit le risque en bloquant les beacons vers des C2 connus et certaines requêtes malformées, mais il ne remplace pas la surveillance de la base et la rotation d’identifiants.