Une simple erreur opérationnelle commise par un groupe de cybercriminels a permis aux chercheurs de comprendre de l’intérieur comment sont menées les compromissions de sites Web à grande échelle.
Selon les travaux de recherche de SOCRadar, un serveur exposé sur Internet appartenant à un groupe malveillant suivi sous le nom de WP-SHELLSTORM est resté accessible au public pendant environ trois semaines.
« WP-SHELLSTORM est la cybercriminalité industrialisée rendue visible parce que quelqu’un a laissé ouvert, sans authentification, un répertoire Python SimpleHTTPServer pendant 22 jours », a déclaré Jacob Krell, directeur principal des solutions d’IA sécurisée et de la cybersécurité chez SuzuLabs, dans un e-mail adressé à eSecurityPlanet.
Il a ajouté : « De nombreuses organisations n’évaluent encore leur exposition externe qu’à la publication d’une entrée majeure dans le registre Common Vulnerabilities and Exposures, ou lors d’évaluations périodiques des vulnérabilités. »
- À retenir
- Comment WP-SHELLSTORM a compromis des sites WordPress
- Les vulnérabilités WordPress connues ont alimenté les attaques
- De longues listes de cibles ne signifient pas une compromission à grande échelle
- Les webshells fournissaient un accès persistant
- Les chercheurs ont découvert une campagne antérieure de vol d’identifiants
- Des erreurs opérationnelles ont exposé les attaquants
- Comment les organisations peuvent réduire les risques
- En résumé
À retenir
- Un serveur WP-SHELLSTORM exposé a révélé comment les attaquants ont automatisé la compromission de sites WordPress à grande échelle en exploitant des vulnérabilités connues.
- La campagne visait principalement des extensions WordPress et des composants Joomla obsolètes, plutôt que de s’appuyer sur des failles zero-day.
- Plus de 1,4 million de sites Web figuraient sur les listes de cibles des attaquants, mais les chercheurs ont confirmé que beaucoup moins avaient effectivement été compromis.
- L’infrastructure exposée a également révélé une campagne antérieure qui dérobait des identifiants cloud d’entreprise avant de se réorienter vers l’implantation massive de portes dérobées sur des sites Web.
Comment WP-SHELLSTORM a compromis des sites WordPress
WP-SHELLSTORM opérait comme un courtier en accès par webshell, compromettant des sites en masse avant de revendre les accès.
Leur serveur contenait environ 800 Mo de données, notamment des outils d’exploitation, des webshells, des listes de cibles, des journaux d’activité et des historiques de commandes.
Les fichiers exposés ont révélé comment le groupe compromettait des sites vulnérables, offrant un nouvel éclairage sur une opération de webshell visant des sites WordPress à grande échelle.
Plutôt que d’exploiter des vulnérabilités zero-day, le groupe automatisait des attaques contre des failles connues dans des extensions WordPress, exposant ainsi les faiblesses de la sécurité des sites WordPress.
Les vulnérabilités WordPress connues ont alimenté les attaques
Les chercheurs ont constaté que la boîte à outils permettait d’exploiter 27 vulnérabilités connues, même si un petit nombre d’entre elles représentait l’essentiel de l’activité.
L’attaque la plus fructueuse visait l’extension de mise en cache WordPress Breeze (CVE-2026-3844), que les attaquants ont lancée contre plus de 45 000 sites Web.
Selon les propres journaux du groupe, plus de 17 000 webshells ont été déployés, ce qui en fait l’une des plus grandes attaques par webshell documentées contre WordPress observées cette année.
Breeze et les vulnérabilités de Joomla étaient des cibles privilégiées
Cependant, les chercheurs ont noté que la vulnérabilité ne concerne que les installations de Breeze sur lesquelles l’option non activée par défaut « Host Files Locally – Gravatars » est activée, ce qui limite le nombre de sites réellement vulnérables.
Les attaquants ont également ciblé massivement CVE-2026-48907, une vulnérabilité de l’éditeur JCE de Joomla.
De longues listes de cibles ne signifient pas une compromission à grande échelle
Les données exposées faisaient référence à plus de 1,4 million de sites Web, mais les chercheurs ont rappelé que ce nombre correspondait à des cibles de balayage et non à des victimes confirmées.
Un seul fichier contenait plus de 587 000 domaines Joomla sélectionnés pour être analysés.
Après avoir supprimé les doublons et vérifié les compromissions avérées, Ctrl-Alt-Intel a recensé environ 25 195 sites Web compromis, tandis que SOCRadar a observé plus de 5 700 webshells actifs au cours de son analyse.
Les webshells fournissaient un accès persistant
Une fois qu’ils avaient exploité avec succès un site Web vulnérable lors de l’attaque par webshell visant WordPress, les attaquants y installaient un webshell obfusqué appelé down.php, que les chercheurs pensent dérivé du webshell chinois open source BestShell.
La porte dérobée permettait aux attaquants d’exécuter des commandes à distance, de parcourir les fichiers, de dérober des identifiants, d’établir des shells inversés et de se déplacer latéralement dans les environnements compromis.
Pour renforcer la persistance, les opérateurs déployaient le dropper SNOWLIGHT afin d’installer VShell, un outil d’accès à distance conçu pour se faire passer pour un processus légitime de travail du noyau Linux en utilisant des noms tels que [kworker/0:2].
Bien que VShell soit apparu dans des campagnes liées à des acteurs étatiques chinois présumés, les chercheurs indiquent qu’il est également largement utilisé par des cybercriminels sinophones.
Sa seule présence n’indique donc pas une implication étatique.
Les chercheurs ont découvert une campagne antérieure de vol d’identifiants
Le serveur exposé a également révélé les traces d’une campagne antérieure, menée avant le lancement de l’attaque par webshell visant des sites WordPress à grande échelle.
Selon SOCRadar, le groupe ciblait des serveurs de configuration Nacos vulnérables en exploitant CVE-2021-29441, ce qui permettait aux attaquants de contourner l’authentification et de dérober les données de configuration des organisations.
Les chercheurs ont également récupéré des identifiants cloud pour AWS, Oracle Cloud, Alibaba Cloud, Tencent Cloud et DigitalOcean, ainsi que des mots de passe de bases de données et des clés cryptographiques.
SOCRadar estime que cette séquence suggère que le groupe a d’abord récolté des identifiants d’entreprise avant de se tourner vers une campagne d’implantation de portes dérobées sur des sites Web, menée à plus grande échelle.
Des erreurs opérationnelles ont exposé les attaquants
Malgré une boîte à outils sophistiquée, les acteurs malveillants ont commis plusieurs erreurs de sécurité opérationnelle.
Le groupe a laissé un serveur Web Python non authentifié accessible au public pendant 22 jours, exposant des historiques internes de commandes, des configurations de recherche FOFA, des scripts d’exploitation et des informations sur l’infrastructure.
Les chercheurs ont également constaté que les opérateurs avaient tenté de supprimer une partie des journaux après avoir pris conscience de l’exposition, mais leur intervention est arrivée trop tard.
Sur la base du chinois simplifié présent dans les fichiers, de l’utilisation de FOFA et des logiciels malveillants employés, les chercheurs estiment avec un niveau de confiance modéré à élevé que les opérateurs sont chinois ou sinophones.
Cependant, SOCRadar estime que la campagne était motivée par des considérations financières plutôt que liée à une opération soutenue par un gouvernement.
Comment les organisations peuvent réduire les risques
Les organisations responsables de la sécurité des sites WordPress ou d’environnements Joomla doivent donner la priorité à l’installation des dernières mises à jour de sécurité.
Pour réduire le risque d’attaques similaires :
- Appliquez des correctifs à WordPress, Joomla et à toutes les extensions, en donnant la priorité, sur la base de cette étude, aux vulnérabilités connues pour être activement exploitées.
- Supprimez ou désactivez les extensions inutilisées, les thèmes et les modules afin de réduire votre surface d’attaque globale.
- Surveillez en continu les sites Web afin de détecter toute modification non autorisée des fichiers, les webshells suspects et autres indicateurs d’une attaque par webshell visant WordPress.
- Recherchez les indicateurs de compromission, notamment les fichiers suspects tels que .bd.php, .wp-log.php et .brq-*.php, ainsi que les faux processus [kworker] dotés de chemins exécutables ou de connexions réseau.
- Faites tourner les identifiants et lesAPI clés si des systèmes vulnérables, tels que des serveurs Nacos exposés, ont pu être compromis.
- Testez vosplans de réponse aux incidents et utilisez des simulations portant sur des scénarios de compromission de sites Web.
Ensemble, ces mesures peuvent aider les organisations à réduire leur exposition globale et à renforcer leur résilience.
En résumé
L’opération WP-SHELLSTORM rappelle une fois de plus qu’une sécurité efficace des sites WordPress repose sur la prise en charge systématique des risques connus, et pas uniquement sur la réaction aux dernières menaces.
Alors que les acteurs malveillants recourent de plus en plus à l’IA pour identifier leurs cibles et passer à l’échelle leurs attaques, l’exploitation automatisée des vulnérabilités connues continue d’alimenter les campagnes de webshells visant des sites WordPress à grande échelle.
Les organisations peuvent réduire les risques en combinant l’application rapide de correctifs ou le virtual patching, une surveillance continue, des plans de réponse aux incidents testés et des principes de zero trust qui contribuent à limiter l’ampleur des dommages causés par les compromissions réussies.