Threat Hunting oltre gli alert: principi e modelli operativi
La pratica del Threat Hunting esiste da molti anni, ben prima di essere formalizzata con questa denominazione. Prima di fornirne una definizione, è opportuno chiarire alcuni fraintendimenti, specificando innanzitutto che cosa non è. In primo luogo, non coincide con la Cyber Threat Intelligence (CTI), che si focalizza prevalentemente sull’analisi e sulla profilazione delle minacce emergenti, né con l’Incident Response (IR), il cui obiettivo è la gestione di un incidente già in corso. Pur essendo strettamente correlate, queste discipline perseguono finalità differenti. Quali sono dunque le relazioni tra queste attività? La CTI può rappresentare un valido punto di partenza per il Threat Hunting, fornendo contesto e ipotesi sulle possibili minacce da ricercare. L’Incident Response, invece, costituisce spesso la fase successiva, avviata da un’organizzazione in seguito all’individuazione di una compromissione attraverso un’attività di Threat Hunting condotta con successo. È importante sottolineare che il Threat Hunting è un’attività human-driven, guidata dall’analisi, dall’esperienza e dal giudizio umano. Analogamente alla Threat Intelligence, adotta un approccio proattivo alla sicurezza, poiché mira a individuare le minacce prima che sia troppo tardi; non si tratta, quindi, di una misura reattiva come l’Incident Response. Che cos’è il Threat Hunting? Il Threat Hunting è un approccio proattivo orientato alla ricerca di minacce già presenti all’interno di una rete aziendale e che sono riuscite ad eludere i controlli dei sistemi di sicurezza implementati. Tale attività si basa sull’assunto che una violazione sia già avvenuta e prevede una ricerca continua di segnali di compromissione all’interno dell’ambiente organizzativo. L’obiettivo principale di un threat hunter è identificare una compromissione nel minor tempo possibile, al fine di ridurne l’impatto e minimizzare il dwell time. Quest’ultimo rappresenta l’intervallo di tempo che intercorre tra il momento in cui un attaccante riesce a infiltrarsi in una organizzazione e quello in cui viene rilevato. Secondo Mandiant nel 2024 il dwell time è stato di 11 giorni (https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2025 ). Un aspetto fondamentale da comprendere è che la riduzione del dwell time rappresenta una sfida continua e potenzialmente senza fine. È ampiamente riconosciuto che quanto più a lungo un attaccante riesce a rimanere all’interno di un’organizzazione senza essere individuato, tanto maggiori saranno le opportunità di occultare le proprie attività e più gravi i danni che potrà causare. Il dwell time costituisce pertanto un fattore di rischio critico, poiché: una permanenza prolungata consente all’attaccante di esplorare l’infrastruttura e compromettere ulteriori asset. aumenta la probabilità di esfiltrazione dei dati, della creazione di backdoor persistenti o della preparazione di attacchi futuri. una mancata rilevazione per un lungo periodo riduce l’efficacia delle contromisure difensive e rende la risposta all’incidente più complessa e costosa. Di conseguenza, un Threat Hunter deve mantenersi costantemente aggiornato, acquisendo conoscenze sulle nuove tecniche adottate dagli avversari, così da migliorare progressivamente le capacità di rilevamento e ridurre il dwell time. In sintesi, il Threat Hunting è un’attività human-driven che consiste nella ricerca proattiva di segnali di compromissione all’interno di un’organizzazione con l’obiettivo di ridurre il dwell time e minimizzare l’impatto di una violazione. Costruzione dell’ipotesi Sebbene l’esperienza abbia un peso rilevante, ciò non implica che solo professionisti altamente specializzati possano svolgere attività di Threat Hunting. Va tuttavia considerato che alcune tecniche richiedono anni di pratica per essere pienamente padroneggiate. Una delle competenze fondamentali di un buon threat hunter è la capacità di porsi le domande giuste al fine di formulare un’ipotesi di caccia, ovvero una supposizione strutturata e motivata sull’esistenza di una possibile attività malevola all’interno dell’ambiente dell’organizzazione. Il threat hunter deve inoltre essere in grado di trovare risposte a tali domande, attraverso l’analisi dei dati disponibili, per confermare o smentire l’ipotesi formulata. L’ipotesi è al centro di ogni processo di Threat Hunting e si basa in parte sull’osservazione di eventi anomali rispetto alla baseline dell’ambiente e in parte su informazioni che possono derivare dall’esperienza del threat hunter o da altre fonti, come la threat intelligence. La corretta formulazione dell’ipotesi è cruciale per condurre attività di caccia efficaci, un’ipotesi poco definita può condurre a risultati fuorvianti o a conclusioni errate, con potenziali conseguenze negative per l’organizzazione. Un’ipotesi ben definita deve essere concisa, concreta e testabile, senza presupporre una disponibilità illimitata di tempo e risorse. Un’ipotesi che il threat hunter non è in grado di verificare non è utile; pertanto, nella sua formulazione devono essere considerate le strumentazioni disponibili e i dati necessari. L’ipotesi non deve essere né troppo ampia né eccessivamente specifica, ma deve indicare chiaramente le fonti dei dati da analizzare e ciò che si intende cercare. Robert M. Lee e David Bianco hanno scritto un whitepaper per SANS intitolato Generating Hypotheses for Successful Threat Hunting. In questo documento, essi distinguono tre principali tipi di ipotesi: Basata sulla Threat Intelligence: questo tipo di ipotesi prende in considerazione gli Indicatori di compromissione (IOC) correttamente contestualizzati. Il principale rischio associato a questo tipo di ipotesi è l’eccessivo focus sugli IOC, che può generare corrispondenze di bassa qualità. È preferibile concentrarsi sulle TTP dell’attaccante piuttosto che su feed contenenti centinaia di indicatori. Basata sulla Situational Awareness: questo tipo di ipotesi si basa sull’identificazione degli asset più importanti all’interno dell’organizzazione, noto anche come Crown Jewels Analysis. L’hunter cerca di determinare cosa l’avversario potrebbe ricercare nell’ambiente dell’organizzazione, compresi i suoi obiettivi. Da questo punto di partenza, il threat hunter deve riflettere su quali dati e attività sarà necessario monitorare. È importante ricordare che non tutto deve rimanere confinato al dominio cyber: quando si formulano ipotesi basate sulla situational awareness, devono essere considerati anche persone, processi e requisiti di business. Basata sull’Expertise di Dominio: questo tipo di ipotesi deriva dall’esperienza e competenza del threat hunter. L’ipotesi generata è condizionata dal background e dalle esperienze del singolo hunter. Le cacce svolte in passato influenzeranno anch’esse le ipotesi future. In questo contesto, il processo di documentazione è particolarmente importante per registrare le lezioni apprese e condividerle con gli altri membri del team Le ipotesi migliori e di maggior successo sono quelle che combinano questi tre tipologie Tipologie di Threat Hunting Il team di Sqrrl ha individuato cinque differenti tipologie di Threat Hunting: data-driven, intel-driven, entity-driven, TTP-driven e hybrid. Contestualmente, tali tipologie possono essere ulteriormente classificate in strutturate (basate su un’ipotesi preliminare) e non strutturate (basate sull’osservazione di anomalie nei dati): L’approccio data-driven si basa sull’analisi approfondita dei dati di sicurezza disponibili (log, eventi di rete, endpoint telemetry), con l’obiettivo di individuare pattern anomali o comportamenti sospetti. L’approccio intel-driven è guidato da informazioni di Cyber Threat Intelligence, come indicatori di compromissione (IoC), report su campagne attive o profili di attaccanti, che orientano la ricerca verso minacce note o emergenti. L’approccio entity-driven si concentra sull’analisi del comportamento di specifiche entità (utenti, host, account di servizio), ricercando anomalie rispetto alla loro baseline. Il Threat Hunting TTP-driven prende come riferimento le Tactics, Techniques and Procedures degli attaccanti, spesso mappate tramite framework come MITRE ATT&CK, al fine di individuare segnali di compromissione anche in assenza di indicatori noti. Infine, l’approccio hybrid combina più metodologie, sfruttando simultaneamente dati, intelligence e modelli comportamentali per aumentare l’efficacia dell’attività di hunting. Le Competenze di un Threat Hunter Abbiamo già evidenziato che il Threat Hunting non è un’attività riservata esclusivamente ad analisti di sicurezza con elevata esperienza. Tuttavia, poiché la threat intelligence rappresenta uno dei principali elementi che attivano le attività di hunting, un buon threat hunter deve possedere almeno una conoscenza di base dei concetti fondamentali della Cyber Threat Intelligence, conoscere le tipologie di malware, le motivazioni o gli obiettivi dei threat actor, ecc… Inoltre, un threat hunter deve comprendere le modalità con cui un attaccante conduce un attacco, di conseguenza avere familiarità con il framework MITRE ATT&CK. Deve conoscere l’architettura di rete su cui si focalizza l’attività di hunting e avere dimestichezza con un SIEM, così da poter analizzare i log e individuare eventuali pattern anomali. Infine, il threat hunter deve saper comunicare in modo chiaro e strutturato i risultati delle proprie attività, affinché le evidenze emerse possano essere valorizzate e contribuiscano al miglioramento continuo del programma di Threat Hunting. La Pyramid of Pain La Pyramid of Pain di David Bianco è un modello utilizzato sia nella Cyber Threat Intelligence sia nel Threat Hunting. Rappresenta il livello di “dolore” che viene inflitto agli attaccanti quando sono costretti a modificare le proprie modalità operative a seguito dell’identificazione dei loro Indicatori di Compromissione, dell’infrastruttura di rete e degli strumenti utilizzati. I tre livelli inferiori della piramide (hash, indirizzi IP e nomi di dominio): sono principalmente rilevanti per i sistemi di rilevamento automatico. Si tratta di indicatori che un threat actor può modificare con relativa facilità e a costi contenuti. Ad esempio, se viene individuato l’hash di un malware o di uno strumento utilizzato dall’attaccante, quest’ultimo può aggirare il blocco semplicemente modificando il file, anche con cambiamenti minimi, ottenendo così un nuovo hash. Allo stesso modo, quando un nome di dominio viene scoperto e bloccato, l’attaccante può registrarne rapidamente un altro. Il cambio di indirizzi IP risulta ancora più semplice, mentre la registrazione e configurazione di nuovi domini richiede uno sforzo leggermente maggiore, poiché comporta costi e attività amministrative. I livelli intermedi della piramide, rappresentati dagli artefatti di rete e di host, richiedono invece un impegno più significativo per essere modificati dall’ attaccante. Rientrano in questa categoria indicatori come chiavi di registro, user agent o nomi di file. Se il team di Incident Response riesce a individuare e rilevare un numero elevato di questi indicatori, l’avversario può essere costretto a modificare in modo sostanziale o addirittura a riscrivere i propri strumenti di attacco. Un esempio utile è immaginare di aver investito tempo e risorse nello sviluppo di un software, adattandolo alle proprie esigenze, per poi doverlo abbandonare e ricominciare da zero. Pur sembrando un caso limite, rende bene l’idea della complessità che un attaccante deve affrontare Al vertice della piramide si collocano le tattiche, tecniche e procedure (TTP). In questo caso, la difesa non si concentra sugli strumenti utilizzati dall’attaccante, ma sulle modalità operative con cui viene condotto l’attacco. Il rilevamento delle TTP rappresenta l’azione più efficace, poiché obbliga l’avversario a cambiare il proprio modo di agire. Ciò comporta la necessità di ripensare le strategie adottate, apprendere nuovi metodi operativi e investire ulteriori risorse di tempo, di denaro e di competenze, rendendo l’attacco significativamente più costoso e complesso. Nella Pyramid of Pain, gli indicatori dei livelli inferiori sono più semplici da individuare, ma provocano un impatto limitato sull’attaccante, poiché possono essere modificati rapidamente e con poco sforzo. Man mano che si sale lungo la piramide, le informazioni diventano più complesse da ottenere, ma risultano anche molto più efficaci, in quanto costringono l’avversario a cambiare approccio, aumentando significativamente il costo e la difficoltà delle sue attività. Il Modello di maturità del Threat Hunting La composizione del team di Threat Hunting e il tempo dedicato all’attività di hunting dipendono dalle dimensioni e dalle esigenze dell’organizzazione. Quando non è disponibile un budget per un team dedicato, il tempo destinato al Threat Hunting viene ricavato dagli orari di lavoro di altri analisti di sicurezza. In questo scenario, gli analisti fanno generalmente parte del SOC (Security Operations Center) o del team di incident response. Tutte le organizzazioni possono svolgere attività di Threat Hunting, ma per farlo in modo efficace è necessario investire nelle infrastrutture e negli strumenti adeguati. Tuttavia, per ottenere un buon ritorno sull’investimento, l’organizzazione deve aver raggiunto un livello di maturità sufficiente nei propri processi. Gli effetti di un programma di Threat Hunting risultano limitati se il team non dispone delle competenze, degli strumenti e dei dati necessari. È in questo contesto che il Threat Hunting Maturity Model di David Bianco può aiutarci a determinare il livello di maturità di un programma di Threat Hunting considerando tre elementi: • competenze degli analisti • qualità e quantità dei dati raccolti • strumenti disponibili per analisi e accesso ai dati Tra questi, le competenze degli analisti sono il fattore più determinante, poiché trasformano i dati grezzi in capacità di rilevamento. Anche la qualità e la varietà dei dati influiscono fortemente sul livello di maturità: più dati affidabili sono disponibili, maggiore è la possibilità di individuare attività malevole. Il Threat Hunting Maturity Model può essere utilizzato per determinare lo stadio in cui si trova un’organizzazione e quali passi siano necessari per progredire verso un livello superiore. Il Hunting Maturity Model (HMM) descrive cinque livelli di maturità delle organizzazioni nel Threat Hunting, da HMM0 (minimo) a HMM4 (massimo). HMM0 – Initial Le organizzazioni a questo livello si affidano quasi esclusivamente a strumenti automatici (IDS, SIEM, antivirus) e a feed di threat intelligence per rilevare attività malevole. Il contributo umano è principalmente orientato alla gestione e risoluzione degli alert generati automaticamente. La raccolta dati è minima e sufficiente solo a supportare il rilevamento automatico; di conseguenza, queste organizzazioni non sono considerate in grado di svolgere attività di hunting. HMM1 – Minimal Oltre a usare sistemi automatici, le organizzazioni HMM1 iniziano a raccogliere sistematicamente dati dall’ambiente IT e punta un modello di rilevamento guidato dalla CTI (intel-driven). Quando emergono nuove minacce, gli analisti possono estrarre gli IOC dai report di Threat Intelligence ed effettuare ricerche retroattive sui dati raccolti per verificare se tali indicatori siano già comparsi in passato. Grazie a questa capacità di analisi, l’HMM1 costituisce il primo livello in cui si manifesta una forma, seppur limitata, di Threat Hunting. HMM2 – Procedural Le organizzazioni HMM2 applicano procedure di hunting sviluppate da terzi, adattandole se necessario. Queste procedure combinano dati specifici con tecniche di analisi per individuare particolari minacce (ad esempio malware o attività sospette). Le attività vengono eseguite regolarmente, anche se non sempre secondo una pianificazione rigorosa. HMM2 rappresenta il livello più comune tra le organizzazioni con programmi di hunting attivi. HMM3 – Innovative Le organizzazioni HMM3 creano e applicano procedure proprie, sfruttando tecniche analitiche avanzate come correlazioni di dati, visualizzazioni complesse o machine learning. La raccolta dati si evolve continuamente, integrando nuove fonti. Gli analisti trasformano le tecniche in processi ripetibili e documentati, aumentando notevolmente l’efficacia nel rilevare e contrastare le attività degli attaccanti. La crescita del numero di processi può però creare problemi di scalabilità. HMM4 – Leading Le organizzazioni HMM4 uniscono l’innovazione del livello precedente a un alto grado di automazione. I processi di hunting efficaci vengono automatizzati, liberando gli analisti dalle attività ripetitive e permettendo loro di sviluppare nuovi approcci o migliorare quelli esistenti. Questo approccio consente un miglioramento continuo del programma di Threat Hunting, rendendo l’organizzazione estremamente efficace nel contrastare le minacce. Automazione e Hunting Maturity Model Può apparire controintuitivo il fatto che sia HMM0 sia HMM4 facciano ampio uso dell’automazione, ma la differenza risiede nel modo in cui questa viene impiegata. Le organizzazioni HMM0 si affidano unicamente al rilevamento automatico, sia esso fornito dai vendor o sviluppato internamente. Anche se possono migliorare le proprie capacità introducendo nuove firme o feed di intelligence, il loro approccio alla scoperta delle minacce rimane sostanzialmente invariato. Anche in presenza di strumenti di analisi avanzati, se l’organizzazione si limita ad attendere la generazione di alert, non sta realmente svolgendo attività di hunting. Le organizzazioni HMM4, al contrario, sperimentano continuamente nuovi metodi per individuare i threat actor all’interno dei propri sistemi. Accettano che alcune iniziative possano non produrre risultati, mentre altre si rivelano efficaci. Questo tipo di approccio richiede creatività, curiosità e agilità, qualità che nessun prodotto di rilevamento completamente automatizzato può offrire. Una piattaforma di hunting può certamente rappresentare un valido supporto, ma la maturità necessaria per raggiungere il livello HMM4 non può essere acquistata. Processi di Threat Hunting All’interno di questo articolo verranno analizzati quattro processi di Threat Hunting: Threat Hunting Loop Threat Hunting Model Data-Driven Model TaHiTI – Targeted Hunting Integrating Threat Intelligence Threat Hunting Loop Il team Sqrrl ha definito uno dei primi processi di Threat Hunting il cosiddetto Threat Hunting Loop: Questo processo è ciclico ed è strutturato in quattro fasi. Nella prima fase il Threat Hunter formula un’ipotesi su una possibile minaccia che potrebbe impattare l’organizzazione. Una volta definita l’ipotesi, si passa alla seconda fase, in cui vengono avviate le indagini sull’ipotesi formulata attraverso ricerche sui dati raccolti da SIEM, EDR e altri strumenti di sicurezza. Nella terza fase si cerca di individuare attività anomale o sospette che normalmente non generano alert automatici, con l’obiettivo di confermare o smentire l’ipotesi iniziale. La fase finale del ciclo consiste nel raccogliere più informazioni possibili che possano arricchire l’analisi sull’ipotesi, ed infine cercare di automatizzare il più possibile l’intero processo. Ciò consentirà al team di concentrare i propri sforzi sulla ricerca di nuove minacce. Threat Hunting Model Dan Gunter e Marc Seitz, nel paper A Practical Model for Conducting Cyber Threat Hunting, propongono un modello pratico pensato per strutturare una processo di Threat Hunting. Questo modello è composto da sei fasi e mette in evidenza la natura iterativa del processo di hunting, sottolineando come ogni fase contribuisca al miglioramento continuo delle capacità di rilevamento: Scopo (Purpose): In questa fase si definisce l’obiettivo dell’attività di hunting, specificando quali dati sono necessari per svolgerla e quale risultato finale si intende ottenere. Lo scopo si articola in tre elementi principali: Scopo della ricerca: Indica la motivazione per cui l’attività di hunting viene avviata. Ambito della ricerca: Delinea l’ambiente in cui si svolgerà l’indagine, insieme alle assunzioni e alle eventuali limitazioni che ne influenzano il perimetro. Risultato desiderato: Specifica l’output atteso, che deve essere allineato agli obiettivi aziendali e mostrare in che modo il Threat Hunting contribuisce alla riduzione del rischio. Ambito (Scope): Questa fase prevede la definizione dell’ipotesi e l’identificazione della rete, dei sistemi, delle sottoreti o degli host dai quali si intende estrarre i dati. L’ambito deve essere definito in modo chiaro e preventivo, al fine di ridurre la quantità di “rumore” che potrebbe interferire con il successo dell’attività. Tuttavia, non deve essere eccessivamente specifico, poiché si rischierebbe di non rilevare la presenza dell’attaccante all’interno dell’ambiente. Equipaggiamento (Equip): Durante questa fase l’attenzione è focalizzata sulle modalità operative. In che modo verranno raccolti i dati? La raccolta è sufficientemente completa? Come verrà condotta l’analisi? In che modo verranno evitati eventuali bias? Al termine di questa fase, il threat hunter dovrebbe disporre di risposte approfondite a ciascuna di queste domande. L’implementazione di un Collection Management Framework (CMF) può supportare il tracciamento dei dati raccolti e della loro provenienza. Revisione del piano (Plan Review): Come suggerisce la denominazione, il responsabile del team o dell’attività di hunting esamina l’intera pianificazione svolta fino a quel momento, al fine di verificare che l’attività sia allineata agli obiettivi dell’organizzazione e che il team disponga di tutte le risorse necessarie (personale, dati, strumenti e tempo) per condurre con successo l’attività. Esecuzione (Execute): La fase di esecuzione si riferisce all’attività di hunting vera e propria, una volta che il piano è stato approvato. Feedback: Questa fase è correlata a tutte le fasi precedenti. L’analisi dei risultati consente al team di svolgere future attività di hunting con maggiore efficienza. L’obiettivo della fase di feedback è il miglioramento continuo di tutte le fasi precedenti; essa permette di identificare non solo se gli obiettivi siano stati raggiunti, ma anche eventuali bias in cui il team possa essere incorso, possibili lacune di visibilità e di raccolta dei dati da correggere, nonché la corretta allocazione delle risorse, e così via. Data-Driven Model Oltre ai modelli precedentemente descritti, i fratelli Roberto e José Luis Rodriguez hanno presentato una metodologia data-driven durante Insomni’hack 2019. Il loro processo prevede sei fasi distinte e, a beneficio della community, hanno sviluppato quattro progetti open source per strutturare e supportare le attività di Threat Hunting in ogni fase. Le sei fasi del modello Rodriguez sono: 1. Definizione dell’obiettivo di ricerca (Defining the research goal): Per un’attività di hunting data-driven, è essenziale comprendere i dati disponibili e mappare le informazioni sulle attività dell’avversario. Roberto Rodriguez suggerisce alcune domande chiave per definire correttamente l’obiettivo: Cosa stiamo cercando? Conosciamo i nostri dati? Esiste una data wiki? I dati sono archiviati correttamente? I log sono mappati alle azioni dell’avversario? Quanto deve essere specifica l’ipotesi? Quante tecniche o sotto-tecniche copre ciascuna ipotesi? 2. Modellazione dei dati (Modeling the data): Questa fase si concentra sulla comprensione dell’origine dei dati, sull’invio dei log a un data lake e sulla loro strutturazione tramite data dictionary, mappando ogni sorgente a un evento. OSSEM: progetto open source per documentare e standardizzare i log degli eventi di sicurezza. GitHub OSSEM 3. Emulazione dell’avversario (Emulating the adversary) Questa tecnica, tipica dei red team, replica i comportamenti degli avversari all’interno dell’organizzazione. È necessario mappare le loro azioni e concatenare le tecniche per creare un piano d’azione. Mordor: progetto open source che fornisce eventi di sicurezza simulati in formato JSON per testare le tecniche avversarie. GitHub Mordor Esempio: framework MITRE ATT&CK per la creazione di piani di emulazione basati su APT3. MITRE ATT&CK Plans 4. Definizione del modello di rilevamento (Defining the detection model) Basandosi sul modello dei dati, si definisce come condurre l’hunting. Il modello viene validato in laboratorio; in caso di risultati insoddisfacenti, si torna alle fasi precedenti per perfezionarlo. 5. Validazione del modello di rilevamento (Validating the detection model) Dopo aver testato il modello in laboratorio e verificato la qualità dei dati (completezza, coerenza, tempestività), si procede con l’ambiente di produzione. Possibili scenari: Assenza di risultati: comportamento dell’avversario non presente. Presenza di risultati: richiede approfondimenti per confermare la compromissione. Volume elevato di risultati: indica la necessità di affinamenti. The HELK: piattaforma open source basata su Elasticsearch, Logstash e Kibana, con funzionalità avanzate tramite Jupyter Notebook e Apache Spark. GitHub HELK 6. Documentazione e comunicazione dei risultati (Documenting and communicating findings) La documentazione deve procedere in parallelo all’attività di hunting e includere conclusioni, ipotesi sviluppate e concetti chiave. The Threat Hunter Playbook: progetto open source dei fratelli Rodriguez per supportare la documentazione, la condivisione di best practice e la costruzione di ipotesi di Threat Hunting. GitHub Threat Hunter Playbook TaHiTI – Targeted Hunting Integrating Threat Intelligence La metodologia Targeted Hunting Integrating Threat Intelligence (TaHiTI) è stata sviluppata congiuntamente da diverse istituzioni finanziarie olandesi per standardizzare l’approccio al Threat Hunting. Come suggerisce il nome, TaHiTI integra strettamente la threat intelligence, utilizzando informazioni sugli avversari per contestualizzare i dati rilevati durante le indagini o identificare TTP (Tactics, Techniques, and Procedures) note. Allo stesso tempo, il Threat Hunting secondo TaHiTI può arricchire la threat intelligence, permettendo di scoprire TTP e IoC (Indicators of Compromise) precedentemente sconosciuti. La metodologia è strutturata in otto passaggi, raggruppati in tre fasi principali: Fase 1 – Avvio Il trigger della caccia viene trasformato in un abstract per l’indagine, archiviato nel backlog. I principali trigger identificati da TaHiTI sono: Threat intelligence Altre indagini di hunting Security monitoring Security Incident Response (dati da incidenti storici o esercitazioni di red teaming) Altro L’abstract contiene una descrizione preliminare dell’ipotesi, la data di creazione, il trigger della caccia e il livello di priorità. Fase 2 – Hunting Questa fase comprende l’indagine vera e propria sull’ipotesi. L’abstract iniziale viene dettagliato con le nuove evidenze, le fonti dati, le tecniche di analisi, il perimetro dell’indagine, le risorse allocate e la threat intelligence disponibile. I risultati di ogni caccia possono essere: Ipotesi confermata: identificato un incidente di sicurezza. Ipotesi smentita: l’ipotesi viene confutata, dopo aver escluso ogni possibile scenario. Risultato inconcludente: informazioni insufficienti; l’ipotesi viene ulteriormente perfezionata fino a confermare o smentire. Fase 3 – Conclusione I risultati della caccia vengono documentati, includendo conclusioni, raccomandazioni di sicurezza e suggerimenti per ottimizzare il processo di hunting. I report sono adattati in base ai destinatari e ai livelli di autorizzazione. TaHiTI distingue cinque processi che possono essere attivati come risultato delle indagini di Threat Hunting: Security Incident Response: avvia un processo di IR. Security Monitoring: crea o aggiorna use case. Threat Intelligence: individua nuove TTP di un threat actor. Vulnerability Management: risolve le vulnerabilità scoperte. Raccomandazioni per altri team: vengono fornite indicazioni ad altri team per migliorare la postura di sicurezza complessiva dell’organizzazione Conclusioni Prima di iniziare l’attività di Threat Hunting vera e propria, è essenziale dedicare tempo a una fase approfondita di riflessione e pianificazione. In questo articolo abbiamo visto cos’è il Threat Hunting, i diversi approcci per implementarlo, le competenze chiave di un buon threat hunter e come formulare un’ipotesi efficace, elemento centrale di ogni processo di hunting. Alcuni concetti fondamentali da ricordare sono: Presumere che una violazione possa verificarsi. Il team di Threat Hunting deve avere una conoscenza approfondita dell’ambiente organizzativo per individuare eventuali anomalie. Dopo una caccia di successo, è importante automatizzare il processo il più possibile. Infine, è cruciale stabilire un processo standardizzato, documentarlo con cura e apprendere sia dai successi sia dagli insuccessi per migliorare continuamente le capacità di rilevamento. References “Practical Threat Intelligence and Data-Driven Threat Hunting: A hands-on guide to threat hunting with the ATT&CK™ Framework and open source tools” https://medium.com/@sqrrldata/the-cyber-hunting-maturity-model-6d506faa8ad5 https://www.aquasec.com/cloud-native-academy/application-security/threat-hunting/ https://detect-respond.blogspot.com/2015/10/a-simple-hunting-maturity-model.html https://sansorg.egnyte.com/dl/kJiJeYbCND https://www.sans.org/reading-room/whitepapers/threats/paper/37172 https://medium.com/@sqrrldata/the-hunting-loop-10c7d451dec8 https://www.betaalvereniging.nl/wp-content/uploads/TaHiTI-Threat-Hunting-Methodology-whitepaper.pdf
blog.8bitsecurity.comFeb 3, 2026extracted