MU-plugins malveillants : quand le malware WordPress se cache de l'administrateur

Le pire piratage n’est pas celui qui casse votre site. C’est celui qui le laisse fonctionner normalement pendant qu’il opère dans l’ombre. J’ai été appelé pour un site WordPress dont le tableau de bord paraissait presque sain — juste quelques menus disparus, un comportement bizarre. En surface, rien d’alarmant. En profondeur, une compromission parmi les plus soignées que j’aie eu à traiter.

Ce cas mérite d’être raconté, parce qu’il illustre une réalité que beaucoup ignorent : le malware WordPress moderne ne se contente plus d’infecter, il se cache — et il se cache précisément des endroits que vous regardez.

Le symptôme trompeur : un tableau de bord qui ment

Les premiers signes étaient déroutants. Des menus d’administration avaient disparu. Des comptes administrateurs légitimes avaient été supprimés — pas ajoutés, supprimés, pour verrouiller les vrais propriétaires hors de leur propre site. Et l’utilisateur encore actif se retrouvait avec un rôle réduit, à peine « auteur », là où il aurait dû être administrateur.

Ce genre de tableau raconte une chose : l’attaquant ne cherchait pas à faire du bruit. Il cherchait à rester, discrètement, en gardant le contrôle tout en donnant l’illusion d’un site à peu près normal. Pour comprendre ce qui se passait, il fallait sortir du tableau de bord — parce que c’est justement là qu’on ne voit rien.

Où le malware se cachait vraiment

En inspectant le site en profondeur, en ligne de commande et fichier par fichier, la mécanique est apparue. Elle reposait sur plusieurs cachettes, toutes choisies pour échapper à l’œil de l’administrateur.

Les MU-plugins. Les « must-use plugins » sont une catégorie particulière d’extensions WordPress : elles se chargent automatiquement, ne peuvent pas être désactivées depuis l’interface, et n’apparaissent pas dans la liste habituelle des plugins. Un endroit idéal pour se cacher. J’y ai trouvé des fichiers malveillants aux noms anodins — des « workers » qui n’avaient rien à faire là, et dont le rôle était d’entretenir la porte dérobée.

Un outil légitime détourné. L’attaquant avait exploité une extension de maintenance connue et parfaitement légitime pour masquer certains plugins à l’administrateur. Autrement dit : même en regardant sa liste d’extensions, le propriétaire ne pouvait pas voir les plugins malveillants, parce qu’un autre plugin les rendait invisibles. Le camouflage utilisait un outil de confiance comme couverture.

Un faux dossier de sécurité. Toujours dans le registre du déguisement, un faux répertoire imitait le nom d’un composant de pare-feu réputé. Qui irait suspecter un dossier qui porte le nom d’un outil de sécurité ? C’est précisément le raisonnement de l’attaquant.

Un fichier de thème piégé. Le fichier JavaScript de rendu du thème — un frontend.js d’apparence ordinaire — chargeait discrètement une ressource distante depuis un domaine externe hébergé sur une plateforme d’edge. Ce type de chargement à distance permet à l’attaquant de modifier son code malveillant à tout moment, sans jamais retoucher votre site. Le fichier a été supprimé, le chargement distant coupé.

Comment on reprend le contrôle d’un site verrouillé

Le premier défi, quand les comptes admin ont été supprimés, c’est de rentrer. On ne peut pas nettoyer un site auquel on n’a plus accès en tant qu’administrateur.

La porte de service, ici, c’est justement le mécanisme des MU-plugins — le même que l’attaquant a utilisé contre le site. En déposant un must-use plugin temporaire, on peut recréer un compte administrateur de confiance et reprendre la main. Une fois l’accès rétabli, le nettoyage peut commencer, dans un ordre précis.

On supprime le compte pirate. On retire les MU-plugins malveillants et l’extension de masquage qui cachait le reste. On met tous les plugins légitimes en quarantaine, en ne gardant actif que le pare-feu, le temps de faire le ménage. On inspecte les fichiers du thème un par un — dans ce cas, le functions.php s’est révélé sain, mais le frontend.js était le vecteur. On vérifie les journaux du pare-feu eux-mêmes, car ils avaient été compromis. Et on cherche, par date de modification, tous les fichiers touchés au moment de l’attaque, pour ne rien laisser passer.

Fermer la porte, pour de bon

Une fois le site propre, il reste le plus important : s’assurer que l’attaquant ne revienne pas. Un site nettoyé mais dont la faille reste ouverte sera recompromis en quelques jours.

Cela passe par le renouvellement de tous les mots de passe — WordPress, mais aussi FTP, SSH et base de données, car on ignore lesquels ont fuité. Par la régénération des clés de sécurité de WordPress, qui invalide toutes les sessions ouvertes, y compris celles de l’attaquant. Par l’activation de la double authentification sur les comptes critiques. Et par une configuration propre du pare-feu, avec l’adresse de l’administrateur en liste blanche pour éviter de se bloquer soi-même.

La leçon de ce cas

Ce piratage résume tout ce qui rend les compromissions modernes difficiles : le site avait l’air à peu près normal, un scan superficiel ne montrait pas grand-chose, et le malware s’était logé précisément dans les angles morts — les MU-plugins, un outil légitime détourné, un faux dossier de sécurité, un fichier de thème. Ce qu’un tableau de bord vous montre n’est pas la vérité de votre site. La vérité est dans les fichiers, les journaux, les dates de modification — et il faut aller la chercher là où l’interface ne regarde pas.

Si votre site se comporte étrangement — des menus qui bougent, un rôle utilisateur qui change, une impression diffuse que quelque chose ne va pas sans pouvoir mettre le doigt dessus — ne vous fiez pas à l’apparence du tableau de bord. C’est exactement le genre de compromission furtive que je traque. Vous pouvez partir de mon panorama sur les sites WordPress piratés, ou décrire votre situation via ma page SOS site piraté.