Un site WordPress compromis peut retrouver une apparence normale tout en conservant un accès malveillant. Sur le site client qui sert de cas concret ici, plusieurs extensions obsolètes et des mots de passe trop faibles ont conduit à contrôler les fichiers, les comptes, les sauvegardes et les accès techniques avant toute remise en production.
Conserver l’état compromis avant de toucher aux fichiers
Lors du premier contrôle du site client, la priorité n’était pas de supprimer immédiatement tout élément inhabituel. Une copie complète devait d’abord conserver l’état du site tel qu’il avait été découvert.
Cette copie comprend les fichiers WordPress et la base de données, qui contient notamment les contenus, les comptes utilisateurs et une partie importante de la configuration.
Le Centre national pour la cybersécurité recommande également de rechercher le code malveillant, de mettre à jour le système concerné et de renouveler les accès après une compromission.
La sauvegarde de l’état infecté ne doit jamais servir directement à remettre le site en ligne. Elle constitue une preuve technique et un point de comparaison pour les investigations.
Vérifier WordPress avant les extensions
Le cœur de WordPress doit ensuite être comparé à une installation saine. Un fichier portant un nom habituel n’est pas nécessairement fiable après un piratage.
Cette vérification permet d’identifier des fichiers modifiés ou ajoutés dans des répertoires qui devraient normalement contenir uniquement les composants officiels du CMS. CMS signifie système de gestion de contenu, c’est le logiciel qui permet d’administrer le site.
Les fichiers du cœur peuvent être remplacés par ceux d’une version officielle propre lorsque leur intégrité ne peut plus être garantie.
Le fichier wp-config.php demande un traitement différent. Il contient des paramètres propres au site et ne doit pas être écrasé sans vérification préalable.
Les extensions obsolètes augmentent la surface à contrôler
Le site client possédait plusieurs extensions qui n’étaient plus à jour. Ce constat ne prouve pas qu’une extension précise a permis l’intrusion, mais chaque composant ancien ajoute du code qui doit être vérifié.
Une extension désactivée reste présente physiquement sur le serveur. Si elle n’est plus utilisée, la supprimer réduit le nombre de fichiers à maintenir.
La documentation officielle de WordPress recommande de maintenir le logiciel et ses composants à jour, mais aussi de limiter les extensions aux éléments réellement nécessaires au fonctionnement du site.
Les thèmes suivent la même logique. Conserver plusieurs anciens thèmes uniquement parce qu’ils sont désactivés ne présente aucun intérêt opérationnel.
Une mise à jour ne remplace pas le nettoyage
Installer toutes les dernières versions constitue une étape nécessaire, mais cela ne supprime pas automatiquement les fichiers ajoutés pendant une attaque.
Prenons un cas pratique. Une extension vulnérable est mise à jour après l’intrusion, mais un script malveillant a déjà été copié dans un autre dossier du serveur.
La faille initiale est alors corrigée. Le fichier introduit auparavant reste pourtant disponible.
Le nettoyage doit donc distinguer deux opérations. La mise à jour ferme des vulnérabilités connues, tandis que l’analyse recherche les modifications déjà réalisées sur l’installation.
Confondre ces deux tâches peut laisser une porte secondaire ouverte.
Les comptes administrateurs doivent être vérifiés individuellement
Le contrôle du site client ne s’est pas limité aux fichiers. Les utilisateurs disposant de droits élevés devaient également être examinés.
Chaque compte administrateur doit correspondre à une personne ou à un besoin technique identifié. Un compte inconnu mérite une vérification de son origine avant suppression lorsque des journaux sont encore disponibles.
Les droits doivent aussi correspondre aux tâches réelles.
Une personne chargée uniquement de rédiger des pages n’a généralement pas besoin de pouvoir installer une extension ou modifier des réglages sensibles.
Réduire les permissions limite les dégâts possibles lorsqu’un identifiant est compromis.
Les mots de passe faibles doivent disparaître partout
Plusieurs accès du site client utilisaient des mots de passe qui n’offraient pas un niveau de protection suffisant.
Le changement ne doit pas concerner uniquement le compte WordPress. Un site peut également dépendre d’identifiants distincts pour l’hébergement, le transfert de fichiers, la base de données ou l’accès au serveur.
Chaque mot de passe doit être unique. Réutiliser le même secret sur plusieurs services transforme la fuite d’un seul compte en risque pour l’ensemble de l’environnement.
Un gestionnaire de mots de passe permet de générer et conserver des identifiants longs sans avoir à les mémoriser.
Lorsque l’hébergeur le permet, l’authentification à deux facteurs ajoute une seconde vérification au mot de passe.
Les anciennes sessions doivent être coupées
Modifier un mot de passe ne ferme pas forcément toutes les sessions déjà ouvertes.
WordPress utilise des clés de sécurité dans son fichier de configuration afin de protéger certaines informations de session. Leur renouvellement oblige les utilisateurs déjà connectés à s’authentifier de nouveau.
Cette opération devient pertinente lorsqu’un attaquant a pu récupérer une session valide.
Elle doit être réalisée avec soin dans wp-config.php. Une erreur dans ce fichier peut rendre le site inaccessible.
Après le renouvellement, les personnes légitimes se reconnectent simplement avec leurs nouveaux identifiants.
Les dossiers de médias peuvent cacher du code inattendu
Le dossier qui contient les images et documents téléchargés depuis WordPress mérite lui aussi une inspection.
Un site classique peut accumuler des milliers de fichiers dans cet emplacement. Cette quantité rend les éléments inhabituels plus faciles à dissimuler.
Un script PHP trouvé au milieu de fichiers JPEG, PNG ou PDF demande par exemple une analyse. PHP est le langage exécuté côté serveur par une grande partie de WordPress.
Cette présence ne doit pas être supprimée automatiquement sans comprendre son origine. Certains plugins génèrent leurs propres fichiers.
Le contexte compte donc autant que l’extension du fichier.
Les dates de modification aident à reconstruire l’incident
Comparer les dates des fichiers peut révéler une série de modifications intervenues pendant une même période.
Supposons qu’une dizaine de scripts soient modifiés en quelques minutes alors qu’aucune maintenance n’était prévue. Ce regroupement fournit un indice utile pour cibler l’analyse.
L’horodatage ne constitue toutefois pas une preuve absolue. Il peut être modifié et certains outils légitimes changent plusieurs fichiers en même temps.
Le contrôle doit croiser plusieurs éléments, notamment le contenu du fichier, son emplacement et sa présence attendue dans l’installation.
Cette approche évite de supprimer un composant légitime simplement parce qu’il possède une date inhabituelle.
Une sauvegarde récente peut déjà être infectée
La date de découverte de l’attaque ne correspond pas forcément à la date de la première intrusion.
Imaginez une infection détectée vendredi. Si l’accès initial remonte au lundi précédent, la sauvegarde du jeudi contient probablement déjà les modifications malveillantes.
Restaurer cette copie replacerait alors le problème en production.
Une ancienne sauvegarde peut néanmoins servir de comparaison. Un fichier présent aujourd’hui mais absent d’une version antérieure mérite une attention particulière.
Une fois le site nettoyé, une nouvelle sauvegarde saine doit être créée et stockée séparément de l’installation active.
Le poste utilisé pour administrer WordPress compte aussi
Changer tous les identifiants depuis un ordinateur compromis peut annuler une grande partie du travail réalisé.
Si un logiciel malveillant récupère les mots de passe saisis sur le poste d’administration, les nouveaux accès peuvent être exposés quelques minutes après leur création.
Les ordinateurs utilisés pour gérer WordPress doivent donc être contrôlés lorsque le vol d’identifiants reste une hypothèse plausible.
Le système d’exploitation, le navigateur et les logiciels courants doivent recevoir leurs correctifs.
Cette étape élargit la sécurité WordPress au-delà de l’hébergement. Le site peut être correctement configuré tout en restant vulnérable à cause d’un poste de travail compromis.
Erreurs à éviter après la remise en ligne
Une page d’accueil qui fonctionne normalement n’indique pas que l’incident est terminé.
La première erreur consiste à garder des extensions inutilisées parce qu’elles sont désactivées. La deuxième consiste à restaurer une sauvegarde sans savoir si elle est antérieure à l’infection.
Réutiliser les anciens mots de passe pose le même problème. Conserver un administrateur dont personne ne connaît l’origine doit également déclencher une vérification.
Une autre erreur fréquente consiste à vouloir attribuer l’attaque à une cause unique sans preuve.
Sur le cas client, les extensions obsolètes et les mots de passe faibles étaient des problèmes réels. Aucun de ces éléments ne pouvait pourtant être désigné comme point d’entrée certain sans données techniques supplémentaires.
Checklist avant de remettre le site en production
La remise en ligne doit suivre une vérification complète, pas simplement la disparition du symptôme visible.
La checklist peut tenir en dix points
- conserver une copie de l’état compromis
- vérifier les fichiers du cœur WordPress
- mettre à jour les composants nécessaires
- supprimer les extensions et thèmes inutiles
- contrôler tous les comptes administrateurs
- renouveler les identifiants potentiellement exposés
- invalider les anciennes sessions
- inspecter les fichiers inhabituels
- vérifier la sauvegarde destinée à la restauration
- créer une nouvelle sauvegarde après nettoyage
Le dernier contrôle concerne les jours qui suivent la réouverture. Les nouvelles créations de comptes, modifications inattendues de fichiers ou connexions inhabituelles doivent être examinées rapidement.
La prochaine étape consiste à attribuer à chaque point de cette checklist un statut précis, vérifié, corrigé ou non applicable. Le site peut revenir en production uniquement lorsque les éléments critiques ont été traités et que les incertitudes restantes sont documentées.
Français 
Deutsch