Najtrudniejsze w wykrywaniu cyberataków nie jest to, że nic nie widać. Przeciwnie – zwykle widać bardzo dużo. Logowanie przez VPN, uruchomiony PowerShell, połączenie z serwerem, zapytanie DNS, dostęp do udziału sieciowego, nowy proces na stacji roboczej. Problem w tym, że każde z tych zdarzeń osobno może wyglądać niewinnie.
Konto, które zwykle pracuje od 8:00 do 16:00, loguje się w nocy. Kilka minut później ta sama stacja odpytuje kontroler domeny. Potem pojawia się ruch do serwerów plików, skrypt uruchomiony z katalogu tymczasowego i komunikacja z domeną, której wcześniej w firmowej sieci nie było. Żaden z tych sygnałów nie musi samodzielnie wywołać alertu. Razem mogą oznaczać, że ktoś właśnie sprawdza, jak daleko może wejść.
I tu zaczyna się threat hunting.
Threat hunting co to jest?
To proces aktywnego poszukiwania oznak cyberzagrożeń, które mogły ominąć standardowe mechanizmy detekcji. Nie chodzi wyłącznie o reagowanie na alerty z systemu EDR, SIEM czy firewalla. Chodzi o stawianie hipotez, analizę danych i szukanie anomalii, które mogą wskazywać na rzeczywisty atak.
Przykładowa hipoteza może brzmieć: „Czy w naszej sieci występują nietypowe logowania administracyjne poza godzinami pracy?” albo „Czy któreś urządzenie komunikuje się z infrastrukturą command and control?”. Threat hunter nie zaczyna więc od alarmu, lecz od pytania. Następnie sprawdza logi, telemetrię endpointów, ruch sieciowy, aktywność kont, zachowanie procesów oraz inne źródła danych.
W praktyce threat hunting łączy wiedzę techniczną, znajomość taktyk atakujących oraz analityczne myślenie. To nie jest chaotyczne przeglądanie logów. To uporządkowana praca oparta na danych, doświadczeniu i znajomości realnych scenariuszy ataków.
Dlaczego samo czekanie na alarm już nie wystarcza?
Klasyczne mechanizmy bezpieczeństwa najlepiej wykrywają to, co już znają: sygnaturę, regułę, powtarzalny wzorzec. Threat hunting jest potrzebny tam, gdzie atak nie wygląda jak atak, tylko jak nadużycie normalnych możliwości systemu. Przejęte konto, PowerShell, RDP, dostęp do udziału sieciowego czy zmiana uprawnień nie są same w sobie dowodem incydentu. Mogą być częścią codziennej administracji. Mogą też być fragmentem ataku.
Dlatego jak wykrywać zagrożenia w sieci oznacza w praktyce: umieć odróżnić użycie od nadużycia. Sprawdzić, czy dana aktywność pasuje do roli użytkownika, historii urządzenia, pory dnia, typu zasobu i dalszej sekwencji działań. Threat hunting nie szuka więc „dziwnych rzeczy” dla samego szukania. Szuka zachowań, które technicznie są możliwe, ale operacyjnie nie mają sensu.
Na czym polega dobre polowanie na zagrożenia?
Zaczyna się od konkretnego pytania do danych. Czy w środowisku widać oznaki ruchu lateralnego? Czy ktoś używa legalnych narzędzi administracyjnych w nietypowy sposób? Czy konto użytkownika zachowuje się inaczej niż zwykle? Czy endpoint wykonuje działania, które mają sens technicznie, ale nie mają sensu biznesowo? To właśnie różni threat hunting od zwykłego monitoringu. Monitoring czeka na zdarzenie pasujące do znanej reguły. Threat hunting sprawdza, czy w danych nie ma zachowań, które dopiero mogą wymagać nazwanej detekcji.
Przykład? Samo uruchomienie PowerShella nie jest jeszcze incydentem. Administratorzy używają go codziennie. Ale PowerShell uruchomiony przez proces Office, z katalogu tymczasowego, po otwarciu załącznika z poczty, a następnie wykonujący połączenie do zewnętrznej domeny – to już zupełnie inna historia.
Threat szuka zatem sekwencji działań, które mogą układać się w technikę ataku: zdobycie dostępu, rozpoznanie środowiska, eskalację uprawnień, przejście na kolejne systemy, przygotowanie do eksfiltracji danych albo uruchomienia ransomware. Dobrze prowadzony threat hunting nie kończy się na znalezieniu jednego podejrzanego hosta. Jego wartość polega na tym, że po każdym takim ćwiczeniu organizacja wie więcej: gdzie ma luki w widoczności, których zachowań nie wykrywa automatycznie i które scenariusze ataku są dla niej najbardziej realne.
Proaktywne wykrywanie zagrożeń w praktyce
Proaktywne wykrywanie zagrożeń wymaga widoczności. Bez danych nie ma huntingu. Zespół bezpieczeństwa musi wiedzieć, co dzieje się na stacjach roboczych, serwerach, w usługach chmurowych, w systemach tożsamości i w ruchu sieciowym.
Poniższa tabela pokazuje przykładowe obszary, które warto analizować podczas threat huntingu.
| Obszar analizy | Co warto sprawdzać | Co może oznaczać problem |
| Logowania i tożsamość | Logowania poza typowymi godzinami, dostęp z nietypowych lokalizacji, użycie kont uprzywilejowanych z nowych urządzeń | Przejęcie konta, testowanie dostępu, próba eskalacji uprawnień |
| Procesy na endpointach | PowerShell, WMI, rundll32, regsvr32, certutil, skrypty .bat i .ps1 uruchamiane w nietypowym kontekście | Wykorzystanie legalnych narzędzi systemowych do działań ofensywnych |
| Aktywność aplikacji biurowych | Word, Excel lub Outlook uruchamiające skrypty, interpretery poleceń albo procesy potomne | Możliwy etap po otwarciu złośliwego załącznika lub dokumentu z makrami |
| Ruch między hostami | Nietypowe połączenia RDP, SMB, WinRM, próby dostępu do wielu maszyn w krótkim czasie | Ruch lateralny, rozpoznawanie sieci, przygotowanie do dalszego etapu ataku |
| DNS i ruch wychodzący | Zapytania do nowych, rzadkich lub losowo wyglądających domen, nietypowe połączenia poza organizację | Komunikacja command and control, pobieranie narzędzi, przygotowanie kanału wycieku danych |
| Dostęp do danych | Masowe odczyty plików, nietypowy dostęp do udziałów sieciowych, aktywność poza profilem użytkownika | Przygotowanie do kradzieży danych, rekonesans zasobów, etap poprzedzający wymuszenie |
| Zmiany w zabezpieczeniach | Wyłączanie ochrony endpointów, modyfikacje reguł firewalla, czyszczenie logów, zmiany polityk | Próba ukrycia aktywności lub osłabienia mechanizmów obronnych |
| Narzędzia administracyjne | PsExec, narzędzia zdalnego zarządzania, skanery sieciowe, polecenia systemowe użyte poza normalnym procesem IT | Nadużycie legalnych narzędzi, działania typu living off the land |
Rola narzędzi EDR i XDR w threat huntingu
Threat hunting bez dobrej telemetrii jest ograniczony. Analityk może mieć świetne hipotezy, ale jeśli nie widzi procesów, połączeń sieciowych, zmian w plikach, aktywności użytkowników i zależności między zdarzeniami, będzie pracował po omacku.
Dlatego w praktyce duże znaczenie mają platformy klasy EDR i XDR. Dobre narzędzie powinno pomóc odpowiedzieć na pytania np. jaki proces został uruchomiony, przez kogo, z jakiego katalogu, jaki miał proces nadrzędny, z czym się komunikował, jakie pliki zmienił i czy podobne zachowanie wystąpiło na innych maszynach.
SentinelOne jest dobrym przykładem narzędzia, które realnie wspiera threat hunting. Jego wartość polega na tym, że pomaga szybciej zrozumieć przebieg zdarzeń: co uruchomiło dany proces, jakie były kolejne działania, z czym komunikował się endpoint, jakie konto brało w tym udział i czy podobne zachowanie pojawiło się gdzie indziej. To nie zastępuje analityka, ale daje mu lepszy punkt startu. Zamiast tracić czas na ręczne składanie fragmentów układanki, może szybciej ocenić, czy patrzy na zwykłą aktywność, błąd konfiguracji, nadużycie uprawnień czy realny atak. I właśnie dlatego dobrze wdrożone XDR może być dla threat huntingu bardzo mocnym wsparciem. Jeżeli chcesz sprawdzić, jak takie podejście mogłoby działać w Twoim środowisku, warto zacząć od rozmowy. Pomożemy dobrać scenariusze threat huntingu, sprawdzić widoczność w infrastrukturze i pokazać, jak np. SentinelOne XDR może wesprzeć zespół w szybszym wykrywaniu realnych zagrożeń – nie na slajdach, tylko na konkretnych danych i przypadkach użycia.
