On croit souvent qu’un site WordPress piraté, c’est d’abord des “bugs” visibles: une redirection bizarre, un malware téléchargeable, une page défigurée. Dans la pratique, le premier dégât utile à comprendre se situe presque toujours en amont, dans l’accès. Une fois qu’un attaquant a prise sur des identifiants, il ne se contente pas d’un mauvais commentaire de spam. Il cherche la persistance, et la persistance passe fréquemment par des tokens, des clés API, des secrets de services et des morceaux de configuration trop “oubliés” pour être surveillés.
La désinfection WordPress devient alors un travail de décontamination et de reprise de contrôle. Pas uniquement “nettoyer”, mais retirer les éléments qui continuent de donner un chemin à l’attaquant. Les tokens et clés compromis en sont le cœur. Et c’est là que beaucoup d’administrateurs perdent du temps: ils suppriment un fichier malveillant, changent un mot de passe, puis constatent que le site reste instable quelques jours plus tard. Rien “n’a l’air” revenu, pourtant les connexions continuent. Il manque souvent l’étape qui fait le vrai tri: invalider les secrets et recalibrer tous les accès dépendants.
Les tokens et clés, ce que ça signifie concrètement dans WordPress
Quand on parle de tokens et clés, on imagine parfois un seul élément: un token d’API. En réalité, sur WordPress, les secrets “vivants” peuvent se trouver à plusieurs endroits, avec des comportements différents.
Un token peut être un mécanisme d’authentification utilisé par un plugin, un thème, ou un service externe. Il peut s’agir d’une clé de service pour accéder à une API de paiement, de push notifications, de stockage de médias, de CDN, de statistiques, ou de sauvegardes automatisées. Il peut aussi être une chaîne utilisée pour déclencher une action à distance, comme un “webhook”, ou pour communiquer avec un outil d’optimisation.
Ce qui rend ces secrets dangereux, c’est leur nature de “passe express”. Contrairement à un mot de passe classique, un token peut fonctionner même si la page d’administration n’est plus accessible. Un attaquant peut continuer d’injecter du code via une intégration, ou modifier des paramètres sans repasser par une connexion utilisateur.
Dans des cas réels que j’ai vus en intervention, le signe a été très banal. Le site avait l’air propre juste après le nettoyage, puis une charge anormale apparaissait à nouveau sur certains endpoints. L’équipe sécurité avait changé les mots de passe, mais les clés d’un service d’automatisation étaient restées valides. Résultat, l’outil reprenait des tâches avec des droits trop larges et favorisait une réinfection.
Comment un attaquant récupère ces secrets
Il n’y a pas une seule route. Les vecteurs varient selon l’hygiène du site, la configuration serveur et les plugins en place. Mais on retrouve des schémas fréquents.
La voie la plus directe, ce sont les accès compromis. Un identifiant d’administrateur réutilisé, un mot de passe faible, ou une faille dans un plugin permet d’obtenir une session. Ensuite, l’attaquant parcourt les réglages WordPress, les options stockées, les variables dans des fichiers de configuration, et toute clé exposée dans des pages d’administration.
Une autre voie passe par la lecture de fichiers. Si un plugin est vulnérable à l’inclusion de fichiers, ou si un espace de stockage a été mal configuré, des secrets dans des fichiers de configuration peuvent devenir lisibles.
On voit aussi des attaques plus “souterraines”: modification du code de sorte à exfiltrer des informations, y compris des tokens. Souvent, ce n’est pas un vol massif immédiatement visible. C’est un mécanisme discret qui récupère les secrets au moment où une page est chargée, puis les envoie ailleurs.
Enfin, il y a le scénario que beaucoup sous-estiment: la chaîne d’approvisionnement. Un plugin “trop permissif” ou compromis peut exiger un token pour “fonctionner”, puis détourner ce token. Si vous avez déjà activé des intégrations externes sans passer par un audit minimal, vous acceptez parfois sans le savoir une zone grise d’exécution.
Symptômes qui pointent vers un token ou une clé encore valide
Pour ne pas perdre de temps, il faut des signaux concrets. Plusieurs comportements reviennent quand des secrets restent compromis.
Le premier symptôme est la réapparition d’un problème après correction. Vous nettoyez un fichier, vous corrigez une injection, puis en quelques heures ou quelques jours le site se remet à dérailler. Le délai correspond souvent à l’intervalle d’un cron, d’une tâche d’automatisation, ou d’une action déclenchée par un service externe.
Deuxième indice: des actions “non humaines”. Par exemple, des modifications de paramètres ou des créations d’utilisateurs sans trace d’une connexion interactive. Les logs peuvent montrer des appels programmatiques, des requêtes venant d’un service, ou un pattern de requête répétitif.
Troisième indice: des erreurs liées à des intégrations qui ne devraient pas se déclencher. Si votre plugin de sauvegarde ou votre connecteur marketing produit des requêtes constantes, alors que vous ne l’avez pas reconfiguré, c’est un drapeau. Les attaques ne se contentent pas de voler, elles essaient aussi de conserver une capacité à agir.
Enfin, vous pouvez voir des requêtes vers des domaines externes inhabituels. Là, la nuance compte: tous les plugins appellent des domaines externes. La question est “lesquels” et “à quelle fréquence”. Un domaine qui n’était jamais sollicité devient soudain central, ou bien les appels augmentent alors que le trafic reste stable.
Préparation avant d’effacer: couper l’accès tout en observant
La désinfection WordPress efficace respecte un ordre. Si vous supprimez tout avant d’observer, vous perdez des indices. Et si vous coupez l’accès trop vite, vous pouvez casser une preuve.
Dans la pratique, je conseille de procéder en trois mouvements: isoler, documenter, puis nettoyer. D’abord isoler le site pour limiter l’impact et empêcher une exécution continue. Ensuite documenter avec les logs disponibles, l’historique des modifications, et l’état des intégrations. Enfin nettoyer avec une logique de remplacement, pas seulement de suppression.
Isoler peut vouloir dire mettre le site en maintenance, ou bloquer l’accès direct aux zones d’administration le temps de vérifier les sessions actives. Si vous êtes sur un hébergement avec firewall ou WAF, on peut aussi filtrer temporairement certains endpoints sensibles. L’idée n’est pas de “tout couper”, mais de réduire la surface pendant la phase de collecte.
Côté documentation, prenez le temps de relever les plugins et services concernés. Notez les dates, les changements récents, et surtout ce qui a été ajouté avant l’apparition du problème: un nouveau plugin, un module d’intégration, une réactivation d’un outil, un changement de thème, une mise à jour “par-dessus”. Les tokens compromis suivent souvent le fil de ces changements.
La stratégie qui marche: invalider les sessions, puis supprimer les secrets à la source
Supprimer un fichier malveillant est utile, mais ça ne traite pas le problème fondamental si un token reste valide. Le bon réflexe est de combiner deux actions: invalider ce qui permet de réagir, et retirer ce qui permet de se connecter sans interaction.
1) Invalider les sessions WordPress. Même si vous changez les mots de passe, des sessions peuvent rester ouvertes selon la configuration. Sur WordPress, il existe des mécanismes pour forcer la déconnexion, notamment via la réinitialisation des sessions utilisateur, et des procédures spécifiques via l’authentification.
2) Revoir les clés et tokens côté WordPress. Selon les plugins, vous trouverez parfois des options stockées dans la base. Certaines clés sont conservées dans des réglages. Les supprimer ne suffit pas si le code malveillant les a déjà utilisées ailleurs, mais c’est un pas immédiat vers la neutralisation.
3) Revoquer les tokens côté plateformes externes. C’est souvent l’étape qui manque. Si un token a accès à un service, vous devez le révoquer dans ce service. Sinon, l’attaquant continue d’agir. Dans plusieurs audits, j’ai vu des clés “refaites dans WordPress” alors que le token externe n’avait pas été changé. La conséquence est simple, le plugin reprenait automatiquement ce qui restait valide.
4) Remplacer par de nouveaux secrets, puis restabiliser en observant. Remettre un nouveau token n’est pas la fin. Il faut surveiller que rien d’inattendu ne réapparaisse.
Ces actions forment une boucle. Ce qui compte, c’est de ne pas confondre “nettoyage de code” et “désactivation des capacités d’accès”.
Où chercher les tokens et clés compromis dans WordPress
Les secrets ne sont pas toujours au même endroit. On peut les trouver dans les réglages du thème et des plugins, dans des options stockées en base de données, dans des variables d’environnement, ou dans des fichiers de configuration serveur.
Le point de départ le plus concret est la gardewp.fr liste des intégrations: plugins qui se connectent à des APIs, outils d’optimisation, connecteurs de sauvegarde, services de notification. Si vous avez récemment ajouté une fonctionnalité, commencez par elle.
Ensuite, inspectez les zones où WordPress stocke des options. Les clés peuvent être enregistrées dans la base sous forme de champs d’options, ou dans des structures propres à chaque plugin. Beaucoup de plugins ont des écrans “paramètres”, et c’est souvent là que les secrets sont visibles indirectement, sous forme partiellement masquée, ou dans des champs internes.
On rencontre aussi des secrets dans wp-config.php, surtout pour certaines constantes ou configurations. Attention, tout ce qui touche à wp-config.php doit être manipulé avec prudence, car une erreur de syntaxe peut casser le site.
Enfin, si vous utilisez des automatisations côté hébergement, il peut exister des clés liées au serveur, par exemple pour des déploiements, des backups ou des scripts. Dans ce cas, le token “WordPress” n’est pas le seul concerné. La désinfection WordPress doit s’étendre au périmètre global.
Checklist de désinfection orientée secrets
Voici une façon de structurer la phase d’urgence sans tomber dans le “je supprime et j’espère”. Elle a l’avantage d’être actionnable, tout en restant pragmatique.
- Mettre le site en maintenance ou limiter l’accès aux zones sensibles le temps d’agir Forcer la déconnexion et vérifier les sessions actives côté WordPress Identifier chaque plugin ou service externe ayant besoin d’un token, webhook ou clé Révoquer et remplacer les tokens côté plateformes externes, puis mettre à jour les paramètres côté WordPress Vérifier les logs sur plusieurs jours pour confirmer que les appels suspects cessent
Révoquer côté plateformes: le détail qui change tout
Quand un token est compromis, le renouveler “sur le site” sans révoquer “ailleurs” est un faux progrès. Certains services conservent la validité du token tant que vous ne le révoquez pas. D’autres peuvent continuer à accepter les requêtes tant que l’intégration n’est pas désactivée.
Dans les environnements où j’ai vu le problème persister, la cause la plus courante était un token qui restait actif dans un service, parce que l’administrateur pensait que WordPress “gère” tout. Or WordPress ne fait que stocker et présenter ce secret à un plugin. Le service externe fait le contrôle d’autorisation.
La bonne approche consiste à traiter chaque fournisseur comme une “source de vérité”. Vous coupez l’accès au niveau fournisseur, puis vous redonnez un nouveau token au niveau WordPress après nettoyage.
Trade-off à connaître: révoquer des tokens peut casser des fonctionnalités légitimes, emails transactionnels, synchronisations, intégrations CRM. C’est pour ça que la maintenance et la surveillance sont utiles. Vous limitez la casse, puis vous restaurez avec des clés neuves.
Remplacement des secrets: éviter la réinfection “par configuration”
Après révocation, vous allez remplacer. C’est tentant de coller le nouveau token et de reprendre. Mais si le code malveillant a modifié la configuration, le plugin peut retrouver des anciennes valeurs, ou bien un script peut réécrire la configuration à l’insu.
J’ai déjà vu un cas où l’on avait remplacé une clé dans l’interface d’un plugin, puis la clé revenait à l’ancienne. Ce n’était pas une “erreur humaine”, c’était un mécanisme qui réécrivait les options dans la base via un cron caché. Tant qu’on n’avait pas identifié la source, les remplacements étaient annulés.
Pour éviter ce piège, surveillez deux choses après remplacement: les logs applicatifs et les changements dans la base. Si vous n’avez pas de visibilité, un minimum de traces vous évite de perdre plusieurs cycles. Le but est de savoir si votre nouveau secret reste réellement en place.
Nettoyer sans casser: plugins, thèmes, et fichiers
Une désinfection WordPress sérieuse implique de revenir à un état sain. Il faut distinguer ce qui est “suspect” de ce qui est “normal”.
- Si un plugin est inconnu, ou installé récemment, il doit être considéré comme un suspect prioritaire. Les thèmes custom peuvent aussi être des vecteurs, surtout s’ils ont été modifiés récemment. Les fichiers injectés sont souvent difficiles à repérer s’il n’y a pas de méthode. Vous avez besoin d’une base de comparaison, une version saine, ou un contrôle via intégrité.
Un point important, que j’insiste souvent auprès des équipes: supprimer un plugin ne remplace pas la rotation des secrets. Un plugin peut être nettoyé, mais si le token qu’il utilisait a été copié puis réutilisé ailleurs, l’attaquant garde un levier. La rotation des secrets est la garantie de “couper la capacité”.
Cas limites: quand il n’y a “aucun token visible”
Parfois, l’enquête donne un résultat frustrant: pas de clé apparente, pas de token stocké dans des réglages, et pourtant le site se réinfecte. Dans ces scénarios, le compromis est parfois plus subtil.
Il peut y avoir des tokens dans du code custom, dans des fichiers inclus dynamiquement, ou sous une forme obfusquée. Ou bien l’attaque n’utilise pas un token de type “API”, mais exploite des mécanismes de réécriture, des webhooks, ou des sessions persistantes.
On peut aussi être en présence d’un accès compromis au niveau serveur. Par exemple, un compte FTP ou SSH avec une clé, un script cron modifié, ou un outil d’hébergement qui exécute des actions. La désinfection WordPress, dans ce cas, doit sortir du périmètre WordPress. Vous devez revalider l’accès serveur.
Le jugement important ici est le suivant: si les réapparitions continuent après une rotation des clés les plus évidentes, vous devez élargir l’investigation. Un coupable n’est pas forcément un plugin supplémentaire, il peut être un chemin d’exécution.
Mettre en place une surveillance utile après la désinfection
La désinfection WordPress ne se termine pas quand le site “remonte”. Elle se termine quand vous pouvez expliquer, avec des observations, que l’attaquant n’a plus de porte de retour.
Je recommande d’assurer une surveillance minimale sur plusieurs jours, plutôt qu’un test unique. Sur un site dynamique, un pattern d’infection peut se manifester à des heures spécifiques, parfois liées au trafic, parfois à un cron.
Dans cette phase, concentrez-vous sur ce qui a un lien direct avec les secrets: requêtes vers des domaines externes inhabituels, tentatives répétées vers des endpoints d’administration, modifications d’options WordPress, création d’utilisateurs, et tâches planifiées.
Si vous avez un outil de logs applicatifs et un journal d’événements côté hébergement, comparez. L’objectif n’est pas de “tout analyser”, mais de repérer ce qui ne correspond pas au fonctionnement normal.
Durcir pour ne pas replonger: limiter l’impact d’un futur compromis
On ne peut pas garantir à 100 pour cent qu’aucun secret ne sera compromis un jour. Mais vous pouvez réduire la surface et la durée de vie des accès.
Deux principes reviennent sans cesse après incident. Le premier, c’est le principe du moindre privilège: les plugins et intégrations doivent avoir uniquement les droits nécessaires. Le second, c’est le principe de rotation maîtrisée: savoir quand et comment renouveler des secrets, avec un processus clair.
J’ajoute un détail pratique, souvent ignoré: limitez le nombre de personnes qui touchent aux clés, et tenez un petit historique. Pas besoin d’un système lourd, une page interne suffit, avec qui a changé quoi, quand, et pourquoi. Lors d’un incident, ce carnet de bord raccourcit l’enquête.
Ce que je change après incident, en pratique
- Je retire les intégrations non indispensables, surtout celles avec tokens de longue durée Je révise les rôles WordPress, et je réduis l’accès admin quand ce n’est pas nécessaire J’organise une procédure de révocation et de rotation documentée pour chaque fournisseur Je surveille les plugins récemment ajoutés et je maintiens un inventaire à jour Je vérifie régulièrement les tâches planifiées et les scripts liés à l’automatisation
Vérifier la réalité: comment confirmer que les tokens compromis ne sont plus actifs
La confirmation n’est pas seulement “le site ne se redirige plus”. Pour être convaincant, il faut chercher des preuves que l’accès a été coupé.
Si un token avait un rôle dans l’envoi de requêtes externes, vous devriez observer une baisse des appels correspondants après révocation, ou au moins un retour à un niveau normal. Si le token était utilisé pour déclencher une action, l’action ne doit plus se produire.
Si vous utilisez une intégration avec suivi, les événements associés au token doivent cesser. Dans certains systèmes, vous pouvez aussi consulter un historique de sessions ou d’autorisations.
Le point de vigilance: certains fournisseurs mettent en cache des réglages, ou ont des latences. Ne concluez pas trop vite. Mais si le site continue de présenter des symptômes persistants, ne cherchez pas seulement du code, cherchez aussi le chemin d’accès encore actif.
Une anecdote typique: “Nettoyage terminé” et le retour du même problème
Je me souviens d’une intervention où l’équipe avait fait le plus difficile côté code: ils avaient retiré des fichiers, restauré un thème, et réinitialisé les mots de passe. Le site avait repris une apparence normale, puis, quelques jours après, la même injection revenait sur une section bien précise.
Le diagnostic a tourné autour des logs. Les requêtes provenaient d’un pattern cohérent, et le timing correspondait à une tâche d’automatisation externe. En recoupant, on a trouvé un token stocké dans un plugin de synchronisation marketing. Le plugin n’était pas le vecteur principal, il était juste le conducteur. Le token externe n’avait jamais été révoqué. Résultat, l’outil reprenait les mêmes tâches au même moment, et déclenchait de nouveau l’accès au contenu compromis.
La correction a été simple sur le papier, plus délicate en exécution: rotation du token côté fournisseur, puis nouvelle configuration WordPress, puis vérification que le nouveau secret ne se faisait pas écraser. Après ce point, le pattern a cessé. Le code n’a plus “ressorti” par lui-même.
Cette histoire résume ce que j’observe le plus: quand des secrets restent vivants, le nettoyage peut être effacé sans que vous le voyiez tout de suite.
La désinfection WordPress, orientée tokens et clés compromis, demande une discipline de bout en bout: comprendre comment l’accès a été maintenu, couper ce maintien là où il vit réellement, puis vérifier par des signaux observables que l’attaquant n’a plus de levier. Si vous faites seulement le nettoyage de code, vous corrigez la surface. Si vous révoquez et remplacez les secrets, vous coupez la persistance.
Si vous voulez, décrivez votre scénario (type d’hébergement, plugins concernés, symptômes après “nettoyage”, et s’il y a des intégrations externes). Je peux vous proposer une méthode d’investigation adaptée, en restant centrée sur la suppression effective des tokens et clés compromis.