Un site WordPress infecté ne se résume presque jamais à “une page bizarre” ou à un spam qui sort du pied de page. Le vrai point de bascule, c’est souvent l’accès non autorisé. C’est là que tout se joue, parce que l’attaque n’est pas seulement un contenu malveillant, c’est une prise de contrôle des leviers: identifiants, cookies, rôles, scripts côté navigateur, cron piégés, bases de données modifiées.
J’ai vu des cas où la page d’accueil semblait intacte, mais où des connexions inconnues étaient présentes dans les journaux applicatifs. À l’inverse, j’ai aussi vu des “défigurateurs” visibles, mais sans preuve claire d’accès, car l’infection se maintenait via des webshell ou des tâches planifiées. Identifier les accès non autorisés, c’est donc la manière la plus rationnelle de remonter la chaîne, au lieu de courir après des symptômes.
Les signes qui doivent vous mettre la puce à l’oreille
Quand un site WordPress est compromis, les traces les plus exploitables sont rarement les plus spectaculaires. Elles ressemblent plutôt à des petits écarts qui reviennent, ou à des actions impossibles à expliquer.
Par exemple:
- Un utilisateur “admin” apparaît sans que vous ayez créé de compte, ou bien un compte existant a récemment changé son mot de passe. Le tableau de bord se montre “normal”, mais vous constatez des modifications dans des fichiers qui n’auraient pas dû être modifiés depuis votre dernière mise à jour. Des requêtes sont enregistrées depuis des pays ou des plages IP que vous ne reliez à aucun de vos usages habituels. Des redirections ou du contenu en dehors de votre thème s’affichent de façon intermittente, selon l’agent navigateur ou la géolocalisation. Vous observez des pics de trafic inexpliqués, surtout sur des URLs inhabituelles, avec des codes HTTP qui ne correspondent pas à votre comportement normal.
Le piège classique, c’est de se focaliser sur l’édition visible. Un plugin malveillant peut créer un accès “discret” et ensuite piloter des injections au bon moment, ou exécuter du code seulement sur des pages spécifiques. Dans ces scénarios, l’accès non autorisé est la porte d’entrée, et l’injection n’est que la suite.
Commencer par les journaux, pas par les fichiers
Avant de “nettoyer”, l’erreur la plus coûteuse est de toucher au système trop tôt. Modifier ou supprimer au hasard des fichiers peut effacer des indices, ou rendre impossible la compréhension de comment l’intrus s’est maintenu.
Côté WordPress, vous pouvez déjà obtenir de précieux signaux via:
- les journaux d’accès à l’admin (selon votre hébergeur ou un plugin de sécurité), les logs du serveur web (Apache ou Nginx), les logs PHP, quand ils sont disponibles, et, si vous avez un pare-feu applicatif ou un WAF, les alertes associées.
Une logique simple s’impose: repérez l’instant où quelque chose d’anormal commence. À partir de là, cherchez ce qui a eu lieu dans les minutes ou heures qui précèdent. On ne remonte pas avec des hypothèses floues, on remonte avec une chronologie.
Sur un hébergement partagé, par exemple, j’ai déjà vu des attaques où le site restait visuellement correct pendant des heures, puis où l’admin était de nouveau accessible de l’extérieur. Les logs montraient alors un pattern de connexions répétées, souvent avec des tentatives de connexion à des URLs “dérivées” de WordPress (pas forcément le formulaire de login classique).
Vérifier les accès et comptes WordPress
La première source d’information, ce sont les comptes et les sessions. Même si l’attaquant a utilisé une autre voie pour injecter du code, il faut comprendre comment il a obtenu un “chemin” vers WordPress.
Ce qu’il faut contrôler côté comptes
- Les comptes utilisateurs: création récente, rôles élevés, changement d’email, champs “last login” suspects. Les événements de connexion: connexions depuis des IP inhabituelles ou à des heures qui n’ont aucun lien avec vos opérations. La présence d’utilisateurs “fantômes” qui n’ont rien à voir avec votre gestion habituelle.
Attention au cas particulier des environnements où plusieurs personnes accèdent au site. Si vous gérez le site depuis votre domicile, depuis un bureau et parfois via un VPN, l’IP peut varier. Le bon réflexe consiste à comparer les adresses avec vos schémas réels, et à regarder le “timing”: une connexion admin un mardi à 3h du matin alors que vous travaillez habituellement en journée, c’est un signal fort.
Détecter des actions irréversibles dans le tableau de bord
Même sans plugin de sécurité, https://gardewp.fr/ WordPress conserve des historiques internes utiles selon les réglages et plugins installés. Vous pouvez aussi croiser:
- les changements dans les menus et pages, les créations de brouillons qui n’émanent pas de votre équipe, les modifications de thèmes ou de fichiers de template, les nouveaux plugins activés récemment.
Un point important, souvent sous-estimé: si l’attaquant a réussi à obtenir un accès administrateur, il peut modifier des rôles, désactiver des plugins de sécurité et créer des mécanismes persistants, notamment des tâches planifiées via wp-cron ou des scripts détournés.
Exploiter les logs du serveur pour dater la compromission
Pour identifier les accès non autorisés, les logs serveur sont souvent la pièce maîtresse. L’objectif n’est pas d’examiner tout le trafic, c’est de retrouver des séquences cohérentes.
Sur Apache, vous chercherez des lignes autour de /wp-login.php, /wp-admin/, et parfois /xmlrpc.php, ainsi que des requêtes sur des fichiers qui n’appartiennent pas à WordPress. Sur Nginx, le principe est identique, mais les formats changent.
Ce que je fais en pratique:
- je repère les IP qui reviennent plusieurs fois, je note la séquence de requêtes: d’abord des essais, puis un accès réussi, puis des actions typiques (fichiers, endpoints XML-RPC, upload de contenu), je compare la chronologie avec vos événements légitimes (mise à jour de plugin, déploiement, export base de données, changement de mot de passe).
Un détail qui compte: certaines attaques “échouent” au login mais finissent par prendre le contrôle autrement. Par exemple, un outil automatisé peut chercher une faille, déposer un fichier, puis déclencher un rendu ou une exécution plus tard. Les logs peuvent alors montrer des tentatives à des endpoints inattendus, sans preuve immédiate de connexion réussie.
Les pièges courants: comment l’attaquant évite de laisser des traces
Il y a des schémas récurrents dans les compromissions WordPress.
1) Connexion via un compte déjà compromis ailleurs
Un compte admin peut être compromis non pas à cause du site, mais parce que le mot de passe a fuit ailleurs. Si vous réutilisez le même mot de passe sur d’autres services, le risque explose. Résultat: l’attaquant peut “entrer proprement” par un login, et vous n’avez qu’un historique de connexion, pas un exploit visible.
2) Exploitation XML-RPC
Beaucoup d’attaques utilisent /xmlrpc.php, car cet endpoint peut permettre des actions plus riches que le simple formulaire de login. Même si le site n’affiche rien de spécial, les logs peuvent montrer un trafic inhabituel sur cet endpoint.
3) Persistance par modification de fichiers “inoffensifs”
Une infection peut être “vivante” sans provoquer d’alerte immédiate. Un fichier modifié dans un répertoire thème ou dans un include peut rester dormant, jusqu’à ce qu’un pattern soit détecté. Dans ce scénario, les accès non autorisés ne servent pas uniquement à démarrer l’infection, ils servent aussi à maintenir la capacité de modification.
4) Session volée ou cookies
Parfois, l’intrus ne revient pas avec ses propres identifiants. Il réutilise une session existante, ou un cookie intercepté. Dans ce cas, les logs de login ne suffisent pas, car la session peut être active sans nouvel événement de connexion.
C’est pour ça qu’il faut combiner plusieurs sources: logs serveur, logs application, état des utilisateurs et, si possible, inventaire des fichiers et des tâches planifiées.
Vérifier les points de persistance les plus fréquents
Sans tomber dans une chasse exhaustive qui vous épuiserait, il faut savoir où regarder, en particulier si vous suspectez un site WordPress infecté.
Il y a des zones très souvent touchées:
- fichiers PHP ajoutés ou modifiés dans des dossiers où ils ne devraient pas être, plugins inconnus ou plugins “légitimes” remplacés, thèmes modifiés, configuration serveur ou scripts d’exécution, événements planifiés.
Les événements planifiés sont importants parce qu’ils peuvent restaurer une logique malveillante après votre nettoyage initial. Un attaquant peut aussi envoyer du spam via des formes ou des imports détournés, et déclencher ces actions à des moments précis.
Checklist immédiate pour repérer les accès non autorisés
Si vous êtes en situation de réponse rapide, l’idée est de stabiliser, dater, et collecter, plutôt que de “faire le ménage” à l’aveugle.
- Récupérer et archiver les logs serveur et applicatifs autour de la période suspecte (au moins 24 à 72 heures). Vérifier la liste des utilisateurs, rôles, dates de création et derniers identifiants de chaque compte administrateur. Contrôler les plugins et thèmes installés ou activés récemment, et comparer avec votre historique de déploiement. Forcer la réinitialisation des mots de passe des comptes à privilèges, puis invalider toutes les sessions. Inspecter les événements planifiés (wp-cron) et toute exécution automatisée récente.
Si vous manquez de temps, cette approche reste utile. Elle ne garantit pas à elle seule la détection à 100 pour cent, mais elle améliore radicalement la qualité des décisions, et limite le risque d’effacer des preuves.
Isoler l’intrusion: réinitialiser sans détruire les preuves
Quand on détecte des accès non autorisés, il faut agir vite. Mais il faut aussi éviter de casser l’enquête.
En pratique, j’encadre l’action autour de deux temps:
1) on capture ce qu’il faut, 2) on purge ce qui donne un accès.
La purge typique inclut la réinitialisation des identifiants, la révocation des sessions, et la suppression des comptes non autorisés. Si vous avez un contrôle d’accès côté hébergement, vous devez aussi vérifier les accès SSH, FTP, accès à votre panneau d’administration d’hébergement, et les clés ou utilisateurs créés récemment.
Un point délicat: invalider toutes les sessions peut interrompre vos équipes si elles sont connectées. C’est acceptable en incident, mais il faut le faire de manière coordonnée si vous travaillez en production. L’idéal est de choisir un moment où vous pouvez supporter le redémarrage de sessions et ré-authentifications.
Comment confirmer qu’un accès était non autorisé
Après nettoyage et mesures de blocage, la confirmation repose sur un faisceau d’indices cohérents, pas sur une seule preuve.
Vous pouvez considérer qu’un accès était non autorisé si plusieurs éléments s’alignent:
- une IP ou un pays incompatible avec votre organisation, une connexion à une heure anormale, un changement de rôle ou de plugin juste après la connexion, des fichiers modifiés autour de la même fenêtre temporelle, des tentatives répétées sur login, XML-RPC, ou des endpoints inhabituels.
À l’inverse, si une IP correspond à votre bureau et que l’activité suit un déploiement planifié, ce n’est pas forcément une intrusion. Le risque, c’est de confondre un changement légitime avec un comportement malveillant, et de prendre des mesures trop agressives, ce qui complique la résolution.
Exemple concret de chronologie utile
Imaginons un cas réel, typique: le site affiche des redirections vers une URL tierce pour certains visiteurs. Visuellement, rien ne semble toucher l’admin.
En ouvrant les logs serveur, vous voyez que, la veille au soir, plusieurs requêtes ont ciblé /xmlrpc.php depuis une même IP. Le lendemain, au même moment, vous constatez qu’un plugin récemment installé, portant un nom presque banal, est activé. Puis, dans les fichiers, un modèle de thème a été modifié avec une fonction inconnue.
Dans ce scénario, l’accès non autorisé n’est pas une “simple tentative de login”. C’est un enchaînement: exploration via XML-RPC, activation plugin, persistance par modification de thème, puis exploitation via injection ou redirection. Même sans voir un login direct dans les logs, la chronologie confirme une intrusion.
C’est exactement ce que vous cherchez à construire: des liens temporels entre accès, modification et effet visible.
Après la suppression: empêcher le retour
Quand vous êtes certain d’avoir retiré le vecteur d’accès, il reste une étape indispensable: empêcher l’attaquant de revenir, soit avec les mêmes identifiants, soit via une même faiblesse.
Voici les actions à privilégier, sans viser la perfection absolue, mais avec une logique solide:
- Mettre à jour tout ce qui peut l’être, WordPress, thèmes, plugins, et dépendances côté serveur. Désactiver ou supprimer les plugins inutiles, surtout ceux qui n’ont pas été maintenus. Renforcer la protection du login: limitation de tentatives, blocage par IP en cas d’abus, et idéalement validation renforcée. Vérifier les permissions fichiers, répertoires, et éviter les écritures trop permissives qui facilitent la persistance. Mettre en place une surveillance régulière: alertes sur création d’utilisateurs, activation de plugins, changements de fichiers et nouveaux scripts.
Si vous devez n’en faire qu’une tout de suite, faites la combinaison “mot de passe + sessions + comptes + mise à jour”, puis sécurisez le login. Les incidents se répètent rarement parce que “l’infection revient toute seule”. Elle revient parce qu’un mécanisme de porte reste ouvert.
Cas particuliers à connaître avant de conclure trop vite
Il y a quelques situations qui peuvent donner l’impression d’une intrusion, alors que c’est autre chose.
- Mises à jour automatisées: certains hébergeurs et outils déploient automatiquement des mises à jour. Les timestamps de fichiers et l’activation de plugins peuvent être légitimes. Plugins de cache et optimisation: certains outils réécrivent des fichiers ou ajoutent des règles. Ce n’est pas automatiquement malveillant, mais il faut comparer avec votre base actuelle et votre historique. Migration de site ou restauration: une restauration partielle peut réintroduire une partie d’une infection plus ancienne. Si vous avez une sauvegarde, comparez sa date avec le moment où les symptômes ont commencé. Modifications de rôles par un outil de gestion: un outil CRM ou un système d’accès peut créer des comptes pour des intervenants. L’important est de vérifier l’origine.
Le bon réflexe est de garder votre chronologie: qui a fait quoi, quand, et via quel outil ou quelles adresses. Sans cela, vous risquez de confondre cause et conséquence.
Mettre en place une routine d’audit, sans y passer vos week-ends
Après un incident, vous avez tendance à tout vérifier en profondeur. C’est normal, mais si vous n’organisez pas un suivi, vous retomberez dans la réaction.
Une routine efficace ressemble à ceci: un audit court, répété. Elle s’appuie sur des indicateurs concrets, pas sur une peur vague.
Si vous gérez plusieurs sites, vous pouvez standardiser l’observation: même fréquence, mêmes points de contrôle. Par exemple, surveiller chaque semaine la création de comptes admin, les changements de plugins et le statut des mises à jour. Une alerte sur la moindre divergence vaut plus qu’une inspection longue une fois par mois.
Et surtout, documentez vos propres opérations. Quand vous avez une mise à jour le mardi matin, notez-la. Quand vous changez un mot de passe admin, notez-le aussi. Pendant un incident, ce journal personnel devient un outil d’enquête, pas juste une habitude.
Quand faire appel à quelqu’un, et pourquoi
Il y a un moment où l’investigation dépasse vos ressources, ou où le risque augmente. C’est le cas si:
- le site reste instable après un premier nettoyage, vous observez des réinfections très rapides, vous n’avez pas accès aux logs nécessaires, le serveur a des signes d’altération plus larges que WordPress (fichiers système, tâches d’arrière-plan), vous devez restaurer sans interruption avec une preuve acceptable pour votre activité.
Dans ces situations, un prestataire peut accélérer la recherche de vecteurs de persistance. Mais même avec un expert, votre rôle reste important, notamment pour fournir l’historique: dates de déploiement, changements récents, accès administratifs, et toute alerte antérieure.
Réponses rapides, décisions sûres
Identifier les accès non autorisés sur un site WordPress infecté, ce n’est pas seulement “trouver l’intrus”. C’est construire une logique de cause à effet: où l’attaque a pris pied, comment elle a obtenu les droits, et comment elle s’est maintenue.
Quand vous abordez l’incident de manière chronologique, à partir des journaux et des comptes, vous évitez la spirale “nettoyer puis découvrir que https://gardewp.fr/nettoyage-malware-wordpress/ tout revient”. Vous gagnez du temps, vous réduisez les erreurs, et vous pouvez ensuite renforcer la prévention avec des mesures ciblées.
Si vous voulez, décrivez votre situation (type d’hébergement, symptômes visibles, et ce que vous avez déjà observé dans les logs). Je peux vous aider à interpréter les indices et à prioriser les vérifications, sans partir dans une chasse aux fichiers au hasard.