Przekonaj się sam!
Pozostaw wiadomość, a skontaktuje się z Tobą nasz dedykowany doradca.
Wyślij nam wiadomość
0/10000
Threat Hunting: Jak przestać kolekcjonować logi, a zacząć łapać hakerów
Opublikowano: 18:26 02.01.2026
Cyberbezpieczeństwo
Ś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.kowalskito nie tylko „User”, ale „Administrator Domeny” lub „Dyrektor Finansowy”. - System musi wiedzieć, że serwer
SRV-005przetwarza 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.exei łą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:
- Commit: Analityk tworzy nową regułę wykrywającą Log4Shell.
- Test: Automat sprawdza, czy reguła jest poprawna składniowo i czy nie generuje miliarda alertów na danych historycznych.
- 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:
- Wazuh: Serce operacji. Działa jako EDR (agent na końcówkach) i SIEM. Zbiera logi, analizuje integralność plików i wykrywa luki.
- TheHive: Mózg operacji. Platforma do zarządzania incydentami (Case Management). Tu trafiają alerty i tu analitycy dokumentują swoje śledztwo.
- 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ą.
- 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:
- Elastic Common Schema (ECS) Reference
- Open Cybersecurity Schema Framework (OCSF)
- Sigma - Generic Signature Format for SIEM Systems
- MITRE ATT&CK Framework
- The Pyramid of Pain - David Bianco
- 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.
O autorze
Aleksander Zębrowski
Dyrektor ds. Technologii w SecurHub.pl
Doktorant z zakresu neuronauki poznawczej. Psycholog i ekspert IT specjalizujący się w cyberbezpieczeństwie.
Powiązane artykuły
Cyberbezpieczeństwo
Security Operations Center (SOC): Kompleksowy Przewodnik na 2026 | Budowa i Wdrożenie
Poznaj wszystko o Security Operations Center (SOC) - od budowy zespołu, przez technologie SIEM/XDR/SOAR, wymogi NIS2, modele wdrożenia, aż po przyszłość z AI. Praktyczny przewodnik dla CISO i menedżerów IT.
07.12.2025
49 min
Cyberbezpieczeństwo
Przestań czekać na alarm. Dlaczego Twoja sieć potrzebuje myśliwego, a nie tylko strażnika?
Tradycyjne cyberbezpieczeństwo to oczekiwanie na włamanie. Threat Hunting to wyjście mu naprzeciw. Odkryj, dlaczego paranoja (ta kontrolowana) jest najzdrowszą strategią dla Twojej organizacji.
10.11.2025
13 min
Cyberbezpieczeństwo
Koniec ery "klikania w konsolę". Jak SOAR i Agentic AI ratują nas przed cyfrowym wypaleniem
Analitycy SOC toną w powodzi danych, marnując godziny na fałszywe alarmy. Czy rok 2025 i nadejście autonomicznych agentów AI to moment, w którym maszyny w końcu pozwolą ludziom przestać "gonić duchy" i zacząć myśleć strategicznie?
05.11.2025
14 min
Komentarze
Ładowanie komentarzy...