Un site compromis se reconnaît rarement à un seul symptôme spectaculaire. Le plus souvent, c’est un ensemble de petites anomalies, répétées, qui finissent par raconter la même histoire. Des pages qui changent sans raison, des pics de trafic, des e-mails envoyés depuis une adresse de l’admin que personne n’a utilisés, une base de données qui grossit vite, des alertes dans votre console de recherche. Et surtout, une sensation familière: quelque chose “ne colle plus”, mais vous n’avez pas encore la preuve.
Dans cet article, je vous propose une méthode pragmatique, orientée terrain, pour repérer rapidement une compromission et surtout agir sans empirer la situation. L’idée n’est pas d’être parfait, c’est d’être efficace: limiter l’impact, vérifier les hypothèses, puis sécuriser site WordPress avec une remise en état propre.
Les premières minutes comptent plus que les premières heures
Quand un site tombe, l’attaquant cherche deux choses. D’un côté, garder un accès durable (un compte caché, une porte dérobée, un fichier qui se réinvente). De l’autre, monétiser ou brouiller les pistes (spams, redirections, pages “miroir”, cryptominage, ou simple collecte d’informations).
Chaque minute passée à “chercher le coupable” sans cadre peut faire gagner l’attaquant. Par exemple, si vous modifiez trop tôt des fichiers sans savoir ce qui a été altéré, vous pouvez détruire des traces. Si vous réinstallez en mode express sans analyser les journaux, vous risquez de réimporter le problème. J’ai déjà vu des équipes relancer la sauvegarde, remplacer des plugins “au hasard”, puis découvrir ensuite que l’injection venait d’un fichier moins visible, côté thème enfant ou d’un fichier d’activation.
Le bon réflexe, c’est d’organiser votre enquête comme un incident: on collecte, on isole, on corrige. Et on ne touche pas au site de production avant d’avoir au moins une base de comparaison (contenu connu, version de WordPress, liste des plugins, état du serveur).
Signaux qui trahissent un site compromis
Il existe des signaux très parlants, mais ils varient selon la façon dont le site est attaqué. Certains pirates exploitent une faille connue, d’autres utilisent un mot de passe réutilisé, d’autres encore passent par une faiblesse de configuration (mauvais droits de fichiers, accès FTP exposé, ou plugins abandonnés).
Voici les signes les plus fréquents, ceux que je rencontre le plus sur des audits et des interventions.
Ce que vous voyez côté utilisateurs
- Des redirections inhabituelles vers des domaines random, parfois seulement sur certaines pages. Des contenus modifiés: encarts publicitaires en dehors de votre logique éditoriale, faux formulaires, textes ajoutés au bas des pages. Une baisse nette de la qualité perçue: images qui disparaissent, CSS cassé, pages qui se chargent lentement et retombent sur des erreurs intermittentes.
Un point important: certaines infections ne se manifestent pas à chaque visite. L’attaquant peut cibler des navigateurs spécifiques, des plages d’IP, ou des comportements (utilisateurs qui viennent d’un moteur de recherche, par exemple). Donc si vous ne voyez rien sur votre machine, ce n’est pas une preuve d’innocence.
Ce que vous observez dans l’administration WordPress
Dans WordPress, les compromis prennent souvent une forme “administrable”, ce qui trompe parce que ça ressemble à une action légitime.
- Comptes utilisateurs créés ou rôles modifiés sans explication. Changements sur les rôles, par exemple un compte “Auteur” devenu “Administrateur”. Apparitions de nouveaux plugins, ou activation de composants qui n’étaient pas dans votre liste. Modifications de fichiers qui ne devraient pas être touchés par des routines normales, par exemple du code injecté dans des thèmes.
Et il y a ce symptôme subtil: un administrateur “perd” d’un coup des droits, ou le panneau refuse des actions après un certain moment. Quand les sessions sont manipulées côté serveur, WordPress peut devenir instable.
Indices côté serveur et logs
Le serveur parle souvent plus vrai que l’interface. Selon votre hébergement, vous avez accès à des logs Apache ou Nginx, aux logs PHP, parfois à des métriques de trafic.
Les signaux typiques incluent:
- Une hausse brutale de requêtes en provenance d’une ou plusieurs adresses IP (souvent sur des chemins étranges). Des erreurs PHP répétées liées à des fichiers que vous ne reconnaissez pas. Une charge CPU anormale si une charge de cryptominage ou un script de minage s’est déployé. Une croissance rapide de la base de données, parfois corrélée à des entrées “bizarres” (contenu auto-généré, révisions, tables supplémentaires).
Si vous avez une règle d’or, c’est celle-ci: si vous n’avez pas de logs exploitables, commencez par réorganiser la collecte. Sans historique, la “détection” devient une opinion, pas une enquête.
Comment vérifier sans aggraver
La tentation naturelle, c’est de restaurer tout de suite à partir d’une sauvegarde, surtout si vous avez un doute. C’est souvent une bonne direction, mais il faut la faire correctement.
Avant toute restauration, prenez le temps de répondre à deux questions: qu’est-ce qui a changé récemment, et où se trouve la persistance probable?
Persistances fréquentes sur WordPress: fichiers modifiés (souvent dans le thème ou des fichiers chargés tôt), scripts dans des dossiers inattendus, ajouts dans la base de données (options, injections dans des champs), ou modifications des droits permettant à un webshell de fonctionner.
Règles simples pour l’investigation
1) Isolez le site. Si possible, mettez en maintenance via le mécanisme WordPress ou via votre reverse proxy, le temps de collecter les infos. Cela évite aussi d’envoyer davantage de trafic vers une version infectée.
2) Préservez les preuves. Faites une copie des fichiers et de la base de données avant toute réécriture. Même si vous finissez par repartir d’une sauvegarde, cette copie vous aidera.
3) Comparez avec un état “connu”. Une sauvegarde récente ou un déploiement maîtrisé est votre repère. Si vous avez des checksums sur des fichiers clés, c’est encore mieux.
4) Ne supprimez pas tout d’un coup. Supprimer des morceaux peut casser des indices. Vous voulez comprendre d’abord, corriger ensuite.
Si vous travaillez en équipe, essayez d’avoir une personne “en garde” qui ne change rien pendant que l’autre enquête. Sur un incident réel, l’improvisation coûte cher.
Checklist des actions immédiates (à faire dans l’ordre)
Voici l’ordre que je recommande en situation réelle, quand le site montre des signes de compromission et que vous devez agir vite, sans perdre votre capacité de diagnostic.
- Mettre le site en maintenance (ou un blocage temporaire) pour limiter l’exposition, puis conserver les journaux du serveur si vous y avez accès. Sauvegarder fichiers et base de données tels quels, pour pouvoir revenir à l’état d’origine et analyser la persistance. Désactiver temporairement les plugins récemment installés, ou passer WordPress en mode “calme” si vous suspectez une injection via un composant spécifique. Vérifier les comptes WordPress: utilisateurs créés récemment, rôles anormaux, changements sur l’identifiant de l’admin, et supprimer uniquement ce qui est clairement identifié. Régénérer les identifiants et jetons de session après nettoyage, puis lancer une remise à plat depuis une base saine (sauvegarde connue) plutôt que “réparer au fil de l’eau”.
Cette liste ne remplace pas une analyse approfondie. Elle sert à garder le contrôle, et à éviter les erreurs classiques, comme supprimer des fichiers sans savoir d’où venait l’accès.
Où se cache la compromission dans WordPress
La question qui revient tout le temps, c’est “où regarder”. Le problème, c’est que les attaquants ne se contentent pas d’un seul endroit. Ils cherchent une zone accessible par écriture, ou une zone qui charge du code avant que vous ne le remarquiez.
Thème, fonctions et chargeurs précoces
Le thème, notamment les fichiers PHP du thème actif et des thèmes enfants, est une cible majeure. Une injection peut ressembler à un bout de code “inoffensif” au début, puis déclencher une action plus tard. Parfois, le code s’exécute seulement si une condition est vraie (heure précise, paramètre d’URL, présence d’un cookie).
Ce que je fais en premier dans ce cas, c’est rechercher les motifs typiques d’obfuscation et les fonctions de lecture exotiques (sans donner une liste exhaustive ici). L’objectif est de repérer du code qui n’a aucune raison d’exister dans un thème: création dynamique de fonctions, base64, mécanismes d’extraction de données, appels à des ressources externes, ou accès à des fichiers sans logique métier.
Plugins, mais surtout les plugins “abandonnés” ou modifiés
Un plugin peut être compromis sans être mauvais au départ. Certains attaquants ciblent une faille dans une version spécifique, puis ajoutent une charge persistante. D’autres modifient directement le plugin pour qu’il serve d’intermédiaire.
Une pratique utile consiste à comparer la version installée avec celle que vous aviez au moment où le site était sain. Si un plugin a été mis à jour sans votre intervention, ou si sa date de modification ne colle pas, c’est un drapeau rouge.
La base de données: persistance silencieuse
WordPress stocke énormément d’éléments en base. Une injection peut se retrouver dans des champs d’options, des contenus de pages, des menus, ou dans des tables liées aux formulaires. La base peut aussi contenir des scripts ou des redirections encodées, parfois sous forme de “texte” qui se révèle au moment du rendu.
Si votre site a été modifié de manière visible, la base semble souvent le coupable principal. Si le site paraît “presque normal” mais comporte une redirection à certains moments, la base peut être un vecteur moins évident.
Les erreurs à éviter pendant la remise en état
Le nettoyage d’un site compromis, c’est aussi du design de risques. Une mauvaise décision peut transformer une infection localisée en incident plus large.
Voici les pièges les plus fréquents.
Restauration sans diagnostic
Repartir d’une sauvegarde “ancienne” peut masquer le problème, mais si vous restaurez trop tardivement après le déploiement de la persistance, vous pouvez remettre la charge en place. L’autre risque, c’est que la sauvegarde contienne déjà les modifications malicieuses, surtout si elle a été prise après que l’accès ait été établi.
Dans la pratique, je préfère analyser d’abord rapidement, puis restaurer. Si vous n’avez pas le temps, la restauration immédiate depuis la dernière sauvegarde connue saine est souvent acceptable, mais il faut ensuite reprendre la vérification pour s’assurer que la persistance ne revient pas.
Mettre à jour “tout” pendant que l’infection est active
Mettre à jour WordPress et les plugins peut corriger une faille, mais si votre site est compromis, la mise à jour peut aussi écraser des fichiers qui vous servent d’indice. Elle peut aussi laisser la charge active dans un endroit non touché.
Le compromis doit être traité avant de “normaliser” complètement l’empilement logiciel.
Changer les mots de passe trop tôt
Si vous pensez avoir un accès compromis via le mot de passe, changer le mot de passe du compte admin peut sembler logique. Mais si des sessions sont déjà en place, l’attaquant peut garder un accès via des cookies, des sessions persistantes, ou des mécanismes côté serveur.
Le bon moment pour changer les secrets, c’est après avoir isolé, supprimé la persistance, et idéalement régénéré les sessions. Sinon, vous risquez de voir les modifications revenir.
Une méthode de vérification pragmatique après nettoyage
Une fois le site “remis en état”, il faut vérifier. Pas au sens “regarder si la page d’accueil s’affiche”. Je parle d’une vérification orientée preuves.
Vérifier l’intégrité des fichiers
Sur WordPress, une partie du travail consiste à s’assurer que les fichiers noyau sont cohérents, et que seuls les thèmes et plugins que vous attendez sont présents. Dans une approche rigoureuse, on remplace les fichiers WordPress core par une copie officielle, puis on réinstalle les plugins de manière contrôlée.
Le point délicat, c’est la personnalisation. Si vous avez des modifications dans le thème, vous devez distinguer ce qui est attendu de ce qui ne l’est pas.
Dans une intervention récente, le site paraissait sain après suppression d’un plugin malveillant. Le problème est revenu deux jours après, car la persistance était dans un thème enfant modifié. Le diagnostic avait été trop “plugin centré”. Depuis, je vérifie systématiquement les zones de chargement du thème, et pas seulement les plugins.
Vérifier les utilisateurs WordPress
Après nettoyage, je fais une revue des utilisateurs et des rôles, puis je vérifie les dates de création et les derniers accès quand l’outil le permet. Un compte “inutile” reste souvent dans l’ombre.
Si vous utilisez un plugin de sécurité ou un journal d’activité, prenez le temps de lire un échantillon d’événements, surtout autour des heures où vous avez détecté l’anomalie.
Vérifier la base de données de manière ciblée
Sans faire une chirurgie totale, vous pouvez chercher des incohérences évidentes: contenus ajoutés, redirections, options modifiées, comptes liés à des formulaires, ou champs qui contiennent des fragments de code.
Ce travail est plus facile quand vous avez des repères de ce qui est normal pour votre site: quelles pages existent, quel contenu éditorial est typique, quelles tables doivent avoir une taille stable. Sans cela, la base devient un puzzle immense.
Sécuriser site WordPress après un incident, sans transformer votre site en forteresse impraticable
Le nettoyage stoppe l’urgence, mais la sécurité se joue après, dans les réglages et les habitudes. Et il y a des compromis. Un verrouillage trop agressif peut bloquer des robots utiles, ou casser l’expérience admin. Un laxisme total remet le risque à zéro seulement sur le moment du nettoyage.
Mesures “rentables” en priorité
Je privilégie des mesures simples, robustes, qui réduisent fortement la surface d’attaque sans compliquer le quotidien.
1) Mettre à jour le noyau WordPress, les thèmes et les plugins, mais de façon ordonnée, en commençant par ce qui est le plus exposé. 2) Réduire les droits d’écriture et vérifier les permissions de fichiers, surtout si votre hébergement les a modifiées. 3) Activer un mécanisme de protection contre la force brute, et limiter les tentatives de connexion. 4) Mettre en place une authentification forte pour l’accès admin quand c’est possible (au minimum pour les comptes à privilèges). 5) Surveiller les journaux d’accès et les erreurs PHP, au moins sur une période post-incident.
Ces actions ne sont pas “magiques”. Elles changent juste les conditions dans lesquelles l’attaquant peut agir.
Comment détecter plus tôt la prochaine fois
Une compromission se détecte mieux quand vous surveillez des signaux cohérents et que vous réagissez vite. Le but n’est pas d’installer dix outils. C’est d’avoir quelques alertes qui ont du sens et de vérifier la logique métier.
Trois signaux faciles à suivre
- Variation brutale du trafic sur des pages spécifiques, surtout si elles n’ont rien à voir avec votre contenu. Augmentation de requêtes HTTP avec erreurs 404, 500, ou chemins inhabituels, corrélée à des pics de CPU ou à des erreurs PHP. Changements dans l’écosystème WordPress, tels que nouvelles extensions, mise à jour inattendue, ou modification de fichiers.
L’intérêt, c’est la corrélation. Un seul signal isolé peut être un bug, une mise à jour, ou un événement marketing. Deux ou trois signaux en tandem, c’est souvent le début d’une preuve.
Mise en situation: une détection “presque normale”
Je repense à un cas typique, un site WordPress vitrine, pas un blog agressif. Un matin, les métriques annoncent un trafic stable. Rien d’alarmant. Pourtant, l’outil d’inspection du navigateur montre une redirection vers une page externe seulement sur mobile, seulement quand l’URL contient certains paramètres.
En observant les logs, on voit une poignée d’IP, pas énorme, qui sollicite des endpoints sans lien avec l’activité normale. L’équipe a d’abord regardé les plugins car c’est leur réflexe. Mais le code injecté se trouvait dans un fichier de thème enfant, chargé à chaque rendu, et la redirection n’était déclenchée que sur des conditions spécifiques. Tant que vous ne reproduisez pas la condition exacte, https://gardewp.fr/securite-wordpress/ vous pouvez passer à côté.
Leçons concrètes: collecter les logs dès le départ, et inspecter les zones de rendu, pas seulement l’administration. Après correction, on a renforcé les permissions et on a restauré proprement le thème en gardant uniquement les modifications attendues.
Questions à vous poser tout de suite
Si vous êtes en train de suspecter une compromission, vous allez gagner du temps avec quelques questions simples. Elles cadrent l’enquête, et elles évitent de vous disperser.
Signaux récents
Qu’est-ce qui a changé dans les jours précédents, mise à jour de plugin, ajout de thème enfant, modification de configuration, intervention d’un prestataire, accès d’un nouvel utilisateur?
Nature du symptôme
Est-ce que le problème touche les visiteurs, seulement l’admin, ou seulement un sous-ensemble d’URLs? L’attaque est parfois “conditionnelle”, donc la portée du symptôme aide.
Persistance probable
Avez-vous des logs qui montrent une activité avant vos premiers symptômes? Si oui, l’attaque peut déjà être installée depuis un moment.
Quand faire appel à un spécialiste
Vous pouvez gérer certains incidents seul, surtout si la modification est localisée et que vous avez des sauvegardes propres. Mais il y a des situations où il vaut mieux mobiliser un spécialiste sans attendre, par exemple:
- si vous n’avez plus de sauvegarde fiable, si la compromission implique des mécanismes côté serveur hors WordPress (webshell au niveau PHP, modification d’une configuration proxy, accès système), si votre environnement est complexe (multisite, intégrations, hébergement avec restrictions), si la compromission semble évoluer malgré vos premières actions.
J’insiste sur un point: faire analyser un incident peut être moins coûteux que reconstruire à l’aveugle, surtout si votre site a une valeur commerciale.
Une stratégie de reprise propre, sur le long terme
Après un incident, le plus dur est souvent de repartir sur quelque chose de stable. Je recommande une démarche de reprise qui privilégie la propreté plutôt que la réparation cosmétique.
Concrètement, l’approche la plus sûre consiste à repartir d’un état sain, reconstruire l’écosystème avec des versions maîtrisées, puis remettre en place vos personnalisations de manière contrôlée. Ensuite, vous ajustez la sécurité, et vous mettez un monitoring minimal pour capter les prochains signaux.
Le vrai gain, c’est la discipline. Vous n’éliminez jamais le risque à 0, mais vous limitez fortement la probabilité d’une compromission et surtout sa capacité à rester invisible.
Si vous retenez une seule idée, gardez celle-ci: détecter un site compromis, ce n’est pas “trouver un plugin bizarre”. C’est comprendre comment l’attaquant a obtenu et conservé l’accès, puis fermer le chemin sans laisser de porte secrète derrière la correction.
Et quand vous faites cette remise en état avec sérieux, vous sécurisez site WordPress pour de bon, pas seulement pour une journée.