Un web shell peut offrir à un attaquant une exécution de commandes durable via un serveur web compromis. Même lorsque la vulnérabilité d'origine n'est plus visible, la création ou la modification de fichiers exécutables côté serveur peut laisser des traces que les défenseurs peuvent surveiller.

La source définit deux approches de détection complémentaires : la surveillance de l'intégrité des fichiers de Wazuh et les événements de création de fichiers Sysmon.

Pourquoi la surveillance des fichiers de web shell est importante

Le comportement couvert par cette recherche comprend le téléversement de fichiers arbitraires, la traversée de répertoires, la désérialisation, l'injection de commandes et la persistance après RCE.

La détection se concentre sur les extensions de fichiers et les répertoires couramment associés à l'exécution côté serveur :

• fichiers ASPX sous SharePoint ou IIS ;

• fichiers JSP dans les répertoires d'applications Java ;

• fichiers PHP dans les racines web ;

• fichiers CGI dans les répertoires CGI ;

• fichiers ASHX sous IIS.

Un nouveau fichier dans l'un de ces emplacements n'est pas automatiquement malveillant. Les applications et les déploiements peuvent légitimement créer des fichiers. Cependant, les scripts côté serveur inattendus, en particulier dans les environnements de production, doivent être examinés.

Requête de surveillance de l'intégrité des fichiers de Wazuh

rule.groups:syscheck and syscheck.event:(added or modified) and syscheck.path:(*spinstall*.aspx or *\_layouts\*.aspx or *\inetpub\wwwroot\*.aspx or */webapps/*.jsp or */j2ee/cluster/apps/*.jsp or */htdocs/*.php or */www/*.php or */public_html/*.php or */cgi-bin/*.cgi)

Cette requête surveille les fichiers ajoutés ou modifiés dans des chemins d'application sélectionnés.

Requête Sysmon de création de fichiers

data.win.system.eventID:11 and data.win.eventdata.targetFilename:(*spinstall*.aspx or *\_layouts\*.aspx or *\inetpub\wwwroot\*.aspx or *\webapps\*.jsp or *\wwwroot\*.ashx)

L'ID d'événement Sysmon 11 offre un autre moyen de détecter la création de fichiers suspects sur les systèmes Windows.

La source a enregistré zéro correspondance au cours des 30 derniers jours.

Comment investiguer une correspondance

Un événement de fichier isolé doit être enrichi de contexte avant de tirer une conclusion.

Les questions importantes comprennent :

• Quel processus a créé ou modifié le fichier ?

• Quel compte a effectué l'action ?

• Y avait-il une activité de déploiement ou de correctifs au même moment ?

• Le nom du fichier correspond-il à la référence de l'application ?

• Le fichier a-t-il été consulté via HTTP après sa création ?

• Le serveur a-t-il ensuite lancé cmd.exe, PowerShell ou un autre shell ?

• Le fichier contient-il des fonctionnalités inattendues de script ou d'exécution de commandes ?

La comparaison de l'empreinte du fichier avec des paquets d'application réputés sains peut également aider à déterminer si le fichier appartient à un déploiement approuvé.

Corrélation avec l'activité des processus

La détection de web shells devient plus solide lorsque les événements de fichiers sont corrélés avec la création de processus.

Par exemple :

new ASPX file → HTTP access → w3wp.exe → powershell.exe

offre plus de confiance que n'importe quel événement pris isolément.

Il en va de même sur les systèmes Java ou PHP. Un nouveau fichier JSP ou PHP suivi d'une exécution inattendue de shell mérite une priorité nettement plus élevée.

Ajuster la détection

Comme les déploiements d'applications peuvent légitimement modifier les répertoires web, l'ajustement doit tenir compte des pipelines de livraison connus et des fenêtres de maintenance approuvées.

Les exceptions doivent être précises. Au lieu d'exclure toute une racine web, envisagez de limiter une exception à un processus de déploiement connu, à un chemin attendu, à un paquet approuvé ou à un compte de service.

L'objectif est de préserver la visibilité sur les modifications de fichiers inattendues tout en réduisant le bruit des changements contrôlés.

Utilisation opérationnelle

La source n'a identifié aucune correspondance sur la période de 30 jours, mais l'absence d'événements peut rester utile. Une règle à faible volume peut devenir une alerte de grande valeur lorsqu'elle est déployée dans un environnement de production stable où les fichiers exécutables côté serveur changent rarement.

Pour les serveurs web, les plateformes d'applications et les environnements SharePoint, la surveillance de l'intégrité des fichiers reste un complément important de la télémétrie de processus et réseau lors de la recherche d'exploitation et de persistance.