TL;DRUn webshell est un petit script — le plus souvent en PHP — déposé par un attaquant sur un serveur compromis, qui lui donne ensuite un accès distant complet : exécution de commandes, lecture et écriture de fichiers, envoi de spam, ou rebond vers d'autres sites hébergés sur la même machine. Contrairement à une attaque bruyante, un webshell est conçu pour rester discret le plus longtemps possible. Voici, sur la base de cas réels rencontrés en exploitation de sites WordPress et PrestaShop, les signes qui doivent alerter et la méthode pour vérifier sans se faire piéger.

Pourquoi les webshells sont difficiles à repérer#

Un webshell efficace ne ressemble pas à un fichier malveillant à l'œil nu. Il porte souvent un nom qui imite un fichier système légitime (wp-cache.php, class-config.php, index_old.php), et son contenu est presque toujours obfusqué : encodage base64, chiffrement XOR avec une clé courte, ou empilement de fonctions comme eval(), gzinflate(), str_rot13() ou assert() qui ne révèlent leur comportement réel qu'à l'exécution. Un simple grep sur le mot « shell » ou « hack » dans les fichiers ne trouve donc quasiment jamais rien.

Les signes qui doivent alerter#

  • Un fichier PHP dans un dossier qui ne devrait contenir que des images ou documents — wp-content/uploads/, public/uploads/, ou tout répertoire normalement réservé aux médias téléversés par les utilisateurs. C'est le point d'entrée le plus fréquent, car ces dossiers sont souvent accessibles en écriture par le serveur web lui-même.
  • Des fichiers appartenant à un utilisateur inattendu — sur un hébergement mutualisé ou VPS bien configuré, les fichiers de l'application appartiennent à l'utilisateur applicatif (ex. www-data ou un utilisateur dédié), jamais à root. Un fichier récent appartenant à root dans le webroot public est un signal fort d'intrusion, pas une coïncidence.
  • Une date de modification récente et isolée — un fichier modifié ou créé à une date qui ne correspond à aucune mise à jour ou déploiement connu, surtout s'il est seul au milieu de fichiers plus anciens du même dossier.
  • Un trafic sortant anormal — pic d'envoi d'emails, requêtes sortantes vers des domaines inconnus dans les logs, ou pic de bande passante sans explication côté visiteurs.
  • Un référencement Google qui se dégrade brutalement ou l'apparition de pages inconnues dans Google Search Console : c'est souvent la première alerte visible côté propriétaire du site, bien après la compromission réelle.
  • Une archive volumineuse et chiffrée déposée dans le webroot public, souvent avec une extension banale (.zip, .tar) — une pratique observée pour exfiltrer ou stocker des données avant de les récupérer plus tard.

Où chercher en priorité#

Concentrez la recherche sur les dossiers accessibles en écriture par le serveur web : répertoires d'upload, dossiers de cache, dossiers temporaires, et la racine publique elle-même. Comparez ensuite la liste des fichiers présents avec une installation propre du même CMS ou framework (via un diff avec l'archive officielle pour WordPress, ou avec un dépôt Git propre pour une application sur-mesure) : tout fichier qui n'existe pas dans la version de référence mérite un examen.

Une commande simple et efficace sur un hébergement Linux : lister les fichiers PHP modifiés dans les 30 derniers jours et les trier par propriétaire, pour repérer immédiatement tout fichier root dans un webroot qui devrait appartenir à l'utilisateur applicatif.

Comment vérifier sans se faire piéger#

Un webshell peut être configuré pour se supprimer lui-même s'il détecte qu'il est consulté depuis un navigateur classique, ou pour ne s'activer que sur un paramètre précis dans l'URL. Ouvrir le fichier suspect dans un simple éditeur de texte, sans l'exécuter, est la seule manière sûre de l'examiner : cherchez les fonctions d'exécution dynamique (eval, assert, create_function, call_user_func) combinées à un décodage (base64_decode, gzinflate, une boucle XOR manuelle) — cette combinaison est la signature quasi systématique d'un webshell obfusqué, même quand le reste du code est illisible.

Que faire si vous en trouvez un#

Ne supprimez pas immédiatement le fichier trouvé : mettez-le d'abord en quarantaine (déplacé hors du webroot, permissions retirées) plutôt que détruit, pour pouvoir l'analyser après coup et comprendre le point d'entrée. Changez ensuite tous les mots de passe liés au site (administration CMS, base de données, FTP/SFTP, hébergement), et surtout identifiez la faille d'entrée avant de remettre le site en ligne : un webshell supprimé sans corriger la vulnérabilité initiale (plugin obsolète, mot de passe faible, permissions de fichiers trop larges) revient généralement en quelques jours, parfois via un fichier différent. Il n'est pas rare d'en retrouver une nouvelle occurrence quelques semaines plus tard si la porte d'entrée réelle n'a pas été fermée.

Comment prévenir une intrusion#

  • Maintenir à jour le CMS, les plugins/modules et le thème : la grande majorité des webshells exploitent une vulnérabilité déjà corrigée dans une version plus récente.
  • Interdire l'exécution de PHP dans les dossiers d'upload via la configuration du serveur web (Apache/Nginx) — même si un fichier malveillant est déposé, il ne pourra pas s'exécuter.
  • Limiter les permissions d'écriture au strict nécessaire, et ne jamais laisser de fichiers applicatifs appartenir à root.
  • Auditer périodiquement la liste des fichiers du webroot par rapport à une installation de référence, plutôt que d'attendre un signe visible de compromission.
  • Sauvegarder régulièrement, avec un historique suffisant pour pouvoir revenir à une version antérieure à l'intrusion, pas seulement à la veille.

Besoin d'un audit de sécurité ou d'un nettoyage de site compromis ? Websource intervient sur WordPress, PrestaShop et applications sur-mesure, identification de la faille comprise.