Threat Hunting: Co to jest i jak to działa

Threat hunting to praktyka proaktywnego przeszukiwania sieci i punktów końcowych w poszukiwaniu atakujących, którzy już przeszli obok istniejących detekcji. Zaczyna się od prostego, niewygodnego założenia: coś złego może już być wewnątrz i żaden alert się nie pojawił. Zamiast czekać na wyzwolenie reguły SIEM, hunter formułuje hipotezę i szuka dowodów, aby ją potwierdzić lub odrzucić.

Dlaczego sama detekcja nie wystarczy

Detekcja oparta na sygnaturach i regułach łapie znane wzorce. Atakujący używający living-off-the-land binaries (LOLBins), prawidłowych poświadczeń lub powolnych, niskotonażowych technik mogą pozostać poniżej tych progów przez tygodnie. Threat hunting wypełnia tę lukę, gdy człowiek aktywnie kwestionuje dane: czy to wywołanie PowerShella ze stanowiska finansowego o 2 w nocy ma sens? Dlaczego svchost.exe nawiązuje połączenie wychodzące na IP bez odwrotnego DNS?

To nie jest response na incydent. IR rozpoczyna się po tym, gdy wiesz, że coś się stało. Hunting zaczyna się, gdy jeszcze nie wiesz, a cel to dowiedzieć się tego zanim większe zdarzenie zmusi do pytania.

Trzy częste punkty wyjścia

Większość hunts zaczyna się z jednego z trzech kierunków:

• Intelligence-driven: nowy raport o zagrożeniach opisuje TTP (np. nadużywanie zaplanowanego zadania dla persistencji) i sprawdzasz, czy to jest obecne w Twojej infrastrukturze.
• Situational awareness: patrzysz na to, co jest rzeczywiście niezwykłe dla Twojej organizacji — service account uwierzytelniający się z kraju, z którego nigdy się nie uwierzytelniał, lub skok ruchu SMB między stanowiskami, które normalnie rozmawiają tylko z serwerami.
• Analytics-driven: budujesz baseline normalnego zachowania (drzewa procesów, czasy logowania, wielkość zapytań DNS) i szukasz anomalii statystycznych.

MITRE ATT&CK to referencja, którą większość zespołów używa do strukturyzacji hipotez. Zamiast "szukaj malware", wybierasz technikę taką jak T1053 (Scheduled Task/Job) i pytasz: jak by to wyglądało w naszych Windows Event Logs lub telemetrii EDR i czy mogę na to zapytać teraz?

Jak wygląda rzeczywisty workflow

Hunt zwykle przebiega w tej pętli:

1. Formułuj konkretną, testowalną hipotezę (nie "sprawdź, czy są włamania" ale "sprawdź, czy są nowe zaplanowane zadania utworzone poza oknami aktualizacji w ostatnich 30 dniach").
2. Zidentyfikuj potrzebne źródła danych — Sysmon Event ID 1 dla creation procesu, Windows Security Event ID 4698 dla creation zaplanowanego zadania, drzewa procesów EDR, lub Zeek conn logi dla kontekstu sieciowego.
3. Wykonuj query i pivot. W praktyce oznacza to pisanie KQL w Microsoft Sentinel, SPL w Splunk, lub raw queries względem indeksu Elastic.
4. Triażuj wyniki — większość będzie false positives lub nieszkodliwą aktywnością admina, a zadaniem jest zawężenie tego szumu do czegoś rzeczywiście anomalnego.
5. Dokumentuj ustalenia, czy to potwierdzony kompromis, luka w detekcji, czy po prostu