Punti chiave
- Il threat hunting è la ricerca proattiva, guidata da un'ipotesi, di attaccanti già presenti nei sistemi che i controlli automatici non hanno segnalato. Il NIST lo descrive nel controllo RA-10 della SP 800-53 Rev. 5.
- Il monitoraggio degli alert parte da una regola che scatta; il threat hunting parte da una domanda dell'analista e cerca nei log anche senza alert. Una caccia ben fatta lascia una regola di rilevamento nuova.
- Per M-Trends 2026 di Mandiant il dwell time mediano globale è salito a 14 giorni (11 l'anno prima), e a 122 giorni negli incidenti di spionaggio e in quelli legati ai lavoratori IT nordcoreani.
- Conviene cercare comportamenti (TTP) più che indicatori: un hash o un IP l'attaccante li cambia in fretta. Le ipotesi si scrivono con MITRE ATT&CK, che nella v20 conta 15 tattiche, 227 tecniche e 479 sotto-tecniche Enterprise.
- NIS2, DORA e ISO 27001 non nominano il threat hunting, ma chiedono gestione degli incidenti, individuazione tempestiva delle anomalie (DORA art. 10) e monitoraggio (ISO 27001 controllo 8.16).
Il threat hunting è la ricerca proattiva di un attaccante già presente nei sistemi che nessun controllo automatico ha segnalato. Il monitoraggio degli alert parte da una regola che scatta e chiede a un analista di valutarla. Il threat hunting parte da un'ipotesi dell'analista, per esempio qualcuno usa credenziali rubate per muoversi tra i server, e la verifica nei log anche senza alcun alert.
In questo articolo trovi la definizione del NIST, la differenza pratica con il lavoro sugli alert, i dati che spiegano perché serve, come si svolge una caccia passo per passo, cosa dicono NIS2, DORA e ISO 27001 e come ci si organizza in un'azienda mid-market.
Cos'è il threat hunting: la definizione del NIST
La definizione più usata come riferimento è quella del NIST, nel catalogo dei controlli di sicurezza SP 800-53 Rev. 5. Il controllo RA-10 Threat Hunting chiede di costruire e mantenere una capacità di threat hunting per due scopi: cercare indicatori di compromissione nei sistemi dell'organizzazione, e rilevare, tracciare e interrompere le minacce che sfuggono ai controlli esistenti. La frequenza con cui la si esercita la decide l'organizzazione.
La guida che accompagna il controllo aggiunge tre punti utili:
- il threat hunting è una forma attiva di difesa, diversa dalle misure tradizionali come firewall, sistemi di rilevamento e prevenzione delle intrusioni, sandbox e SIEM;
- l'obiettivo è intercettare l'avversario il prima possibile nella sequenza dell'attacco e rendere più rapida e precisa la risposta, in modo misurabile;
- chi fa threat hunting usa la threat intelligence esistente e ne produce di nuova, che può condividere con altre organizzazioni, ISAC ed enti pubblici.
Threat hunting e monitoraggio degli alert: la differenza
Le due attività convivono nello stesso SOC e usano gli stessi dati, ma partono da punti opposti.
- Da dove parte. Il monitoraggio parte da un alert generato da una regola del SIEM o dell'EDR. Il threat hunting parte da una domanda formulata da una persona.
- Cosa cerca. Il monitoraggio valuta se un evento già segnalato è un incidente vero. Il threat hunting cerca ciò che non ha generato nessun segnale, perché la regola non esiste, è scritta male o l'attaccante l'ha aggirata.
- Come procede. Il monitoraggio è continuo e reattivo, misurato sui tempi di presa in carico. Il threat hunting è a campagne, con un inizio, una fine e un esito documentato.
- Cosa lascia. Il monitoraggio chiude o scala un alert. Una caccia ben fatta lascia anche qualcosa che resta: una regola di rilevamento nuova, una fonte di log da aggiungere, una configurazione da correggere.
In sintesi: il monitoraggio trova quello che sai già cercare, il threat hunting allarga quello che sai cercare.
Perché serve: quello che i controlli non vedono
Il rapporto M-Trends 2026 di Mandiant (Google Cloud), basato su oltre 500.000 ore di indagini su incidenti condotte nel 2025, dà la misura del problema:
- il dwell time mediano globale, cioè il tempo in cui l'attaccante resta nei sistemi prima di essere scoperto, è salito a 14 giorni dagli 11 dell'anno prima. Mandiant lo collega alla crescente capacità di eludere i controlli;
- negli incidenti di spionaggio informatico e in quelli legati ai lavoratori IT nordcoreani la mediana è di 122 giorni;
- nel 52% delle indagini la prima evidenza dell'attacco è stata rilevata dall'organizzazione stessa, contro il 43% del 2024: negli altri casi la notizia è arrivata da una fonte esterna;
- alcuni gruppi colpiscono VPN e router, apparati che di solito non hanno la telemetria di un EDR. Con minacce come BRICKSTORM, rimaste nei sistemi per quasi 400 giorni, una conservazione dei log di 90 giorni non basta a ricostruire da dove è entrato l'attaccante.
Nelle sue raccomandazioni Mandiant indica di passare dagli indicatori statici a un rilevamento basato sui comportamenti e sugli scostamenti da una baseline, perché gli attaccanti cambiano infrastruttura in fretta e usano malware su misura che gira in memoria. È esattamente il terreno del threat hunting.
Dagli hash alle TTP: cosa conviene cercare
Non tutti gli indicatori valgono uguale. Nel 2013 David Bianco ha descritto la Pyramid of Pain, che ordina gli indicatori in base a quanto costa all'attaccante perderli:
- Hash dei file: molto precisi, ma basta modificare un bit del file per cambiarli;
- indirizzi IP e nomi di dominio: si sostituiscono con poco sforzo;
- artefatti di rete e di host: chiavi di registro, pattern di URL, user agent anomali;
- strumenti: il software che l'attaccante porta con sé;
- TTP (tattiche, tecniche e procedure): il modo in cui l'attaccante lavora, dalla ricognizione all'esfiltrazione.
Un elenco di indicatori di compromissione si carica nel SIEM e scatta da solo. Il valore del threat hunting sta nei livelli alti: cercare un comportamento, come il riuso di credenziali per accedere a un server, resta utile anche quando l'attaccante ha cambiato tutti i suoi IP e i suoi file. È per questo che hunting e threat intelligence lavorano insieme: l'intelligence dice quali TTP usano i gruppi che colpiscono il tuo settore, il threat hunting verifica se sono già in casa.
MITRE ATT&CK, il linguaggio comune delle ipotesi
Per descrivere le TTP in modo condiviso si usa MITRE ATT&CK, la base di conoscenza pubblica dei comportamenti osservati negli attacchi reali. La versione corrente è la v20, pubblicata il 13 ottobre 2026: la matrice Enterprise conta 15 tattiche, 227 tecniche e 479 sotto-tecniche.
Le tattiche sono il perché di un'azione (ottenere l'accesso iniziale, persistere, muoversi lateralmente, esfiltrare), le tecniche sono il come. Un'ipotesi di caccia ben scritta parte quasi sempre da una tecnica. Un esempio: la sotto-tecnica T1550.002 descrive il pass-the-hash, cioè l'autenticazione con l'hash di una password rubata al posto della password stessa. L'ipotesi diventa: negli ultimi 30 giorni ci sono autenticazioni NTLM da postazioni che normalmente non amministrano server? È una domanda a cui i log rispondono, e che nessun alert generico pone da solo.
Come si svolge una caccia, passo per passo
- Formulare l'ipotesi. Da un report di intelligence, da una tecnica ATT&CK rilevante per il settore, da un incidente passato o da un'anomalia notata durante il triage. L'ipotesi deve essere verificabile con i dati disponibili.
- Verificare di avere i dati. Quali log servono (endpoint, autenticazioni, DNS, proxy, cloud) e per quanto tempo indietro. Se mancano, la caccia si ferma qui ma ha già prodotto un risultato: una lacuna di visibilità da chiudere.
- Cercare. Query sui log centralizzati, confronto con il comportamento normale di utenti e sistemi, pivot da un'evidenza all'altra.
- Analizzare. Separare l'attività legittima da quella sospetta. Qui serve chi conosce l'ambiente: uno script di backup e uno strumento di esfiltrazione possono somigliarsi molto.
- Chiudere con un esito. Se emerge una compromissione, si passa all'incident response. Se non emerge niente, l'ipotesi è respinta e si documenta perché.
- Trasformare la caccia in rilevamento. Quello che hai cercato a mano diventa una regola che il SIEM esegue da solo da domani. È il passaggio che fa crescere la copertura nel tempo.
Cosa serve per farlo
Dati centralizzati e conservati abbastanza a lungo
Senza log non c'è caccia. Servono le fonti giuste in un unico posto, normalizzate, e una conservazione che copra i tempi reali degli attacchi: con un dwell time mediano di 14 giorni e casi oltre i 120, una finestra di poche settimane lascia fuori proprio gli eventi che contano.
Persone con tempo dedicato
Un analista sommerso dagli alert non fa threat hunting, perché la coda ha sempre la priorità. La caccia richiede tempo protetto e competenze specifiche: conoscenza delle TTP, del linguaggio di query della piattaforma e dell'ambiente che si sta analizzando.
Strumenti che rendono la ricerca veloce
In Google Security Operations (Google SecOps) la ricerca sui log normalizzati nel modello UDM usa il linguaggio YARA-L 2.0 o SQL, e la documentazione di Google indica la modalità Basic proprio per il threat hunting iniziale e la verifica delle ipotesi su finestre temporali ampie. Secondo la pagina del prodotto, i pacchetti includono un anno di conservazione della telemetria di sicurezza. Google documenta anche il Threat Hunt Agent, un agente basato su Gemini e fondato su Google Threat Intelligence, sull'esperienza di Mandiant e su MITRE ATT&CK, che pianifica la caccia, costruisce le query e analizza le evidenze: al momento è in anteprima pubblica e riservato ai clienti Enterprise Plus.
NIS2, DORA e ISO 27001 chiedono il threat hunting?
Nessuna delle tre usa il termine. Chiedono però capacità che il threat hunting aiuta a dimostrare.
- DORA. Il Regolamento (UE) 2022/2554, all'art. 10, chiede alle entità finanziarie meccanismi per individuare tempestivamente le attività anomale, testati periodicamente, e risorse e capacità sufficienti per monitorare l'attività degli utenti, le anomalie e gli incidenti TIC, in particolare gli attacchi informatici.
- NIS2. La Direttiva (UE) 2022/2555, recepita in Italia dal D.Lgs. 138/2024, non nomina il threat hunting. Fra le misure minime di gestione dei rischi, l'art. 21, par. 2, elenca la gestione degli incidenti, che presuppone la capacità di accorgersene.
- ISO/IEC 27001:2022. Nell'Annex A i controlli più vicini sono l'8.16 Monitoring activities e il 5.7 Threat intelligence.
- NIST SP 800-53. È l'unico dei riferimenti citati con un controllo dedicato, il RA-10, che però non fa parte della baseline High: l'organizzazione lo sceglie in base al proprio rischio.
Per un'azienda soggetta a NIS2 o DORA, quindi, il threat hunting non è un adempimento a sé, ma un modo concreto per mostrare a un auditor che il rilevamento non si ferma alle regole preconfezionate.
Interno o gestito: come si organizza un'azienda mid-market
Un programma di threat hunting interno richiede almeno una persona con tempo dedicato, una piattaforma con dati centralizzati e una conservazione adeguata, e un processo che trasformi ogni caccia in rilevamento. Per molte aziende del mid-market è più realistico trovarlo dentro un servizio: un MDR o un SOC gestito che lo include fa cacce periodiche e mirate sui dati del cliente, oltre al monitoraggio 24 ore su 24.
Quando valuti un fornitore, tre domande aiutano a capire se il threat hunting è reale:
- con che frequenza fate cacce sui nostri dati, e su quali ipotesi?
- cosa ci consegnate alla fine di una caccia, anche quando non trovate niente?
- quante regole di rilevamento sono nate dalle cacce negli ultimi sei mesi?
In sintesi: il threat hunting è la ricerca proattiva, guidata da un'ipotesi, di attaccanti che i controlli automatici non hanno segnalato. Si appoggia a MITRE ATT&CK per formulare le ipotesi, punta ai comportamenti più che agli indicatori, e ogni caccia ben fatta lascia una regola di rilevamento in più. Se vuoi un monitoraggio 24 ore su 24 su Google SecOps con cacce periodiche sui tuoi dati e l'intelligence di Mandiant, guarda come lavora il nostro SOC gestito e MDR.