Prise en charge en cours Lun–Ven · 9h–19h
Signaler un incident
P.02 PK.ECM

Webshell PHP : la porte dérobée dans votre hébergement

Webshell PHP : la porte dérobée dans votre hébergement

Un site compromis ne ressemble pas toujours à un site piraté. Pas de page défacée, pas de redirection visible : l'attaquant a simplement déposé un fichier PHP discret quelque part sur votre serveur. Ce fichier lui donne un accès complet à votre hébergement, à votre base de données, à vos fichiers de configuration. Il peut revenir des semaines plus tard. C'est un webshell.

Définition en une phrase

Un webshell est un script PHP (ou parfois ASP, JSP) malveillant déposé sur un serveur web compromis, qui permet à un attaquant d'exécuter des commandes système, de lire ou modifier des fichiers, et d'accéder à la base de données depuis un simple navigateur.

En clair, pour les non-initiés. Imaginez qu'un intrus entre chez vous, cache une copie de clé sous une latte du parquet, et reparte. La porte principale est fermée, tout semble normal. Mais il peut revenir quand il veut. Un webshell fonctionne pareil : c'est une clé cachée sur votre serveur que l'attaquant peut utiliser depuis n'importe où dans le monde.

Pourquoi c'est important pour votre site

Un webshell actif sur votre serveur signifie qu'un tiers a un contrôle total sur votre infrastructure. Ce qu'il peut faire :

  • Lire tous vos fichiers de configuration : mots de passe base de données, clés API, tokens Stripe.
  • Extraire l'intégralité de votre base de données clients, commandes, emails.
  • Installer d'autres backdoors pour maintenir l'accès même après un nettoyage partiel.
  • Utiliser votre serveur comme point de rebond pour attaquer d'autres cibles.
  • Envoyer des emails de spam ou de phishing depuis votre IP, ce qui dégrade votre réputation email.
  • Déposer du contenu SEO parasitaire (pharma hack) qui blackliste votre site sur Google.

Trouver un webshell ne veut pas dire que l'incident est clos. L'attaquant a peut-être copié toutes vos données avant d'être détecté.

Où on trouve les webshells

Sur les sites que nous traitons en P.02, les webshells sont déposés dans des emplacements prévisibles :

Sur WordPress :

  • /wp-content/uploads/ : répertoire accessible en écriture, souvent mal surveillé. On y trouve des fichiers .php déguisés en images (image.php, thumb.php.jpg).
  • /wp-content/plugins/ : dans des plugins abandonnés ou compromis.
  • /wp-content/themes/ : dans le thème enfant ou un thème inactif.
  • À la racine du site : info.php, test.php, wp-config.bak.php.

Sur PrestaShop et Magento :

  • /modules/ : dans des modules tiers mal auditués.
  • /var/upload/ : répertoire d'upload PrestaShop.
  • /pub/media/ (Magento) : accessible publiquement.

Variantes de nommage fréquentes :

c99.php, r57.php, shell.php, cmd.php, wso.php
b374k.php, mini.php, 1.php, up.php, x.php

Un attaquant expérimenté renomme le fichier pour qu'il ressemble à un fichier légitime du CMS. On a vu des webshells nommés wp-helper.php, class-db-optimizer.php, ou updater.php.

Comment on les détecte

La détection repose sur plusieurs angles combinés :

1. Recherche de patterns de code malveillants :

# Chercher des patterns d'exécution de commandes dans les fichiers PHP
grep -r "eval(" /var/www/ --include="*.php" -l
grep -r "base64_decode(" /var/www/ --include="*.php" -l
grep -r "system(" /var/www/ --include="*.php" -l
grep -r "exec(" /var/www/ --include="*.php" -l
grep -r "passthru(" /var/www/ --include="*.php" -l
grep -r "shell_exec(" /var/www/ --include="*.php" -l

Ces fonctions sont légitimes dans certains contextes. Leur présence dans /wp-content/uploads/ ou dans un fichier créé récemment est un signal fort.

2. Fichiers PHP dans des répertoires d'uploads :

find /var/www/html/wp-content/uploads/ -name "*.php" -type f
find /var/www/html/wp-content/uploads/ -name "*.php*" -type f

Aucun fichier PHP ne devrait se trouver dans un répertoire d'uploads.

3. Modifications récentes :

# Fichiers modifiés dans les dernières 48 heures
find /var/www/ -name "*.php" -newer /var/www/html/wp-config.php -type f

4. Analyse des logs d'accès :

Les webshells génèrent des requêtes POST ou GET vers des fichiers inhabituels. Un POST /wp-content/uploads/2023/03/image.php HTTP/1.1 dans les logs Apache est un signal direct.

Comment Secushot traite les webshells en intervention

Dans notre protocole P.02 Nettoyage post-attaque, la séquence est la suivante :

  1. Scan complet du système de fichiers avec plusieurs méthodes combinées (grep patterns, dates de modification, hachages des fichiers core du CMS vs référence officielle).
  2. Analyse des logs d'accès HTTP sur les 30 derniers jours pour identifier les requêtes vers des fichiers suspects.
  3. Retrait des webshells identifiés et documentation de leur emplacement, contenu, et date probable de dépôt.
  4. Identification du vecteur d'entrée : comment l'attaquant a-t-il déposé le webshell ? Plugin vulnérable, upload non restreint, credentials FTP compromis, injection de fichier. Sans comprendre le vecteur, le nettoyage est incomplet.
  5. Correction du vecteur : fermeture de la faille d'entrée, restriction des répertoires d'upload, mise à jour des composants vulnérables.
  6. Rapport d'incident PDF : liste des webshells trouvés, IOC (voir IOC), chronologie reconstituée, recommandations post-incident.

Un point ferme dans notre doctrine : retirer le webshell sans corriger le vecteur d'entrée ne résout rien. L'attaquant redépose un nouveau fichier dans les heures qui suivent si la faille est toujours présente.

Les erreurs qu'on rencontre le plus souvent

1. Supprimer le webshell sans chercher d'autres backdoors

Un webshell est rarement le seul fichier malveillant. Les attaquants déposent souvent plusieurs backdoors dans des emplacements différents pour garder un accès même si l'un est trouvé. On cherche l'intégralité du périmètre avant de déclarer le site propre.

2. Ne pas restaurer les permissions d'upload

Les répertoires d'uploads WordPress doivent accepter les fichiers image et PDF, pas les fichiers PHP. Ajouter un .htaccess dans /wp-content/uploads/ pour bloquer l'exécution PHP ferme ce vecteur d'entrée :

<Files "*.php">
    deny from all
</Files>

3. Changer les mots de passe sans révoquer les sessions actives

Si l'attaquant a eu accès à votre base de données, il a peut-être créé un compte admin WordPress discret. Changer le mot de passe admin existant ne suffit pas : on vérifie et supprime les comptes non reconnus, et on invalide toutes les sessions actives.

4. Scanner uniquement le répertoire WordPress

Un accès FTP ou SSH compromis permet de déposer un webshell n'importe où sur l'hébergement, y compris hors de la racine web. On scanne l'ensemble du compte d'hébergement, pas seulement public_html/.

5. Considérer le nettoyage comme une garantie d'immunité

Un nettoyage correctement fait élimine les fichiers malveillants connus et ferme le vecteur d'entrée identifié. Il ne garantit pas qu'aucune autre backdoor n'est présente, ni qu'une nouvelle compromission ne surviendra pas si le site n'est pas durci par la suite. On le dit clairement dans notre rapport.

Questions fréquentes

Comment savoir si mon site a un webshell sans accès FTP ? Les signaux indirects : comportements inhabituels dans les logs, pages inconnues indexées par Google, alertes Google Search Console sur du contenu malveillant, emails de spam envoyés depuis votre domaine, site blacklisté sur Google Safe Browsing. La confirmation nécessite un accès au système de fichiers.

Un plugin de sécurité WordPress peut-il détecter un webshell ? Wordfence et Sucuri scannent les fichiers PHP du répertoire WordPress contre des signatures connues. Ils ratent les variantes obfusquées, les nouveaux webshells non encore dans leur base de signatures, et tout ce qui se trouve hors du répertoire WordPress. Leur scan est un complément, pas une garantie.

Combien de temps faut-il pour nettoyer un site compromis ? Pour un WordPress standard avec un vecteur d'entrée identifiable, notre SLA P.02 est de 24 h. Pour un site avec plusieurs backdoors, une compromission ancienne, ou une stack e-commerce complexe, le délai peut s'allonger. Nous livrons toujours un rapport avant/après.

Faut-il prévenir mes clients après une compromission ? Si des données personnelles ont été accessibles (liste clients, emails, données de carte), la RGPD impose une notification à la CNIL sous 72 h et potentiellement aux personnes concernées. Notre rapport d'incident documente les accès constatés pour vous aider à évaluer l'obligation de notification.

Peut-on prévenir le dépôt de webshells ? Plusieurs mesures réduisent fortement le risque : bloquer l'exécution PHP dans les répertoires d'upload, restreindre les permissions de fichiers (644 pour les fichiers, 755 pour les répertoires), maintenir plugins et CMS à jour, limiter l'accès FTP/SSH. Ces configurations font partie de notre durcissement P.03.

Pour aller plus loin

Vous soupçonnez un fichier malveillant sur votre serveur ? Notre nettoyage post-attaque (P.02, 1 290 € TTC, SLA 24 h) analyse votre système de fichiers, identifie et retire les webshells, ferme le vecteur d'entrée. Rapport d'incident PDF inclus. Briefer une intervention P.02

Dernière mise à jour · 22 avril 2026 ← Retour au lexique