Une backdoor WordPress auto-réparatrice utilise la mémoire partagée et une C2 basée sur la blockchain

Des chercheurs en sécurité ont identifié une backdoor WordPress sophistiquée qui résiste à la suppression en répartissant sa charge utile sur huit emplacements différents, y compris la mémoire système. Baptisé SC, ce malware crée un maillage auto-réparateur capable de se restaurer depuis la base de données ou la RAM, même après la suppression de tous les fichiers visibles.

Ce qui s'est passé

Le malware, analysé par Sucuri, fonctionne comme un système circulaire sans point de défaillance unique. Le chercheur en sécurité Gabriel Barbosa a noté que la suppression d'un composant déclenche la réécriture par un autre, garantissant ainsi que la backdoor reste active. La charge utile existe simultanément dans les fichiers, la base de données et la mémoire partagée, permettant à toute copie survivante de reconstruire l'infection complète au chargement de page suivant.

Cette souche spécifique n'utilise pas de noms de fonctions lisibles. Elle emploie plutôt un décodeur de chiffrement par substitution pour déchiffrer son code à l'exécution. L'infection masque sa présence des écrans d'administration et des vérifications de mise à jour tout en maintenant une communication avec un serveur de commande et de contrôle (C2) via la blockchain Ethereum. Elle crée également des comptes administrateurs cachés et peut injecter des skimmers JavaScript ciblant les visiteurs du site.

La divulgation coïncide avec une exploitation active d'une faille d'injection SQL de gravité élevée dans le plugin wpForo Forum, suivie sous la référence CVE-2026-1581. Cette vulnérabilité affecte les versions jusqu'à la 2.4.14 et présente un score CVSS de 7,5. Les télémétries de Previdian montrent moins de 20 tentatives d'exploitation depuis le 3 juillet 2026, provenant d'adresses IP situées en Bulgarie, en Suisse, en France, aux États-Unis et au Yémen.

Comment cela fonctionne

La backdoor SC repose sur la redondance de huit composants spécifiques. Tout commence avec .user.ini, qui force PHP à exécuter un chargeur avant chaque requête. Ce chargeur localise un fichier caché préfixé par un point agissant comme première étape, trouvant ensuite un faux plugin nommé hyper-engine-kit. Si le plugin est absent, le chargeur le reconstruit à partir de trois sources : une copie existante, un stub encodé dans le cache ou un bundle ZIP.

Deux fichiers drop-in, db.php et advanced-cache.php, servent de couches critiques de persistance. db.php contient la charge utile compressée et encodée en Base64, et la redéploie si le plugin est absent ou trop petit. advanced-cache.php remplit une fonction similaire mais puise dans cinq sources, incluant un segment de mémoire partagée System V. Ce stockage basé sur la RAM survit à la suppression des fichiers et au nettoyage de la base de données, rendant son éradication particulièrement difficile sur les environnements d'hébergement partagé.

Le fichier de thème functions.php et les copies de fichiers de plugins agissent comme sauvegardes supplémentaires. Une fois actif, le malware enregistre des hooks cron avec des noms randomisés. Ces hooks déclenchent le redéploiement selon un calendrier via le cron système, indépendamment du trafic des visiteurs. Le canal de commande utilise une infrastructure blockchain légitime pour masquer ses communications, récupérant des charges utiles supplémentaires ou exécutant du code PHP arbitraire selon les directives de l'opérateur.

Détails clés

• Le malware est baptisé SC en raison des marqueurs "SC_" présents dans le contenu injecté.
• Il persiste dans au moins huit emplacements, y compris les fichiers, la base de données et la mémoire partagée System V.
• La communication avec le serveur de commande et de contrôle est dissimulée dans les transactions de la blockchain Ethereum.
• La charge utile utilise un chiffrement par substitution pour obscurcir les noms de fonctions et la logique.
• Le redéploiement est déclenché par des tâches cron programmées, et non seulement par les requêtes utilisateurs.
• Une exploitation active de la CVE-2026-1581 du plugin wpForo a été observée depuis cinq adresses IP uniques.

Pourquoi c'est important

Pour les développeurs et les administrateurs de sites, cet incident souligne que les infections modernes sont des systèmes plutôt que de simples fichiers. Les méthodes de nettoyage traditionnelles, qui se concentrent sur le scan des fichiers disque à la recherche de signatures connues, sont insuffisantes face aux menaces stockant leurs charges utiles dans la RAM ou les entrées de base de données. Si vous supprimez le malware visible mais laissez intacte la base de données ou le segment de mémoire partagée, le site se réinfectera immédiatement.

L'utilisation de la blockchain pour le command-and-control complique davantage la détection. En dissimulant les instructions dans des transactions légitimes du registre public, les attaquants évitent la détection traditionnelle par signature réseau. Cela signifie que les outils de sécurité doivent rechercher des anomalies comportementales, telles que des requêtes sortantes inattendues ou la création non autorisée de comptes administrateurs, plutôt que de simplement bloquer des domaines malveillants connus.

Ce que vous pouvez faire

• Auditez votre installation WordPress à la recherche de mu-plugins inconnus et de fichiers drop-in tels que db.php.
• Vérifiez la présence de comptes administrateurs cachés et supprimez ceux qui n'ont pas été créés par votre équipe.
• Inspectez les segments de mémoire partagée System V sur votre serveur si vous suspectez une compromission.
• Mettez à jour le plugin wpForo Forum vers une version supérieure à la 2.4.14 pour corriger la CVE-2026-1581.
• Surveillez les tâches cron à la recherche de hooks randomisés ou inconnus pouvant déclencher le redéploiement du malware.
• Implémentez une surveillance de l'intégrité des fichiers pour détecter les modifications non autorisées des fichiers cœur de WordPress.