Quand un scanner malware WordPress remonte une alerte, on a souvent envie d’appuyer tout de suite sur “réparer” ou de lancer une suppression automatique. Le problème, c’est que les infections WordPress ne se résument pas à un fichier malveillant isolé. Elles s’installent aussi via des accès, des droits trop permissifs, des comptes administrateurs créés discrètement, ou des identifiants laissés en clair dans des endroits improbables.
Dans les incidents que j’ai vus sur le terrain, l’erreur la plus coûteuse consiste à nettoyer le code, puis à oublier l’accès. Quelques jours plus tard, le site “recontamine” parce que quelqu’un (ou quelque chose) a gardé une porte ouverte: un compte admin supplémentaire, un plugin avec des capacités excessives, ou une configuration de rôles qui permet à un compte éditorial d’installer des webshells. Voilà pourquoi, après un scan malware, vérifier les permissions et les utilisateurs administrateurs n’est pas une étape optionnelle, c’est le cœur de la remédiation.
Pourquoi les permissions et les admins comptent plus qu’on ne le croit
WordPress repose sur un modèle de rôles. Administrateur, éditeur, auteur, contributeur, abonné. En théorie, chacun a des capacités limitées. En pratique, une infection cherche souvent à transformer ce modèle en faiblesse.
Un malware peut, par exemple, créer un utilisateur administrateur avec un nom banal, puis l’activer en tâche de fond. Il peut aussi profiter d’un rôle trop large, ou d’une installation où les droits de fichiers et de dossiers sont devenus “libres”, ce qui permet à du code injecté de s’exécuter ou de persister.
Il y a aussi une réalité opérationnelle: les scanners malware ne peuvent pas toujours confirmer ce qui s’exécute réellement sur votre serveur, surtout si l’infection déclenche des charges seulement dans certains contextes (chargement de pages précises, requêtes par méthode POST, chaînes de paramètres spécifiques). En vérifiant les permissions et les comptes, vous couvrez l’angle mort le plus fréquent: l’accès.
La première passe après l’alerte: verrouiller avant d’enquêter
Avant de modifier des choses, j’applique une règle simple: ralentir la propagation. Si le site est compromis, il peut encore recevoir des requêtes malveillantes, et si vous remplacez des fichiers au milieu, vous pouvez casser l’accès légitime ou, pire, donner au malware une fenêtre pour réécrire.
Concrètement, vous pouvez mettre le site en mode maintenance ou le basculer derrière une protection d’accès le temps de l’audit. L’objectif n’est pas de “tout figer” indéfiniment, mais de réduire les changements dynamiques pendant que vous examinez la couche utilisateurs et droits.
Ensuite, je travaille en deux circuits. D’un côté, je vérifie les utilisateurs et les rôles WordPress. De l’autre, je contrôle les permissions côté système de fichiers et la configuration des plugins, thèmes et outils d’administration.
Vérifier les utilisateurs administrateurs: la partie la plus révélatrice
Le test le plus rentable après un scanner malware, c’est la liste des comptes ayant le rôle administrateur. Les injections réussissent souvent parce que quelqu’un a pu créer ou conserver un accès “high privilege”.
Commencez par inspecter l’écran utilisateurs dans l’administration WordPress. Filtrez l’affichage sur les rôles administrateur, et regardez les détails: date d’inscription, nom d’affichage, identifiant, et surtout cohérence avec votre gestion interne.
Une infection crée parfois un compte avec un libellé peu significatif, sans gravité apparente. Parfois, elle utilise un identifiant qui ressemble à un prestataire ou à un ancien membre d’équipe. La cohérence compte plus que la “bizarrerie”.
Si le site est géré par une équipe, demandez-vous: qui aurait eu la capacité, ce jour-là, de créer un nouvel administrateur ou d’élever un rôle ? Si vous n’avez pas d’événement interne correspondant (onboarding, migration, intervention technique), considérez le compte comme suspect.
Les signaux classiques sur un compte administrateur compromis
Sans tomber dans la paranoïa, voici ce que j’observe le plus souvent dans les cas concrets:
Un compte administrateur créé juste après un pic d’alertes ou juste après une mise à jour. Un identifiant qui n’a rien à voir avec votre organisation. Un compte qui ne correspond à aucun utilisateur interne. Un compte qui a peut-être été utilisé une seule fois, puis laissé en place.
Le vrai indicateur, c’est parfois l’historique d’activité, si vous avez un plugin ou un journal fiable. Sinon, la date d’inscription et la cohérence des opérations suffisent souvent pour décider quoi faire ensuite.
Contrôler la “capacité” des comptes, pas seulement leur intitulé
WordPress affiche un rôle, mais ce que le compte peut réellement faire dépend des capacités enregistrées. Par exemple, un plugin peut étendre les droits d’un rôle, ou un compte peut obtenir des capacités via des modifications de base de données.
Le piège typique: un scanner signale une incohérence sur un plugin ou un fichier, mais les comptes affichés semblent “normaux”. Dans ce scénario, le malware n’a peut-être pas créé un nouvel admin, il a peut-être modifié les permissions d’un rôle existant ou ajouté des capacités dans les tables de WordPress.
Je recommande de vérifier deux choses:
- Que seuls les comptes attendus ont le rôle administrateur. Que les plugins et thèmes installés n’accordent pas de capacités anormales à des rôles non administrateurs.
Selon votre setup, vous pouvez aussi consulter les journaux d’événements WordPress ou serveur. Les journaux serveur (accès PHP, tentatives de connexion) sont très utiles, surtout si le scanner a identifié des fichiers manipulés.
Une checklist courte pour repérer les comptes suspects
Je préfère une courte liste, parce qu’en incident on perd vite du temps à “tout relire”. Voilà une checklist pratique, limitée pour rester actionnable:
- comptes administrateur créés récemment, sans raison interne claire identifiants qui ressemblent à des noms d’outils ou de prestataires non connus comptes dont l’activité ne correspond à aucun utilisateur humain de l’équipe présence d’administrateurs multiples alors que votre modèle habituel est plus simple incohérence entre la date d’inscription et la fenêtre d’incident remontée par le scan
Si vous cochez plusieurs cases, ne vous contentez pas de “supprimer un fichier”. Commencez par traiter l’accès.
Désactiver, supprimer, ou juste geler ? Le bon jugement
Supprimer un compte administrateur semble simple, mais il y a un piège: si votre site dépend d’un compte de service (par exemple, une intégration, un export, ou une synchronisation), la suppression peut casser des mécanismes légitimes. Et si vous n’êtes pas certain que le compte est malveillant, vous pouvez préférer un gel temporaire.
Je fonctionne comme suit. Si vous avez une identité claire, vous pouvez supprimer. Si vous avez un doute, vous pouvez d’abord changer le mot de passe, forcer une nouvelle authentification, et vérifier l’absence d’activité inhabituelle. Dans certains cas, je désactive temporairement l’accès au site pour empêcher toute utilisation pendant que je valide.
Le critère qui tranche, c’est la “preuve opérationnelle”. Un compte administrateur créé dans une période suspecte, combiné à des signatures malveillantes sur d’autres composants, justifie généralement une suppression ou au minimum une invalidation rapide.
Attention aux plugins “helpers” qui détournent l’accès
Un malware n’existe pas toujours en mode “fichier magique”. Il peut se cacher dans un plugin ou un thème, ou utiliser un plugin légitime pour appeler du code à des moments précis.
Après un scan malware WordPress, inspectez les plugins installés et ceux récemment ajoutés ou mis à jour. Les scanners remontent souvent un nom de fichier ou un chemin, mais pas toujours le mécanisme de persistance.
Voici l’endroit où les permissions redeviennent critiques. Un plugin peut ajouter des rôles, modifier les capacités, ou exposer des endpoints. Un scanner peut signaler un fichier suspect, mais votre action doit aussi inclure une revue des permissions que ce code a la capacité d’exploiter.
Ce que je cherche côté plugins
Je regarde les éléments suivants, sans en faire un roman:
Plugins installés en double, par exemple un plugin “de sécurité” copié ou un plugin dont le dossier ne correspond pas à votre liste habituelle. Plugins installés sans trace de procédure interne. Plugins liés à des campagnes SEO, des “shortcodes” exotiques, ou des outils “coupon” quand vous n’en avez pas l’usage.
Si le scanner indique qu’un fichier a été modifié, je considère aussi la possibilité que le plugin soit un vecteur, même si le fichier signalé n’est pas un webshell évident.
Vérifier les permissions de fichiers et dossiers: l’accès technique
Une infection peut persister grâce à des permissions de fichiers trop ouvertes. Sur un hébergement classique, l’erreur la plus fréquente est de donner trop de droits à certains répertoires. Par exemple, des écritures autorisées pour des dossiers qui ne devraient recevoir que du lecture, ou des permissions “monde écrivain” sur des chemins critiques.
Je ne vais pas vous donner une valeur unique pour toutes les plateformes, parce que les environnements diffèrent, mais le principe reste le même: WordPress doit pouvoir lire ses fichiers, écrire dans les zones attendues (uploads, cache si vous en utilisez), mais un attaquant ne doit pas pouvoir déposer ou modifier du code dans des zones qui contiennent la logique applicative ou des fichiers système.
Dans un incident que j’ai traité, le scanner avait identifié plusieurs fichiers “modifiés”, mais la vraie cause a été une étape de déploiement qui avait laissé des permissions trop larges sur le répertoire du thème actif. Le nettoyage avait supprimé le code visible, mais le serveur réécrivait à chaque requête, parce que le malware avait conservé l’accès d’écriture. La correction a consisté à resserrer les droits et à réappliquer une version saine des composants concernés.
Comment approcher la vérification sans faire plus de dégâts
Le piège, quand on corrige les permissions, c’est de casser l’écriture nécessaire ou de modifier des chemins que le serveur attend. Donc:
- Commencez par comparer avec un état “connu” si vous avez une sauvegarde ou un déploiement récent correct. Appliquez des changements progressifs, en priorisant les dossiers où l’écriture est attendue (uploads). Vérifiez après correction en contrôlant le site et les opérations d’administration.
Si vous êtes sur un environnement géré (hébergement mutualisé, panneau de contrôle), utilisez les mécanismes fournis plutôt que de jouer au hasard avec des commandes. Un mauvais ajustement peut générer des erreurs 500 ou empêcher WordPress de mettre à jour.
La base de données compte aussi, même si le scan semble “fichier”
Le scan malware WordPress peut vous donner des chemins, mais si l’infection a modifié la base de données, vous pouvez voir un symptôme sans comprendre la cause. Un compte administrateur créé persiste via les tables d’utilisateurs, mais aussi via des associations de rôles et de capacités.
Si vous avez un doute sérieux, l’idéal est de consulter les éléments de base de données liés aux utilisateurs et aux métadonnées d’authentification. Sans inventer de procédures universelles, l’idée reste: valider que la liste des admins WordPress correspond à votre compréhension, et que les capacités ne semblent pas “gonflées” par des ajouts inattendus.
Cette étape demande du soin, parce que des plugins peuvent aussi modifier des capacités de manière légitime. Ici, le jugement repose sur le contexte: quels plugins vous utilisez vraiment, quels sont ceux apparus juste avant l’incident, et quels changements datent de la même période.
Deux étapes qui font gagner du temps lors de la remédiation
Quand je prépare une remédiation, je vise deux résultats: réduire le risque immédiat et augmenter la certitude. Voilà un enchaînement court qui limite les allers-retours.
D’abord, mettez en sécurité l’accès: changez les mots de passe des comptes administrateurs légitimes, puis traitez les comptes suspects. Même si vous supprimez un compte, si le mot de passe a été compromis, le compte légitime doit être régénéré.
Ensuite, resserrez ce qui a rendu l’attaque facile. Les permissions trop permissives, les plugins non nécessaires, et la capacité d’installer des éléments non vérifiés sans contrôles sont des accélérateurs. Le malware aime les environnements “souples”.
A quoi ressemble une bonne vérification après nettoyage
Le vrai test se voit souvent dans les détails:
Le nombre d’admin correspond à votre modèle normal. Les comptes récemment créés ont été traités. Les plugins et thèmes présents correspondent à votre liste attendue, et ceux suspects sont désactivés ou remplacés. Les permissions côté serveur ne permettent plus l’écriture là où elle ne devrait pas exister. Et surtout, de nouvelles alertes ne réapparaissent pas après quelques heures ou après une navigation normale sur le site.
Le délai compte. Une infection peut déclencher une charge seulement sur certains parcours, ou uniquement sur une fréquence. Donc, je n’évalue pas tout à chaud.
Cas fréquents: “le scan dit un fichier, mais l’accès était le problème”
Je repense à un cas où le scanner malware WordPress signalait un fichier dans le répertoire uploads et mentionnait une signature de code. L’équipe avait nettoyé le fichier, puis tout semblait aller. Le scan n’a pas “tout” vu, ou plutôt il n’a pas relié la persistance à la cause.
Quelques jours plus tard, un nouvel admin était apparu. Les logs d’accès montrent des tentatives de connexion depuis des plages IP associées à des automatisations. Et surtout, les permissions sur une zone temporaire du serveur permettaient l’écriture inattendue, ce qui transformait une simple tentative en persistance. La correction finale a été un mélange: suppression du compte rogue, resserrage permissions, suppression ou remplacement de composants et durcissement d’accès.
Cette histoire illustre une règle que je répète sur les audits: quand le scanner remonte quelque chose, traitez d’abord la persistance potentielle, donc l’accès et les droits, puis seulement après le code.
Mettre en place une hygiène “admins” qui évite le prochain incident
Une fois le site stabilisé, il reste une question: comment empêcher la même forme d’incident de se reproduire, même si le vecteur initial change.
Sans entrer dans une liste exhaustive (je préfère rester concret), je recommande de réduire la surface d’administration. Limitez le nombre de comptes administrateurs aux personnes qui en ont réellement besoin. Utilisez une gestion d’identifiants sérieuse, des mots de passe uniques, et idéalement un deuxième facteur si votre environnement le permet.
Ensuite, pensez au cycle de vie des plugins et thèmes. Supprimer ce qui n’est pas utilisé réduit les possibilités d’abus. Et si vous utilisez des plugins d’administration ou d’optimisation, gardez ceux qui sont maintenus et cohérents avec votre besoin.
Enfin, surveillez. Si vous avez un système de logs, vous pouvez détecter l’apparition d’un nouvel administrateur ou une modification d’un fichier anormal. Les alertes “fichier modifié” sont bien, mais les alertes “nouvel utilisateur admin” sont souvent encore plus rapides pour empêcher une persistance.
Une petite vérification de fin de travail
Avant de rouvrir le site en mode normal, je fais une dernière passe. Elle est courte, mais elle évite les retours arriérés.
- contrôle de la liste des admins et des dates d’inscription vérification que les plugins récemment ajoutés sont traités resserrage des permissions là où l’écriture n’est pas requise confirmation que le scan ne remonte plus d’alertes après navigation
Cette étape n’assure pas une sécurité absolue, mais elle réduit fortement la probabilité d’être “nettoyé” sur le papier uniquement.
Les pièges qui font perdre des heures (ou pire, aggravent)
Je termine avec les erreurs les plus fréquentes, celles qui reviennent dans beaucoup de missions.
Première erreur: supprimer un fichier sans vérifier l’accès. Si le malware a conservé un compte administrateur, il réécrira ailleurs.
Deuxième erreur: supprimer un compte légitime par “suspicion”. Si vous ne savez pas qui gère le site, prenez deux minutes pour confirmer, ou geliez au lieu de supprimer, puis validez.
Troisième erreur: corriger les permissions au hasard. Un réglage mal ciblé peut casser les uploads, les mises à jour, ou des dépendances du thème. Une https://gardewp.fr/nettoyage-malware-wordpress/ correction progressive et basée sur votre réalité d’hébergement vaut mieux qu’une recette générique.
Quatrième erreur: considérer qu’un scan suffit. Les scanners sont utiles, mais ils ne remplacent pas l’analyse des utilisateurs et des droits.
Quand demander de l’aide, et quoi préparer
Si l’alerte est sévère, si vous ne contrôlez pas l’hébergement, ou si vous voyez une multiplication rapide des changements (nouveaux admins, nouveaux fichiers modifiés), il est souvent plus efficace de solliciter une aide spécialisée. Dans ce cas, préparez un dossier simple: liste des administrateurs, date d’apparition suspecte, logs d’accès si vous les avez, et résultats du scan malware WordPress avec les chemins cités.
Ce que vous apportez ainsi permet de gagner du temps, et de passer directement de la théorie à la correction.
Une règle de terrain pour finir
Après un scanner malware WordPress, j’adopte une logique directe: traiter l’accès d’abord, parce que c’est lui qui permet à l’infection de revenir. Vérifier les permissions, contrôler les utilisateurs administrateurs, resserrer ce qui permet l’écriture non nécessaire, puis seulement ensuite revenir au nettoyage du code.
C’est souvent moins spectaculaire qu’un “remplacement de fichiers”, mais c’est ce qui tient dans le temps.