Une compromission WordPress ne ressemble presque jamais à un scénario propre et documenté. Dans la pratique, on voit des symptômes disparates, parfois dans un ordre qui n’a rien d’aligné avec ce que la console de sécurité raconterait. Un site qui redirige vers une page bizarre, un pic de trafic inexpliqué, des formulaires qui renvoient des erreurs, des comptes administrateurs qui “apparaissent”, ou encore des fichiers qui n’auraient jamais dû exister dans wp-content. Le point commun reste le même: si on repart nettoyer au hasard, on perd du temps, on détruit des indices, et on laisse une porte ouverte à la reprise de l’attaque.
Voici une procédure de récupération pensée pour tenir sur le terrain. Elle n’est pas “magique”, elle privilégie la preuve, la maîtrise du risque, et des décisions assumées selon ce que vous observez réellement. L’objectif est double: remettre le site en ligne proprement, et empêcher la récidive. Et, dès que possible, transformer l’incident en base solide pour votre protection site WordPress.
1) Réagir vite, mais sans casser l’enquête
Quand vous suspectez une compromission, la tentation est d’agir sur le champ. C’est sain, mais il faut le faire avec méthode. Les premiers gestes servent à stopper l’exécution malveillante et à limiter la propagation, tout en conservant des traces exploitables.
Dès les premières minutes, j’essaie de répondre à trois questions simples, sans jargon:
- Est-ce que le site exécute encore du code malveillant, maintenant ? Est-ce que la compromission touche uniquement les fichiers ou aussi la base de données et les comptes ? Est-ce que l’attaque a déjà laissé des “persistances” (tâches planifiées, webhooks, utilisateurs créés, plugins modifiés) ?
Même un site “juste” défiguré peut avoir des mécanismes persistants. Et même un site qui semble normal peut contenir un fichier déclencheur qui ne s’active que sur certains navigateurs, certains pays, ou certaines périodes.
2) Contenir: couper la capacité d’agir de l’attaquant
La priorité est d’empêcher le code malveillant de continuer à tourner, surtout si vous voyez des redirections, des téléchargements automatiques, ou un volume anormal de requêtes. Contenir ne veut pas dire tout effacer immédiatement. Contenir veut dire isoler.
Dans un environnement idéal, vous basculez le site hors ligne proprement ou vous imposez une barrière temporaire (restriction IP, règles WAF, mode maintenance) pour bloquer les comportements évidents. Si votre hébergeur propose un mode “suspension du site” ou une isolation réseau, utilisez-le. Ce type de geste réduit aussi le risque que des données soient exfiltrées pendant que vous inspectez.
Un détail qui compte: si vous mettez WordPress en maintenance, l’attaquant peut continuer à exécuter certaines fonctions via des endpoints non couverts, ou via des scripts au niveau du serveur. Donc, maintenance seulement est parfois insuffisante. Le bon niveau de containment dépend de ce que vous observez.
3) Stabiliser l’environnement et documenter
Avant de toucher aux fichiers, prenez des notes. Elles vous aideront à reconstituer la chronologie et à corriger les erreurs de décision. Je commence par rassembler, dans un dossier local, tout ce qui permet d’établir un “état des lieux”:
- captures des pages modifiées ou comportements visibles (URL, heure, message, cible de redirection) logs serveur (HTTP status, user agents suspects, endpoints) logs applicatifs si disponibles (accès WP, erreurs PHP) liste des plugins et thèmes actifs au moment du signalement historique des modifications si votre système de déploiement enregistre des événements
Si vous avez accès à des métriques (CPU, RAM, load average), notez l’évolution. Une attaque peut être plus “silencieuse” côté navigation et plus vorace côté ressources.
Pour rester concret: j’ai déjà vu une compromission qui semblait “uniquement” déformer une page, mais les logs révélaient des appels répétés à des scripts cachés en dehors du flux normal. Sans cette observation, l’équipe aurait restauré des fichiers partiellement, et l’activité malveillante aurait continué.
4) Préserver les preuves: ce que vous ne devez pas supprimer trop tôt
La phase de triage mérite un minimum de discipline. Vous allez vouloir nettoyer, mais avant ça, vous devez éviter de détruire ce qui peut expliquer comment l’attaque est entrée, et comment elle persiste.
Voici une courte liste de ce que je recommande de faire avant de lancer des actions irréversibles. Elle n’est pas longue, parce qu’un incident n’attend pas.
Exportez la base de données (dump) et conservez une copie des tables, même si vous pensez restaurer ensuite. Faites une copie des répertoires wp-content, des fichiers racine WordPress (y compris wp-config.php), et du dossier uploads. Conservez la liste des utilisateurs WordPress et leurs rôles, ainsi que tout élément “anormal” (nouveaux comptes, admins additionnels). Récupérez les logs serveur sur une fenêtre de temps cohérente avec le début probable de l’incident. Notez les hachages (MD5 ou SHA256) des fichiers suspects si vous avez l’outillage pour le faire rapidement.Cette étape peut sembler lourde, mais elle évite des discussions stériles après coup, du genre “on ne sait plus ce qui était là”.
5) Identifier le vecteur le plus probable
Sur WordPress, les vecteurs fréquents ne sont pas mystérieux. Ils sont souvent liés à la gestion des identifiants, aux plugins trop permissifs, aux mises à jour manquées, ou à des configurations d’hébergement trop laxistes.
Quelques scénarios réalistes:
- un compte administrateur compromis via mot de passe réutilisé, phishing, ou absence de MFA un plugin ou un thème modifié, parfois via une mise à jour compromise, parfois via une vulnérabilité exploitée une compromission au niveau serveur (permissions, accès FTP/SFTP, mauvaises clés, panel d’hébergement) une insertion dans les fichiers de configuration ou des fichiers “autoload” via la racine ou wp-content
L’important n’est pas de choisir le scénario “le plus plausible” à la première minute, mais d’investir juste assez de temps pour confirmer ce que vous pouvez. Par exemple, si vous trouvez des fichiers PHP inconnus dans wp-content/uploads ou des scripts dans des dossiers temporaires, vous avez un indice très fort.
6) Vérifier l’intégrité des fichiers WordPress et des extensions
Une fois l’environnement contenu, passez en mode vérification. WordPress est relativement “standard”. Cela rend l’analyse plus facile, à condition d’avoir une base de comparaison.
L’approche pratique que j’utilise:
- comparer les fichiers présents à une version WordPress connue correspondant à la branche et à la version exacte vérifier les dates de modification (dans une fenêtre cohérente avec l’incident) repérer les fichiers ajoutés ou les tailles incohérentes analyser les fichiers PHP inhabituels: obfuscation, présence de requêtes HTTP vers des domaines non attendus, fonctions de chargement dynamique, base64 très “denses”, accès système, écriture de fichiers
Attention aux faux positifs. Les outils d’intégrité peuvent signaler des différences normales (langues, caches, modifications de thèmes légitimes). Le jugement compte: un écart de date “normal” dans un thème édité par vos équipes n’est pas la même chose qu’un fichier inconnu au milieu de uploads.
Si votre site utilise un thème ou un builder avec des personnalisations en profondeur, la comparaison “100% identique” devient moins utile. Dans ce cas, visez plutôt:
- repérer le code qui n’est pas attendu pour votre stack inspecter les zones où WordPress n’ajoute pas de code par lui-même vérifier que les hooks et fonctions éditées correspondent à votre code source versionné
7) Confronter la base de données: tables, options et persistance
Quand des attaquants prennent pied, la base de données devient souvent le cœur de la persistance. Les fichiers peuvent être un amorçage, mais la plupart des comportements persistants se pilotent via:
- wp_options (options modifiées) wp_users (ajout d’utilisateurs et changement de rôles) wp_postmeta (contenus ou métadonnées altérés) parfois des injections via des tables de cache ou d’extensions
Dans la pratique, si vous voyez des redirections, des champs de configuration étranges peuvent être à l’origine du comportement. Si vous voyez du spam ou des comptes ajoutés, c’est côté utilisateurs.
Un piège fréquent: restaurer seulement les fichiers, mais laisser la base compromise. Résultat: vous redémarrez “propre” en apparence, puis l’attaquant réinstalle son mécanisme depuis la base. Inversement, restaurer seulement la base sans nettoyer les fichiers peut laisser un point d’entrée.
La bonne stratégie dépend de votre capacité à reconstruire proprement.
8) Restaurer proprement: nettoyer vs repartir d’une base saine
C’est le moment où beaucoup d’équipes hésitent, et c’est normal. Il y a deux grandes voies:
1) nettoyer ce qui est compromis, fichier par fichier, en supprimant ce qui est suspect
2) repartir d’une restauration de sauvegarde saine, puis réappliquer ce qui est nécessaireLe nettoyage a un avantage, il réduit le risque de perdre des contenus récents si vos sauvegardes sont anciennes. Mais il impose une rigueur forte, parce qu’un seul fichier ou une option restée active peut suffire à relancer l’infection.
La restauration a un avantage, elle remet le socle à un état connu. Elle exige toutefois:
- une sauvegarde réellement saine (pas une sauvegarde prise après l’infection) de la discipline sur l’ordre des actions (fichiers, base, config) un plan de re-déploiement (comment vous reconstruisez le site pour rester aligné)
Si vous avez des sauvegardes quotidiennes, et que l’incident est récent, la restauration peut être très efficace. Si l’incident est ancien ou que vos sauvegardes ne sont pas fiables, le nettoyage devient plus risqué, car vous risquez de “réinstaller” la persistance via la base.
Mon conseil terrain: si vous avez une sauvegarde dont vous pouvez raisonnablement défendre la propreté (heure cohérente, absence d’indices dans l’archive, traces de modification), partez sur la restauration. Sinon, faites un nettoyage méticuleux et supposez que la persistance peut se cacher dans plusieurs endroits.
9) Rotation des identifiants et fermeture des accès
Pendant qu’on nettoie, l’attaquant peut encore essayer d’accéder. Donc la rotation des identifiants est un geste de sécurité indispensable, même si vous êtes persuadé d’avoir “tout supprimé”.
Sur WordPress, la rotation doit inclure:
- comptes WordPress (surtout admin) comptes FTP/SFTP si utilisés identifiants d’hébergement et de panneau (cPanel, Plesk, accès SSH) clés API et tokens éventuels
Si votre hébergeur fournit des mécanismes d’accès à distance, régénérez les sessions ou forcez une re-authentication.
Un point souvent oublié: si vous avez un client mail, des webhooks, des plugins qui se connectent à des https://gardewp.fr/securite-wordpress/ services externes, l’attaquant peut aussi avoir capturé des tokens. La rotation ne se limite pas au couple utilisateur/mot de passe.
10) Éliminer la persistance côté code et planifications
Les compromissions “sérieuses” cherchent des points de persistance. Dans WordPress, ça peut passer par des plugins modifiés, des fichiers déposés en dehors des dossiers attendus, et des tâches planifiées.
Dans votre inspection, je cherche systématiquement:
- des fichiers dans wp-content non liés à votre stack des classes ou fonctions PHP “bizarres” ajoutées des fichiers dont le nom ressemble à quelque chose d’inoffensif, mais dont le contenu fait du chargement dynamique des mécanismes planifiés (via plugins ou WP-Cron) qui ré-exécutent des actions
Si vous trouvez un plugin “modifié” mais toujours actif, le simple désactivation peut suffire à stop net, mais la suppression est souvent le meilleur choix une fois que vous avez confirmé que le plugin est compromis.
11) Réinstaller un socle propre et réactiver avec parcimonie
Quand le nettoyage est terminé ou après restauration, le rétablissement doit se faire avec contrôle. Réactiver tout d’un coup est tentant, surtout si vous manquez de temps. Pourtant, si un plugin compromis revient en place, vous redonnez une porte ouverte.
Je procède généralement en réactivation progressive:
- d’abord thèmes et plugins “indispensables” ensuite les autres, un par un et à chaque étape, vérification du comportement, puis revue des logs
Le signe qui m’intéresse le plus est la cohérence des réponses HTTP. Si vous voyez encore des redirections, des codes 4xx inhabituels, ou des requêtes répétées vers des domaines externes non attendus, je n’essaie pas de “fermer les yeux”. Je replonge dans l’analyse.
12) Durcir la sécurité pour éviter la récidive
Une compromission est souvent un symptôme. Le système n’est pas tombé par hasard. Les mêmes causes reviennent, surtout si vous n’appliquez pas une protection site WordPress pragmatique.
À ce stade, je recommande de vérifier au moins:
- mise à jour WordPress, thèmes, plugins, et compatibilités PHP suppression des thèmes/plugins inutilisés limitation des privilèges (principe du moindre accès) MFA sur les comptes administrateurs quand c’est possible désactivation des fonctionnalités inutilement exposées durcissement serveur: permissions de fichiers, configuration PHP, désactivation des exécutions dans les dossiers non nécessaires
Il y a aussi un volet “hygiène”: mots de passe uniques, gestion des comptes, rotation régulière quand l’entreprise est sujette aux départs de collaborateurs.
Le trade-off est clair: trop de durcissement peut casser un workflow légitime (API, intégrations, scripts de déploiement). La solution consiste à tester, documenter, et introduire les changements progressivement, pas en bloc pendant la crise.
13) Mettre en place une surveillance utile, pas juste des alertes
Après une remise en ligne, le risque n’est pas seulement “que le site soit encore infecté”. Le risque est aussi de rater un comportement qui se déclenche dans certains cas: un bot visite rarement votre home page, mais interroge un endpoint précis; un script attend une fenêtre horaire; une injection réécrit certains contenus seulement quand un formulaire est envoyé.
Une surveillance utile se traduit souvent par:
- alertes sur des changements de fichiers sensibles contrôle des nouveaux utilisateurs administrateurs observation des journaux pour des pics d’accès anormaux vérification de la santé WP-Cron et des tâches périodiques
Si vous utilisez déjà un outil de sécurité, vérifiez qu’il couvre réellement vos vecteurs. Un scanner de vulnérabilités ne remplacera jamais un suivi de l’intégrité applicative, surtout si la compromission a été réalisée via des permissions système.
14) Exemple de scénario réel de terrain (sans dramatiser)
Je repense à un cas typique: redirection ponctuelle, parfois sur mobile uniquement. Les équipes ont d’abord cherché “le mauvais fichier” dans la racine. Ils n’ont rien trouvé. La persistance se déclenchait via un chemin lié aux uploads et à un hook activé par un plugin spécifique. Tant que le plugin n’était pas isolé, la restauration partielle semblait fonctionner, puis le comportement revenait quelques heures après.
Ce genre de scénario illustre pourquoi la procédure doit être séquencée: 1) contenir pour stabiliser 2) préserver les preuves 3) comprendre où se situe la persistance 4) corriger de manière cohérente (fichiers et base) 5) réactiver avec contrôle
L’ordre n’est pas une lubie. Il évite les cycles de “on a nettoyé, mais ça revient”.
15) Démarrer une check finale avant de déclarer “propre”
Avant de relâcher le site, prenez deux minutes supplémentaires. Les signatures d’une compromission peuvent être nettes, mais certaines modifications sont discrètes. Et dans WordPress, un petit morceau de code peut produire beaucoup d’effet.
Voici une mini-vérification finale, en prose, pour rester proche de ce que vous pouvez constater:
- vérifiez que la page d’accueil ne redirige plus, y compris sur des navigateurs et tailles d’écran différents testez quelques formulaires et endpoints critiques (recherche, formulaires, login) contrôlez les utilisateurs WordPress, aucun nouvel admin “inattendu” assurez-vous que les plugins et thèmes actifs correspondent à ce que vous maintenez réellement inspectez les logs récents, pas de requêtes répétées vers des domaines suspects ou d’erreurs PHP récurrentes
Quand tout ça est cohérent, vous pouvez passer en régime normal, mais gardez le plan de surveillance actif au moins quelques jours, parfois quelques semaines selon la gravité.
16) Après l’incident: exploiter les leçons pour votre protection site WordPress
Un incident WordPress finit rarement par “un seul correctif”. La vraie valeur vient de la correction des causes racines.
Les leçons que je vois le plus souvent ressortir:
- un plugin trop ancien ou non maintenu devient le point d’entrée des identifiants réutilisés ou stockés de manière fragile donnent un accès instantané des permissions d’écriture trop larges permettent l’injection de fichiers l’absence de versionning de thèmes ou le manque de sauvegardes fiables rend le nettoyage plus long
Si vous tenez à une approche pragmatique, partez d’un objectif: réduire la surface d’attaque et réduire le temps de reconstruction. Cela signifie, entre autres, sauvegardes testées, procédure documentée, et capacité à restaurer rapidement sans improvisation.
Si vous me décrivez vos symptômes (redirections, pages modifiées, nouveaux comptes, symptômes serveur, plugins incriminés, date approximative), je peux vous aider à adapter cette procédure à votre cas, notamment sur le choix entre nettoyage et restauration, et sur ce qu’il faut prioriser dans l’analyse des fichiers et de la base.