Comptes admin frauduleux sur WooCommerce : anatomie d'une escalade de privilèges

Sur une boutique en ligne, un compte administrateur créé en douce par un attaquant, c’est la clé du royaume : accès aux commandes, aux données clients, à la possibilité d’injecter n’importe quoi. J’ai traité le cas d’un site WooCommerce victime exactement de ça — une série de faux comptes administrateurs apparus au fil des semaines, symptôme d’une porte grande ouverte. Ce cas est intéressant parce qu’il pose un problème que beaucoup de propriétaires de boutiques ignorent : sur WooCommerce, on ne peut pas protéger l’administration comme sur un site classique.

La chronologie d’une intrusion, reconstituée dans les journaux

Quand j’ai plongé dans les journaux du serveur, l’histoire s’est écrite d’elle-même, datée à la minute. Un premier compte administrateur frauduleux ajouté à une date. Un second, au nom trompeur évoquant une interface technique légitime, ajouté deux semaines plus tard. Puis, un soir précis, une rafale : à 17h51 une injection de code pour créer un compte administrateur, à 19h08 une nouvelle injection pour publier un article parasite, à 19h36 une troisième pour modifier le pied de page du site.

L’article injecté faisait la publicité de casinos en ligne — la signature classique du SEO parasite, qui exploite l’autorité d’un site compromis pour référencer des contenus tiers. Je l’ai déplacé en corbeille. Le pied de page modifié, lui, servait à héberger des liens cachés sur toutes les pages du site.

Cette chronologie n’est pas un détail : elle est la base de tout. Sans elle, on nettoie à l’aveugle. Avec elle, on sait exactement quels comptes révoquer, quels contenus purger, et à quel moment la faille a été exploitée.

Le blocage immédiat : couper l’accès aux attaquants

Les journaux révélaient aussi l’ampleur des tentatives d’accès : certaines adresses IP frappaient le site des centaines à près de deux mille fois par jour. La première urgence, c’est d’endiguer ce flot.

Le blocage s’est fait via le pare-feu applicatif, sur deux sources : les adresses IP identifiées dans les journaux du serveur comme à l’origine des injections, et celles que le pare-feu lui-même signalait dans ses tentatives récurrentes. Bloquer les attaquants ne répare pas la faille, mais ça arrête l’hémorragie pendant qu’on travaille — un préalable indispensable avant le nettoyage de fond.

Le problème spécifique de WooCommerce

Voici le point technique qui rend ce cas instructif. Sur un site WordPress classique, une des meilleures protections consiste à verrouiller l’accès au répertoire d’administration wp-admin par un mot de passe au niveau du serveur — une double porte, indépendante de WordPress. Un attaquant qui ne connaît pas ce second mot de passe ne peut même pas atteindre la page de connexion.

Mais sur une boutique WooCommerce, cette protection n’est pas applicable. WooCommerce a besoin d’accéder à certaines ressources de wp-admin pour son propre fonctionnement — le traitement des commandes, les requêtes en arrière-plan, la communication entre le site et sa partie boutique. Verrouiller wp-admin par mot de passe casserait la boutique. On se retrouve donc privé de l’une des protections les plus efficaces, précisément sur les sites qui ont le plus à perdre : ceux qui manipulent des paiements et des données clients.

Il faut donc protéger autrement le point faible exploité ici — la création de comptes administrateurs.

Verrouiller la création d’administrateurs

La parade, sur ce site, a consisté à ajouter une barrière au moment précis de la création d’un compte administrateur. Concrètement, un extrait de code impose un second secret — un mot de passe de vérification — pour qu’un nouveau compte administrateur puisse être créé. Même quelqu’un ayant réussi à accéder à l’administration ne peut pas s’octroyer les pleins pouvoirs sans connaître ce second secret.

C’est une défense contre l’escalade de privilèges : elle ne compte pas sur le fait d’empêcher toute intrusion — objectif illusoire — mais sur le fait de rendre inutile une intrusion partielle. Un attaquant qui entre avec des droits limités ne peut pas les transformer en droits d’administrateur. La porte est ouverte sur le vestibule, mais la salle des coffres reste verrouillée.

Ce mot de passe de vérification ne se partage évidemment qu’avec des personnes de confiance, et se transmet toujours de façon sécurisée — jamais écrit dans un document qui circule, jamais visible dans une capture d’écran. Un secret de sécurité qui traîne n’est plus un secret.

Le durcissement complet et la vérification

Autour de cette protection centrale, la sécurisation a suivi le protocole habituel : mise à jour de l’ensemble — WordPress, thème, extensions, et montée de version de PHP par paliers pour ne rien casser — installation d’un CAPTCHA sur le formulaire de contact pour tarir le spam, et scan antimalware complet pour confirmer l’absence de code résiduel.

Un mot sur ce scan, parce qu’il illustre un piège du métier : sur ce site, comme sur d’autres que j’ai traités, un scan automatique peut passer des dizaines de milliers de fichiers au crible sans rien trouver, alors même que l’infection était bien réelle — parce qu’elle vivait dans un fichier de thème légitime et dans le contenu éditorial, deux endroits qu’un scanner considère comme normaux. Le scan est un outil, pas un verdict. La vérification humaine, elle, va regarder le pied de page, la liste des utilisateurs, les articles récents — là où la machine ne voit rien d’anormal.

La leçon de ce cas

Deux enseignements, sur ce piratage de boutique. D’abord, WooCommerce a ses contraintes propres : les protections standard de WordPress ne s’appliquent pas toutes, et il faut compenser par des défenses ciblées, comme le verrouillage de la création d’administrateurs. Ensuite, la règle qui vaut pour tous les cas de ce genre : nettoyer ne suffit jamais, il faut fermer la porte exploitée. Ici, la porte, c’était la création libre de comptes admin. Tant qu’elle restait ouverte, chaque nettoyage n’aurait été qu’un sursis.

Si vous gérez une boutique WooCommerce et que vous voyez apparaître des comptes que vous n’avez pas créés, ou des articles que vous n’avez pas écrits, considérez-la comme compromise et agissez vite — les données clients sont en jeu. Vous pouvez partir de mon panorama sur les sites WordPress piratés, ou décrire votre situation via ma page SOS site piraté.