Quand un WordPress est “infecté”, on pense vite au thème, aux plugins ou à un fichier PHP qui a été modifié. Pourtant, dans beaucoup de cas réels, l’attaque laisse des traces plus discrètes dans la base de données. C’est souvent là que se cachent des charges utiles invisibles dans l’interface, des redirections logicielles, du contenu injecté, ou des options qui changent le comportement du site sans changer les fichiers immédiatement.
Vérifier les tables MySQL ou MariaDB, ce n’est pas une tâche exotique réservée aux experts. C’est une méthode pragmatique, surtout quand vous avez accès à phpMyAdmin, à WP-CLI, ou à un shell. L’objectif n’est pas de “tout effacer au hasard”, mais de repérer ce qui déraille, de relier les indices à une action probable, et de décider ensuite si vous devez corriger, restaurer, ou simplement isoler.
Je vais vous guider avec une approche qui s’appuie sur ce qu’on voit le plus souvent sur des installations compromises, en insistant sur les tables de la base de données WordPress que vous devez regarder en premier, et sur les requêtes à utiliser pour confirmer ce que vous suspectez.
Ce que vous cherchez vraiment dans la base
Avant de lancer des requêtes, clarifiez le but. Une base WordPress contient des données “normales” (articles, pages, utilisateurs, GardeWP urgence malware WordPress options de configuration), mais aussi des données qui peuvent être modifiées de façon indirecte.
Les scénarios fréquents ressemblent à ça :
- un plugin compromis modifie des options, ajoute des filtres, ou injecte des scripts via des champs “cachés” dans la base ; un attaquant crée un utilisateur administrateur, souvent avec un identifiant discret et un rôle élevé ; un spam de liens ou du contenu frauduleux apparaît sur le site, mais les fichiers du thème ne changent pas, parce que l’injection passe par des métadonnées ou une option ; des redirections apparaissent seulement sur certains parcours, parfois selon l’agent utilisateur, parce que des options ou des tables de tracking ont été altérées.
Le piège classique, c’est de confondre une installation qui a vécu avec des modifications “légitimes” (migration, ajout de plugin, optimisation) et des altérations malveillantes. C’est pour ça qu’on ne “scrute” pas la base en mode paranoïa, on compare et on cible.
Préparer l’enquête (et éviter d’aggraver)
Avant de toucher à quoi que ce soit :
1) Travaillez sur une copie ou une instance isolée si possible. Une export de la base, même rapide, vous donne une option de retour en arrière. Sur un site en production, ça change tout le niveau de risque.
2) Notez la période suspecte. Si vous savez “l’incident a commencé entre mardi soir et mercredi matin”, vous pouvez comparer l’état actuel avec ce qui existait avant, via logs d’hébergement, captures, ou au minimum une restauration.
3) Vérifiez l’authenticité d’accès. Si le site est compromis, le risque n’est pas seulement la base, c’est aussi votre session de travail. Utilisez un compte d’admin distinct pour l’investigation quand c’est possible, et évitez d’exécuter des commandes depuis un environnement non maîtrisé.
4) Gardez un œil sur la cohérence. WordPress stocke beaucoup de choses en option ou en meta. Une incohérence peut être juste un plugin mal configuré, mais si plusieurs tables montrent des anomalies dans le même sens, la probabilité augmente.
Vous n’avez pas besoin de devenir forensique dès la première heure, mais vous devez travailler “proprement”.
Les tables à vérifier en priorité sur WordPress
WordPress utilise un préfixe de tables, souvent wp_, parfois autre chose. Vos requêtes doivent intégrer ce préfixe. Pour simplifier, je vais parler des noms “WP standard”, mais gardez à l’esprit qu’il faut remplacer par le vôtre.
wp_options (la table la plus parlante)
C’est généralement la première à inspecter. Elle contient la configuration sous forme de paires clé-valeur. Beaucoup d’attaques s’exécutent en modifiant des options, en ajoutant des hooks ou en stockant des bouts de code dans des champs que WordPress réinjecte au runtime.
Ce que vous cherchez, ce sont des options dont la valeur ressemble à du JavaScript injecté, du HTML inattendu, des fragments PHP, ou des configurations de type “redirection” sans raison claire.
Exemples d’anomalies qu’on rencontre souvent :
- une option contenant des scripts obfusqués ou encodés (base64, chaînes avec des patterns répétitifs) ; des clés d’options “non standard” qui semblent liées à un plugin inconnu ; des valeurs volumineuses qui ne ressemblent pas à la configuration attendue.
Une requête utile consiste à lister les options dont les noms ne correspondent pas à des patterns habituels. Selon votre prudence, vous pouvez commencer par filtrer par taille de valeur :
SELECT option_name, LENGTH(option_value) AS size FROM wp_options ORDER BY size DESC LIMIT 30;Si vous voyez des valeurs gigantesques dans option_value, c’est un drapeau rouge. WordPress peut stocker des choses volumineuses (transients, caches, certains plugins), donc ce n’est pas une preuve, mais un point de départ.
Ensuite, ciblez des patterns de code dans les valeurs :
SELECT option_name, option_value FROM wp_options WHERE option_value LIKE '%