Quand un site WordPress est infecté, on pense souvent au front, aux pages qui affichent de la pub ou aux redirections bizarres. Pourtant, dans une grosse partie des cas qui reviennent en intervention, le vrai danger se joue ailleurs: les secrets. Les clés API, les tokens, les mots de passe d’anciens plugins, parfois même des variables de configuration sensibles restent dans les fichiers, ou sont réutilisés par le malware pour persister. Et tant que ces éléments compromis ne sont pas invalidés, la “suppression” du code malveillant ressemble trop souvent à une réparation provisoire.
J’ai vu des sites réinfectés à peine quelques heures après “nettoyage”, parce que la clé API qui servait à interroger un backend externe avait déjà fuité. Le code supprimé, mais la porte restait ouverte, ou pire, le malware avait gardé en mémoire une logique de récupération de nouveaux éléments. C’est pour ça que la démarche la plus fiable consiste à traiter deux chantiers en parallèle: retirer le malware, puis supprimer ou révoquer les clés API et secrets exposés, pour couper les communications.
Comprendre pourquoi les clés API font partie du problème
Sur WordPress, les secrets se cachent partout, parfois de façon banale. Un plugin peut stocker une clé d’API en dur dans un fichier, ou l’exposer via une option dans la base de données. Un thème enfant peut charger des identifiants pour une intégration tierce. Un script d’automatisation peut utiliser un token pour pousser des médias ou synchroniser des données. Et quand un malware arrive, il ne fait pas forcément du “remplacement de texte” ou du spam. Il peut surtout:
- lire des fichiers de configuration, exfiltrer des tokens, modifier des hooks WordPress, réécrire des paramètres pour appeler un serveur contrôlé.
Le point critique, c’est que le malware n’a pas besoin de rester sur le serveur. Il peut avoir une “capacité de reprise”, c’est-à-dire qu’il a déjà récupéré le secret, ou qu’il sait où il se trouve pour le re-fouiller plus tard. Supprimer le malware sans révoquer les clés revient parfois à effacer les traces, mais laisser l’accès.
Les signaux qui doivent vous faire penser “secrets compromis”
Tous les incidents ne laissent pas des indices spectaculaires, mais il y a des patterns. Si vous constatez un comportement anormal côté serveur ou côté services externes, méfiez-vous des secrets. Parmi les signaux qui reviennent:
- des appels réseau sortants inhabituels (pics vers un domaine ou un IP, requêtes récurrentes à des endpoints “exotiques”), des erreurs d’authentification chez vos fournisseurs (par exemple des journaux qui montrent des tentatives API depuis des IP inattendues), une augmentation brutale des tâches planifiées (wp-cron) ou des mises à jour automatiques qui ne correspondent à aucune routine interne, un accès admin qui change (création d’utilisateurs, modification des rôles, sessions invalidées puis recréées), des modifications invisibles côté code mais visibles via la base (options et metadata modifiées).
Dans les interventions que j’ai menées, le scénario le plus coûteux est celui où le site paraît “net” après coup, mais des services tiers continuent de recevoir des requêtes et des webhooks déclenchent des événements hors contexte. C’est là que la piste “clés API et secrets compromis” devient prioritaire.
Cartographier ce qui peut contenir des secrets sur WordPress
Avant de supprimer des choses au hasard, prenez le temps de faire une cartographie. Le but n’est pas d’ouvrir chaque fichier, mais d’identifier les zones typiques où des secrets se logent.
Sur un WordPress standard, les points d’attention incluent souvent:
- le fichier wp-config.php (constantes, clés, parfois des variables de configuration associées à des plugins), les fichiers de plugins et de thèmes (parfois des paramètres en dur, surtout dans des scripts “helpers”), la base de données (options, meta, paramètres de configuration stockés via des interfaces d’administration), les fichiers de configuration “cachés” générés par des outils (cachés de build, scripts d’export, fichiers de déploiement), le système de cache et les formats de logs (certains malwares écrivent des journaux qui contiennent des morceaux de secrets).
Une règle simple aide à trier: plus un secret est “utilisé pour appeler un service externe”, plus il doit être considéré comme compromis dès qu’un incident sérieux est suspecté.
La stratégie fiable: couper les accès avant ou après le nettoyage ?
Il y a un équilibre à trouver. Si vous révoquez trop tôt, certains plugins peuvent cesser de fonctionner, et vous perdez un peu de contexte sur l’origine du trafic sortant. Si vous nettoyez sans révoquer, vous risquez une reprise.
Dans la pratique, je recommande souvent de procéder en séquence courte et structurée, surtout si vous avez accès aux journaux et à un environnement de test.
L’idée, c’est de limiter la fenêtre où les clés compromis peuvent être réutilisées. Pour un cas “urgences”, vous gagnez souvent à:
- nettoyer d’abord les vecteurs de persistance évidents, identifier les secrets exposés, révoquer immédiatement ceux qui ont de vraies dépendances externes, puis seulement après, finir la chasse aux scripts et aux fichiers restants.
Ce n’est pas une loi universelle. Si vous n’avez aucun accès aux fournisseurs ou si vous ne pouvez pas révoquer rapidement, vous devrez peut-être faire autrement. Mais en général, la réactivité sur les secrets apporte un vrai bénéfice.
Ce qu’il faut révoquer, exactement (clés API, tokens, webhooks)
“Supprimer les clés API et secrets compromis” n’est pas une formule vague. Vous devez viser tout ce qui pourrait servir d’authentification ou de récupération.
Voici les catégories à traiter en priorité, parce qu’elles permettent à un acteur distant d’agir:
Clés API et tokens pour des services externes (cloud, messagerie, paiement, CMS externes, CRM), Identifiants utilisés pour des webhooks ou des intégrations d’événements, Secrets stockés dans wp-config.php ou des fichiers de configuration de plugins, Mots de passe stockés pour des mécanismes d’automatisation (SSH, FTP, bases distantes, services de synchronisation), Credentials internes utilisés pour des requêtes vers des endpoints que vous n’utilisez pas habituellement.Selon les plugins que vous avez, cela peut être très concret: un token pour un fournisseur de notifications, un key pour un service d’indexation, une clé pour une API de transcription, ou un secret de signature pour valider des webhooks.
Le point délicat est que certains secrets ne sont pas “visible en clair” dans les fichiers. Ils peuvent être chiffrés au niveau applicatif, stockés dans des options, ou fournis via des variables d’environnement. Dans ce cas, votre démarche doit inclure l’inventaire des emplacements d’où proviennent ces secrets.
Où trouver les clés et secrets potentiellement exposés
Dans une enquête utile, vous combinez trois sources: le code, la base et les logs. C’est rarement une seule preuve.
1) Vérifier les emplacements “classiques”
Commencez par wp-config.php et cherchez des constantes ou sections qui n’ont pas de raison d’être là. Un malware peut injecter des blocs, ou pousser des paramètres pour améliorer son efficacité.
2) Chercher côté base de données
Les options WordPress, certains meta, et des configurations de plugins peuvent contenir des tokens. Si vous avez un export, cherchez les champs qui ressemblent à des identifiants, par exemple des chaînes longues et non lisibles. Les valeurs “en clair” sont parfois surprenantes.
3) Correlater avec l’activité sortante
Si vos journaux (au niveau reverse proxy, pare-feu applicatif, ou logs d’accès) montrent une destination unique, creusez si cette destination correspond à un service que vous utilisez, ou à un service qui n’est pas documenté côté administration.
Procéder sans casser le site: un plan de travail pragmatique
L’erreur fréquente consiste à “supprimer” tout, trop vite, puis à découvrir que votre site ne peut plus contacter son fournisseur d’email, son outil SEO, ou son intégration de paiement. Vous voulez éviter ça, tout en réduisant le temps d’exposition.
Voici un déroulé pratique, en gardant la main sur ce qui change.
Checklist d’investigation rapide (avant modifications irréversibles)
- Identifier les fichiers modifiés récemment, surtout dans wp-content (plugins, thèmes, dossiers uploads si vous avez autorisé des modifications). Rechercher des patterns de persistance (hooks, options update_option, chargement conditionnel, inclusion dynamique de fichiers distants). Repérer les comptes admin créés récemment, et vérifier les rôles. Extraire une liste des intégrations (services tiers) réellement utilisées par le site. Lister les endroits où vous stockez des secrets (fichiers, options base, variables d’environnement côté hébergement).
Cette base vous évite de “révoquer pour rien” ou de rater un secret qui reste actif.
Révoquer et remplacer les secrets compromis: méthode en 3 temps
Vous devez traiter les secrets comme des éléments en rupture de confiance. Même si vous supprimez le malware, un token compromis doit être considéré comme grillé.
1) Révoquer
Quand c’est possible, révoquez côté fournisseur. Selon les plateformes, cela peut être https://gardewp.fr/ un bouton “revoke”, la régénération d’un token, ou la rotation d’une clé.
Je vous conseille de commencer par les secrets qui permettent d’écrire ou d’agir. Une clé qui ne fait qu’un accès lecture peut parfois être réutilisable, mais dans un incident réel, le coût d’une rotation est souvent inférieur au risque.
2) Remplacer
Une fois révoqués, mettez les nouveaux secrets en place dans les mêmes emplacements “propres”. Si un plugin stocke une clé en base, remplacez-la dans l’interface ou via une mise à jour contrôlée. Si c’est dans un fichier, mettez à jour le fichier et vérifiez les permissions.
3) Vérifier la propagation
Le piège, c’est que certains plugins mettent en cache des valeurs. Après remplacement, surveillez que:
- l’intégration fonctionne, les erreurs d’authentification disparaissent, les appels sortants reviennent à une fréquence normale, aucun webhook suspect ne continue à être envoyé.
Cas concret: quand le nettoyage “réussit”, mais le site continue de parler
Une situation typique: vous trouvez et supprimez le code malveillant. Les pages redeviennent normales. Puis, une heure plus tard, vous recevez une alerte côté fournisseur de logs: “tentatives d’API depuis un utilisateur invalide” ou “signature de webhook incorrecte”, et vous remarquez un domaine étrange.
Ce que ça indique, en pratique, c’est souvent l’un des scénarios suivants:
- le malware avait déjà exfiltré un token et continue depuis un script persistant, un fichier “helper” reste présent ailleurs que dans le plugin infecté, ou le site tente encore de joindre un endpoint avec un secret ancien, conservé dans la base.
Dans ce cas, “supprimer malware WordPress” ne suffit pas. Vous devez faire une rotation des clés, puis vérifier dans les journaux serveur et côté fournisseur qu’il n’y a plus d’appel vers des endpoints non attendus.
Le diagnostic repose sur la corrélation: si vous révoquez une clé et que le trafic cesse immédiatement, vous avez une confirmation forte. Sinon, il faut chercher un autre secret compromis, ou un mécanisme alternatif.
Où les secrets compromis restent souvent après un nettoyage
Même une intervention propre laisse parfois des résidus. Par expérience, les secrets peuvent survivre sous ces formes:
- options de base modifiées (le plugin croit appeler un service, mais utilise un token remplacé), fichiers “drop” dans wp-content/uploads ou des sous-dossiers, fragments de code dans des thèmes ou plugins tiers, pas forcément le plugin suspect initial, configurations importées via des outils (migrations, backups automatiques) qui réintroduisent les anciennes valeurs.
Un point qui mérite attention: les backups. Si vous restaurez un snapshot trop ancien après nettoyage, vous réinjectez les secrets compromis. Sur le long terme, il faut que la rotation de secrets prenne le dessus sur la logique de restauration.
Réinitialiser aussi l’écosystème d’accès, pas seulement les tokens
Les clés API ne sont pas le seul élément à rétablir. Si un acteur a pu viser des secrets, il a probablement touché aussi l’accès humain.
Cela ne veut pas dire “réinitialiser tout pour tout casser”, mais une vérification ciblée est nécessaire.
Je recommande de traiter au moins:
- les comptes admin récemment créés ou suspects, les sessions persistantes, les comptes utilisés pour des intégrations (par exemple, OAuth apps ou utilisateurs de services tiers).
La rotation des secrets est une partie du “cercle de confiance”. Si un compte compromis reste actif, un token peut être régénéré automatiquement via des workflows, et vous repartez pour un tour.
Sécuriser les étapes suivantes pour éviter la réinjection
Une fois le site redevenu stable, la vraie victoire est d’empêcher la prochaine infection d’atteindre vos secrets.
Sans tomber dans la paranoïa, quelques mesures font souvent la différence:
- mettre à jour plugins et thèmes, mais pas “en aveugle” si vous avez des dépendances critiques, limiter les droits d’écriture sur les fichiers sensibles, notamment dans wp-content, surveiller les créations d’utilisateurs et les changements de rôles, désactiver ou surveiller les plugins qui ont des comportements réseau incompréhensibles, garder une procédure claire de rotation de secrets après incident.
Le principe: plus votre système est facile à auditer, plus vous réagissez vite le jour où un malware essaie de re-percer.
Une mini liste d’actions de contrôle après rotation
- vérifier que les clés tournent sur un environnement de test ou une fenêtre de maintenance si possible, confirmer la disparition du trafic vers les domaines inattendus, contrôler les options WordPress sensibles et les valeurs de configuration de plugins, enregistrer les dates de rotation et les numéros de version des plugins concernés, garder une trace des fournisseurs révoqués et remplacés.
Les pièges fréquents: erreurs qui prolongent l’incident
Certaines erreurs reviennent en mission, et elles coûtent cher en temps.
Le premier piège, c’est de supprimer uniquement le plugin ou le fichier infecté, puis de ne rien faire côté fournisseur. Si un token était déjà utilisé, vous ne coupez pas l’impact.
Le deuxième piège, c’est de remplacer la clé API dans un seul endroit alors qu’elle existe à plusieurs niveaux. Un plugin peut stocker une valeur en base, tout en ayant une configuration par défaut dans un fichier. Résultat: vous pensez avoir tourné la clé, mais le plugin continue avec l’ancienne.
Le troisième piège, c’est la restauration depuis backup. Si votre backup contient les mêmes secrets compromis, vous recréez la faille dès la restauration.
Enfin, le quatrième piège est l’absence de logs. Sans journaux, vous ne pouvez pas confirmer l’effet de la rotation. Vous “faites” le changement, mais vous ne prouvez pas que le risque est parti.
Comment tester que les clés et secrets sont bien neutralisés
Le test doit être réel, pas juste “ça charge sur mon navigateur”.
Quand vous révoquez une clé, vous voulez observer un changement mesurable. Les signes utiles sont:
- les erreurs d’authentification côté application disparaissent après remplacement, les requêtes sortantes cessent vers les destinations suspectes, les webhooks ou intégrations ne se déclenchent plus hors contexte, les logs côté fournisseurs ne montrent plus de tentatives venant de votre instance compromise.
Si vous avez accès aux logs d’application et aux journaux d’hébergement, faites un point de comparaison avant et après rotation. Même un échantillon d’une journée donne souvent une vue claire.
Conclusion opérationnelle: pourquoi “supprimer malware WordPress” passe aussi par les secrets
Traiter une infection WordPress comme un simple nettoyage de fichiers, c’est souvent insuffisant. Le malware s’attaque à la persistance, et dans cette persistance il y a une idée simple: utiliser les secrets pour continuer à agir ou pour récupérer d’autres instructions.
Quand vous supprimez malware WordPress, vous devez aussi supprimer ou révoquer les clés API et secrets compromis, pas uniquement retirer le code visible. Le bénéfice est double: vous stoppez l’exfiltration potentielle et vous empêchez les actions “à distance” basées sur des authentifications déjà capturées.
Si vous ne deviez retenir qu’un seul principe, ce serait celui-ci: un secret compromis ne mérite pas d’être “nettoyé”, il mérite d’être remplacé. Et une fois cette discipline en place, le site devient beaucoup plus résilient face aux variantes de malware qui changent de fichiers, mais reposent sur les mêmes leviers.