Threat Hunting: Cos'è e Come Funziona

Il threat hunting è la pratica di cercare proattivamente all'interno di reti ed endpoint gli attaccanti che hanno già superato i tuoi rilevamenti esistenti. Parte da un presupposto semplice e sgradevole: qualcosa di brutto potrebbe essere già dentro, e nessun alert l'ha segnalato. Invece di aspettare che una regola SIEM si attivi, un hunter forma un'ipotesi e inizia a cercare prove per confermarla o scartarla.

Perché il rilevamento da solo non basta

Il rilevamento basato su firma e su regole cattura i pattern noti. Gli attaccanti che usano living-off-the-land binaries (LOLBins), credenziali valide, o tecniche lente e a basso volume possono stare al di sotto di quelle soglie per settimane. Il threat hunting colma quel gap avendo un umano che questiona attivamente i dati: ha senso questa invocazione PowerShell da una workstation finance alle 2 di mattina? Perché svchost.exe sta facendo una connessione outbound verso un IP senza reverse DNS?

Questa non è incident response. L'IR inizia dopo che sai che è successo qualcosa. L'hunting inizia quando non lo sai ancora, e l'obiettivo è scoprirlo prima che un evento più grande forzi la domanda.

I tre punti di partenza comuni

La maggior parte degli hunt inizia da uno di questi tre angoli:

• Intelligence-driven: un nuovo threat report descrive una TTP (per esempio, abuso di un'attività pianificata per la persistenza), e tu verifichi se è presente nel tuo ambiente.
• Situational awareness: guardi cosa è davvero insolito per la tua organizzazione — un service account che si autentica da un paese da cui non l'ha mai fatto, o un picco di traffico SMB tra workstation che normalmente parlano solo con i server.
• Analytics-driven: costruisci una baseline del comportamento normale (process tree, orari di login, volume di query DNS) e cerchi gli outlier statistici rispetto ad essa.

MITRE ATT&CK è il riferimento che la maggior parte dei team usa per strutturare le ipotesi. Invece di "cerca il malware", scegli una tecnica come T1053 (Scheduled Task/Job) e chiediti: come apparirebbe nei nostri Windows Event Logs o nella telemetria EDR, e posso interrogarla adesso?

Come appare il flusso di lavoro effettivo

Un hunt solitamente segue questo ciclo:

1. Forma un'ipotesi specifica e testabile (non "controlla per intrusioni" ma "controlla per nuove attività pianificate create al di fuori delle finestre di patch negli ultimi 30 giorni").
2. Identifica le fonti dati necessarie — Sysmon Event ID 1 per la creazione di processo, Windows Security Event ID 4698 per la creazione di attività pianificata, process tree EDR, o Zeek conn log per il contesto di rete.
3. Query e pivot. In pratica questo significa scrivere KQL in Microsoft Sentinel, SPL in Splunk, o query grezze contro un indice Elastic.
4. Triage dei risultati — la maggior parte saranno falsi positivi o attività admin benigne, e il lavoro è ridurre quel rumore a quello che è genuinamente anomalo.
5. Documenta i risultati, che sia un compromesso confermato, un gap di rilevamento, o semplicemente