Identifier, neutraliser et supprimer des webshells : types et solutions

Montrer le sommaire Cacher le sommaire

• Comment savoir si un web shell est présent sur mon site
• Quels chemins les attaquants empruntent pour implanter un web shell
• Que peut faire un pirate une fois qu’il dispose d’un web shell
• Quels types de web shells existe-t-il et comment les reconnaître
• Quelles erreurs commettent souvent les administrateurs lors d’une suppression
• Quelles étapes suivre immédiatement après la découverte d’un web shell
  • Signaux techniques à collecter en priorité
• Quels outils et méthodes offrent les meilleures chances de détection
• Comment empêcher la réapparition d’un web shell après nettoyage
• Quand faut-il faire appel à un spécialiste externe
• FAQ

Trouver un fichier inconnu sur votre serveur web n’est pas toujours un simple oubli de nettoyage : il peut s’agir d’une porte dérobée active appelée web shell, capable de donner à un attaquant un accès persistant. Plutôt que de rester théorique, cet article vous explique comment repérer ces scripts malveillants, quelles erreurs fréquentes vous évitent de les éradiquer complètement, et quelles étapes concrètes suivre pour limiter les dégâts dès la découverte.

Comment savoir si un web shell est présent sur mon site

La détection d’un web shell commence par l’observation d’anomalies plutôt que par la recherche d’un seul fichier suspect. Vous verrez souvent un mélange de signes discrets : fichiers nouveaux ou modifiés dans des répertoires publics, pics d’activité HTTP vers des pages inhabituelles, processus web lançant des commandes système ou des connexions sortantes vers des adresses inconnues.

En pratique, surveillez ces signaux prioritaires

• Appels HTTP POST vers des scripts qui n’ont pas vocation à recevoir des formulaires.
• Présence de fonctions PHP comme shell_exec, popen ou eval dans des fichiers récemment ajoutés.
• Modifications de fichiers légitimes (themes, plugins, index) avec du code encodé ou obfusqué.
• Crons, tâches planifiées ou .htaccess réécrits pour réinstaller du code après suppression.

Quels chemins les attaquants empruntent pour implanter un web shell

Il n’y a pas de secret magique : les web shells arrivent là où une défense est faible. Les vecteurs classiques que vous rencontrerez en production sont l’exploitation de vulnérabilités (SQLi, RCE, LFI/RFI), des uploads de fichiers mal filtrés, des interfaces d’administration exposées et des identifiants compromis.

Un fait souvent ignoré est la chaîne d’attaques : plusieurs failles faibles peuvent être combinées pour atteindre le serveur. Par exemple, un SSRF qui révèle un service interne, suivi d’une désérialisation non sécurisée pour déclencher une exécution de code. Ce sont ces enchaînements qui rendent l’investigation plus complexe.

Que peut faire un pirate une fois qu’il dispose d’un web shell

Un web shell est un outil polyvalent. Selon ses privilèges il permettra de lire des fichiers, exfiltrer des bases de données, lancer des processus, créer des comptes, et déployer d’autres malwares comme des skimmers ou des ransomwares. Même un petit shell minimaliste suffit souvent à faire le travail initial : récupérer des secrets puis installer des mécanismes de persistance plus robustes.

Dans la plupart des incidents réels, l’attaquant ne se contente pas d’un seul fichier. On observe typiquement :

• Extraction de fichiers de configuration contenant des identifiants (wp-config, .env).
• Création de comptes administrateurs et d’entrées dans la base pour garder l’accès.
• Propagation latérale vers d’autres hôtes via clés SSH, services internes ou partages réseau.

Quels types de web shells existe-t-il et comment les reconnaître

On peut classer les web shells selon leur complexité et leur objectif plutôt que selon leur langage. Les distinctions courantes sont :

Catégorie	Caractéristiques	Indices de détection
Minimaliste	Une ou deux lignes pour exécuter des commandes (souvent PHP, Perl, Bash)	Présence de fonctions système, suffixes .php .phtml .pl, requêtes POST inhabituelles
Complet	Interface web, gestion de fichiers, base de données, upload	Grand fichier, références à FilesMan/FilesManager, éléments GUI visibles via navigateur
Persistant	Mécanismes pour revenir après nettoyage : cron, services, modules	Tâches planifiées, backdoors dans des plugins, modifications de démarrage

Quelles erreurs commettent souvent les administrateurs lors d’une suppression

Supprimer le fichier visible est l’étape la plus fréquente mais rarement suffisante. Les erreurs que nous voyons le plus souvent sont :

• Ne pas analyser la méthode d’intrusion ni vérifier les credentials stockés
• Restaurer depuis une sauvegarde infectée sans la vérifier
• Oublier les tâches planifiées, les injections dans les templates ou les modules compilés
• Ne pas réinitialiser les mots de passe, clés API et certificats potentiellement compromis

Un nettoyage complet demande de penser en termes d’incident plutôt que de fichier : identifier la chaîne d’attaque, combler la faille, et réparer les conséquences.

Quelles étapes suivre immédiatement après la découverte d’un web shell

Lorsque vous trouvez un web shell, agissez vite mais méthodiquement. Voici un ordre d’action pragmatique adapté aux équipes techniques :

• Isoler l’hôte impacté du réseau si possible pour éviter l’exfiltration en cours.
• Basculer en mode lecture seule sur les emplacements critiques pour empêcher l’effacement de traces.
• Prendre des instantanés et copies des logs et des fichiers suspects pour analyse forensique.
• Rechercher signes de persistance (crons, autoruns, modifications de configuration).
• Changer les identifiants exposés et révoquer clés compromettantes.
• Corriger la vulnérabilité initiale : patcher, durcir les uploads, restreindre l’accès administrateur.

Signaux techniques à collecter en priorité

Les informations suivantes accélèrent l’analyse : journaux d’accès et d’erreurs du serveur web, journaux de base de données, sorties de l’outil netstat/lsof pour connexions inhabituelles, liste des crons, checksum des fichiers système, et dumps de mémoire si possible.

Quels outils et méthodes offrent les meilleures chances de détection

Il n’existe pas d’outil miracle. Combinez plusieurs approches :

• Analyse statique des fichiers pour signatures connues et fonctions dangereuses.
• Analyse comportementale des processus web et des requêtes réseau.
• Scanners de vulnérabilités pour trouver la faille exploitée (RCE, LFI, uploads).
• Intégrité des fichiers via checksums et solutions de versionning.

Les scanners basés sur des signatures détectent les web shells connus mais échouent face à l’obfuscation. Les systèmes qui surveillent le comportement — par exemple des alertes sur scripts qui lancent des shells ou qui établissent des connexions sortantes non autorisées — sont souvent plus utiles en production.

Comment empêcher la réapparition d’un web shell après nettoyage

La prévention repose sur des contrôles de base bien appliqués et sur la réduction de la surface d’attaque. Les mesures les plus efficaces observées en milieu professionnel sont :

• Gestion stricte des permissions : principe du moindre privilège pour les processus web.
• Validation côté serveur des uploads et désactivation des exécutions sur répertoires publics.
• Mises à jour régulières de CMS, bibliothèques et dépendances.
• Segmentation du réseau et limitation des accès internes depuis le couche web.
• Rotation des secrets et gestion centralisée des identités.

Quand faut-il faire appel à un spécialiste externe

Si l’attaque touche des données sensibles, si vous ne maîtrisez pas la profondeur de la compromission, ou si elle réapparaît après plusieurs nettoyages, il est prudent de consulter un analyste d’incident. Les investigations forensiques permettent de répondre à deux questions essentielles : comment l’attaque s’est produite et jusqu’où l’attaquant est allé. Sans ces réponses, la probabilité d’une récidive reste élevée.

FAQ

Comment différencier un fichier légitime d’un web shell
Regardez la fonctionnalité du fichier, sa date de création/modification, les appels à des fonctions système et l’origine des requêtes HTTP qui le ciblent. Un fichier qui n’appartient pas à votre application et qui contient des fonctions d’exécution mérite une analyse.

Un WAF peut-il empêcher l’installation d’un web shell
Un WAF bloque de nombreuses tentatives d’exploitation mais ne remplace pas le patching. Les attaques en chaîne ou les credentials compromis peuvent contourner un WAF.

Puis-je restaurer depuis une sauvegarde sans risque
Uniquement si la sauvegarde est antérieure à l’intrusion et a été vérifiée. Vérifiez toujours l’intégrité et scannez la sauvegarde avant restauration.

Le simple fait de supprimer le fichier met-il fin à l’incident
Rarement. Il faut identifier la porte d’entrée, vérifier les persistance et changer les identifiants et secrets exposés.

Quels langages sont les plus ciblés pour les web shells
PHP est très courant à cause de sa présence sur le web, mais on trouve aussi des shells en Python, Ruby, ASP, Perl et même des scripts shell/Bash.

Comment automatiser la surveillance pour repérer rapidement un web shell
Mettez en place des contrôles d’intégrité des fichiers, des alertes sur les modifications dans les répertoires web, la surveillance des requêtes anormales et des règles pour détecter l’exécution de commandes système via le processus web.