En bref : savoir si un serveur a été piraté via PHP2Shell ne se lit pas sur une seule caractéristique. Il n'existe pas d'indicateurs de compromission (IOC) publiés et confirmés ; la détection repose sur l'analyse comportementale. Les signes typiques sont de nouveaux fichiers PHP, des tâches cron inconnues et des connexions inhabituelles. Sauvegardez d'abord les journaux à partir du 20 octobre, avant de modifier quoi que ce soit.
Existe-t-il des signes univoques d'une attaque PHP2Shell ?
Non, et c'est la réponse honnête. Pour de nombreuses failles connues, les éditeurs ou les sociétés de sécurité publient des traces concrètes : noms de fichiers, sommes de contrôle, adresses IP. Pour PHP2Shell, de tels indicateurs de compromission confirmés n'existent pas jusqu'ici.
Ce qui est connu : selon des reportages de médias, une première tentative d'attaque a été observée le 17 octobre, quatre jours avant les correctifs du 21 octobre. Cloudflare a signalé d'autres tentatives. Selon le BSI (l'office fédéral allemand de la sécurité des technologies de l'information), des attaques réussies à grande échelle n'étaient d'abord pas connues. Qui était joignable sans protection entre le 17 octobre et son propre correctif devrait donc vérifier plutôt qu'espérer.
Pour l'appréciation, c'est surtout la période qui compte. Entre la première tentative d'attaque observée le 17 octobre et les correctifs du 21 octobre, il n'existait aucune mise à jour officielle. Tout serveur PHP accessible publiquement était potentiellement attaquable pendant cette période. La durée pendant laquelle votre serveur est resté ouvert au-delà dépend du moment où la mise à jour a été installée et PHP redémarré. Plus cette période est longue et plus les données sont sensibles, par exemple comptes clients, commandes ou candidatures, plus l'examen devrait être approfondi.
Signes typiques qu'un serveur a été piraté
Après une exécution de code réussie, les attaquants cherchent généralement à s'installer durablement et à utiliser le serveur. Il en résulte des signes qui ne sont pas spécifiques à PHP2Shell, mais comptent pour tout examen d'intrusion :
- Fichiers PHP nouveaux ou modifiés, surtout dans les répertoires d'envoi, de cache ou d'images, où il n'y a normalement pas de fichiers PHP.
- Tâches cron inconnues ou tâches planifiées, par exemple pour l'utilisateur du serveur web.
- Connexions sortantes inhabituelles vers des adresses inconnues, forte charge réseau ou envoi de courriels que personne n'a déclenché.
- Nouveaux comptes administrateur dans le CMS ou la boutique, mots de passe modifiés, clés SSH inconnues.
- Charge inhabituelle : utilisation du processeur durablement élevée par des processus inconnus, souvent un indice de minage de cryptomonnaie.
- Conséquences visibles : redirections vers des sites étrangers, pages de spam dans l'index de Google, avertissements dans le navigateur ou dans la Search Console.
Aucun de ces signes ne prouve à lui seul une intrusion, et leur absence ne prouve pas le contraire. Le tableau d'ensemble est décisif.
Premiers contrôles sans détruire de traces
Avant de supprimer ou de redémarrer quoi que ce soit : sauvegardez les journaux. La presse spécialisée conseille de conserver les journaux du serveur à partir du 20 octobre. Copiez les journaux du serveur web, de PHP et du système vers un endroit sûr en dehors du serveur.
Des vérifications en lecture seule aident ensuite. Les chemins et noms d'utilisateurs varient selon le système :
# Fichiers PHP modifiés depuis le 17.10.
find /var/www -type f -name "*.php" -newermt "2026-10-17" -ls
# Fichiers PHP dans les répertoires d'envoi (exemple WordPress)
find /var/www -path "*/uploads/*" -name "*.php" -ls
# Tâches cron de l'utilisateur du serveur web et à l'échelle du système
crontab -l -u www-data
ls -la /etc/cron.d /etc/cron.daily /var/spool/cron 2>/dev/null
# connexions réseau actives avec processus
ss -tunp
# dernières connexions
last -n 30
Notez que les attaquants peuvent falsifier les horodatages des fichiers. Un résultat discret de find n'est donc pas un acquittement. Comment analyser les journaux de façon ciblée, Analyser les journaux du serveur web après une attaque le décrit ; comment trouver les portes dérobées, Reconnaître et supprimer les webshells.
Si vous trouvez des indices concrets, par exemple un fichier PHP inconnu dans le dossier d'envoi : ne le supprimez pas, ne réinstallez pas, ne « réparez » pas rapidement l'application. Déconnectez ou isolez le serveur, sauvegardez les journaux et une image du système et commencez un traitement structuré de l'incident.
Ce qu'il ne faut pas faire
- Seulement corriger et continuer. Un correctif ne supprime aucun logiciel malveillant déjà introduit.
- Supprimer aussitôt les fichiers suspects. Cela fait disparaître les preuves de ce qui s'est passé et des données qui peuvent être concernées.
- Réinstaller le serveur avant d'avoir sauvegardé. La cause reste floue, et une porte dérobée dans la base de données ou dans les identifiants survit à la réinstallation.
- Restaurer d'anciennes sauvegardes sans les vérifier. Une sauvegarde peut elle aussi contenir déjà la porte dérobée.
- Oublier les identifiants. Après une exécution de code, des mots de passe de base de données, clés d'API et autres identifiants ont pu fuiter depuis des fichiers de configuration. Renouvelez-les après le nettoyage, pas avant, afin qu'un attaquant encore actif ne lise pas aussitôt les nouveaux.
Si le soupçon se confirme
Il s'agit alors de plus que de technique. Vérifiez avec votre délégué à la protection des données si une notification au titre du RGPD est nécessaire ; le délai est de 72 heures à compter de la prise de connaissance, détails sous Obligation de notification RGPD. Informez tôt votre cyberassureur, s'il y en a un, et clarifiez avec un avocat s'il faut porter plainte. Nous donnons à ce sujet des indications générales, pas de conseil juridique.
Comment PHP SOS aide-t-il concrètement ?
Avec notre réponse aux incidents, nous traitons un soupçon de façon structurée :
- Sauvegarder : les journaux à partir du 20 octobre et, si nécessaire, une image du système, avant que quoi que ce soit ne soit modifié.
- Examiner : analyse comportementale des fichiers, processus, connexions et comptes ; au besoin avec valeur probante devant un tribunal grâce à la forensique informatique.
- Nettoyer et refermer : supprimer les portes dérobées, mettre PHP à jour, renouveler les identifiants, durcir le serveur.
- Documenter, jusqu'à ce que l'incident soit clos et documenté, comme base pour la protection des données, l'assurance et la direction.
Questions fréquentes
La mise à jour de PHP prouve-t-elle que mon serveur est sain ?
Non. Un correctif ferme la faille pour l'avenir, mais ne supprime aucun logiciel malveillant déjà introduit. Il ne dit rien non plus sur le fait que quelqu'un se soit introduit avant le correctif.
Existe-t-il un scanner qui détecte à coup sûr les attaques PHP2Shell ?
Pas jusqu'ici. Il n'existe pas d'indicateurs de compromission publiés et confirmés qu'un scanner pourrait rechercher de façon ciblée. Les scanners de malwares trouvent des webshells connues, mais l'appréciation d'un serveur repose sur l'analyse comportementale.
Dois-je signaler un soupçon à l'autorité de protection des données ?
Cela dépend de la possibilité que des données personnelles soient concernées. Le RGPD prévoit pour les violations de données à notifier un délai de 72 heures à compter de la prise de connaissance. Clarifiez-le tôt avec votre délégué à la protection des données ou un avocat ; nous ne donnons pas de conseil juridique à ce sujet.
Dois-je simplement réinstaller le serveur piraté ?
Pas comme première étape. Sauvegardez d'abord les journaux et, si possible, une image du système. Qui réinstalle aussitôt perd les traces qui montrent ce qui s'est passé et quelles données pourraient être concernées.