threat hunting (polowanie na zagrożenia)

Polowanie na zagrożenia (threat hunting) to aktywne, prowadzone przez analityka poszukiwanie śladów napastnika w danych telemetrycznych, wychodzące od hipotezy, a nie od alertu wygenerowanego przez system. NIST w katalogu zabezpieczeń SP 800-53 opisuje je jako aktywny środek obrony, w odróżnieniu od tradycyjnych środków takich jak zapory, systemy wykrywania i zapobiegania włamaniom, izolowanie złośliwego kodu w piaskownicy i technologie SIEM (Security Information and Event Management) ^[1]. Polowanie polega na proaktywnym przeszukiwaniu systemów, sieci i infrastruktury organizacji w poszukiwaniu zaawansowanych zagrożeń ^[1].

Cel i założenia

Punktem wyjścia jest założenie, że część ataków omija istniejące zabezpieczenia. Zabezpieczenie RA-10 wymaga ustanowienia zdolności do poszukiwania wskaźników kompromitacji (IoC) w systemach organizacji oraz do wykrywania, śledzenia i zakłócania zagrożeń, które omijają istniejące zabezpieczenia ^[1]. Celem jest zakłócenie działań przeciwnika jak najwcześniej w sekwencji ataku oraz mierzalna poprawa szybkości i trafności reakcji ^[1].

Polowanie różni się od zwykłej pracy SOC (Security Operations Center) punktem startu.

NIST zaznacza, że zespoły polujące korzystają z istniejącego threat intelligence i mogą tworzyć nowe, które udostępnia się organizacjom partnerskim, ośrodkom wymiany informacji i właściwym instytucjom ^[1].

Jak przebiega

Polowanie jest cyklem: każdy przebieg kończy się wiedzą, która zasila następną hipotezę albo nową regułę wykrywania.

RYS. 1Cykl polowania na zagrożenia

Hipoteza wynika zwykle z wiedzy o zachowaniu napastników. Źródłem takiej wiedzy jest MITRE ATT&CK, opisany przez MITRE jako globalnie dostępna baza wiedzy o taktykach i technikach przeciwników, oparta na obserwacjach z rzeczywistych ataków ^[3]. Hipoteza może brzmieć: „jeśli napastnik zostawił na serwerze webshell, w katalogu WWW są pliki, których nie było we wdrożeniu”.

Dane to logi serwerów, telemetria EDR (Endpoint Detection and Response), zapisy sieciowe i stan plików. NIST jako oznaki kompromitacji wymienia nietypowy ruch sieciowy, nietypowe zmiany plików i obecność złośliwego kodu ^[1].

Poziom wskaźników. Lepsze polowanie szuka zachowań, nie konkretnych plików. NIST odróżnia wskaźniki, czyli artefakty systemowe lub obserwacje związane z atakiem, od taktyk, technik i procedur (TTP), które opisują zachowanie aktora ^[6]. Przykładami wskaźników według NIST są adres IP podejrzanego serwera C2 (command and control), podejrzana nazwa domeny, adres URL prowadzący do złośliwej treści, skrót złośliwego pliku wykonywalnego albo temat złośliwej wiadomości e-mail ^[6]. Takie ślady łatwo sprawdzić, ale napastnik łatwo je też zmienia. David J. Bianco w modelu „piramidy bólu” zauważa, że obrona skierowana przeciw TTP zmusza napastnika do najbardziej czasochłonnej rzeczy: nauczenia się nowych zachowań ^[5]. Wartość skrótu pliku zmienia się natomiast po dowolnej, nawet nieistotnej modyfikacji ^[5].

W WordPressie

Polowanie na zagrożenia w środowisku WordPress to regularne sprawdzanie hipotez o typowych śladach przejęcia strony, zanim pojawią się objawy widoczne dla odwiedzających. Hipotezy wynikają z opisów technik i z dokumentacji WordPress.org.

• Webshell w katalogu WWW. MITRE jako sygnał wykrywania wymienia nieoczekiwane tworzenie plików w katalogach WWW i proces serwera uruchamiający powłokę ^[4]. Na WordPressie szuka się plików PHP w wp-content/uploads i plików spoza wdrożenia.
• Zmienione pliki wtyczek. Polecenie WP-CLI porównuje pliki wtyczek z sumami kontrolnymi z WordPress.org; opcja --all sprawdza wszystkie wtyczki, a --strict zgłasza także drobne zmiany, na przykład w readme.txt ^[7].
• Nowe konta. WordPress.org wśród wskaźników włamania wymienia nieautoryzowane działania, na przykład tworzenie nowych użytkowników ^[8], co odpowiada hipotezie o nieautoryzowanym koncie administratora.
• Kod poza listą wtyczek. Przy każdym przebiegu warto przejrzeć zawartość katalogu mu-plugins.

wp plugin verify-checksums --all
wp user list --role=administrator --fields=ID,user_login,user_registered

Wynik polowania na jednej stronie bywa punktem wyjścia do kolejnej hipotezy na wielu stronach, na przykład w agencji obsługującej wiele witryn na podobnych wtyczkach.

Przykład z Polski

CERT Polska w lutym 2026 roku opisał incydent z fałszywą CAPTCHA, po którym złośliwe oprogramowanie trafiło na stację roboczą w firmie ^[2]. Po przeanalizowaniu mechanizmu zespół szukał podobnych wskaźników i odkrył więcej polskich domen zainfekowanych w ten sam sposób ^[2]. CERT Polska podsumował, że proaktywne polowanie na zagrożenia tego typu pozwala reagować szybciej na ataki ^[2]. W tym przykładzie ślad z jednego incydentu stał się hipotezą, a hipoteza doprowadziła do kolejnych zainfekowanych domen.

Miejsce wśród innych działań

Polowanie korzysta z tych samych danych co SIEM i EDR (Endpoint Detection and Response), ale inaczej je czyta: zamiast czekać na regułę, analityk sam formułuje pytanie. Gdy polowanie znajdzie ślad napastnika, zaczyna się zwykłe reagowanie na incydent, w tym usunięcie zagrożenia. Nowa wiedza wraca do threat intelligence: NIST wskazuje, że zespoły polujące mogą ją udostępniać organizacjom partnerskim, ośrodkom ISAC i ISAO oraz właściwym instytucjom państwowym ^[1].

Ograniczenia

Polowanie wymaga danych: bez retencji logów nie da się sprawdzić hipotezy wstecz. Wymaga też czasu analityka, dlatego RA-10 każe organizacji samej określić częstotliwość prowadzenia polowań ^[1]. Wynik negatywny nie dowodzi, że środowisko jest czyste, tylko że nie znaleziono śladów sprawdzanej techniki. Wartość trwała powstaje wtedy, gdy trafione hipotezy zamienia się w reguły detection engineering, które odtąd działają automatycznie.