Che cos'è la caccia alle minacce nella sicurezza informatica? Manuale di istruzioni end-to-end (2026)
Cyberlord Security Team Profilo autore
Mai un avviso, nessun incidente per settimane: la console di sicurezza ferma non prova che l'ambiente sia pulito, prova solo che nessun rilevamento ha incrociato quel comportamento. Cos'è la caccia alle minacce nella sicurezza informatica riguarda esattamente questo vuoto: è l'indagine proattiva che l'analista conduce su log e telemetria per trovare un aggressore già attivo in silenzio.
La differenza con la risposta agli incidenti è netta: la risposta parte da un avviso, la caccia parte da un'ipotesi. Qui trovi la definizione operativa, il metodo per costruire ipotesi da MITRE ATT&CK, il triage delle fonti di log, il flusso di lavoro dall'ipotesi al verdetto, i prerequisiti per un SOC piccolo e gli errori che fermano un programma di hunting sul nascere.
1. Cos'è la caccia alle minacce nella sicurezza informatica
Risposta breve: la caccia alle minacce (threat hunting) è l'indagine strutturata e proattiva per individuare compromissioni in corso che i rilevamenti automatici non hanno segnalato. L'analista formula un'ipotesi sul comportamento di un attaccante, la verifica sui dati disponibili e chiude con un verdetto documentato e, quando serve, con una nuova regola di rilevamento.
La definizione regge solo con il contesto operativo. Una caccia utile tocca identità (chi può eseguire cosa su quali macchine), qualità della telemetria (ciò che non viene registrato non può essere cercato) e ingegneria dei rilevamenti (il risultato deve diventare un controllo duraturo). Se manca un anello, l'indagine resta senza conseguenze per l'ambiente.
2. Caccia guidata da ipotesi e pianificazione secondo il NIST
Esistono due stili di caccia. Nel modello guidato da ipotesi (hypothesis-driven) la domanda è falsificabile: «se un aggressore estraesse credenziali da LSASS o eseguisse comandi PowerShell oscurati, che tracce lascerebbe nel nostro EDR?». L'analista costruisce la query, la esegue e ordina i risultati: è lo stile che produce scoperte nuove, ma richiede maturità sui dati.
L'altro punto di vista viene dal Cybersecurity Framework del NIST: si descrive lo stato attuale delle funzioni di rilevamento, si individuano le lacune e si scelgono scenari prioritari. Dove la funzione Rileva non ha copertura, la prossima caccia va cercata lì. I due stili si completano: il framework trova il buco, l'ipotesi lo esplora.
3. Framework operativi: PEAK e approccio threat-based
Tra i framework diffusi, PEAK alterna preparazione (fonti, ipotesi, formato dell'output), fasi guidate dall'intelligence sugli exploit in circolazione e una fase di knowledge che rende ogni caccia riutilizzabile: query salvate, note, ipotesi derivate. L'approccio threat-based parte invece da una minaccia specifica: si rilegge il report su un ransomware o un gruppo APT, si estraggono le TTP ricorrenti e le si traducono in query sui log propri — il ponte naturale con la guida sui TTP.
4. Da dove partire: triage delle fonti di log
La qualità di una caccia dipende prima dai dati che dall'ingegno dell'analista. Il triage tipico procede per priorità:
- Telemetria EDR: processi con linee di comando complete, registro di sistema, DLL, connessioni di rete.
- Log di identità: accessi riusciti e falliti (4624/4625 su Windows), creazioni di account, anomalie Kerberos, attività degli account privilegiati.
- Rete e DNS: risoluzioni verso domini appena registrati, flussi in orario anomalo.
- Console applicative e cloud: azioni amministrative su SaaS e provider cloud.
Ogni ipotesi va confrontata con le fonti prima di iniziare: ipotizzare uno script PowerShell oscurato senza logging dei moduli significa costruire una caccia non verificabile. Tre segnali di problemi di qualità dei dati: agenti EDR disattivati, retention troppo breve, parser difettosi.
5. Il flusso di lavoro: dall'ipotesi al verdetto
Il ciclo operativo della caccia passa dagli stessi passi:
- Formulazione: un'ipotesi falsificabile, ancorata a una tecnica ATT&CK e a un asset prioritario.
- Perimetro: quali log, quale finestra temporale, quali macchine.
- Raccolta: prime query, restrizioni del rumore, verifica dei falsi positivi attesi.
- Analisi: triage dei risultati, correlazione tra fonti, ricostruzione della sequenza se emerge qualcosa.
- Verdetto: positivo reale (scatta la risposta all'incidente), positivo benigno (attività legittima da escludere nelle prossime query) o lacuna di dati (l'ipotesi non è testabile finché la telemetria non migliora).
- Chiusura: documentazione, eventuale nuovo rilevamento testato, aggiornamento della cassetta degli strumenti.
Un programma sano annota i lead aperti: indizi che meritano una verifica successiva con dati migliori. Un lead non è un verdetto, e confonderli mina la credibilità del programma.
6. Concetti fondamentali su cui ogni team dovrebbe allinearsi
- Ipotesi falsificabile: una domanda che si può negare sui dati disponibili
- Responsabilità chiare: chi caccia, chi converte in rilevamenti, chi risponde
- Priorità alla criticità: identità amministrative, server esposti, dati sensibili
- Visibilità certificata: fonti di log complete e leggibili
- Ciclo di chiusura: verdetto scritto e artefatto riutilizzable
Senza questo terreno comune la caccia degenera in ricerche occasionali che non lasciano né rilevamenti né memoria.
7. Cruscotto e caccia non sono la stessa cosa
Un cruscotto mostra quello che i rilevamenti già sanno: avvisi su comportamento classificato, definito a partire da incidenti passati. La caccia opera nell'intervallo che resta fuori: comportamenti che nessuna regola descrive, tecniche per cui l'ambiente non ha mai visto un campione. Un cruscotto tutto verde non esclude quindi una compromissione in corso: la caccia serve a mettere alla prova quel verde.
8. Errori comuni che bloccano un programma di hunting
Il primo è comprare la piattaforma prima di definire il metodo: senza cadenza, ipotesi e formato di output la caccia resta una ricerca sporadica. Il secondo è formulare ipotesi non falsificabili («ci sono indizi di compromissione?»), che non si possono chiudere con un sì o con un no. Il terzo è il verdetto positivo senza conversione: nessuno scrive il rilevamento e la ricerca va ripetuta da capo. Il quarto è la dipendenza da un solo senior: note, query e lead lasciano l'organizzazione insieme a lui. Il quinto è la chiusura in silos: la caccia trova, ma risposta all'incidente e operazioni IT non ricevono le informazioni.
Ogni errore è prevenibile con una cadenza di revisione condivisa e un formato unico per gli esiti.
9. Prerequisiti realistici per un SOC piccolo
Non serve un centro di operazioni a tempo pieno: tre prerequisiti bastano per iniziare:
- Una console EDR o log centralizzati con ricerca salvata: endpoint, identità, rete essenziale
- Un tempo protetto: un paio di ore a settimana solo per la caccia, non per i ticket
- Un elenco corto di tecniche: accesso a LSASS, script PowerShell sospetti, servizi remoti, movimento laterale via WMI o SMB
Con questo nucleo ci si appoggia alle risorse MITRE ATT&CK e CISA indicate più avanti. La prima caccia convertita in un rilevamento che resta attivo vale più di dieci ricerche sporadiche.
10. Lista di controllo pratica
- Scegliere una tecnica ATT&CK prioritaria per il proprio settore e formulare l'ipotesi.
- Verificare che le fonti di log che la sostengono esistano, siano aggiornate e leggibili.
- Eseguire le query e documentare i risultati, inclusi i falsi positivi previsti.
- Scrivere il verdetto: positivo reale, positivo benigno o lacuna di dati.
- Convertire i risultati in un rilevamento testato, un playbook o una richiesta di telemetria.
- Aggiornare l'elenco dei lead aperti e pianificare la caccia successiva.
Il valore della caccia non sta nella singola ricerca brillante, ma nella ripetizione completa del ciclo.
11. Metriche che dimostrano il miglioramento
- Cacce chiuse con verdetto documentato, non cacce soltanto avviate
- Percentuale di ipotesi mappate su tecniche ATT&CK
- Conversione: quante cacce producono un rilevamento o un aggiornamento delle fonti
- Lacune di telemetria individuate e chiuse
- Tempo dal verdetto positivo al contenimento da parte della risposta all'incidente
Metriche si rivedono insieme a sicurezza e operazioni IT: la caccia vale se i risultati cambiano le difese.
12. Piano di implementazione in 30-60-90 giorni
Giorni 1-30
- Mappare le fonti: quali log esistono, quali sono completi, quali mancano
- Scegliere le prime tre ipotesi partendo da ATT&CK e dal proprio settore
- Definire il formato di output: modello di ipotesi, modello di verdetto, registro dei lead
Giorni 31-60
- Eseguire le prime cacce con cadenza regolare, ognuna chiusa con un verdetto
- Convertire il primo risultato in un rilevamento e testarlo con una simulazione controllata
- Controllare che le ipotesi coprano davvero le identità privilegiate e gli asset più esposti
Giorni 61-90
- Rivedere le priorità delle fonti e colmare la lacuna più grave
- Addestrare un secondo analista per non dipendere da una sola persona
- Rendicontare alla leadership: cacce chiuse, conversioni, lacune aperte
Riferimenti affidabili per approfondire
- Cybersecurity Framework del NIST: https://www.nist.gov/cyberframework
- Risorse CISA sulla cybersecurity: https://www.cisa.gov/cybersecurity
- MITRE ATT&CK: https://attack.mitre.org/
- Documentazione di sicurezza Microsoft: https://learn.microsoft.com/security/
Domande frequenti
Qual è il rischio maggiore di implementazione?
Mancanza di proprietà e di metodo: cacce occasionali senza cadenza, formato e responsabile non lasciano né rilevamenti né memoria.
Quanto velocemente il team vede i risultati?
Con cadenza e formato di output già definiti, le prime conversioni in rilevamento arrivano in genere tra i 30 e i 90 giorni.
È pensata solo per le grandi organizzazioni?
No. Con una console EDR, un elenco corto di tecniche e qualche ora protetta a settimana, anche un team ridotto esegue cacce valide e le converte in rilevamenti.
Cosa conviene misurare per primo?
Copertura delle identità privilegiate, velocità di chiusura dei verdetti, conversione in rilevamenti.
Come si mantiene efficace la caccia nel tempo?
Con cadenza di revisione, formato unico di verdetto e conversione sistematica dei risultati in rilevamenti testati.
Conclusione
A questo punto la caccia alle minacce è un ciclo che si avvia subito: ipotesi da ATT&CK, triage delle fonti, verdetto documentato, conversione in rilevamento, revisione periodica. Serve supporto per implementarlo? Contatta Cyberlord per una roadmap pratica.