Web shell
Un web shell est un fichier déposé par un attaquant sur un site, souvent un simple fichier PHP, qui lui rend le contrôle du serveur depuis un navigateur ordinaire.
Définition
Un web shell est un fichier déposé par un attaquant sur un site, souvent un simple fichier PHP, qui lui rend le contrôle du serveur depuis un navigateur ordinaire. Il ne casse rien, il n’affiche rien, et c’est précisément ce qui le rend difficile à remarquer : il attend, à une adresse que son auteur est seul à connaître.
Qu’est-ce qu’un web shell ?
Un fichier qui transforme une adresse du site en console d’administration parallèle.
MITRE le range parmi les composants ajoutés à un logiciel serveur : un script installé sur un site public, qui donne à son auteur une interface de commande accessible par le web. Sur WordPress, cela prend la forme d’un fichier PHP posé dans wp-content, dans le dossier des médias ou à la racine. On l’appelle en ouvrant son adresse dans un navigateur, et il répond par un formulaire ou par le résultat d’une commande.
Le fichier est un logiciel malveillant au sens strict, mais d’un genre passif : il n’infecte rien de lui-même et se contente d’attendre une requête pour exécuter ce qu’on lui demande. Les capacités vont du strict minimum au gestionnaire complet. Les plus courts tiennent en une ligne et se contentent d’exécuter ce qu’on leur envoie. Les plus complets affichent une arborescence de fichiers, un éditeur de texte, un formulaire de téléversement, un accès à la base de données et une console. Les plus complets ajoutent l’exécution de commandes système, celles-là mêmes qu’un administrateur taperait dans un terminal. Dans les deux cas, la conséquence est la même : l’attaquant n’a plus besoin de la vulnérabilité par laquelle il est entré.
Pourquoi il compte plus que la faille d’origine
Parce qu’il rend l’accès permanent et indépendant de tout le reste.
La vulnérabilité exploitée pour entrer se referme d’elle-même à la première mise à jour de l’extension concernée. Le fichier déposé, lui, reste. Il ne dépend d’aucun compte, d’aucun mot de passe, d’aucune session : il ne se sert pas de WordPress, il se sert du serveur qui exécute WordPress. C’est ce qui explique le scénario classique du site nettoyé qui redevient infecté quelques jours plus tard.
La documentation WordPress consacrée aux sites compromis le dit dans son ordre de priorités : identifier ce qui a été ajouté vient avant la remise en service. Un fichier ajouté ne se voit pas dans le tableau de bord, il ne figure dans aucune liste d’extensions, il n’apparaît nulle part dans l’interface. Il n’existe que sur le disque.
Changer les mots de passe ne referme rien. C’est le premier réflexe, il est utile contre un accès volé, et il ne produit aucun effet sur un fichier déposé. Tant que ce fichier est en place, l’attaquant recrée le compte administrateur supprimé la veille, en une requête, sans jamais voir le formulaire de connexion.
Comment il se cache dans un site
Par un nom crédible, à un endroit où personne ne regarde.
Le nom imite ce qui existe déjà. Un dossier plugins contient des dizaines de sous-dossiers dont personne ne connaît le détail : un de plus, appelé comme un utilitaire de gestion de fichiers ou de cache, ne surprend pas. Le dossier des médias est le second lieu privilégié, parce qu’il est le seul du site où WordPress écrit tous les jours, et le seul où un fichier récent n’attire aucune attention.
Trois signaux se relèvent sans outil particulier : un fichier PHP là où seules des images sont attendues, une date de modification isolée au milieu de fichiers tous datés du même déploiement, et un dossier d’extension qui n’apparaît pas dans la liste des extensions installées.
Comment le chercher méthodiquement
Quatre passes, de la plus rapide à la plus sûre.
Comparer le cœur à l’original
Les fichiers du cœur de WordPress sont publiés et vérifiables : tout écart signale un ajout ou une modification. C’est la seule partie du site où la comparaison est totale et sans faux positif.
Lister les PHP hors de leur place
Un fichier exécutable dans le dossier des médias se compte en secondes. Le compte seul ne prouve rien : plusieurs extensions y déposent des fichiers vides de protection. Il faut les ouvrir.
Trier par date de modification
Un site normal a des dates groupées par événement : une mise à jour, un déploiement, un téléversement. Une date isolée, surtout nocturne, mérite une lecture du fichier.
Recouper avec les journaux du serveur
Un shell posé est un shell appelé. Le journal d’accès garde la trace de l’adresse demandée, du jour et de l’heure. C’est ce recoupement qui distingue un fichier suspect d’un fichier utilisé.
Ce que les journaux d’un site sain montrent déjà
Mesure du 9 septembre 2026, sur un mois de journaux d’un site vitrine WordPress d’une trentaine de pages, sans compromission connue. Du 31 juillet au 31 août, 1 028 requêtes ont demandé un fichier PHP qui n’existe pas sur le compte, sous les dossiers des extensions, des thèmes ou des images. 164 adresses différentes essayées, depuis 234 machines, tous les jours du mois sans exception, et uniquement en lecture : pas un seul envoi de données. Ces robots ne cherchent pas à déposer un fichier, ils vérifient si quelqu’un d’autre en a déjà déposé un. Les noms les plus demandés sont ceux qui imitent une extension : un gestionnaire de fichiers dans un faux dossier hellopress, 220 fois, un up.php dans un faux dossier fix, 176 fois, l’initialisation d’une extension qui n’est pas installée sur ce site, 68 fois. D’autres ne se cachent même plus, avec des dossiers nommés shell ou pwnd. Deuxième enseignement, moins attendu : ce balayage qui ne trouve rien a quand même coûté 10 mégaoctets de réponses au site en un mois, dont 7,1 pour les 96 pages introuvables rendues par WordPress, à 74 kilooctets pièce.
Ce qu’il faut faire une fois le fichier trouvé
Ne pas le supprimer en premier.
Un fichier supprimé emporte avec lui la date, le contenu et la trace qui permettent de comprendre par où l’intrusion est passée. Il se copie d’abord hors du site, puis se neutralise. Sans cette étape, la seule conclusion possible sera qu’il y avait quelque chose, sans savoir quoi ni depuis quand.
Un shell trouvé signifie ensuite qu’il faut en chercher d’autres : ils vont rarement seuls, et le second est souvent posé ailleurs, précisément pour survivre à la découverte du premier. Le reste suit l’ordre d’un nettoyage : remise à l’identique des fichiers vérifiables, rotation des identifiants et des clés de sécurité, contrôle des comptes administrateurs, puis correction de la faille d’origine.
Questions fréquentes
Un antivirus d’hébergement détecte-t-il un web shell ?
Souvent, quand le fichier reprend un code de malware déjà répertorié. Un shell d’une ligne, ou un code brouillé pour l’occasion, passe régulièrement entre les mailles. L’absence d’alerte n’est pas une preuve d’absence.
Mon site a été nettoyé et il est réinfecté, pourquoi ?
C’est la signature d’un fichier oublié. Le nettoyage a retiré ce qui se voyait, les redirections ou les pages ajoutées, mais pas l’outil qui les remet en place. La recherche doit repartir des fichiers, pas du symptôme.
Peut-on empêcher l’exécution des PHP dans le dossier des médias ?
Oui, par une règle de serveur, et c’est une des protections les plus rentables : elle ne coûte rien et neutralise l’emplacement le plus utilisé. Elle ne dispense pas de vérifier le reste du site.
Quelle différence avec un reverse shell ?
Le web shell attend qu’on l’appelle : c’est l’attaquant qui ouvre l’adresse. Le reverse shell fait l’inverse, il ouvre depuis le serveur une connexion sortante vers une machine choisie par l’attaquant, ce qui lui permet de traverser un pare-feu qui ne filtre que l’entrant. Sur un hébergement mutualisé, le premier est de loin le plus courant, parce qu’il ne suppose aucune connexion sortante.
Faut-il restaurer une sauvegarde plutôt que nettoyer ?
Seulement si l’on sait de quand date l’intrusion. Une sauvegarde postérieure au dépôt du fichier le restaure avec le reste. La date de dépôt se lit dans les fichiers et dans les journaux, elle se détermine avant de choisir.
Sources
Et sur votre site ?
Une définition ne dit pas si vous êtes concerné.
L'audit gratuit répond dans votre cas : état technique, temps de chargement, et ce que Google voit réellement de vos pages. Un constat écrit, sans engagement et sans jargon.