Après un piratage, on a vite fait de se focaliser sur la “désinfection WordPress” au sens strict, supprimer des fichiers, nettoyer des injections, réinstaller des thèmes et des extensions. C’est nécessaire, mais ce n’est pas suffisant. Le vrai risque de rechute vient souvent d’un détail plus discret : des rôles et des permissions modifiés, des comptes créés en douce, des droits trop larges attribués à quelqu’un qui n’a plus rien à faire là.
J’ai vu des sites “propres” après nettoyage complet, puis recommencer à distribuer des pages d’attaque deux ou trois jours plus tard. La cause n’était pas un nouveau malware téléchargé depuis l’extérieur. C’était un utilisateur persistant, avec un rôle trop puissant, encore capable d’ajouter des fichiers ou de modifier des paramètres. Une fois qu’on comprend ce mécanisme, la désinfection devient aussi une opération de remise à zéro des accès.
Pourquoi les rôles et permissions sont un point de rupture
Dans WordPress, le modèle de rôles est pratique, mais il est aussi facilement détournable. Un attaquant n’a pas besoin de “pirater” toute votre infrastructure. Il lui suffit, pendant la fenêtre d’accès, de :
- créer un compte avec un rôle élevé, changer le rôle d’un compte existant, modifier des réglages d’administration, ouvrir une passerelle vers d’autres fonctionnalités (édition de fichiers, création de scripts, installation d’extensions).
Même si vous supprimez les fichiers malveillants dans /wp-content/, l’accès reste. Le site peut rebasculer en mode compromis, parce que la personne derrière le piratage a laissé une clé dans la serrure.
À ce stade, j’aime poser une question simple à l’équipe ou au client : “Qu’est-ce qui, aujourd’hui, pourrait permettre à quelqu’un de refaire la même chose, sans repasser par un exploit ?” Les rôles et permissions répondent directement.
Ce que l’attaquant cherche à obtenir côté WordPress
Les méthodes varient selon les campagnes, mais le schéma revient souvent. Pendant que le site est vulnérable, l’attaquant stabilise l’accès. La stabilisation passe rarement par une seule action visible. Elle ressemble plutôt à une “mise en place” progressive :
Un premier signe typique est l’apparition d’un nouvel utilisateur. Parfois l’adresse email est réaliste, parfois elle est bricolée. Le nom d’affichage peut ressembler à un membre d’équipe. Si le rôle est “Administrateur”, c’est un drapeau rouge immédiat.
Autre cas fréquent : un compte existant, que vous pensiez maîtrisé, a vu ses capacités augmenter. Je pense notamment aux cas où un rôle “Éditeur” a été reconfiguré, ou où une capacité a été ajoutée via un plugin, un code de plugin, ou un snippet injecté dans un fichier “propre” mais au moment du piratage modifié.
Enfin, il y a la piste des paramètres. Certains pirates ne restent pas dans l’interface d’administration. Ils profitent de la configuration, de la gestion des fichiers, ou de fonctions liées aux rôles pour réinjecter du contenu au fil de l’eau.
Le point clé : votre nettoyage de fichiers ne couvre pas forcément les “mécanismes d’accès” qui, eux, peuvent survivre.
Commencer par cadrer : qui a accès, et depuis quand
Avant de modifier quoi que ce soit, prenez une photo de l’existant. Pas une capture d’écran au hasard, une trace exploitable.
Dans WordPress, vous avez déjà des données utiles. La liste des utilisateurs vous dit qui a accès. Les rôles vous donnent une première lecture. Mais dans un contexte post-piratage, je recommande aussi de regarder la surface d’attaque plus large :
- Les comptes créés récemment. Les tentatives de connexion suspectes (même si elles ne prouvent pas l’attaque en soi). L’existence de comptes “internes” qui n’ont pas de raison d’être (compte admin, compte lié à un service, ou compte sans activité).
Selon vos outils de logs, vous pouvez croiser l’horodatage de création avec des événements serveur, ou des alertes WAF. Si vous ne disposez pas de logs fiables, ce n’est pas bloquant, mais votre décision doit être plus prudente : vous allez privilégier la réduction des accès et la suppression des comptes douteux, plutôt que de “faire confiance” à des indices faibles.
Inspecter les utilisateurs : le tri qui évite les erreurs
La première étape pratique consiste à faire l’inventaire des utilisateurs WordPress et à repérer les écarts. Le piège, c’est de vouloir trancher trop vite uniquement sur le nom. Un attaquant peut choisir un nom plausible.
Ce que vous cherchez, c’est l’ensemble des signaux. Les signaux les plus utiles sont le rôle, la date de création, l’existence d’activités, et la cohérence avec votre organisation.
Dans les contextes où j’ai travaillé, la meilleure approche est la séparation mentale entre “compte nécessaire” et “compte potentiellement persistant”. Les comptes nécessaires sont ceux que votre organisation utilise réellement. Les autres deviennent candidats à la suppression ou à la neutralisation, surtout si leur rôle est élevé.
Les rôles élevés sont à considérer comme compromettables
Après piratage, je traite tous les comptes disposant de rôles d’administration comme “à risque”, au moins temporairement. Même si le compte ne semble pas suspect aujourd’hui, son accès a peut-être été utilisé durant la fenêtre d’attaque.
Cela ne veut pas dire “supprimer tout le monde”. Cela veut dire : appliquer un principe de réduction de surface d’attaque. Si vous avez deux administrateurs légitimes, limitez-vous à eux et retirez les autres, surtout s’ils ont un rôle trop puissant.
Détecter les comptes créés en douce, ou les rôles modifiés
WordPress ne fournit pas toujours, en interface, un historique complet des changements de rôles. Mais vous pouvez avancer avec une démarche réaliste.
Observez les utilisateurs :
- utilisateurs créés récemment, utilisateurs dont le profil ne correspond pas à vos pratiques, utilisateurs sans justification.
Ensuite, vérifiez la cohérence des rôles. Un compte avec un rôle “administrateur” doit être justifié. Un compte “éditeur” peut être légitime si votre équipe publie réellement des contenus, mais il doit rester limité. Les rôles “auteur” et “contributeur” devraient être rares côté administration, sauf workflows de publication.
Si vous utilisez un plugin de gestion des droits ou un système SSO, il faut aussi considérer que l’attaquant a pu détourner l’authentification. Dans ce cas, la désinfection ne se limite pas à WordPress, mais à ce que WordPress croit être la “source de vérité”.
Étape de réduction des accès : supprimer, neutraliser, ou forcer une réinitialisation
Une fois l’inventaire fait, vous devez décider. Votre objectif n’est pas seulement d’enlever le contenu malveillant, c’est de rendre impossible la réinfection via des droits persistants.
Dans les incidents que j’ai vus, les meilleures décisions sont souvent celles qui semblent trop strictes au début. Il vaut mieux perdre un compte non essentiel que garder un accès admin douteux.
Voici la logique opérationnelle que j’applique, avec des choix gradués :
1) supprimer les comptes manifestement non légitimes et tous ceux dont vous ne pouvez pas justifier l’existence, 2) pour les comptes légitimes, réinitialiser les mots de passe et forcer une revue des pratiques d’accès, 3) pour les comptes “zone grise”, retirer immédiatement les capacités les plus sensibles.
Concrètement, dans WordPress, cela implique de modifier des rôles, de supprimer des comptes, et de revenir à une configuration minimaliste.
Checklist actionnable (rôles et comptes)
- Listez tous les utilisateurs et triez par date de création. Retirez tout rôle “administrateur” qui n’est pas strictement indispensable. Supprimez les comptes que vous ne reconnaissez pas ou dont le rôle est anormal. Réinitialisez les mots de passe des comptes légitimes restants (et utilisez des mots de passe uniques). Vérifiez que seuls les comptes nécessaires peuvent modifier les thèmes et plugins.
Cette liste ressemble à une évidence, mais dans les faits, c’est là que beaucoup d’équipes hésitent. “On verra plus tard” devient un facteur de rechute.
La question la plus délicate : quel rôle donner aux “restants” ?
Après nettoyage, on peut être tenté de restaurer l’ancien état. C’est une erreur fréquente. Si un pirate a réussi à modifier des droits, vous n’avez aucune garantie que l’ancien état était sain. En post-incident, je privilégie un modèle de “moindre privilège” qui respecte le workflow réel.
Un bon repère : un utilisateur devrait avoir le rôle minimal qui lui permet d’effectuer son travail sans marge. Par exemple :
- Un rédacteur doit pouvoir gérer ses brouillons et ses publications, mais pas installer des extensions. Un administrateur technique ne devrait pas être l’unique compte, sauf contraintes organisationnelles, mais ses droits doivent rester strictement nécessaires. Une personne qui valide uniquement des contenus doit rester en mode approbation, pas en mode modification des fichiers.
Si vous avez une équipe petite, vous pouvez limiter les rôles à un noyau. Ça ralentit peut-être un peu la publication, mais ça réduit considérablement les dégâts en cas de nouvelle compromission d’un compte.
Faire attention aux plugins qui changent la sécurité “par procuration”
Le nettoyage des droits ne concerne pas uniquement l’onglet Utilisateurs. Certains plugins influencent les permissions ou la sécurité de manière indirecte. Après un piratage, j’ai déjà vu des cas où la présence d’un plugin “cachait” des capacités ou ajoutait des rôles via des réglages.
Sans refaire un audit complet de tout le parc applicatif, il faut au minimum vérifier :
- quels plugins sont actifs, si un plugin récemment installé a été créé ou activé autour de la date du piratage, si des plugins de gestion des rôles existent (ou des plugins de sécurité qui manipulent des capacités).
La règle de prudence : après incident, vous pouvez temporairement désactiver des plugins non indispensables, puis réactiver seulement ce qui est nécessaire. Ça réduit l’espace où un attaquant peut “rejouer” la compromission.
Ce point est d’autant plus important que certains plugins de sécurité ou d’accès ajoutent des couches, et parfois des bugs ou des comportements inattendus en situation “sale”.
Les sessions, la persistance et le “retour” d’un attaquant
Il y a un autre aspect qui dépasse la gestion des rôles stricto sensu : l’état de session. Dans WordPress, un attaquant peut se connecter avant la fin du piratage et rester actif même si vous supprimez certains fichiers.
Même si vous nettoyez et supprimez les comptes à risque, une session déjà établie peut garder un avantage si vous ne cassez pas l’accès.
Selon votre stack, les sessions peuvent être gérées côté WordPress, côté reverse proxy, ou via un plugin de sécurité. La bonne pratique consiste à invalider les sessions après nettoyage et après changement des mots de passe, surtout si vous avez identifié un compte compromis.
Je le dis souvent ainsi : un mot de passe changé est une mesure, mais invalider les sessions est une garantie plus immédiate.
Exemple concret : le “site propre” qui réinfecte parce qu’un admin restait
Je vous raconte un cas typique, même si les détails varient selon les clients. Un site avait été compromis. La désinfection avait été faite “proprement” : fichiers nettoyés, thèmes et plugins mis à jour, et réinstallation d’éléments. Tout semblait réglé.
Puis deux jours plus tard, le même type de pages d’attaque réapparaissait. Les logs indiquaient des modifications depuis l’interface d’administration, pas via une nouvelle infection entrante. En regardant côté utilisateurs, on a découvert un compte administrateur créé quelques jours avant la désinfection. Le compte n’avait pas été supprimé, car il semblait “peu suspect” à première vue.
Le rôle administrateur faisait la différence : même avec un site nettoyé, le pirate pouvait réinjecter le contenu en utilisant l’éditeur, ou via l’installation d’un plugin, ou en modifiant des fichiers par mécanisme prévu.
Une fois le compte supprimé, plus de réinjection. C’était mécanique. Le nettoyage avait retiré les symptômes, pas la cause d’accès.
Comment éviter d’être trop agressif, ou pas assez
La difficulté après piratage, c’est le curseur entre prudence et opérationnel.
Si vous supprimez trop de choses, vous perdez du temps, des contenus, ou vous créez un incident secondaire. Si vous êtes trop doux, vous laissez un accès qui permettra la rechute.
Pour calibrer, je recommande d’adopter cette méthode de décision :
- Si vous ne pouvez pas justifier un compte, vous le traitez comme indésirable. Si un compte a un rôle élevé, vous le traitez avec davantage de scepticisme qu’un compte à rôle faible. Si un compte légitime existe, vous le conservez mais vous durcissez (mots de passe uniques, invalidation de session, éventuellement mise en place de 2FA si votre organisation le permet).
Cette approche évite la paralysie. Elle n’exige pas la certitude absolue, elle exige la réduction du risque.
Durer dans le temps : durcissement des permissions après réinfection évitée
Nettoyer et réduire les rôles ne suffit pas, sinon vous vous retrouvez avec un “prochain incident” au même endroit. La phase suivante, c’est d’ancrer des pratiques.
Je vois trois axes qui fonctionnent bien :
Le premier, c’est la gouvernance des comptes. Moins de comptes admin, plus de rôles “raisonnables” pour les tâches du quotidien.
Le deuxième, c’est l’authentification renforcée. Si vous avez la capacité d’imposer une double authentification aux comptes sensibles, c’est un gain direct contre les compromissions par mot de passe réutilisé ou volé.
Le troisième, c’est la traçabilité. WordPress enregistre certaines actions, mais pas tout. L’idée n’est pas de construire un SI complet. C’est de conserver au moins un historique d’événements côté serveur et d’administrer des alertes simples.
Cela vous permet de repérer rapidement une nouvelle création de compte, un changement de rôle inattendu, ou une tentative de connexion suspecte.
Le cas des multisites, et des droits qui débordent
Si vous gérez un WordPress multisite, les rôles peuvent être encore plus piégeux, car les permissions s’articulent différemment selon les niveaux. Après un piratage, l’attaquant peut viser un site du réseau, puis profiter des droits pour agir plus largement.
Dans ces contextes, je traite les rôles au niveau réseau et au niveau site séparément. Si vous https://gardewp.fr/ ne vérifiez que les utilisateurs “du site principal”, vous pouvez rater une anomalie ailleurs. Le risque devient alors structurel : même si un site local est nettoyé, un autre reste un point d’entrée.
La règle pratique est simple : si vous avez un multisite, vous devez auditer les comptes et rôles sur l’ensemble du réseau, pas seulement là où vous avez vu le contenu attaqué.
Après l’effort : valider que WordPress n’a plus de portes ouvertes
Une fois la gestion des rôles remise à niveau, vous pouvez passer en phase de validation. Cette validation n’a pas besoin d’être compliquée, mais elle doit être systématique.
Vous voulez confirmer, notamment :
- que seuls des comptes maîtrisés disposent de droits élevés, qu’aucun nouvel utilisateur n’est apparu juste après vos changements, que les plugins suspects ne sont plus là, et que les comportements “bizarres” dans les pages d’administration ont cessé.
Si vous constatez une nouvelle création d’utilisateur après vos modifications, c’est un signal que la source d’accès persiste quelque part, soit dans un composant non nettoyé, soit via une autre couche d’accès hors de WordPress.
À ce moment, je reviens toujours au même principe : une rechute post-désinfection est souvent une question de droits et de persistance, pas uniquement de fichiers.
Petite méthode pour documenter ce que vous avez changé
Dans les incidents, la mémoire est un risque. Même avec des notes, on oublie des décisions. Or, la gestion des rôles, c’est précisément le genre de changement qu’on regrette quand il n’est pas documenté.
Je conseille de noter pendant l’intervention :
- quels comptes ont été supprimés, quels comptes restent admin (et pourquoi), quels mots de passe ont été changés, et quand les validations ont eu lieu.
Ce n’est pas un “luxe”. C’est ce qui permet de prouver, à vous-même et au client, que la désinfection WordPress n’a pas seulement retiré le contenu visible, mais a aussi fermé les accès à l’origine du problème.
Rester réaliste : WordPress est solide, mais les comptes restent le talon d’Achille
WordPress n’est pas fragile en soi. Le cœur est bien compris, la communauté est active, les correctifs existent. Pourtant, la plupart des compromissions qui reviennent sont liées à un facteur humain et à des droits.
Un mot de passe réutilisé, un compte admin conservé trop longtemps, un plugin oublié, un rôle donné “pour dépanner”, et tout bascule.
Gérer les rôles et permissions après piratage, c’est donc l’étape qui rend la désinfection durable. Vous ne cherchez pas la perfection, vous cherchez une version du système où l’attaquant, même en reprenant contact, se heurte à une barrière simple : moins de privilèges, plus de contrôle, et une surface d’accès qui ne pardonne pas.
Si vous deviez retenir une idée, ce serait celle-ci : le nettoyage des fichiers règle la partie “symptômes”, mais la gestion des rôles règle la partie “mécanisme”. C’est elle qui empêche la rechute.