Les chercheurs de Sucuri ont publié le 1er octobre 2026 l'analyse d'un backdoor WordPress particulièrement résistant au nettoyage manuel, relayée par The Hacker News, baptisé SC en référence aux marqueurs « SC_ » retrouvés dans le contenu injecté. Sa particularité : après suppression de ses fichiers, il se reconstruit automatiquement au chargement de page suivant, à partir de copies stockées en base de données et en mémoire partagée. Cet article détaille son fonctionnement, ses capacités, et la méthode de nettoyage adaptée à ce type de persistance distribuée.
Huit points d'ancrage pour un seul backdoor
Selon l'analyse de Sucuri, SC ne repose pas sur un fichier unique mais sur huit composants qui se surveillent et se régénèrent mutuellement :
| Composant | Rôle |
|---|---|
.user.ini |
Force le chargement automatique du loader via auto_prepend_file |
wp-content/c1b12371.php et sa version cachée .c1b12371.php |
Chargeurs de premier niveau |
wp-content/db.php |
Porte le backdoor compressé et encodé en Base64 |
wp-content/advanced-cache.php |
S'exécute avant les extensions si le cache est actif |
Thème khorshidi/functions.php |
Point de persistance côté thème |
Extension must-use hyper-engine-kit.php |
Chargée automatiquement par WordPress, sans activation manuelle |
Extension standard hyper-engine-kit |
Copie visible dans la liste des extensions, mais masquée de l'interface d'administration |
| Segments de mémoire partagée System V et base de données | Copies de secours utilisées pour la reconstruction |
Ce type d'encodage multi-couches peut être exploré avec notre décodeur universel, utile pour comprendre comment un contenu Base64 ou compressé est imbriqué dans un fichier compromis.
À retenir : supprimer l'extension ne suffit pas, le drop-in de cache la réécrit ; nettoyer tous les fichiers disque ne suffit pas non plus, la prochaine page chargée restaure l'ensemble depuis la base de données ou la mémoire partagée.
Ce que fait le backdoor une fois installé
Au-delà de sa persistance, SC embarque plusieurs fonctions offensives : il se masque de l'écran des extensions dans l'administration WordPress, crée des comptes administrateur cachés, exécute du code PHP arbitraire transmis par son canal de commande, injecte des scripts de type skimmer destinés à intercepter les données saisies par les visiteurs (formulaires de paiement notamment), et peut désactiver ou supprimer certaines extensions, probablement pour neutraliser des outils de sécurité concurrents ou gênants.
Élément notable relevé par Sucuri : le canal de commande et contrôle s'appuie en partie sur la blockchain Ethereum, une technique qui complique le blocage par simple liste de domaines puisqu'elle ne dépend pas d'une infrastructure DNS classique.
Sucuri signale par ailleurs, sans établir de lien de cause à effet direct avec les intrusions observées, une activité d'exploitation limitée sur une vulnérabilité distincte de l'extension wpForo Forum (CVE-2026-1581, injection SQL, score CVSS 7.5, consultable via notre base de données CVE) : moins de 20 tentatives recensées depuis cinq adresses IP depuis le 3 juillet 2026. Cette donnée illustre surtout que les sites WordPress restent sondés en continu sur des vecteurs variés, comme le montrent aussi les deux failles critiques détaillées dans notre article sur la chaîne RCE wp2shell, qu'elles soient ou non liées à ce backdoor précis.
Comment détecter ce backdoor WordPress
La détection de SC demande de sortir du seul scan de fichiers, puisque la persistance ne s'y limite pas :
- Comparer l'intégralité des fichiers du cœur, des thèmes et des extensions à une copie de référence saine, fichier par fichier, y compris les fichiers cachés commençant par un point.
- Inspecter le contenu de la table
wp_optionset des tables personnalisées à la recherche de données compressées ou encodées en Base64 qui n'ont pas leur place dans une configuration standard. - Vérifier la présence de segments de mémoire partagée System V inhabituels sur le serveur (
ipcs -msous Linux), un indicateur rarement surveillé mais pertinent pour ce type de persistance. - Lister les comptes administrateur WordPress et comparer avec la liste attendue, y compris les comptes qui pourraient être masqués de l'écran standard des utilisateurs.
- Surveiller le trafic sortant vers des nœuds ou passerelles liés à Ethereum depuis le serveur web, un comportement atypique pour une infrastructure d'hébergement classique. Consigner ces observations comme des IOC exploitables facilite leur partage avec d'autres équipes.
Comment se protéger
- Maintenir à jour le cœur WordPress, le thème actif et toutes les extensions, y compris celles non utilisées activement : elles restent un vecteur d'accès initial fréquent.
- Restreindre les droits d'écriture du compte du serveur web sur les répertoires
wp-content/themes,wp-content/pluginsetwp-content/mu-pluginsen dehors des fenêtres de mise à jour planifiées. - Désactiver ou auditer
advanced-cache.phplorsqu'il n'est pas utilisé par une extension de cache légitime connue. - Isoler l'hébergement WordPress dans un environnement surveillé (WAF applicatif, journalisation des accès admin) pour repérer la création de comptes ou l'apparition de fichiers hors mise à jour planifiée.
- En cas de compromission confirmée, privilégier une restauration complète depuis une sauvegarde antérieure à l'infection plutôt qu'un nettoyage fichier par fichier, compte tenu des multiples points de persistance.
À retenir : face à un backdoor WordPress multi-composants comme SC, un nettoyage partiel donne une fausse impression de résolution : seule une restauration complète ou une revue exhaustive de tous les points d'ancrage (fichiers, thème, base de données, mémoire) garantit l'éradication.
Points clés
Le backdoor WordPress SC, documenté par Sucuri le 1er octobre 2026, se distingue par une architecture de persistance répartie sur huit composants (fichiers de configuration, thème, extension must-use et standard, base de données, mémoire partagée), capable de se reconstruire automatiquement après un nettoyage incomplet. Il crée des comptes administrateur cachés, injecte des skimmers visant les visiteurs et communique via un canal lié à la blockchain Ethereum. Sa prise en charge exige une détection qui dépasse le simple scan de fichiers, et un nettoyage exhaustif, idéalement par restauration complète, plutôt qu'une suppression partielle qui laisse le mécanisme de reconstruction actif.