Quand un site WordPress a été compromis, le nettoyage est souvent présenté comme un passage obligé et presque mécanique. Dans la pratique, c’est plutôt un chantier en plusieurs temps, où l’on retire ce qui dépasse, puis on prouve que ce qui reste est sain. Et surtout, on doit vérifier l’intégrité avant et après le nettoyage, sinon on travaille “à l’aveugle”. J’ai vu des sites “remis en ligne” en quelques heures, puis infectés à nouveau une semaine plus tard, parce que le point d’entrée initial n’avait jamais été réellement supprimé.
L’audit après incident a donc deux objectifs. Le premier est de comprendre ce qui s’est passé, même si c’est imparfait, pour éviter de refaire les mêmes erreurs. Le second est de mesurer, sur des preuves, que le site n’a pas été seulement nettoyé, mais aussi stabilisé et replacé dans un état cohérent.
Pourquoi l’intégrité se joue avant même le premier “scan”
Avant de lancer un nettoyage, il faut résister à la tentation de “tout effacer” immédiatement. Sur WordPress, l’infection peut vivre à plusieurs endroits, parfois discrets, parfois très visibles. Une action trop agressive peut détruire des indices utiles: logs tronqués par suppression, fichiers modifiés réécrits sans conservation des versions, bases de données réimportées depuis une sauvegarde trop ancienne, ou plugins remplacés sans garder les traces.
En incident response, on cherche souvent à obtenir un minimum de vérité exploitable, pas une perfection médico-légale. Concrètement, ça veut dire préparer l’enquête, isoler, puis documenter. Même si vous ne disposez pas d’une équipe SOC, vous pouvez faire une différence énorme avec deux gestes: figer l’état actuel et relever des éléments de comparaison.
Ce que j’ai appris en audit “à froid”
Lors d’un cas récent, le site semblait “propre” après nettoyage, car les pages malveillantes n’étaient plus servies. Pourtant, l’analyse a montré des persistances dans des fichiers rarement modifiés, ainsi qu’une modification dans une table d’options. Résultat: la contamination revenait dès qu’un certain comportement déclenchait un appel à une option altérée. La réparation avait échoué non pas parce que le nettoyage était mauvais, mais parce que l’audit après incident n’avait pas établi de référence claire avant et après.
Définir le périmètre d’intégrité dans WordPress
“Intégrité” ne signifie pas seulement “absence de malware”. Pour un site WordPress, l’intégrité englobe plusieurs plans.
D’abord, l’intégrité des fichiers: thèmes, plugins, fichiers WordPress core, scripts éventuels côté serveur, et fichiers d’upload. Ensuite, l’intégrité du code stocké ou généré: contenus de pages, shortcodes, variables PHP dans des thèmes ou plugins, transformations dans des champs de base de données.
Enfin, l’intégrité d’exécution: configuration serveur, règles de redirection, tâches planifiées, comptes administrateurs, hooks, et paramètres WordPress liés aux mises à jour automatiques, à la désactivation de protections, ou à l’activation d’un lecteur “externe” qui pourrait réintroduire un code.
Dans un audit après incident, il est utile d’exprimer cette approche en termes de comparaison. On compare un état “avant” (ou le plus proche possible) et un état “après”. Les deux états ne doivent pas forcément être parfaits, mais ils doivent être traçables.
Construire une référence “avant nettoyage”
Quand on dit “vérifier avant”, on parle de collecter une base de vérité. Ça ne veut pas dire “garder chaque bit” si vous ne pouvez pas. Ça veut dire garder ce qui permet de dire: “ce fichier existait, il a été modifié, voici comment, voici ce que ça affectait”.
Capturer des preuves sans ralentir l’intervention
Voici ce que je recommande, en pratique, pour une référence avant nettoyage:
- conserver une copie des fichiers suspectés, pas seulement une capture d’écran; sauvegarder l’état des répertoires WordPress et wp-content, ainsi que les fichiers PHP clés; exporter une partie de la base de données utile à la compréhension (options, utilisateurs, cron, éventuels champs liés à l’injection); récupérer des logs d’accès et d’erreur sur la période de l’incident.
La nuance importante, c’est le choix des données à garder. Sur un site à fort trafic, les logs peuvent être énormes. On peut alors cibler la plage horaire où l’injection a été observée, ou la période autour de la première alerte.
Exemple concret de “preuve utile”
Si vous détectez un fichier PHP modifié dans un thème ou un plugin, l’idéal est d’obtenir une version antérieure ou au moins un hash de référence. Si vous n’avez pas de hash historique, vous pouvez comparer à une version saine issue du dépôt officiel ou d’un package que vous savez exact (par exemple une version de plugin que vous aviez déployée le jour J). Le but n’est pas de prouver au tribunal, c’est de décider vite et bien ce qui doit être remplacé, reconstruit ou restauré.
Ce que vous devez vérifier sur les fichiers
Une infection WordPress s’exprime rarement dans un seul fichier. Elle utilise plutôt des “points de passage”: un fichier PHP modifié qui ajoute un chargement conditionnel, une fonction qui déclenche une requête externe, un script qui récupère du code à l’exécution, ou une manipulation via un fichier de configuration.
Dans un audit après incident orienté intégrité, je regarde les familles suivantes, car ce sont celles qui reviennent le plus souvent:
Fichiers core WordPress: on cherche des modifications de bas niveau, car WordPress core n’est pas censé changer à la main; Thèmes: fonctions du thème, fichiers PHP dans le thème actif, et tout ce qui est dans des zones de template ou des includes; Plugins: mêmes logiques que pour les thèmes, avec ajout ou modification de hooks; Wp-content/uploads: images et médias peuvent servir de vecteur via des fichiers déguisés, ou être liés à une exécution via d’autres bugs; Fichiers “à la marge”: robots, .htaccess, fichiers de configuration, scripts temporaires, ou fichiers masqués.Je sais, ça semble large. Mais l’intérêt est justement de ne pas se limiter aux signatures anti-malware. Les signatures repèrent souvent le connu, pas forcément le sur mesure.
Travailler avec les timestamps, avec prudence
Beaucoup d’admins se basent sur les dates de modification. C’est utile pour orienter, mais c’est risqué pour conclure. Sur certains environnements, les timestamps peuvent changer lors de déploiements, de transferts ou de restaurations. En revanche, si un fichier PHP a un timestamp clairement incompatible avec vos changements habituels (par exemple, un plugin censé être stable, modifié en plein milieu de la nuit sans mise à jour), c’est un drapeau rouge.
Vérifier la base de données sans casser la récupération
La base de données contient souvent les vraies traces: utilisateurs ajoutés, rôles modifiés, options altérées, contenus injectés, ou planifications malveillantes. En termes d’intégrité, le piège est de nettoyer le code PHP et de laisser une persistance en base, ce qui rend la “désinfection” fragile.
Il faut aussi garder une logique de comparaison. Si vous restaurez depuis une sauvegarde antérieure, la base revient à un état antérieur, ce qui peut être un avantage. Mais si la sauvegarde est trop ancienne, vous perdez des correctifs et vous réintroduisez peut-être un vecteur. C’est un arbitrage.
Les cibles fréquentes en audit
Sans en faire une liste exhaustive, je vérifie particulièrement:
- les utilisateurs (admins créés, comptes inconnus, rôles modifiés); les champs d’options (valeurs qui pilotent des comportements cachés, désactivation de protections, ou chemins de chargement); les contenus (pages et articles avec injections, contenus “vides” mais qui déclenchent du code via un hook ou un shortcode); les événements planifiés (cron) et traces associées.
Dans plusieurs incidents que j’ai gérés, la base de données a donné plus d’indices que les fichiers. Ce n’est pas systématique, mais c’est assez fréquent pour que l’audit après incident ne se limite pas aux dossiers.
Rechercher la persistance: comptes, hooks, planifications
La persistance est le moment où un site “revient” après nettoyage. Elle prend souvent trois formes: un accès (compte administrateur ou token), un chargement (hook qui réinjecte du code), ou une exécution planifiée (cron). L’objectif du contrôle d’intégrité est de repérer ces mécanismes et de les neutraliser durablement.
Deux signaux d’alerte qui reviennent
Premièrement, des changements “non expliqués” dans WordPress admin. Un utilisateur inexplicable, un plugin ajouté alors qu’il n’y a pas eu de ticket, une modification de thème actif. Deuxièmement, un comportement qui se reproduit au même moment: par exemple à une heure précise, ou lors d’un déclencheur (appel à une page spécifique, génération d’un sitemap, exécution d’un cron).
Pour cadrer cette recherche, j’utilise un petit set de vérifications systématiques, limité pour ne pas perdre du temps.
- Vérifier la liste des utilisateurs et l’historique des rôles pour repérer des comptes “fantômes”. Recontrôler wp-cron et les tâches planifiées, car un cron malveillant peut réinjecter. Inspecter les hooks et filtres côté thèmes et plugins (recherche de fonctions anormales, includes suspectes). Rechercher toute dépendance à un domaine ou une URL externe non documentée, surtout dans des conditions.
Le nettoyage: agir, mais sans effacer les preuves
Une fois la référence établie, on passe au nettoyage. Nettoyer un site WordPress infecté, ne veut pas dire simplement supprimer “ce qui est visible” dans le navigateur. Il faut rétablir un état fonctionnel et sain, avec un mécanisme de stabilisation.
Dans la pratique, ça implique souvent des remplacements plutôt que des retouches. Remplacer un thème ou un plugin par une version propre est souvent plus fiable que corriger à la main un fichier PHP dont vous ne connaissez pas le contexte. Pareil pour WordPress core.
Le point clé, c’est de documenter ce qui a été fait. Pas pour “faire joli”, mais pour que l’audit après incident ait un sens: vous devez pouvoir relier une modification à un résultat mesuré.
Choix techniques et compromis
Vous pouvez:
- reconstruire à partir d’une sauvegarde propre, déployer des versions propres de plugins et thèmes, nettoyer manuellement certains fichiers si vous avez une raison technique de le faire.
Le compromis typique, c’est le risque de perdre des personnalisations. Si vous avez un thème très modifié, remplacer l’intégralité peut casser la mise en page. Mais garder un thème contaminé peut coûter beaucoup plus cher à long terme. L’issue dépend de la nature de l’infection et de votre capacité à rebaser sur une version saine.
Audit après nettoyage: prouver que le problème est réellement parti
Après nettoyage, l’audit ne doit pas se limiter à “ça marche à nouveau”. Vous devez prouver l’intégrité, avant de considérer l’incident clos.
Je sépare mentalement l’audit en deux phases. La première est la vérification “internaute”, ce que voit un visiteur ou un robot de test. La seconde est la vérification “serveur”, ce que fait le site dans sa logique d’exécution.
Vérifications côté rendu et comportement
Vous testez:
- les pages concernées par l’infection, les pages qui déclenchent des scripts (accueil, pages de catégories, pages avec contenu riche), les flux (sitemap, flux RSS, endpoints connus).
Le but est de repérer les injections résiduelles, les redirections, ou les scripts qui reviennent après un certain délai.
Vérifications côté configuration et intégrité des fichiers
Côté serveur, je recommence un cycle de contrôle: comparaison des fichiers core, contrôle des thèmes et plugins, vérification de l’absence de fichiers inconnus, et rehash si vous utilisez cette méthode.
Si vous avez pu conserver une “photo” avant nettoyage, la comparaison devient très parlante. https://gardewp.fr/nettoyage-malware-wordpress/ Si un fichier suspect réapparaît, vous saurez que le problème est revenu, pas seulement masqué.
Contrôle d’intégrité: méthodes concrètes (sans jargon inutile)
Il existe plusieurs approches pour vérifier l’intégrité. Le meilleur résultat dépend de votre niveau d’accès et de votre environnement d’hébergement.
Comparaison à des sources fiables
La méthode la plus robuste consiste à comparer vos fichiers à des sources connues fiables:
- WordPress core: par version exacte; plugins et thèmes: par version exacte, idéalement via le même canal d’obtention que celui utilisé en production.
Si votre production a des montages (plugins vendus en zip interne, forks, thème sur mesure), vous devez définir ce que “connu fiable” signifie dans votre contexte.
Hashing et inventaire
Un inventaire par hash est souvent utile, surtout si vous suspectez des modifications furtives. L’objectif n’est pas de générer un rapport pour chaque fichier, mais d’identifier ce qui a changé et pourquoi.
Le piège fréquent est de recalculer les hash “après” sans refaire une étape “avant”. Si vous n’avez pas les valeurs antérieures, l’exercice devient plus interprétatif. D’où l’intérêt de figer l’état au tout début.
Logs de validation
Les logs d’accès et d’erreur peuvent confirmer ou infirmer un comportement malveillant. Un domaine externe contacté après nettoyage, ou un pattern de requêtes identique à la période de l’infection, est un signal fort.
En incident, je préfère une observation simple et répétable plutôt qu’un “rapport” qui explique tout sans être actionnable. Si vous pouvez établir “ces requêtes n’existent plus”, c’est déjà une preuve.
Comprendre les causes possibles, sans se raconter d’histoires
Dans un audit après incident, on cherche la faille, pas uniquement le symptôme. Les vecteurs les plus courants sur WordPress sont:
- identifiants compromis (bruteforce ou vol de session), plugins ou thèmes vulnérables, mauvaise gestion des permissions de fichiers, déploiements incomplets ou mises à jour non appliquées.
Le point délicat, c’est de ne pas tomber dans un récit unique trop confortable. Parfois, il y a un accès initial via un compte, puis une infection qui change de méthode. Parfois, vous avez plusieurs plugins “au point faible” sans le savoir.
Un détail qui aide beaucoup
Si vous avez des timestamps précis des modifications et des logs autour de la période d’infection, vous pouvez souvent relier l’ordre des événements. Exemple: première requête vers une page, puis ajout d’un fichier dans wp-content, puis modifications d’options. Cette chronologie aide à décider si vous êtes face à un script opportuniste, ou à une persistance construite.
Cas typique: l’infection “revient” après nettoyage
Quand un site re-s’infecte, la cause n’est pas toujours que “vous n’avez pas nettoyé”. Elle peut être que:
- les mêmes identifiants compromis continuent d’être valides, un domaine externe re-pousse du code, un plugin vulnérable réintroduit la charge, une sauvegarde restaurée est antérieure à la correction du point d’entrée.
Dans ce scénario, l’audit d’intégrité devient un outil de diagnostic. Vous regardez ce qui a changé entre l’instant où vous avez dit “terminé” et l’instant où l’incident a refait surface. En général, le delta vous mène à la cause la plus probable.
Durcir après vérification: restaurer la confiance dans la durée
Un bon audit après incident se termine rarement par “voilà, c’est propre”. Il se termine par une réduction mesurable du risque.
Je ne vais pas multiplier une checklist exhaustive, mais je peux décrire les actions qui reviennent le plus souvent après un nettoyage réussi:
- verrouiller les accès et réduire les surfaces d’administration, retirer les comptes inutiles ou inconnus, mettre à jour ce qui doit l’être, notamment plugins et thèmes, contrôler les permissions et la configuration des répertoires, installer une surveillance qui signale les changements de fichiers.
Ce dernier point est crucial. Si vous n’avez qu’une seule vérification manuelle après incident, vous êtes aveugle entre deux périodes. La surveillance transforme l’intégrité en routine, pas en événement.
Une règle que je garde en tête
Après un incident, je traite chaque “retour à la normale” comme une hypothèse, pas comme une certitude. Les infections peuvent rester dormantes puis se réactiver lors d’un changement de plugin, d’une mise à jour, ou d’un appel à un endpoint. L’audit d’intégrité après nettoyage sert justement à réduire l’espace des surprises.
Plan d’audit pratique: du avant au après, sans s’y perdre
Pour éviter que l’audit devienne un labyrinthe, je m’appuie sur un enchaînement logique. L’idée est simple: d’abord figer, puis relever, puis nettoyer, puis comparer à nouveau. Voici comment je cadre les points de contrôle essentiels, sous forme courte.
- Avant nettoyage: capturer un état de référence (fichiers et traces de base de données utiles), en ciblant la période de l’incident. Nettoyage: remplacer les composants compromis par des versions saines quand c’est possible, en documentant les actions. Après nettoyage: vérifier l’absence de persistance (utilisateurs, cron, hooks, rechargements). Validation finale: contrôler le rendu, puis recontrôler l’intégrité des fichiers et des points de configuration.
Si vous suivez cette logique, vous pouvez justifier vos décisions. Vous saurez ce que vous avez changé, sur quoi vous vous basez, et ce que vous avez prouvé.
Ce qu’il faut consigner pour les prochains audits
Un audit après incident n’est utile que si la prochaine personne (ou vous-même dans trois mois) peut relire et agir vite. Je conseille de conserver au minimum:
- la date et l’heure de détection, l’ordre des actions (nettoyage, restauration, mises à jour), les fichiers ou composants remplacés, les indices de persistance trouvés, la validation effectuée après nettoyage.
Ce n’est pas du “bureaucratique”. C’est ce qui empêche de retomber dans le même cycle, surtout quand on n’a pas le même contexte en tête.
Conclusion opérationnelle, sans slogan
Vérifier l’intégrité avant et après nettoyage, sur un site WordPress compromis, n’est pas un luxe. C’est la différence entre une réparation temporaire et une remise en état durable. Le nettoyage enlève le symptôme visible, l’audit d’intégrité prouve que la base du site n’a pas été sabotée, que les persistances ont été traitées, et que votre environnement est cohérent.
Si vous ne deviez retenir qu’une seule chose, ce serait celle-ci: sans référence avant, le “après” reste difficile à interpréter. Avec une comparaison claire, même imparfaite, vous transformez une opération urgente en processus de récupération maîtrisé. Et c’est exactement ce que vous voulez quand vous devez nettoyer site WordPress infecté, puis dormir tranquille.