Threat Hunting: Jak przestać kolekcjonować logi, a zacząć łapać hakerów

Średni Breakout Time – czas, jakiego hakerzy potrzebują od momentu włamania do rozpoczęcia ekspansji w sieci (lateral movement) – to często mniej niż dwie godziny. Niektórzy adwersarze robią to w minuty.

Jeśli Twój SOC (Security Operations Center) opiera się na ręcznym przeglądaniu alertów wygenerowanych przez statyczne reguły, przegrałeś ten wyścig, zanim w ogóle wstałeś z krzesła. Musimy zbudować system, który jest nieprzyjemny dla napastnika, a nie dla analityka.

Oto rozszerzona architektura proaktywnego Threat Huntingu.

Faza 1: Higiena Danych (To, czego nikt nie chce robić, a każdy musi)

Większość projektów SIEM upada nie przez brak drogich narzędzi, ale przez bałagan w danych. Wyobraź sobie, że próbujesz znaleźć „podejrzanego mężczyznę”, ale jeden świadek opisuje go po francusku, drugi po japońsku, a trzeci podaje tylko numer buta.

1. Normalizacja to Twoje Esperanto

Wspomniałem o ECS (Elastic Common Schema) i OCSF. Rozwińmy to. Normalizacja to nie tylko mapowanie pól. To ujednolicenie wartości.

• Przykład: Czy zdarzenie logowania to „Logon”, „Login”, „SessionStart” czy ID 4624? Twój SIEM musi sprowadzić to wszystko do jednej wartości: event.action: "authentication_success".
• Dlaczego to krytyczne: Dzięki temu analityk pisze jedno zapytanie, które obejmuje Windowsa, Linuxa, chmurę i bazę danych SQL. Bez tego Threat Hunting jest walką z semantyką, a nie z hakerem.

2. Wzbogacanie kontekstem biznesowym

Techniczny kontekst (GeoIP) to podstawa. Ale prawdziwa magia dzieje się, gdy dodasz kontekst biznesowy.

• Twoje logi powinny wiedzieć, że użytkownik j.kowalski to nie tylko „User”, ale „Administrator Domeny” lub „Dyrektor Finansowy”.
• System musi wiedzieć, że serwer SRV-005 przetwarza dane kart płatniczych (PCI DSS).
• Zasada: Alert dotyczący serwera testowego to „informacja”. Ten sam alert dotyczący kontrolera domeny to „pożar”. SIEM musi znać tę różnicę zanim obudzi analityka w nocy.

Faza 2: Strategia Detekcji (Wyjście poza sygnatury)

Tutaj wchodzi koncepcja Piramidy Bólu (Pyramid of Pain) Davida Bianco.

Większość systemów skupia się na dole piramidy: hashe plików, adresy IP, domeny. To proste do wykrycia, ale dla hakera trywialne do zmiany. Zmienia IP i Twoja reguła jest bezużyteczna.

Nowoczesny SIEM musi celować w szczyt piramidy: TTPs (Tactics, Techniques, and Procedures).

1. Wykrywanie behawioralne (UEBA)

Przestań szukać "złych plików". Zacznij szukać "dziwnych zachowań".

• Nie pytaj: „Czy ten plik ma wirusa?”
• Pytaj: „Dlaczego proces winword.exe (Word) próbuje uruchomić powershell.exe i łączyć się z internetem?”
• To podejście pozwala wykryć ataki zero-day, na które nie ma jeszcze sygnatur. Word otwierający Powershella jest podejrzany zawsze, niezależnie od tego, jakiego exploita użyto.

2. Hipotezy Łowieckie

Threat Hunting nie polega na patrzeniu w ekran i czekaniu na natchnienie. To proces naukowy.

• Hipoteza: „Myślę, że atakujący mogą używać Pass-the-Hash do przeskakiwania między serwerami”.
• Eksperyment: „Szukam w logach zdarzeń Windows 4624 z typem logowania 3 i użyciem NTLM, gdzie stacja źródłowa nie jest stacją roboczą admina”.
• Wniosek: Potwierdzenie (incydent) lub zaprzeczenie (bezpieczeństwo).

Faza 3: Operacjonalizacja (Detection as Code)

Jeśli Twoje reguły detekcji żyją tylko w klikalnym interfejsie Twojego SIEM-a, jesteś zakładnikiem tego vendora.

CI/CD dla Bezpieczeństwa

Traktuj reguły detekcji (np. pliki YAML w formacie Sigma) jak kod aplikacji:

1. Commit: Analityk tworzy nową regułę wykrywającą Log4Shell.
2. Test: Automat sprawdza, czy reguła jest poprawna składniowo i czy nie generuje miliarda alertów na danych historycznych.
3. Deploy: Reguła jest automatycznie wdrażana na produkcję.

To eliminuje „dryf konfiguracji” i sytuacje, w których ktoś przypadkiem wyłączył kluczowy alert trzy miesiące temu i nikt tego nie zauważył.

Faza 4: Architektura Tiering (Gorące, Ciepłe, Zimne)

Musimy pogodzić chciwość (chcemy wszystkich danych) z ekonomią (nie mamy budżetu NASA). Rozbudujmy model przechowywania:

• Hot (NVMe/SSD): Ostatnie 7-14 dni. Tu dzieje się 90% zapytań analityków. Odpowiedzi muszą być natychmiastowe.
• Warm (HDD): Do 3-6 miesięcy. Dane są dostępne, ale zapytanie może potrwać kilka minut. Idealne do analizy trendów i polowania na „low and slow” (powolne ataki APT).
• Cold/Frozen (S3/Taśma): Lata. Dane są skompresowane, tanie jak barszcz. Wyciągamy je tylko, gdy prokurator lub audytor zapuka do drzwi. Przywrócenie ich trwa godziny (tzw. Rehydration), ale kosztuje grosze.

Przykład z poligonu: Detection as Code w praktyce

Teoria brzmi dobrze, ale jak to wygląda na klawiaturze? Zamiast klikać w GUI, piszemy regułę. Oto przykład prostej reguły w formacie Sigma, wykrywającej Worda uruchamiającego PowerShella (klasyczny Initial Access):

title: Suspicious PowerShell Child Process
id: 1234-5678-90ab-cdef
status: experimental
description: Detects PowerShell being spawned by Microsoft Word
author: SecurHub
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        ParentImage|endswith:
            - '\winword.exe'
        Image|endswith:
            - '\powershell.exe'
    condition: selection
level: high
tags:
    - attack.execution
    - attack.t1059.001

Taki plik ląduje w repozytorium Git. Automat (CI/CD) konwertuje go na zapytanie zrozumiałe dla Twojego SIEM-a (np. Elastic DSL, Splunk SPL) i wdraża. Zero manualnego klikania.

Czym to zbudować? (Open Source Stack)

Nie potrzebujesz budżetu banku, żeby zacząć. Możesz zbudować potężny SOC, płacąc jedynie za prąd i czas inżynierów. Oto "Starter Pack" nowoczesnego Threat Huntera:

1. Wazuh: Serce operacji. Działa jako EDR (agent na końcówkach) i SIEM. Zbiera logi, analizuje integralność plików i wykrywa luki.
2. TheHive: Mózg operacji. Platforma do zarządzania incydentami (Case Management). Tu trafiają alerty i tu analitycy dokumentują swoje śledztwo.
3. MISP: Pamięć operacji. Platforma Threat Intelligence. Tu przechowujesz informacje o złośliwych IP, domenach i hashach, którymi dzielisz się ze społecznością.
4. Cortex: Ręce operacji. Silnik analizy, który na żądanie TheHive może „prześwietlić” podejrzany plik na VirusTotal lub sprawdzić IP w bazie reputacyjnej.

Podsumowanie: Ludzie > Narzędzia

Na koniec najważniejszy element, którego nie ma w żadnym pliku konfiguracyjnym: mentalność.

Najlepszy SIEM to taki, który zdejmuje z ludzi ciężar powtarzalnej, nudnej pracy (automatyzacja, odsiewanie fałszywych alertów), pozwalając im robić to, w czym AI wciąż jest słabe: łączyć kropki, myśleć kreatywnie i rozumieć kontekst, którego nie ma w logach.

Nie buduj muzeum danych. Buduj centrum dowodzenia.

Aleksander

Źródła:

1. Elastic Common Schema (ECS) Reference
2. Open Cybersecurity Schema Framework (OCSF)
3. Sigma - Generic Signature Format for SIEM Systems
4. MITRE ATT&CK Framework
5. The Pyramid of Pain - David Bianco
6. SANS Institute - Hunting Maturity Model

FAQ

Czym różni się Threat Hunting od zwykłego monitoringu (SOC)?

Tradycyjny SOC reaguje na alerty (jest reaktywny), które wygenerowały systemy bezpieczeństwa. Threat Hunting to proces proaktywny – zakładamy, że zabezpieczenia zawiodły i aktywnie szukamy śladów obecności intruza, opierając się na hipotezach, a nie na gotowych sygnaturach.

Czy potrzebuję drogiego SIEM-a, żeby zacząć polowanie na zagrożenia?

Nie. Choć SIEM ułatwia centralizację danych, Threat Hunting można zacząć od analizy logów na stacjach końcowych (np. Sysmon, EDR) lub prostych rozwiązań open-source. Kluczowa jest wiedza analityka i zrozumienie, czego szukamy (TTPs), a nie narzędzie.

Co to jest "Piramida Bólu" w cyberbezpieczeństwie?

To koncepcja pokazująca relację między rodzajem wskaźników kompromitacji (IoC) a trudnością, jaką ich wykrycie sprawia atakującemu. Na dole są hashe i IP (łatwe do zmiany dla hakera), a na szczycie TTPs (taktyki, techniki, procedury) – ich wykrycie i zablokowanie zmusza napastnika do zmiany całego arsenału, co jest dla niego "bolesne" i kosztowne.

Jak zautomatyzować proces Threat Huntingu?

Poprzez podejście "Detection as Code". Gdy hipoteza łowiecka okaże się skuteczna (znajdziemy zagrożenie lub potwierdzimy, że dane zachowanie jest podejrzane), powinniśmy zamienić ją w automatyczną regułę detekcji (np. w formacie Sigma) i wdrożyć do systemu SIEM, aby w przyszłości wykrywał to zagrożenie samodzielnie.

Dlaczego normalizacja danych jest tak ważna?

Bez normalizacji (np. do standardu ECS lub OCSF) analityk musi pisać osobne zapytania dla każdego systemu (Windows, Linux, Firewall). Ujednolicenie nazw pól pozwala przeszukiwać całe środowisko jednym zapytaniem, co drastycznie przyspiesza wykrywanie anomalii.