WordPress piraté : derrière le site défiguré, un serveur compromis

Le site WordPress est défiguré. C’est le symptôme qui déclenche l’intervention en urgence. Il s’agit d’un staging, l’environnement où l’on prépare les changements avant de les envoyer en production. On pourrait commencer par remettre la bonne page en ligne. Mais jusqu’où les attaquants sont-ils entrés ?

Derrière ce WordPress piraté, l’enquête retrouve plusieurs portes dérobées, des données récupérées et un mineur dissimulé sur le serveur. Les droits du compte web ouvrent un périmètre bien plus large que celui du site. La machine héberge aussi d’autres services et des échanges la relient à la production.

Pour comprendre pourquoi cet incident a imposé une reconstruction, il faut suivre cette extension du périmètre : de la page visible aux accès laissés aux attaquants, puis à ce que ces accès permettaient d’atteindre. Ce récit anonymisé reprend les constats par gravité croissante, sans reproduire l’ordre des découvertes. Il prolonge Failles en cascade avec le cas d’un service secondaire dont la compromission engageait toute une machine.

Une faille majeure du cœur de WordPress permettait d’exécuter du code à distance sans se connecter. Pas besoin d’une extension vulnérable ni d’un mot de passe volé : une installation standard d’une version concernée suffisait. Searchlight Cyber a décrit cette chaîne, baptisée wp2shell.

WordPress publie le correctif et déclenche des mises à jour forcées sur les installations compatibles. La course commence aussitôt. ELLIO observe les premières sondes sur son réseau de leurres dès le lendemain, puis une campagne massive en moins de deux jours après la publication du correctif. Le repérage des sites et les tentatives d’exploitation circulent déjà à grande échelle.

La chaîne s’automatise. Des outils testent les cibles, cherchent à récupérer des données et tentent d’installer un accès durable. Elastic a exécuté en laboratoire un outil public qui enchaîne l’exploitation, le dépôt d’une extension et l’exécution de commandes. Un site de préparation accessible sur Internet entre dans le même champ de recherche qu’un site public.

Dans notre cas, la production avait appliqué le correctif avant les premières tentatives conservées dans ses journaux. La bascule vers la version corrigée y est visible et concorde avec une mise à jour automatique. Le staging, lui, a été compromis. La raison de son retard de mise à jour reste inconnue. Cette différence a compté : le correctif avait fermé la faille en production avant l’arrivée des attaques observées.

Sur le staging, des comptes administrateurs ont été ajoutés par l’attaque. Les intrus disposaient donc d’identifiants pour revenir par l’administration du site. Des extensions malveillantes leur offraient d’autres accès, au milieu des composants légitimes de WordPress.

Des scripts de commande à distance avaient aussi été déposés. Ces portes dérobées permettent de faire exécuter des instructions par le serveur web : lire des fichiers, en écrire d’autres, lancer des programmes avec les droits de ce compte. Certaines étaient cachées dans des sous-répertoires ou sous des apparences de fichiers ordinaires. Retirer une extension pirate ne suffisait pas à supprimer tous les chemins d’entrée.

Les données avaient elles aussi été atteintes. Les traces documentaient la récupération du fichier de configuration, qui contient les accès à la base, ainsi qu’une extraction SQL. Le problème ne se limitait plus à ce que les visiteurs voyaient. Des informations avaient été récupérées, et les secrets présents dans la configuration devaient être renouvelés.

Remettre la page en état aurait laissé des comptes utilisables, du code capable de recevoir des commandes et des accès aux données déjà exposés. Même après une mise à jour, une porte dérobée conserve son utilité : l’attaquant n’a plus besoin d’exploiter la faille initiale pour revenir. L’intervention devait chercher ces accès et examiner ce qu’ils avaient permis de faire.

Un autre usage de la machine apparaît : elle a servi à miner de la cryptomonnaie. Le logiciel retrouvé est XMRig, un mineur de Monero. Il fonctionnait sous le compte du serveur web et utilisait les ressources du serveur au bénéfice des attaquants.

Son installation cherchait à se fondre dans le système. Les fichiers étaient dissimulés dans un répertoire caché au nom évoquant un service système, lui-même prolongé par un sous-répertoire caché. Des noms de cache et de bibliothèque rendaient l’ensemble moins voyant. Les dates de modification avaient été falsifiées pour faire paraître les fichiers plus anciens que leur dépôt.

Le mineur disposait aussi d’un mécanisme de relance. Une tâche planifiée appelait un script de surveillance toutes les cinq minutes. Arrêter un processus isolé laissait donc en place ce qui pouvait le redémarrer. Les journaux conservés attestent un fonctionnement prolongé sur plusieurs semaines : le serveur avait eu le temps de travailler pour d’autres que ses utilisateurs légitimes.

Cette présence élargissait encore l’enquête. Il fallait examiner les tâches planifiées et les fichiers hors de WordPress, jusque dans les répertoires temporaires du système. Les différentes intrusions ne peuvent pas être attribuées à un seul acteur ; elles ont en revanche laissé sur la même machine plusieurs moyens de l’utiliser et d’y revenir.

Le point le plus dangereux était dans les droits du compte web. Celui qui exécutait WordPress appartenait à un groupe donnant accès au moteur de conteneurs. Avec cet accès, il est possible de lancer un conteneur qui accède aux fichiers de l’hôte et d’en prendre le contrôle. Une exécution de code dans le site pouvait ainsi dépasser les limites de WordPress.

L’enquête n’a pas établi de prise de contrôle root, le compte administrateur du système. Mais une compromission était avérée et le compte utilisé disposait d’un chemin vers le contrôle de l’hôte. Dans ces conditions, toute la machine devait être traitée comme compromise et reconstruite. Retirer les seuls fichiers identifiés ne permettait plus de lui confier à nouveau des services et des secrets.

D’autres services partageaient cet hôte. Leurs fichiers, leurs configurations et les secrets accessibles avec les droits obtenus entraient dans le périmètre à examiner. Le staging avait beau servir à préparer un site, ses permissions l’avaient placé à proximité de ressources qui dépassaient largement cet usage.

Il existait aussi une voie vers la production : les synchronisations de fichiers et de bases de données. Des transferts depuis l’environnement de staging vers la production étaient documentés. Si une synchronisation emporte un fichier malveillant ou un compte administrateur ajouté dans la base, elle peut transporter la compromission avec les changements attendus. Le serveur de destination n’a alors pas besoin d’être encore vulnérable à la faille initiale.

La production corrigée restait donc exposée à ce mécanisme. Les contrôles réalisés n’ont pas établi de contamination par cette chaîne. Il fallait néanmoins examiner les échanges, les états transférés et les accès utilisés pour les autoriser. La frontière entre préparation et production dépendait aussi de ce qui pouvait la traverser.

La réponse a mobilisé de nombreuses personnes. Il fallait préserver les éléments utiles à l’enquête, fermer les accès dangereux, maintenir les services légitimes et préparer la reprise. Les preuves ont été conservées avant les retraits. La machine a été réinstallée, les sauvegardes examinées et les secrets renouvelés.

L’ordre de ces opérations compte. Une sauvegarde peut contenir les mêmes fichiers malveillants que le site que l’on vient de retirer. Un secret neuf placé sur une machine encore compromise peut être récupéré à son tour. La reprise a donc associé le choix des éléments restaurés, un système réinstallé et la rotation des accès, au lieu de remettre simplement l’ancienne arborescence en ligne.

La reconstruction a aussi changé les frontières. L’organisation par environnement et par site, avec des serveurs affectés, réduit le périmètre partagé. Les comptes SQL sont limités à la base du site. Les droits accordés aux comptes de service sont revus pour éviter qu’un accès web donne le contrôle de l’hôte. Les échanges avec la production font partie de cette revue : leurs identifiants et les contenus qu’ils transportent engagent la sécurité du service de destination.

Le staging est désormais protégé par une authentification HTTP. Les chemins sensibles, dont les configurations et sauvegardes, font l’objet de refus explicites ; disposer d’identifiants valides ne donne pas accès à ces fichiers. Les scripts sont interdits dans les répertoires concernés. Les parcours d’administration et de téléversement ont été vérifiés après ce durcissement pour préserver les usages nécessaires.

La maintenance produit maintenant des traces consultables. Un ordonnanceur système la déclenche sous compte de service, avec un verrou contre les exécutions simultanées, des erreurs journalisées et une date de dernière réussite. De vrais déclenchements planifiés ont été observés. Le cœur de WordPress et les extensions et thèmes éligibles du dépôt officiel sont couverts ; les composants privés et premium demandent leur propre suivi. La surveillance d’une absence de réussite reste à raccorder et à vérifier.

Les réglages sont décrits avec Terraform et Ansible, les versions d’exécution ont été modernisées, et les relances contrôlées sur les staging n’ont produit aucun changement. L’équipe dispose ainsi d’une configuration qu’elle peut reproduire et examiner. Cette mobilisation collective a permis de sortir de l’urgence avec une infrastructure reconstruite et une politique de sécurité reprise en profondeur.

Pour un dirigeant, ce cas donne une autre manière de regarder les services secondaires : quels accès ouvrent-ils, que peuvent-ils envoyer en production, et quelle preuve récente montre que leur maintenance fonctionne ? Un diagnostic technique et organisationnel aide à établir les réponses manquantes. La sécurité applicative et opérationnelle consiste ensuite à entretenir ces frontières, y compris pour un site dont l’indisponibilité semblait peu coûteuse.