Détecter et neutraliser des webshells sur un hébergement mutualisé

Contexte & enjeux

En plus de son propre site, Websource héberge les sites de plusieurs clients sur un socle mutualisé. Début avril 2026, une première détection a révélé la présence de webshells — des scripts PHP obfusqués en XOR/hexadécimal déposés dans des répertoires accessibles publiquement, vecteur classique de prise de contrôle à distance après exploitation d'une extension tierce vulnérable ou d'un accès FTP affaibli.

Ce type de compromission ne se contente presque jamais d'un seul fichier : c'est la porte d'entrée qui compte, pas le symptôme visible.

Situation avant intervention

La première vague avait été traitée par suppression des fichiers identifiés, sans scan récurrent mis en place derrière et sans certitude absolue sur le point d'entrée initial. Un mois plus tard, une seconde vague de fichiers similaires a été détectée : la preuve que le premier passage n'avait traité que les symptômes, pas la cause.

Problèmes rencontrés

• Fichiers malveillants disséminés dans plusieurs arborescences (uploads, cache, thèmes), ce qui rend une simple suppression manuelle peu fiable.
• Obfuscation XOR/hexadécimale qui passe sous le radar d'un scanner basé sur de simples signatures.
• Difficulté à distinguer un fichier légitime d'un fichier injecté sans revue manuelle ligne par ligne.
• Absence de suivi en versionnement sur certains répertoires sensibles, rendant impossible la datation précise de l'apparition d'un fichier suspect.

Objectifs

• Identifier et neutraliser l'intégralité des fichiers compromis, pas seulement ceux déjà signalés.
• Mettre en place un processus de détection reproductible plutôt qu'une intervention ponctuelle.
• Réduire la surface d'attaque : permissions, comptes FTP, extensions tierces.

Solution technique mise en place

Audit manuel et scripté de l'ensemble de l'arborescence hébergée, en recherchant les patterns d'obfuscation et les enchaînements de fonctions à risque (eval, base64_decode, gzinflate imbriqués). Plutôt qu'une suppression immédiate, chaque fichier suspect a été isolé dans un répertoire de quarantaine horodaté, hors webroot, pour conserver une preuve exploitable et permettre une analyse a posteriori.

• Mise en quarantaine systématique (et non suppression directe) de chaque fichier suspect identifié.
• Suivi en Git des fichiers sensibles du dépôt applicatif, pour permettre un diff et une datation en cas de récidive future.
• Durcissement des permissions et rotation des accès FTP concernés.

Qualité, suivi et prévention de la récidive

• Processus de quarantaine documenté et reproductible, réutilisable en cas de nouvelle détection.
• Passage d'une posture réactive (intervention après signalement) à une posture de scan périodique.
• Fichiers sensibles désormais suivis en Git pour dater précisément toute modification suspecte.