Analyser les journaux pour dater et comprendre un piratage WordPress

Nettoyer un site piraté sans savoir comment le pirate est entré, c'est refermer la porte sans savoir laquelle : le site sera réinfecté par le même chemin. Les journaux du serveur sont la seule trace fiable de ce qui s'est passé, chaque requête y étant inscrite avec son adresse IP, son heure, son URL et sa réponse. Ce guide complète notre guide de nettoyage d'un site WordPress piraté et les premiers réflexes après un piratage.

Où trouver les journaux de votre site WordPress

Les journaux du serveur web : access.log et error.log

Apache et nginx écrivent deux fichiers. Le journal d'accès (access.log) enregistre chaque requête reçue ; le journal d'erreurs (error.log), les erreurs du serveur et de PHP. Sur un serveur dédié ou un VPS, ils sont dans /var/log/apache2/ ou /var/log/nginx/. Les deux serveurs utilisent par défaut le même format, dit « combined », documenté par Apache :

203.0.113.42 - - [03/Sep/2026:02:14:07 +0200] "POST /wp-content/uploads/2026/08/wp-cache.php HTTP/1.1" 200 512 "-" "python-requests/2.32"

Sur un hébergement mutualisé : cPanel, o2switch, OVHcloud

Sans accès SSH, les journaux se récupèrent depuis le panneau d'hébergement.

• cPanel (o2switch et de nombreux hébergeurs) : rubrique « Mesures » puis « Accès brut ». Vous téléchargez un fichier .gz contenant le journal d'accès du domaine. Par défaut, cPanel ne garde que le journal courant et l'efface une fois les statistiques calculées, chaque jour ; cochez l'archivage en fin de mois pour conserver un historique dans le dossier logs/ de votre compte, comme le rappelle la documentation d'o2switch.
• OVHcloud : espace client, « Web Cloud », votre hébergement, onglet « Statistiques et logs ». OVHcloud sépare les journaux web, FTP, erreurs, CGI, sortants, SSH et cron, avec un différé d'environ cinq minutes.

Le debug.log de WordPress, Wordfence et les journaux d'activité

WordPress peut écrire son propre journal si la constante WP_DEBUG_LOG est activée dans wp-config.php : wp-content/debug.log. Déconseillé en production, il peut contenir des avertissements générés par le code malveillant lui-même, avec son chemin et l'heure.

Si Wordfence était installé avant le piratage, son onglet « Live Traffic » a enregistré connexions, tentatives de connexion et requêtes bloquées, avec IP et agent utilisateur ; selon la documentation de l'éditeur, 30 jours au maximum. Les journaux d'activité comme Simple History enregistrent connexions, installations d'extensions et créations de comptes, pendant 30 à 60 jours par défaut. Ces journaux vivent dans la base : un pirate avec un accès administrateur peut les effacer. Notre article sur la journalisation de l'activité WordPress compare ces outils.

Ce que l'on cherche dans les journaux après un piratage

Un journal d'accès contient des milliers de lignes par jour, surtout du bruit. On ne lit pas tout ; on cherche des signatures précises.

• Un POST vers un fichier qui ne devrait pas en recevoir. Hors wp-login.php, wp-comments-post.php, admin-ajax.php et les formulaires, un POST vers un fichier PHP inhabituel, à la racine, dans un thème, dans wp-includes/ ou dans une extension, est presque toujours un appel à une porte dérobée.
• Un fichier PHP appelé dans wp-content/uploads/. Ce dossier ne doit contenir que des médias : toute requête vers un .php qui s'y trouve, surtout en code 200, signale un webshell déposé par une faille d'envoi de fichier. D'où notre conseil de bloquer l'exécution de PHP dans uploads.
• Des rafales sur xmlrpc.php ou wp-login.php. Des centaines de POST en quelques minutes depuis quelques adresses : une force brute. Les requêtes vers /wp-json/wp/v2/users ou ?author=1 qui la précèdent sont l'énumération des comptes.
• Des paramètres étranges vers une extension précise, suivis de l'apparition d'un fichier : la faille exploitée. Les avis de Wordfence ou Patchstack décrivent souvent la requête utilisée.
• Des agents utilisateurs de scripts (python-requests, curl, Go-http-client, chaînes vides), et la même adresse IP qui revient régulièrement sur le même fichier : le pirate vérifie que sa porte dérobée répond.

Les commandes grep, awk, sort et uniq avec des exemples lisibles

Les exemples supposent un accès SSH et un journal nommé access.log. Sur un fichier téléchargé depuis cPanel, décompressez-le, ou remplacez grep par zgrep, qui lit les .gz.

Tous les POST, sauf ceux attendus, pour repérer une porte dérobée :

grep '"POST ' access.log | grep -v -E 'wp-login.php|admin-ajax.php|wp-comments-post.php|wp-cron.php' | awk '{print $4, $1, $7, $9}' | head -50

Toute requête vers un fichier PHP dans uploads, avec le code de réponse :

grep -E 'wp-content/uploads/[^ ]*\.php' access.log | awk '{print $4, $1, $6, $7, $9}'

Les adresses IP les plus actives sur xmlrpc.php et wp-login.php :

grep -E 'xmlrpc.php|wp-login.php' access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

Les agents utilisateurs les plus fréquents, pour isoler un outil d'attaque :

awk -F'"' '{print $6}' access.log | sort | uniq -c | sort -rn | head -20

Tout ce qu'une adresse suspecte a fait, dans l'ordre, puis la première apparition d'un fichier malveillant, archives comprises :

grep '^203.0.113.42 ' access.log | awk '{print $4, $6, $7, $9}'
zgrep -m1 'wp-cache.php' access.log access.log.*.gz

Les numéros de champs correspondent au format combined ; si votre hébergeur ajoute un champ en tête, décalez-les d'un cran.

Croiser avec les dates de modification des fichiers

Le journal dit quand une requête est arrivée ; le système de fichiers dit quand un fichier a changé. Les deux doivent concorder. La commande find liste les fichiers modifiés après une date (-newermt) ou dans les derniers jours (-mtime) :

find /var/www/monsite -type f -newermt "2026-08-28" -not -path "*/cache/*" -printf "%TY-%Tm-%Td %TH:%TM %p\n" | sort
find /var/www/monsite -type f -name "*.php" -mtime -10 -printf "%TY-%Tm-%Td %TH:%TM %p\n" | sort

Deux précautions. Un pirate peut falsifier la date de modification (mtime) avec touch ; la date de changement d'inode (ctime) n'est pas modifiable ainsi, et -newerct ou stat la révèlent. Et une vague de modifications à 3 h du matin peut être une mise à jour automatique : le journal tranche (appel à wp-cron.php plutôt que POST inconnu).

Pour séparer ce qui vient de WordPress.org de ce qui a été ajouté, WP-CLI compare le cœur aux sommes de contrôle officielles :

wp core verify-checksums
# Warning: File doesn't verify against checksum: wp-includes/version.php
# Error: WordPress installation doesn't verify against checksums.

Chaque fichier signalé ou inattendu est à chercher dans le journal. Pour garder cette comparaison en continu, voyez notre guide sur la surveillance de l'intégrité des fichiers WordPress.

Reconstituer la chronologie du piratage

La méthode tient en cinq étapes.

1. Partir du fichier le plus ancien. Parmi les fichiers malveillants trouvés (scanner, verify-checksums, find), prenez celui dont la date de changement est la plus ancienne : le « patient zéro ».
2. Trouver sa première trace dans le journal. Un grep -m1 sur son nom, dans les journaux courants puis archivés, donne l'heure du premier appel. Le dépôt se trouve juste avant : un POST vers une extension ou un formulaire d'envoi, quelques minutes plus tôt.
3. Isoler l'adresse IP et tout ce qu'elle a fait. Ses requêtes dans les heures précédentes montrent la reconnaissance puis l'exploitation. Le chemin et les paramètres de cette requête désignent la faille.
4. Suivre les fichiers créés ensuite. Chaque fichier ou modification postérieure est à relier à une requête : seconde porte dérobée, création d'un compte administrateur, redirections injectées, envoi de spam.
5. Vérifier l'accès aux données. Requêtes vers un fichier d'export SQL, accès à phpMyAdmin depuis l'adresse suspecte, porte dérobée qui reçoit des commandes de lecture de la base : c'est ce qui décide des obligations vis-à-vis des personnes concernées.

Le résultat tient dans un tableau daté (heure, source, événement, preuve), à conserver avec le rapport de nettoyage : énumération des comptes à 01:52, POST vers l'extension vulnérable à 01:58, apparition de wp-cache.php à 01:58 d'après son ctime, premier appel à 02:14, compte administrateur créé le lendemain.

Ce que l'analyse apporte : la faille, l'étendue, les preuves

Le premier gain est la faille exploitée. Sans elle, le nettoyage ne tient pas : le pirate, ou son script, reviendra par le même chemin. Avec elle, la correction est précise : extension mise à jour ou supprimée, identifiant FTP changé, exécution PHP bloquée dans uploads.

Le deuxième est l'étendue. La date du premier accès dit quelles sauvegardes sont saines. Les requêtes du pirate disent s'il a touché la base de données, donc si des données personnelles ont pu être lues : c'est le point de départ de vos obligations RGPD et de la notification à la CNIL. Le bilan publié par la CNIL en 2024 note un délai moyen de 113 jours entre une violation et sa détection.

Le troisième est la preuve. L'hébergeur qui a suspendu le compte veut savoir ce qui a été corrigé ; l'assureur demande la chronologie et le vecteur ; la CNIL attend la nature de la violation et les mesures prises. Un tableau daté, appuyé sur des extraits de journaux, répond aux trois. La CNIL recommande d'ailleurs, dans son guide de la sécurité, de conserver les journaux « sur une période glissante comprise entre six mois et un an ».

Les limites : rotation des journaux, hébergement mutualisé, CDN

• La rotation. Sur Debian et Ubuntu, la configuration livrée avec le paquet Apache fait tourner les journaux chaque jour et n'en conserve que quatorze : un piratage vieux de trois semaines n'a plus de trace directe. Sur cPanel, sans archivage, le journal disparaît dès le calcul des statistiques.
• L'hébergement mutualisé. Pas d'accès SSH, journaux parfois limités au domaine principal, et impossible de voir ce que font les autres sites du même compte. Notre article sur la sécurité de l'hébergement mutualisé revient sur ce cloisonnement.
• Le CDN ou le proxy. Derrière Cloudflare ou un autre proxy, le champ IP du journal contient l'adresse du proxy, sauf si le serveur est configuré pour lire l'en-tête transmis par le CDN.
• Le bruit et l'effacement. Un POST vers un fichier qui n'existe pas (code 404) n'a rien déposé : ne retenez que les requêtes réussies vers des fichiers qui existent. Et un attaquant qui obtient les droits du compte peut modifier les journaux accessibles en écriture ; ceux gérés par l'hébergeur sont plus fiables.

Si vous n'avez ni le temps ni les accès nécessaires, cette analyse fait partie de notre intervention de nettoyage : le rapport remis comprend la chronologie, la faille identifiée quand les journaux le permettent et la liste datée des fichiers touchés.

Sources

• « Log Files », documentation Apache HTTP Server 2.4, Apache Software Foundation : httpd.apache.org
• « Module ngx_http_log_module », documentation nginx : nginx.org
• « Raw Access », documentation cPanel : docs.cpanel.net
• « Logs d'accès brut », documentation o2switch, 24 avril 2025 : faq.o2switch.fr
• « Consulter les statistiques et logs d'un site web », documentation OVHcloud, 3 juin 2026 : docs.ovhcloud.com
• « Debugging in WordPress », Advanced Administration Handbook, WordPress.org : developer.wordpress.org
• « wp core verify-checksums », documentation WP-CLI, WordPress.org : developer.wordpress.org
• « Live Traffic » et « Global Options », documentation Wordfence, Defiant : wordfence.com et wordfence.com
• « Simple History », fiche de l'extension, WordPress.org, version 5.32.0 du 5 septembre 2026 : wordpress.org
• « find(1) », page de manuel Linux (findutils), man7.org : man7.org
• « apache2.logrotate », configuration livrée avec le paquet apache2 de Debian : salsa.debian.org
• « Sécurité : tracer les opérations », guide de la sécurité, CNIL, 14 mars 2024 : cnil.fr
• « Violations de données personnelles : bilan de 5 années de RGPD », CNIL, 27 mars 2024 : cnil.fr