En bref

  • Des chercheurs de XLab (division cybersécurité de QiAnXin) ont découvert CWPdoor, une backdoor dissimulée dans des binaires trojanisés du serveur web cwpsrv de Control Web Panel, remplaçant les versions légitimes 1.15.10 et 1.24.0.
  • Plus de 340 000 instances Control Web Panel sont exposées sur internet ; la backdoor supprime activement ses traces dans les logs et ne s'active que sur réception d'un en-tête HTTP RSA-signé chiffré en AES-256-CBC.
  • Action requise : vérifier l'intégrité du binaire cwpsrv, rechercher le socket Unix ngx_http_integrity_helper, mettre à jour CWP depuis les canaux officiels uniquement.

Les faits

Le 5 novembre 2026, l'équipe de recherche XLab, division cybersécurité du groupe chinois QiAnXin, a publié une analyse technique détaillant la découverte de CWPdoor, une backdoor sophistiquée dissimulée dans des binaires trojanisés du logiciel de gestion d'hébergement Control Web Panel (CWP, anciennement CentOS Web Panel). La découverte a été faite lors d'une investigation sur un serveur Linux compromis dont le comportement réseau présentait des anomalies inexpliquées malgré l'absence de toute trace dans les fichiers de logs.

Control Web Panel est un panneau d'administration d'hébergement web utilisé par des milliers d'hébergeurs, d'agences web et d'administrateurs système sur des serveurs Linux. Il centralise la gestion des sites web, des bases de données, des comptes email, des certificats SSL et de la configuration serveur via une interface web. Sa popularité en fait une cible de choix pour des attaquants cherchant un accès persistant à des serveurs d'hébergement gérant potentiellement des dizaines ou des centaines de sites web. Selon les données Shodan analysées par XLab, plus de 340 000 instances CWP sont directement exposées sur internet.

La backdoor CWPdoor fonctionne en remplaçant le binaire légitime cwpsrv, le serveur web propriétaire de CWP basé sur Nginx, par une version trojanisée. Deux versions spécifiques du binaire légitime ont été ciblées : la version 1.15.10 et la version 1.24.0. Les binaires trojanisés sont fonctionnellement identiques aux binaires légitimes — CWP continue de fonctionner normalement, ce qui rend la détection particulièrement difficile sans vérification cryptographique des fichiers. Un administrateur vérifiant le fonctionnement de son panneau d'hébergement ne verrait aucune anomalie apparente.

Le mécanisme de déclenchement de la backdoor est remarquablement sophistiqué. La porte dérobée ne s'active pas de manière autonome ou périodique, mais uniquement sur réception d'une requête HTTP spécialement forgée contenant un en-tête X-Ngx-Integrity. Cet en-tête doit contenir une commande chiffrée en AES-256-CBC et signée avec une clé RSA privée contrôlée par l'attaquant. Cette architecture à double verrou cryptographique — chiffrement symétrique AES-256-CBC et signature asymétrique RSA — garantit que seul l'attaquant possédant la clé privée RSA peut activer la backdoor. Des tiers, même s'ils découvrent l'en-tête X-Ngx-Integrity, ne peuvent pas l'exploiter sans la clé privée correspondante.

Une fois la signature RSA vérifiée et la commande déchiffrée, cwpsrv exécute la commande reçue avec les privilèges du processus cwpsrv. Selon la configuration, cwpsrv peut s'exécuter avec des privilèges élevés, offrant potentiellement un accès root à l'attaquant. Les commandes exécutées sont entièrement arbitraires : le protocole ne se limite pas à des commandes prédéfinies mais permet l'exécution de n'importe quel code shell. Upload de fichiers, reverse shell, mouvement latéral, exfiltration de données : toutes ces actions sont réalisables via une seule requête HTTP bien formée.

L'une des caractéristiques les plus préoccupantes de CWPdoor est sa furtivité active. Le binaire trojanisé supprime délibérément ses propres entrées dans les logs de cwpsrv. Les requêtes HTTP contenant l'en-tête X-Ngx-Integrity ne génèrent aucune ligne de log dans les fichiers d'accès standard, rendant l'investigation forensique difficile sur la base des logs seuls. Cette capacité de suppression d'artefacts indique un niveau de sophistication élevé dans le développement de la backdoor et suggère un acteur ayant une expérience significative dans le développement de malwares pour des environnements Linux.

Le vecteur de distribution initial n'est pas encore entièrement élucidé par XLab. Plusieurs hypothèses sont envisagées : un dépôt de mise à jour CWP compromis (attaque supply chain), un mécanisme de mise à jour automatique détourné, ou des installateurs CWP trojanisés distribués via des canaux tiers. Les administrateurs qui téléchargent CWP depuis des sources non officielles ou qui utilisent des scripts d'installation automatisés trouvés sur des forums ou des dépôts GitHub non officiels sont particulièrement exposés à cette dernière hypothèse.

Les indicateurs de compromission (IoC) publiés par XLab permettent une vérification rapide. La présence du socket Unix ngx_http_integrity_helper dans le répertoire temporaire ou de travail de cwpsrv est un signal fort de compromission. Des processus helpers cwpsrv inhabituels visibles dans la liste des processus constituent un autre indicateur. Sur le plan réseau, la surveillance du trafic HTTP entrant sur les ports CWP pour détecter des en-têtes X-Ngx-Integrity peut permettre d'identifier des tentatives d'activation de la backdoor, même si les logs locaux sont supprimés. Un SIEM ou un système de capture réseau externe au serveur est donc indispensable pour cette détection.

La détection via vérification cryptographique des fichiers est l'approche la plus fiable. Comparer le hash SHA-256 du binaire cwpsrv installé avec les hashes publiés par CWP pour les versions légitimes permet de détecter un remplacement. Cette vérification doit être effectuée depuis un système de référence sain ou depuis une image disque préservée, car un OS compromis à un niveau plus profond pourrait potentiellement retourner des résultats falsifiés.

Impact et exposition

L'exposition est potentiellement massive. Control Web Panel est particulièrement populaire en Europe de l'Est, au Moyen-Orient et en Asie du Sud-Est, mais son usage est mondial. Un hébergeur mutualisé utilisant CWP compromis expose l'ensemble de ses clients : tous les sites hébergés, toutes les bases de données, tous les emails transitant par le serveur. Un accès root via CWPdoor offre à l'attaquant une capacité de pivotement vers l'ensemble de l'infrastructure hébergée. Les serveurs d'hébergement sont des cibles de choix pour le déploiement de malwares, l'injection de contenu malveillant dans des sites légitimes (web skimming, SEO poisoning), l'exfiltration de données clients et le déploiement de relais de phishing ou d'infrastructures de commande et contrôle.

Recommandations

  • Vérifier immédiatement l'intégrité du binaire cwpsrv en comparant son hash SHA-256 avec les valeurs officielles publiées par l'éditeur CWP pour votre version.
  • Rechercher la présence du socket Unix suspect : find /tmp /var/run /dev/shm -name "ngx_http_integrity_helper" 2>/dev/null.
  • Analyser les processus en cours d'exécution pour détecter des helpers cwpsrv inhabituels : ps aux | grep cwp.
  • Télécharger CWP uniquement depuis le site officiel et vérifier les checksums avant installation ou mise à jour.
  • Si une compromission est suspectée : isoler le serveur du réseau, préserver une image disque pour investigation forensique, et reconstruire le serveur depuis une image propre.
  • Mettre en place une surveillance des fichiers critiques (file integrity monitoring) sur les binaires CWP pour détecter les remplacements futurs.

Alerte critique

Si vous administrez des serveurs d'hébergement sous Control Web Panel, vérifiez l'intégrité de cwpsrv en priorité. Un serveur d'hébergement compromis expose l'ensemble de vos clients hébergés. Ne faites pas confiance aux logs locaux pour détecter cette backdoor : ils sont activement supprimés par le malware.

Comment vérifier si mon CWP a été trojanisé ?

La méthode la plus fiable est la vérification du hash SHA-256 du binaire cwpsrv. Exécutez sha256sum /usr/local/cwpsrv/sbin/cwpsrv et comparez le résultat avec le hash officiel publié par CWP pour votre version. En parallèle, recherchez le socket Unix suspect avec find /tmp /var/run /dev/shm -name "ngx_http_integrity_helper". Si l'un ou l'autre de ces contrôles révèle une anomalie, traitez le serveur comme compromis et préservez une image disque avant toute modification.

Votre infrastructure est-elle exposée ?

Ayi NEDJIMI réalise des audits de sécurité ciblés pour identifier et corriger vos vulnérabilités avant qu'elles ne soient exploitées.

Demander un audit