Threat Hunting: Ce este și cum funcționează

Threat hunting este practica de a căuta în mod proactiv pe rețele și endpoints pentru atacatori care au trecut deja peste detectările existente. Pornește de la o presupunere simplă și neplăcută: ceva rău poate fi deja în interior, și nicio alertă nu s-a declanșat pentru asta. În loc să aștepte o regulă SIEM să se declanșeze, un hunter formulează o ipoteză și caută dovezi pentru a o confirma sau a o infirma.

De ce detectarea singură nu este suficientă

Detectarea bazată pe semnături și pe reguli prinde modele cunoscute. Atacatorii care folosesc living-off-the-land binaries (LOLBins), credențiale valide, sau tehnici lente și cu volum mic pot rămâne sub acele praguri timp de săptămâni. Threat hunting umple acel gol prin aceea că un om pune activ sub semnul întrebării datele: are sens o invocație PowerShell de pe o stație de lucru din finanțe la ora 2 noaptea? De ce svchost.exe face o conexiune externă la o adresă IP fără reverse DNS?

Acesta nu este răspuns la incident. IR-ul începe după ce știi că ceva s-a întâmplat. Huntingul începe când nu știi încă, și scopul este să afli asta înainte ca un eveniment mai mare să forțeze întrebarea.

Trei puncte de plecare obișnuite

Majoritatea vânătorilor încep din una dintre trei direcții:

• Intelligence-driven: un nou raport de amenință descrie un TTP (de exemplu, abuzul unei sarcini planificate pentru persistență), și verifici dacă este prezent în mediul tău.
• Situational awareness: privești ce este de fapt neobișnuit pentru organizația ta — un cont de serviciu care se autentifică dintr-o țară din care nu s-a autentificat niciodată, sau o creștere a traficului SMB între stații de lucru care de obicei vorbesc doar cu servere.
• Analytics-driven: construiești o linie de bază a comportamentului normal (arborii de procese, orele de conectare, volumul interogărilor DNS) și cauți valori aberante statistice față de ea.

MITRE ATT&CK este referința pe care o folosesc cele mai multe echipe pentru a structura ipoteze. În loc de "caută malware", alegi o tehnică ca T1053 (Scheduled Task/Job) și întrebi: cum ar arăta asta în Windows Event Logs sau EDR telemetry, și pot să o interoghez chiar acum?

Cum arată fluxul de lucru real

O vânătoare de obicei urmează această buclă:

1. Formulează o ipoteză specifică și testabilă (nu "verifică dacă sunt intruziuni" ci "verifică pentru noi sarcini planificate create în afara ferestrelor de patch în ultimele 30 de zile").
2. Identifică sursele de date necesare — Sysmon Event ID 1 pentru crearea proceselor, Windows Security Event ID 4698 pentru crearea sarcinilor planificate, arborii de procese EDR, sau jurnale de conexiune Zeek pentru context de rețea.
3. Interogare și pivot. În practică asta înseamnă scrierea KQL în Microsoft Sentinel, SPL în Splunk, sau interogări brute împotriva unui index Elastic.
4. Triajul rezultatelor — majoritatea vor fi fals pozitive sau activitate admin benigă, iar jobul este de a restrânge acel zgomot la ceea ce este cu adevărat anomal.
5. Documentează constatările, indiferent dacă este o compromitere confirmată, o lacună în detectare, sau doar