Case study: od alertu w SIEM do dowodu w Wiresharku

W realnym SOC droga do przechwycenia pakietów w Wiresharku prawie zawsze zaczyna się gdzie indziej — od alertu wygenerowanego przez SIEM (np. Splunk) na podstawie logów z EDR (np. Wazuh) lub innych źródeł.

Przykładowy scenariusz

1. Wazuh (EDR) zgłasza na hoście nietypowy proces wykonujący cykliczne żądania sieciowe — np. curl uruchamiany co kilka sekund przez proces, który normalnie nie wykonuje ruchu sieciowego.
2. Splunk (SIEM) koreluje to zdarzenie z logami zapory/proxy i generuje alert: powtarzalne żądania HTTP zwracające kod 200 do nieznanego wcześniej hosta — wzorzec pasujący do beaconingu (komunikacji C2).
3. Analityk przechodzi do Wiresharka, żeby potwierdzić hipotezę dowodem z samego ruchu: znajduje adres IP i przedział czasu z alertu, zawęża przechwycenie (ip.addr == ... and frame.time >= "..."), sprawdza regularność odstępów między żądaniami (frame.time_delta) i treść samych żądań przez Follow HTTP Stream.
4. Wynik trafia z powrotem do SIEM/EDR jako potwierdzenie lub odrzucenie hipotezy — Wireshark dostarcza dowód na poziomie pakietów, którego logi aplikacji same w sobie nie dają (np. rzeczywistą treść nagłówków, timing, czy ruch faktycznie wyszedł na zewnątrz).

Dlaczego ta kolejność ma znaczenie

Przechwytywanie całego ruchu "na wszelki wypadek" bez wcześniejszego alertu jest w praktyce rzadkie — zbyt duży wolumen danych do analizy. SIEM/EDR działają jako filtr wstępny, który wskazuje co i kiedy analizować, a Wireshark dostarcza dowód na poziomie sieci, którego same logi nie dają.