Le vulnerabilità di esecuzione di codice remoto possono consentire a un attaccante di passare da un'applicazione vulnerabile al sistema operativo che la ospita. Sebbene la vulnerabilità iniziale possa differire da un prodotto all'altro, l'attività di post-sfruttamento produce spesso relazioni tra processi simili che i difensori possono monitorare.

Un segnale particolarmente utile è un processo di un'applicazione o di un web server che avvia inaspettatamente una shell dei comandi, un motore di script o uno strumento di sistema. Su Windows, ciò può fornire visibilità sul punto in cui lo sfruttamento dell'applicazione diventa esecuzione sul sistema.

Dallo sfruttamento delle applicazioni web ai comandi di sistema

Il rilevamento si concentra sui processi lato server come IIS, WSUS, Tomcat, Java, Apache, Nginx, PHP e Node.js. Questi processi hanno normalmente schemi di esecuzione prevedibili. Quando iniziano a creare processi figlio come cmd.exe, powershell.exe, pwsh.exe, wscript.exe, mshta.exe, rundll32.exe, certutil.exe, bitsadmin.exe o curl.exe, l’attività merita di essere indagata.

La fonte associa questo comportamento a RCE che interessano SharePoint, WSUS, applicazioni ospitate su IIS, SAP su Windows, console di gestione web e vulnerabilità legate a deserializzazione o caricamento di file.

Una catena di processi sospetta può avere questo aspetto:

w3wp.exe → powershell.exe

oppure:

java.exe → cmd.exe

La relazione tra i processi in sé non è una prova di compromissione, ma può indicare che un'applicazione lato server ha iniziato a eseguire comandi al di fuori del normale flusso applicativo.

Query di rilevamento

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 fonte ha registrato 15,523 corrispondenze nei 30 giorni precedenti.

Perché il numero di risultati è importante

Un numero elevato di corrispondenze non significa automaticamente che si siano verificati migliaia di attacchi. I server applicativi a volte eseguono script o strumenti da riga di comando per legittimi motivi operativi. Le applicazioni Java possono richiamare comandi di shell, le applicazioni Node.js possono invocare interpreti di comandi e i sistemi ospitati su IIS possono eseguire script amministrativi.

Per questo motivo, questa query funziona bene come punto di partenza per il threat hunting. Il primo obiettivo dovrebbe essere capire quali combinazioni padre-figlio generano il volume.

Raggruppamenti utili includono:

• processo padre;

• processo figlio;

• nome del sistema;

• account di servizio o utente;

• riga di comando;

• percorso di esecuzione;

• frequenza.

Se la maggior parte degli eventi proviene da un server applicativo noto che avvia ripetutamente lo stesso script approvato, tale comportamento può essere documentato. Un evento raro w3wp.exe → powershell.exe su un server esposto a Internet, tuttavia, può meritare un’indagine immediata.

Indagare sugli eventi sospetti

La riga di comando è uno dei campi più importanti da esaminare. Uno script amministrativo noto ha un profilo di rischio molto diverso da un comando PowerShell codificato inatteso, da un URL di download esterno o da un comando che esegue attività di individuazione.

Gli analisti dovrebbero inoltre esaminare l'attività immediatamente precedente e successiva all'evento di creazione del processo. Domande utili includono:

• L'applicazione ha ricevuto richieste insolite prima dell'avvio del processo?

• Il processo figlio ha creato ulteriori processi?

• Ha scritto file in cartelle temporanee o applicative?

• Ha stabilito connessioni di rete in uscita?

• Ha modificato impostazioni di sicurezza o meccanismi di persistenza?

• Si è verificata un'attività simile su altri sistemi?

Quanto più solide sono le prove circostanti, tanto maggiore è la fiducia che il SOC può riporre nel rilevamento.

Messa a punto del rilevamento

Il rilevamento deve essere calibrato con attenzione. Esclusioni ampie, come ignorare ogni evento java.exe → cmd.exe o w3wp.exe → powershell.exe, potrebbero eliminare una preziosa visibilità di sicurezza.

Un approccio migliore consiste nel creare eccezioni circoscritte usando combinazioni come:

host noto + percorso di processo noto + riga di comando nota + account di servizio noto

Questo preserva il rilevamento basato sul comportamento riducendo al contempo il rumore operativo atteso.

Da regola di threat hunting a regola di rilevamento

Una volta compresa l'attività normale nell'ambiente, la stessa query può essere trasformata in un alert più preciso. Le varianti di alto valore possono concentrarsi su rare relazioni padre-figlio, host inattesi, righe di comando insolite, download esterni o esecuzione da posizioni scrivibili dall'utente.

Il principio chiave è semplice: i servizi web e applicativi non dovrebbero comportarsi inaspettatamente come utenti interattivi. Monitorare il momento in cui iniziano ad avviare shell o strumenti di sistema può fornire un segnale prezioso per rilevare RCE e attività di post-sfruttamento.