Remettre un site WordPress en état après un piratage

01

Garder du recul sous la pression

La documentation officielle de WordPress reconnaît le stress et le sentiment de vulnérabilité que peut provoquer un piratage. Elle recommande de retrouver son calme et de documenter la situation. À l’échelle des crises cyber, l’ANSSI souligne aussi que l’incertitude complique la prise de décision alors même qu’il faut agir rapidement.

Dans ce contexte, l’envie de tout supprimer ou d’appliquer immédiatement une procédure est compréhensible. Pourtant, une action mal comprise peut effacer une trace utile, casser le fonctionnement du site ou laisser en place ce qui entretient l’infection. Multiplier les changements rend aussi leur effet plus difficile à évaluer.

La maîtrise de soi fait partie du travail d’intervention. Elle s’appuie sur des moyens concrets : poser les faits par écrit, hiérarchiser les urgences, noter chaque action et contrôler son résultat. Savoir demander un second regard ou passer le relais quand le périmètre dépasse ses compétences en fait également partie.

02

Comprendre les actions avant de les exécuter

Intervenir demande une connaissance de WordPress et de son environnement : fichiers du logiciel, thème, extensions, base de données, comptes, tâches planifiées et droits d’accès. Il faut pouvoir distinguer ce qui appartient au fonctionnement attendu du site de ce qui a été ajouté ou modifié sans autorisation.

Une consigne trouvée en ligne doit être comprise et replacée dans ce contexte. Que va-t-elle modifier ? Sur quel périmètre ? Quelle conséquence peut-elle avoir sur le site et les preuves conservées ? Comment vérifier son effet ? Tant que ces points restent obscurs, il manque une base pour l’appliquer sereinement.

Consulter la documentation officielle, comparer les fichiers avec une référence fiable et relire le code suspect font partie de cette analyse. Un outil de détection fournit des indices ; son résultat demande une interprétation. La méthode doit pouvoir évoluer à mesure que l’on comprend la compromission.

03

Établir les faits et conserver les traces

Dans cette intervention, l’examen a confirmé des comptes administrateurs non autorisés et des fichiers malveillants. J’ai conservé les preuves de l’intrusion et réalisé des sauvegardes avant les opérations importantes, pour garder une trace de l’état rencontré.

Une copie prise après un piratage peut contenir l’infection. Elle reste utile pour l’analyse, mais ne garantit pas une restauration saine. Il faut savoir ce que contient chaque sauvegarde avant de la réutiliser.

Préserver les traces doit s’articuler avec la limitation d’une attaque encore active. Selon le diagnostic, restreindre des accès ou isoler le site avec l’hébergeur peut être urgent. Prendre du recul sert à choisir cet ordre d’intervention.

04

Comprendre pourquoi les fichiers reviennent

Le logiciel malveillant, ou malware, comportait un mécanisme de persistance : de quoi maintenir des fichiers en place malgré leur suppression ou leur modification. La comparaison du code altéré avec sa version d’origine montrait plusieurs moyens prévus pour cela.

• Conserver des copies de plusieurs fichiers dans un autre emplacement du serveur.
• Vérifier leur présence et leur contenu, puis rétablir la copie lorsqu’un fichier avait disparu ou changé. Une correction pouvait ainsi être annulée.
• Chercher à répéter cette vérification par les tâches planifiées de WordPress.
• Rétablir des droits limitant l’écriture et conserver les dates de modification des fichiers copiés. Cela pouvait compliquer les corrections et rendre un simple tri par date trompeur.

05

Nettoyer, puis vérifier dans la durée

J’ai traité les mécanismes identifiés, supprimé les fichiers et comptes concernés, puis contrôlé leur non-réapparition lors des vérifications réalisées. Le travail consistait à comprendre les liens entre les éléments présents sur le site et à vérifier l’effet du nettoyage.

Ce mécanisme de persistance reste distinct de la porte d’entrée initiale. Identifier du code malveillant ne prouve pas comment l’intrusion a commencé. Une cause doit être étayée ; lorsqu’elle reste incertaine, le rapport doit le dire.

La remise à niveau de WordPress et de son environnement a complété ce travail. Elle réduit l’exposition liée aux composants dépassés, mais ne constitue pas, à elle seule, une preuve de nettoyage. Les contrôles doivent se poursuivre après les premières corrections.

06

Rétablir le fonctionnement et accompagner les accès

Les personnes qui administrent le site doivent pouvoir reprendre leur travail. J’ai confirmé cette possibilité tout en poursuivant le suivi des accès. Une page qui s’affiche correctement reste toutefois insuffisante pour conclure sur la sécurité de tout le système.

J’ai demandé le renouvellement des mots de passe administrateurs, recueilli les confirmations et supprimé un accès devenu inutile. J’ai également fourni une procédure de double authentification et accompagné les questions liées à son activation.

Envoyer une procédure ne signifie pas que tous les comptes sont protégés. Il faut distinguer ce qui est proposé, en cours et vérifié. La reprise des accès doit aussi couvrir le périmètre concerné, dont l’hébergement et les sessions déjà ouvertes lorsque nécessaire.

07

Laisser un compte rendu et organiser la suite

J’ai transmis un rapport décrivant les constats, les opérations réalisées et les mesures encore prévues. Une surveillance a été mise en place. Le client pouvait distinguer le travail terminé des actions qui demandaient un suivi.

Le compte rendu doit préciser les limites des vérifications. L’absence de signe observé de vol de données ne permet pas, par exemple, d’affirmer qu’aucune donnée n’a été consultée.

Après une telle expérience, la confiance se reconstruit avec des éléments vérifiables : comprendre ce qui a été corrigé, savoir ce qui reste à contrôler et disposer d’un suivi. La connaissance technique, la documentation, le recul et la communication rendent cette reprise possible.