Quand un site WordPress se met à faire des choses étranges, la pression monte vite. Un redémarrage ne suffit pas, les formulaires commencent à renvoyer des erreurs, et parfois des pages apparaissent avec un contenu qui n’a rien à voir avec votre activité. Dans ce moment, on veut “nettoyer”, puis on veut “comprendre”, et on oublie souvent qu’il faut surtout prouver. Un bon rapport d’incident, en particulier après un nettoyage virus WordPress, sert à deux usages très concrets: cadrer la reprise et éviter que l’histoire se répète.
Ce qui suit ne décrit pas un modèle théorique. C’est une manière de rédiger un rapport qui colle à la réalité des investigations sur WordPress, là où les causes sont rarement simples et où les décisions doivent être justifiées.
L’objectif réel d’un rapport d’incident
Un rapport n’est pas un roman technique et il n’est pas non plus un document purement administratif. Son rôle, c’est de répondre à des questions qu’un client, un responsable sécurité ou votre équipe support vont forcément poser.
- Qu’est-ce qui s’est passé, concrètement ? Quand cela a commencé, et comment s’est manifesté l’incident ? Quelles preuves ont confirmé qu’il s’agissait d’une compromission (ou pas) ? Quelles actions ont été menées pour éliminer le problème et réduire les risques ? Qu’est-ce qui reste incertain, et quelles mesures sont prises ensuite ?
Si vous écrivez pour “faire joli”, vous perdez du temps et on vous recontactera. Si vous écrivez pour documenter des décisions, vous gagnez en clarté le jour où quelqu’un devra valider la reprise ou engager des actions correctives.
J’ai vu des rapports excellents sur le plan narratif mais inutiles pour la suite, parce qu’ils n’indiquaient pas les versions exactes, les chemins de fichiers modifiés ou les logs exploités. À l’inverse, des documents plus sobres, mais précis, ont permis de retrouver une porte dérobée cachée dans un thème enfant et de corriger le point d’entrée sans refaire tout le chantier.
Avant d’écrire: sécuriser les éléments à documenter
Rédiger commence souvent trop tard. Idéalement, on collecte d’abord ce qu’on ne pourra pas reconstituer après nettoyage, puis on rédige. Sur WordPress, ce décalage est crucial: une fois que vous supprimez des fichiers ou que vous changez des identifiants, les traces disparaissent, et on se retrouve à “supposer” ce qu’on devrait “établir”.
Un incident de type virus ou webshell ne laisse pas toujours une signature nette. Parfois, le site redirige certains visiteurs vers un contenu malveillant, parfois il injecte des scripts dans des pages spécifiques, parfois il s’agit d’une augmentation de trafic étrange couplée à des erreurs de requêtes. La collecte initiale doit donc être pragmatique.
Pour éviter de griller des preuves, je vous recommande de garder une trace minimale de tout ce qui permet de “remonter” la situation, même si vous finissez par restaurer proprement.
Les éléments à joindre au rapport (sans surcharge)
Vous n’êtes pas obligé d’annexer des dizaines de pages. Mais le lecteur doit pouvoir vérifier vos affirmations. Voici une liste courte, utile dans la majorité des cas:
- captures datées des alertes (WAF, antivirus serveur, console d’administration, outils de détection) extraits de logs (au moins l’intervalle temporel pertinent, avec horodatage et source) inventaire des fichiers modifiés ou ajoutés (chemins + taille + date de modification) preuves de l’accès suspect (compte compromis, IP, user-agent, tentative d’upload, action dans wp-admin) résumé des modifications appliquées pendant le nettoyage (ce qui a été supprimé, ce qui a été restauré)
Pensez “preuve réutilisable”. Si votre rapport est relu deux mois plus tard, il doit encore avoir de la valeur.
Structure logique du rapport: de la trace à la décision
Un rapport qui marche ressemble moins à un “plan” qu’à une enquête. Vous partez de ce que vous voyez, vous remontez à ce que vous pouvez démontrer, puis vous terminez par les actions et les suites.
Une organisation efficace ressemble souvent à ceci, sans que vous soyez obligé de reprendre exactement ces intitulés.
1) Identifiants, périmètre et versions
Commencez par ce qui fixe le contexte. Trop de rapports ratent ce point et forcent ensuite le lecteur à deviner.
Indiquez:
- domaine(s) et environnement (production, staging, sous-domaines) rôle du site (blog, vitrine, e-commerce, intranet) version WordPress, thème, plugins (au moins au moment où l’incident a été constaté) type d’hébergement (partagé, VPS, cloud, présence d’un WAF) accès disponibles (FTP/SFTP, accès base de données, logs serveur, accès au DNS)
Sur WordPress, un “détail” de version peut expliquer pourquoi une faille est exploitable, ou pourquoi une procédure de restauration est compatible ou non.
2) Chronologie: la narration factuelle
La chronologie est le cœur du rapport. Elle doit être lisible et datée. On peut y intégrer des heures approximatives, mais il faut le dire. Les lecteurs veulent comprendre la cadence: alerte, premières https://gardewp.fr/nettoyage-malware-wordpress/ actions, découverte, nettoyage, tests, reprise.
Un exemple de formulation qui évite les flous: “Le 12/05 à 09:42, la console d’administration a signalé X. À 10:05, les redirections Y ont été observées sur la page Z depuis l’IP A. Le 12/05 à 11:30, un fichier inconnu a été identifié dans …”
Évitez les phrases du type “vers la fin de journée”. Si vous manquez d’horodatage précis, utilisez des fenêtres (“entre 14h et 15h”) et expliquez comment vous avez déterminé cette fenêtre (extrait de logs, timestamps de fichiers, horloge du serveur).
3) Symptômes: ce qui a été constaté
Décrivez les manifestations sans interprétation excessive. C’est la différence entre “on a vu” et “on conclut”.
Sur WordPress, les symptômes fréquents incluent:
- modifications de pages visibles (texte, liens, iframes) comportements différents selon le visiteur (cookies, IP, user-agent) injection de scripts dans l’en-tête, le pied de page, ou des champs inattendus compte administrateur nouvellement créé requêtes anormales vers wp-admin, xmlrpc.php, ou des endpoints de téléchargement hausse de 404/500, charge CPU inhabituelle, ou pics de requêtes à des moments précis
Même si votre diagnostic final est “compromission”, commencez par les symptômes. Cela aidera ensuite à justifier vos hypothèses.
4) Hypothèses et analyses: comment vous êtes arrivé à la cause
C’est là que beaucoup de rapports deviennent vagues. “Nous avons détecté un virus” n’explique rien. Le lecteur veut comprendre le fil.
Vous pouvez structurer cette partie en deux temps:
- ce que les preuves soutiennent ce que vous n’avez pas pu confirmer
Par exemple, si vous retrouvez un fichier PHP dans un dossier inattendu, expliquez:
- où il se trouvait comment il s’exécutait (incluait-il d’autres fichiers ? Appelait-il des URL externes ?) comment l’exécution se déclenchait (requête spécifique, paramètre, déclencheur par user-agent) comment vous avez confirmé que le fichier était actif (requêtes dans les logs, traces d’exécution, signature, contenu)
Si vous avez utilisé des outils (scan de fichiers, grep, vérification des hachages, analyse de base de données), décrivez le principe et les limites. Un scan peut avoir raté des éléments, mais c’est utile de dire “scan X sur l’arborescence /wp-content, complété par Y”.
L’honnêteté sur les incertitudes fait gagner du crédit. Un rapport qui cache les zones grises sera moins exploitable.
Le nettoyage proprement dit: décrire sans faire “la recette”
Le lecteur ne veut pas votre procédure minute par minute, il veut comprendre ce que vous avez fait et pourquoi cela élimine la cause.
Pour la partie “nettoyage”, privilégiez:
- les actions réalisées l’objet de l’action (qu’est-ce qui a été ciblé) la logique de validation (comment vous avez vérifié que c’était réglé)
Exemples de formulations pertinentes:
- “Remplacement des thèmes et plugins par versions identiques aux dépôts officiels, après comparaison des fichiers et purge des artefacts ajoutés.” “Suppression des scripts injectés identifiés dans wp-content et dans la base de données, suivie d’une vérification des requêtes entrantes sur l’intervalle suspect.” “Changement de toutes les identifiants des comptes ayant des rôles élevés, avec rotation des clés liées aux sessions si disponible.”
Si vous avez restauré depuis une sauvegarde, indiquez la date de la sauvegarde et la raison du choix. Une sauvegarde “propre” au bon moment peut être le meilleur scénario, mais il arrive que la compromission soit déjà présente dans la sauvegarde que vous pensiez saine. Votre rapport doit alors expliquer comment vous l’avez testée (par exemple, vérification de la présence d’artefacts connus).
Gestion des données sensibles et des accès
Même quand l’objectif est “nettoyage virus WordPress”, on touche presque toujours à des éléments sensibles: comptes, base de données, clés d’API, parfois accès serveur.
Dans le rapport, vous n’avez pas besoin de dévoiler des secrets. En revanche, vous devez montrer que vous avez géré le risque.
Décrivez:
- quelles actions d’accès ont été faites (rotation mots de passe, suppression comptes, verrouillage méthodes d’accès) si des tokens ou clés ont été changés (si votre contexte les utilise) si des exports ou copies de base ont été réalisés pour analyse (et s’ils ont été supprimés ensuite) qui avait accès aux éléments d’analyse pendant la durée de l’investigation
Une phrase simple peut suffire, par exemple: “Rotation des identifiants administrateurs et purge des sessions actives, avec revalidation d’accès depuis des comptes de test dédiés.”
Comment écrire la section “preuves”: rendre vos affirmations vérifiables
Un bon rapport donne envie de vous croire, parce qu’il fournit des points d’observation. La clé, c’est de relier chaque affirmation à une preuve.
Quelques techniques rédactionnelles qui marchent bien:
- citer un identifiant de fichier, un chemin, et un timestamp (même approximatif) mentionner un intervalle dans les logs (ex: 09:00 à 11:00) expliquer la correspondance entre symptôme et action (ex: “redirection observée après le chargement de X”) donner un exemple de requête ou de motif, sans publier de données sensibles
Si vous avez observé des indicateurs de compromission, listez-les dans le texte, pas forcément sous forme de points. L’idée est que le lecteur comprenne quoi vérifier et où.
Revue de la base de données: ce que vous devez préciser
Sur WordPress, la compromission passe souvent par:
- modifications de tables d’options ajouts d’enregistrements dans des champs de type “transients” ou options altération de structures liées aux shortcodes ou aux menus injection dans des champs de contenu (selon thèmes et plugins)
Votre rapport doit dire au minimum:
- quelles tables ou types d’enregistrements ont été contrôlés quelles modifications ont été trouvées (nature + impact) comment vous avez choisi une restauration (rollback de la base, correction ciblée, remplacement des éléments)
Je recommande de ne pas surestimer la certitude. En pratique, on peut corriger la base, mais on doit aussi se demander si l’entrée initiale est éliminée. Sinon, la base se réinfectera.
Validation: prouver que le site est “re-nettoyé”
La validation doit être une étape écrite, pas une phrase “tout fonctionne”. Sans cela, on ne sait pas si la reprise est fondée.
Décrivez:
- tests fonctionnels (connexion admin, navigation sur pages sensibles) tests de sécurité côté application (absence de fichiers suspects, vérification des intégrations) tests de conformité (rien ne réapparaît après un délai raisonnable) observation post-nettoyage (par exemple, absence de pics de requêtes sur l’intervalle critique)
Le “délai raisonnable” dépend de votre contexte. Après une modification de fichier et un nettoyage, on attend souvent un peu de temps pour voir si une tâche planifiée relance la charge ou si des injections reviennent lors de certaines conditions. Si vous avez eu un artefact déclenché par un paramètre, vous devez tester ce paramètre, sinon vous risquez de valider trop vite.
Communication: qui lit quoi, et comment le rapport est utilisé
Un rapport d’incident n’est pas uniquement pour l’équipe technique. Souvent, il sert aussi à informer un client, un directeur, ou un service légal.
Le bon réflexe est de rédiger une version “actionnable” pour ceux qui doivent décider, et une version “détaillée” pour ceux qui doivent recommencer si besoin. Si vous ne pouvez pas produire deux versions, au moins, séparez visuellement les parties: contexte, preuves, actions, suites.
Dans la partie communication, évitez les tournures qui minimisent. Les gens n’ont pas besoin d’être rassurés, ils ont besoin d’être informés correctement.
Vous pouvez mentionner:
- la durée d’indisponibilité ou l’impact (même approximatif) l’étendue (quelles URLs, quel sous-ensemble) le risque potentiel (données exposées ou non, à confirmer) les notifications effectuées si nécessaire (selon votre organisation)
Je ne vous donne pas de procédure légale, car elle dépend du pays et de votre cadre, mais je peux vous dire une chose: ne faites pas croire que tout est “certain” si vous ne l’êtes pas. Un rapport honnête est souvent moins agressif qu’un rapport trop optimiste.
Un mini modèle de formulation, prêt à adapter
Plutôt que de vous imposer un gabarit rigide, voici un exemple de sections et de phrases que vous pouvez réutiliser, en les adaptant à votre cas. L’idée est de montrer le niveau de détail attendu.
Vous pourriez écrire:
- “Le 12/05 à 09:42, le site a commencé à afficher des redirections vers une URL non liée au domaine. Les tests manuels ont confirmé le comportement depuis des navigateurs standards.” “À 10:10, nous avons identifié un fichier PHP récemment modifié dans [chemin], dont le contenu appelait [mécanisme]. Son chargement était corrélé à [élément déclencheur] observé dans les logs.” “Le 12/05 à 11:40, nous avons remplacé le thème et les plugins par des versions officielles, puis purgé les artefacts identifiés dans [zones].” “À 14:30, nous avons validé l’absence de requêtes liées au motif observé initialement, et confirmé que les pages clés répondaient sans injection.”
La différence entre ce genre de texte et une description floue, c’est que le lecteur peut “rejouer” vos étapes de vérification.
Ce que j’exigerais dans un rapport de nettoyage virus WordPress
Pour finir cette partie, je vous propose une dernière liste, courte, qui sert de garde-fou au moment de relire votre document. Si un point manque, vous aurez probablement un aller-retour avec quelqu’un.
- Un horodatage exploitable de la chronologie, même approximatif mais justifié Des preuves localisables (chemins de fichiers, extraits de logs, éléments de base de données) La cause la plus plausible, explicitée avec la chaîne preuve vers conclusion Les actions réalisées, liées à l’élimination de la cause et pas uniquement au “retour à la normale” Une validation post-nettoyage décrite, avec critères concrets de réussite
Si vous cochez ces cinq points, vous êtes déjà dans une zone confortable.
Cas concrets: deux pièges qui ruinent les rapports
Piège 1: confondre “nettoyé” et “résolu”
Un rapport peut être très précis sur la suppression de fichiers, et pourtant être incomplet sur la cause d’entrée. Par exemple, si un compte administrateur compromis a été utilisé via une authentification faible, supprimer des scripts peut suffire à faire disparaître la symptomatique, mais l’accès peut persister.
Dans ce cas, le rapport doit expliquer:
- pourquoi l’entrée a été fermée (rotation, suppression comptes, durcissement) comment vous avez vérifié que l’entrée ne redémarre pas quels points de surveillance ont été activés ensuite
Un “résolu” doit être plus solide qu’un “le site ne fait plus la redirection”.
Piège 2: ne pas distinguer les anomalies de WordPress des traces d’une attaque
WordPress peut devenir instable pour des raisons légitimes: plugin mal codé, cache mal configuré, mises à jour interrompues. Un rapport doit éviter de tout attribuer au “virus” par réflexe.
Quand c’est ambigu, vous gagnez en crédibilité en écrivant:
- ce qui ressemble à une compromission ce qui a été vérifié et n’a pas confirmé la compromission ce qui reste possible
Ce n’est pas un aveu d’impuissance, c’est une manière responsable de dire où vous en êtes.
Après le rapport: transformer l’incident en amélioration durable
Un rapport qui finit en “tout est revenu à la normale” ne sert pas assez. Les suites doivent être formulées comme des actions, pas comme des intentions.
Sans entrer dans des listes, vous pouvez décrire des axes réalistes:
- durcissement des rôles et des accès politique de mises à jour (thèmes, plugins, WordPress) supervision des intégrités (surveillance des fichiers, alertes) stratégie de sauvegardes et tests de restauration (pas juste une sauvegarde, mais une restauration testée) procédure de réponse incident plus claire pour la prochaine fois
L’objectif est simple: réduire le temps de détection, raccourcir le diagnostic et empêcher la réinfection.
Ton rapport doit pouvoir survivre au futur
Le meilleur signe que votre rapport est solide, c’est qu’il tient sans vous. Si, dans six semaines, quelqu’un doit expliquer ce qui a été fait, il doit pouvoir le faire à partir de votre texte. Il doit trouver des preuves, comprendre la logique et savoir quoi vérifier s’il revoit un symptôme similaire.
Quand le nettoyage virus WordPress est terminé, le travail “facile” est derrière vous. Le rapport est ce qui reste, et c’est souvent ce qui protège le prochain nettoyage contre les mêmes erreurs. Rédigez-le comme une enquête, pas comme un justificatif.