Les vulnérabilités d'exécution de code à distance peuvent permettre à un attaquant de passer d'une application vulnérable au système d'exploitation qui l'héberge. Bien que la vulnérabilité initiale puisse différer d'un produit à l'autre, l'activité de post-exploitation produit souvent des relations de processus similaires que les défenseurs peuvent surveiller.

Un signal particulièrement utile est un processus d'application ou de serveur web qui lance de manière inattendue un interpréteur de commandes, un moteur de script ou un utilitaire système. Sous Windows, cela peut donner de la visibilité sur le point où l'exploitation de l'application devient une exécution sur l'hôte.

De l'exploitation d'une application web aux commandes système

La détection se concentre sur les processus côté serveur tels que IIS, WSUS, Tomcat, Java, Apache, Nginx, PHP et Node.js. Ces processus ont normalement des schémas d’exécution prévisibles. Lorsqu’ils commencent à créer des processus enfants tels que cmd.exe, powershell.exe, pwsh.exe, wscript.exe, mshta.exe, rundll32.exe, certutil.exe, bitsadmin.exe ou curl.exe, l’activité mérite une investigation.

La source associe ce comportement au RCE affectant SharePoint, WSUS, les applications hébergées sur IIS, SAP sous Windows, les consoles de gestion web et les vulnérabilités impliquant la désérialisation ou le téléversement de fichiers.

Une chaîne de processus suspecte peut ressembler à :

w3wp.exe → powershell.exe

ou :

java.exe → cmd.exe

La relation entre processus n'est pas en soi la preuve d'une compromission, mais elle peut indiquer qu'une application côté serveur a commencé à exécuter des commandes en dehors de son flux applicatif normal.

Requête de détection

data.win.system.eventID:1 and data.win.eventdata.parentImage:(*\w3wp.exe or *\wsusservice.exe or *\tomcat*.exe or *\java.exe or *\httpd.exe or *\nginx.exe or *\php-cgi.exe or *\php.exe or *\node.exe) and data.win.eventdata.image:(*\cmd.exe or *\powershell.exe or *\pwsh.exe or *\wscript.exe or *\cscript.exe or *\mshta.exe or *\rundll32.exe or *\regsvr32.exe or *\certutil.exe or *\bitsadmin.exe or *\curl.exe)

La source a enregistré 15,523 correspondances au cours des 30 derniers jours.

Pourquoi le nombre de résultats compte

Un nombre élevé de correspondances ne signifie pas automatiquement que des milliers d'attaques ont eu lieu. Les serveurs d'applications exécutent parfois des scripts ou des utilitaires en ligne de commande pour des raisons opérationnelles légitimes. Les applications Java peuvent appeler des commandes shell, les applications Node.js peuvent invoquer des interpréteurs de commandes et les systèmes hébergés sur IIS peuvent exécuter des scripts d'administration.

Pour cette raison, cette requête constitue un bon point de départ pour la chasse aux menaces. Le premier objectif doit être de comprendre quelles combinaisons parent-enfant génèrent le volume.

Les regroupements utiles comprennent :

• processus parent ;

• processus enfant ;

• nom d'hôte ;

• compte de service ou utilisateur ;

• ligne de commande ;

• chemin d'exécution ;

• fréquence.

Si la plupart des événements proviennent d’un serveur d’applications connu qui lance de façon répétée le même script approuvé, ce comportement peut être documenté. Un événement rare w3wp.exe → powershell.exe sur un serveur exposé à Internet peut en revanche justifier une investigation immédiate.

Investiguer les événements suspects

La ligne de commande est l'un des champs les plus importants à examiner. Un script d'administration connu présente un profil de risque très différent d'une commande PowerShell encodée inattendue, d'une URL de téléchargement externe ou d'une commande qui effectue de la découverte.

Les analystes doivent également examiner l'activité immédiatement avant et après l'événement de création de processus. Les questions utiles comprennent :

• L'application a-t-elle reçu des requêtes inhabituelles avant le démarrage du processus ?

• Le processus enfant a-t-il créé d'autres processus ?

• A-t-il écrit des fichiers dans des répertoires temporaires ou applicatifs ?

• A-t-il établi des connexions réseau sortantes ?

• A-t-il modifié des paramètres de sécurité ou des mécanismes de persistance ?

• Une activité similaire s'est-elle produite sur d'autres systèmes ?

Plus les preuves environnantes sont solides, plus le SOC peut accorder de confiance à la détection.

Ajuster la détection

La détection doit être réglée avec soin. Des exclusions larges, comme ignorer tous les événements java.exe → cmd.exe ou w3wp.exe → powershell.exe, pourraient supprimer une visibilité de sécurité précieuse.

Une meilleure approche consiste à créer des exceptions étroites à l'aide de combinaisons telles que :

hôte connu + chemin de processus connu + ligne de commande connue + compte de service connu

Cela préserve la détection comportementale tout en réduisant le bruit opérationnel attendu.

De la règle de recherche à la règle de détection

Une fois l'activité normale de l'environnement comprise, la même requête peut être convertie en une alerte plus précise. Les variantes à forte valeur peuvent se concentrer sur des relations parent-enfant rares, des hôtes inattendus, des lignes de commande inhabituelles, des téléchargements externes ou des exécutions depuis des emplacements accessibles en écriture par l'utilisateur.

Le principe clé est simple : les services web et applicatifs ne doivent pas se comporter de manière inattendue comme des utilisateurs interactifs. Surveiller le moment où ils commencent à lancer des shells ou des utilitaires système peut fournir un signal précieux pour détecter le RCE et l'activité de post-exploitation.