Chasse aux menaces liées aux webshells : une approche basée sur les données au-delà des portes dérobées

Par Assaf Morag, chercheur en cybersécurité

Les webshells sont souvent décrits comme une menace simple et directe : un attaquant compromet une application web et y laisse une porte dérobée lui permettant d’y accéder à nouveau à volonté. Dans les grandes lignes, cette description est juste. Cependant, elle sous-estime considérablement la complexité et la diversité des menaces que représentent les webshells aujourd’hui.

Cette recherche démontre que les webshells se présentent sous des formes très variées, reflétant l'étendue des technologies web actuelles et des techniques d'attaque. Outre les différences de langages de programmation et d'implémentations techniques, les webshells diffèrent également par leur finalité, leurs modèles de déploiement, leur utilisation opérationnelle et leur niveau de sophistication.

Cet article propose une analyse exhaustive et fondée sur les données de l'écosystème des webshells, à partir de sources multiples telles que les forums du dark web et du deep web, les places de marché clandestines, les dépôts de code open source et des exemples concrets observés lors d'incidents actifs. La mise en corrélation de ces perspectives révèle que les webshells ne sont pas de simples outils opportunistes, mais une capacité d'attaque mature et évolutive, jouant un rôle central dans la post-exploitation et la persistance à long terme au sein des environnements web modernes.

Principales conclusions sur l'environnement Webshell moderne

• Les webshells représentent une primitive fondamentale de post-exploitation, et non une technique de niche.
• L'écosystème englobe les outils open source, les frameworks offensifs commerciaux et les marchés clandestins.
• Les webshells modernes utilisent de plus en plus le chiffrement, l'obfuscation et l'exécution en mémoire.
• Les renseignements sur les menaces peuvent être utilisés dans les deux sens : pour découvrir de nouvelles familles de webshells, et pour enquêter sur les webshells trouvés lors d’incidents réels et les attribuer.
• Les webshells sont déployés à de multiples fins, notamment la persistance, le déplacement latéral, la manipulation du référencement, la fraude et la revente d'accès.

Cartographie de l'écosystème Webshell

Nous avons entamé ces recherches en collectant systématiquement des informations sur les webshells provenant de sources légitimes et clandestines. Cela incluait les communautés open-source, le deep cryptanalytique et le deep cryptanalytique. forums Web sombre, Chaînes de télégramme, les sites web du marché noir et les données réelles relatives aux incidents. 

Les webshells sont devenus un élément central de la chaîne d'attaque. Une fois qu'un acteur malveillant a accédé à une application web (que ce soit par exploitation de vulnérabilités, mauvaise configuration ou identifiants volés), sa priorité est souvent d'établir une porte dérobée persistante au cas où le point d'entrée initial serait découvert et corrigé.

Canaux légitimes : Outils de sécurité offensifs

Dans les canaux légitimes, les webshells sont largement documentés et distribués dans le cadre de kits d'outils de sécurité offensive.

Voici quelques exemples:

• dépôts de charges utiles Kali Linux
• Modules Metasploit
• Cadres d'équipe rouge

La page de documentation des webshells Linux Kali propose une grande variété de webshells.

Sur GitHub, des centaines de dépôts conservent des collections de webshells. Celles-ci sont utilisées par les équipes de défense (équipes rouges, testeurs d'intrusion) et les acteurs malveillants, des débutants aux opérateurs professionnels.

Ces techniques sont utilisées à la fois par les défenseurs (équipe rouge) et par les acteurs malveillants (principalement des script kiddies).

Marchés clandestins : les webshells comme marchandise

Les webshells font également l'objet d'un commerce actif sur les marchés clandestins. 

Vente de webshells dans des groupes de messagerie instantanée (Flare lien vers la publication, inscrivez-vous à essai gratuit (pour y accéder si vous n'êtes pas déjà client)

Nous avons observé :

• Des groupes Telegram vendent l'accès à des domaines compromis avec des webshells préinstallés
• Des robots automatisés gèrent les achats
• Sites web spécialisés dans le marché noir proposant des inventaires classés par catégories de serveurs piratés

Le parcours entre la découverte et l'achat est souvent sans heurt. Un message sur un forum mène à un bot Telegram, qui lui-même mène à un site web du marché noir spécialisé dans la vente d'accès webshell à des sites web compromis.

Animer un groupe Telegram (Flare lien vers la publication, inscrivez-vous à essai gratuit (pour y accéder si vous n'êtes pas déjà client)

Le message sur le forum renvoie vers un bot Telegram :

Un bot Telegram vend des webshells

Le forum redirige ensuite vers un site web du marché noir :

Site web du marché noir pour les webshells

Domaines piratés avec webshells à vendre

Ces plateformes transforment de fait les webshells en accès en tant que service, où les acheteurs peuvent acquérir :

• Sites gouvernementaux
• Portails d'entreprise
• Plateformes de commerce électronique
• installations CMS

L'acheteur n'a rien à exploiter, puisque l'accès est déjà établi.

Un tournant : les frameworks webshell chiffrés

L'une de nos découvertes les plus importantes sur le dark web a été un blog technique chinois décrivant un webshell chiffré moderne.

Article de blog technique chinois sur le webshell chiffré (Flare lien vers la publication, inscrivez-vous à essai gratuit (pour y accéder si vous n'êtes pas déjà client) 

L'échantillon s'alignait sur des cadres bien connus tels que Behinder (冰蝎) et Godzilla (哥斯拉).

Ces frameworks représentent une évolution majeure dans la conception des webshells.

Nous avons recentré nos efforts sur la clé de chiffrement AES décrite dans le blog et avons identifié à la fois un exemple concret utilisant cette clé et un article distinct contenant l'intégralité du code source PHP.

Exemple de code PHP provenant du site Paste (Flare lien vers la publication, inscrivez-vous à essai gratuit (pour y accéder si vous n'êtes pas déjà client) 

Fonctionnement des webshells chiffrés modernes

Le webshell implémente :

• Un chargeur qui accepte les données POST chiffrées
• Chiffrement symétrique (de type XOR/AES)
• Exécution dynamique à l'aide de eval()

Dans une implémentation, la charge utile principale est stockée dans la mémoire de session côté serveur, et non dans le fichier lui-même. Cela permet :

• Exécution persistante entre les requêtes
• Empreinte minimale sur disque
• Évasion de la détection basée sur les fichiers

Sans la logique de contrôle correspondante, l'interface est inutilisable. Les requêtes doivent respecter un protocole chiffré avec état, initialisation par étapes et persistance de session.

Cela transforme le webshell, initialement un fichier PHP malveillant, en un implant de commande et de contrôle résidant en mémoire et intégré à une application web légitime.

Nous l'avons téléchargé via notre serveur Flare Lab pour observer le code et avons confirmé qu'il correspondait au code de l'article de blog et au dump de code.

De la recherche à la pratique : Détection des webshells déployés sur des serveurs compromis

En utilisant la clé de chiffrement et les modèles de code issus de l'analyse chinoise, nous avons exploité différentes sources de renseignements sur les menaces et identifié des serveurs infectés actifs.

Lorsqu'on y accédait via un navigateur, le serveur tentait de télécharger un fichier PHP malveillant, qui était immédiatement signalé et supprimé par les protections du navigateur.

Lorsqu'on ouvre la page web dans un navigateur, celle-ci tente de télécharger le code PHP. 

Le code PHP est détecté comme malveillant par le navigateur.

Nous avons récupéré l'échantillon dans notre laboratoire de recherche et confirmé :

• Le code correspondait à la structure chiffrée
• Le protocole nécessitait un contrôleur dédié
• Les requêtes HTTP manuelles ont échoué sans message d'erreur.

Le code webshell trouvé dans la nature

Voici un exemple de requête POST pour communiquer avec le webshell.

Cela a confirmé que ces cadres de travail ne sont pas théoriques et qu'ils sont activement déployés dans des systèmes de production réels.

Nous avons élargi notre analyse pour identifier et classer les campagnes de webshells réelles, ce qui a permis de dégager plusieurs catégories dominantes.

Catégories de webshells du monde réel

Webshells pour le référencement et la manipulation des résultats de recherche

Une catégorie importante concerne les abus en matière de référencement (SEO). 

Webshell pour la manipulation du référencement naturel

Ces webshells :

• Activer uniquement pour les robots d'exploration des moteurs de recherche (par exemple, Baiduspider).
• Injecter des liens sortants cachés
• Récupérer à distance des URL contrôlées par un attaquant
• Générer aléatoirement des centaines d'ancres invisibles

Webshell pour la manipulation du référencement naturel

Les utilisateurs normaux ne voient rien, tandis que les moteurs de recherche voient des fermes de liens.

Un script webshell obfusqué

Cela transforme les sites web compromis en une infrastructure de référencement distribuée pour les jeux d'argent, les arnaques, le phishing et la fraude à l'affiliation. Certaines variantes ciblent plusieurs moteurs de recherche, utilisent un masquage poussé et correspondent à des schémas de trafic spécifiques (par exemple, des mots-clés liés aux jeux d'argent).

Le script webshell désobfusqué montre comment il priorise certaines victimes.

Webshells simples pour portes dérobées

Le modèle classique reste largement répandu :

• Fichier PHP unique
• Exécute les commandes système
• Obfuscation minimale
• Souvent laissé pour compte par l'exploitation automatisée

Elles sont fréquemment utilisées pour l'administration manuelle, la livraison de charges utiles secondaires et la collecte d'identifiants.

Un webshell PHP très simple et compact, activement déployé sur un site commercial.

Webshells complexes : contournement de l’authentification WordPress

Des exemples plus avancés incluent les portes dérobées WordPress qui :

• S'insérer dans l'action d'initialisation
• Obfusquer les fonctions principales à l'aide de strrev et base64_decode
• Accepter un seul paramètre GET
• Connexion automatique de l'attaquant en tant qu'utilisateur ID 1 (administrateur)
• Falsifier les cookies d'authentification
• Rediriger vers /wp-admin/

Une interface web WordPress plus avancée

Aucun mot de passe. Aucune authentification. Aucune chaîne d'exploitation. Une simple requête HTTP permet d'obtenir un accès administrateur complet.

Requête HTTP simple et apparemment inoffensive (pour le contrôle du réseau)

Du point de vue d'un défenseur, c'est extrêmement dangereux :

• La requête semble normale aux yeux des contrôles réseau
• Elle laisse des traces médico-légales minimales.
• Il permet un contrôle permanent et sans mot de passe du site

Classification des victimes

Dans l'ensemble des incidents que nous avons examinés, le point de vue de la victime était rarement défini par une seule vulnérabilité ou une seule pile technologique. 

Les serveurs compromis allaient des installations WordPress obsolètes avec des plugins et des thèmes vulnérables, aux applications Web personnalisées affectées par des CVE non corrigées, des panneaux d'administration exposés, des mécanismes de téléchargement de fichiers non sécurisés, des points d'injection XSS, des flux d'authentification faibles et des erreurs de configuration du cloud ou de l'hébergement. 

Dans de nombreux cas, les attaquants ne s'appuyaient pas du tout sur une faille zero-day sophistiquée, mais plutôt sur l'effet cumulatif d'une hygiène de sécurité négligée : mises à jour manquantes, autorisations trop permissives, points de terminaison oubliés et surveillance insuffisante. 

Le point commun est qu'il n'existe pas de solution miracle pour empêcher les compromissions de webshells. Une défense efficace ne consiste pas à déployer un seul outil ou à corriger une seule faille, mais à maintenir une sécurité globale renforcée sur l'ensemble de l'infrastructure web, depuis le code applicatif et ses dépendances, en passant par la configuration d'hébergement et les contrôles d'accès, jusqu'à une visibilité et une détection continues.

Pourquoi c'est important : Les webshells comme infrastructure de menace stratégique

Les webshells ne sont pas une astuce bon marché ni un logiciel malveillant destiné aux script kiddies.

Certains peuvent représenter :

• Des points d'ancrage persistants dans les environnements de production 
• Canaux C2 de la couche application
• Actifs économiques souterrains échangés à des fins lucratives 
• Infrastructure de post-exploitation de base dans les campagnes sophistiquées

Elles font le lien entre l'accès initial et la persistance à long terme. Dans de nombreux exemples cités précédemment, elles permettent également la propagation latérale, la propagation d'autres infections et la monétisation directe de l'attaque.

Application du renseignement sur les menaces à la défense contre les webshells 

La recherche sur les webshells est particulièrement adaptée au renseignement sur les menaces car elle opère dans les deux sens.

Cas d'utilisation défensifs :

• Détectez si vos sites web hébergent un webshell.
• Identifier les techniques et les cadres modernes utilisés
• Former les équipes IR, SOC et d'ingénierie aux techniques actuelles 
• Créer une détection basée sur la signature et sur le comportement

Cas d'utilisation du renseignement :

• Surveillez les marchés clandestins de webshells pour détecter les menaces émergentes.
• Suivre l'évolution et l'adoption des nouveaux cadres de référence 
• Campagnes d'attribution basées sur des outils et une infrastructure partagés
• Découvrez de nouveaux outils avant qu'ils n'arrivent dans votre environnement.

Dans les attaques modernes, les webshells ne sont pas un simple ajout, mais constituent la pierre angulaire de la post-exploitation des infrastructures web. Leur compréhension est donc essentielle et indispensable.