Analiza logów i śladów sieciowych po ataku — praktyczny przewodnik

Praktyczny, krok-po-kroku przewodnik do badania incydentu sieciowego: które logi zebrać, jak je szybko przeszukać, jakie narzędzia użyć i jak zbudować chronologiczną oś zdarzeń (timeline) pozwalającą odpowiedzieć kto → kiedy → jak. Skupiam się na logach sieciowych (PCAP, NetFlow, IDS/IPS, proxy, DNS) oraz powiązanych artefaktach endpointów (Event Log Windows, firewalle, zapisy zapory).

1) Szybka checklist — co zebrać od razu (prioritety)

1. Zrzut ruchu sieciowego (PCAP) z segmentu sieci lub interfejsu podejrzanego hosta.
2. Logi zapory (firewall), NAT/routera, proxy HTTP/HTTPS i serwera VPN.
3. NetFlow/sFlow/RiFlow (jeśli dostępne) — agregowane metadane połączeń.
4. Alerty IDS/IPS (Suricata, Snort) i logi Zeek/Bro (jeśli wdrożone).
5. Logi DNS (resolvery, forwardery) — często wskazują na domeny C2 lub exfil.
6. Windows Event Logs (Security, System, Application, PowerShell) oraz zrzut pamięci jeśli masz podejrzenie „in-memory” malware.
7. Kopie plików konfiguracyjnych serwisów i listy zadań (scheduled tasks).

Zbieraj dowody z zachowaniem integralności (hashy) i zapisz metadane (kto zebrał, kiedy, jak). (NIST: incident response lifecycle – detekcja, analiza, zawężanie, odzyskiwanie).

2) Gdzie szukać „dymu” — które logi dają najszybszy sygnał

• IDS/IPS (Suricata/Snort) — szybkie alerty na znane sygnatury i anomalie.
• Zeek (Bro) — generuje szczegółowe, ustrukturyzowane logi (http.log, dns.log, conn.log, files.log) idealne do forensics i korelacji.
• PCAP (Wireshark/tshark) — pełny zapis pakietów; konieczny, gdy trzeba odtworzyć payload lub zreplikować połączenia.
• DNS i proxy — często pierwsze miejsce, gdzie widać wywołania do domen C2 lub transfery exfiltracyjne. (Przeglądaj zapisy pod kątem nieznanych domen, krótkich TTL, dużej liczby zapytań).

3) Szybkie polecenia do natychmiastowej analizy PCAP / pakietów

• Wyświetlenie podsumowania ruchu w pliku pcap (tshark):

tshark -r capture.pcap -q -z conv,ip

• Filtrowanie po podejrzanym IP / porcie (Wireshark display filter):

ip.addr == 203.0.113.5
tcp.port == 4444

(Wireshark: Display Filter — nie mylić z pcap capture filter).

• Szybkie wyszukiwanie HTTP requestów zawierających „upload” (tshark):

tshark -r capture.pcap -Y 'http.request and http.request.uri contains "upload"'

• Uruchomienie Suricata nad PCAP, aby wygenerować alerty i JSON logi:

suricata -c /etc/suricata/suricata.yaml -r capture.pcap -l out/

(Suricata wygeneruje alerty w eve.json i fast.log).

• Przetworzenie PCAP przez Zeek do logów (conn, dns, http, files):

zeek -r capture.pcap

(Powstają pliki conn.log, dns.log, http.log które łatwiej przeszukać).

4) Co sprawdzać w logach sieciowych — praktyczne wskazówki

• Conn/log flow (Zeek / NetFlow):
  • Duże, nietypowe transfery danych z wewnętrznych hostów na zewnętrzne adresy (może to być exfil).
  • Połączenia na nietypowe porty lub do krajów/ASN, z którymi organizacja nie współpracuje.
• DNS:
  • Długie łańcuchy zapytań do nowo zarejestrowanych domen, DGA-like patterns (generator domen).
  • Duży wolumen krótkotrwałych zapytań — może sugerować tunelowanie DNS (data exfil przez zapytania).
• HTTP/HTTPS / Proxy logs:
  • Nietypowe metody HTTP (PUT, DELETE) od stacji roboczych.
  • Posty z danymi binarnymi lub wieloma wieloczęściowymi (multipart) requestami.
• TLS:
  • Certyfikaty samopodpisane, certyfikaty o krótkiej historii, lub niespójności w SNI; zwróć uwagę na połączenia TLS bez SNI.
• Alerty IDS (Suricata):
  • Szybko przeszukaj eve.json/fast.log po alertach klasy C2, HTTP POST z dużym payloadem, exploit patterns.

5) Analiza Windows Event Log powiązana z ruchem sieciowym

• Logi, które warto przeszukać: Security.evtx (4624, 4625, 4672), PowerShell.evtx (skrypty), System.evtx (sterowniki), Application.evtx. Microsoft opisuje Event ID 4624 (udane logowanie) i 4625 (nieudane) oraz zalecenia monitoringu.
• Szybkie polecenie PowerShell do wyciągnięcia udanych logowań (4624):

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} | 
    Select TimeCreated, @{n='Account';e={$_.Properties[5].Value}}, Message

• Korelacja: znajdź timestamp udanego logowania, następnie w conn.log Zeek lub w PCAP poszukaj połączeń z tej samej maszyny w tym przedziale czasowym — to pomaga łączyć aktywność użytkownika z ruchem sieciowym.

6) Jak wykryć exfiltrację danych w PCAP / logach

• Szukaj długich sesji z dużą objętością danych do jednego zewnętrznego IP.
• Sprawdź HTTP(S) POST z dużymi Content-Length lub wieloczęściowymi załącznikami.
• Analizuj DNS pod kątem długości zapytań (base64-like payloady), częstotliwości i wzorców (DGA).
• Korzystaj z Zeek files.log — potrafi wyodrębnić pliki przesyłane przez protokoły i zapisać je do analizy.

7) Budowanie osi czasu (timeline) — narzędzia i workflow

1. Normalizuj eventy: Zeek logs, IDS alerts, NetFlow, Windows Event Log, proxy logs → ujednolicone zdarzenia z timestampami UTC.
2. Stwórz timeline z narzędzi: Plaso / log2timeline → import do Timesketch (współpraca, annotacje, wyszukiwanie). Timesketch jest dedykowane do kolaboracyjnej analizy timeline.
3. Oznacz kluczowe punkty: pierwsze podejrzane zapytanie DNS, pierwsze udane logowanie, zrzut pamięci, uruchomienie skryptu PowerShell, transfer danych.
4. Interpretuj kolejność: np. exploit → payload → beaconing → lateral movement → exfiltration.

8) Automatyzacja i parsowanie logów — przykładowe skrypty / narzędzia

• jq do przetwarzania eve.json (Suricata) i zeek JSON.
• Elastic Stack (Elasticsearch + Logstash + Kibana) — świetne do agregacji i korelacji ogromnych ilości logów; używane powszechnie w SOC.
• Timesketch + Plaso — do timeline i współpracy.

9) Krótkie playbooki scenariuszowe (przykłady)

Scenariusz A — wykryto nietypowy duży upload z hosta A

1. Zabezpiecz PCAP/NetFlow covering host A timeframe.
2. Uruchom zeek -r capture.pcap → sprawdź conn.log, http.log, files.log.
3. W proxy logach wyszukaj POSTy z IP hosta A.
4. Porównaj z Windows Event 4624/4688 (uruchomienie procesów) by znaleźć program, który realizował transfer.

Scenariusz B — podejrzenie DNS-tunnelingu

1. Przeszukaj dns.log (Zeek) pod kątem długich wartości w qname, częstych zapytań do tej samej domeny.
2. Oblicz entropię zapytań DNS (skrypt Python) — wysoka entropia → sprawdź dalej.
3. Jeśli potwierdzone → zablokuj domenę i zbierz PCAP do dalszej analizy.

10) Najczęstsze pułapki i błędy początkujących

• Brak synchronizacji czasów — zawsze konwertuj do UTC i skoryguj zegary logów (NTP drift).
• Niszczenie dowodów — nie restartuj/zamykaj systemu bez wykonania zrzutu pamięci i obrazu dysku.
• Analiza tylko jednego źródła — PCAP bez korelacji z Event Log czy proxy daje niepełny obraz. (NIST: korelacja źródeł w ramach IR lifecycle).

11) Narzędzia — krótkie przypomnienie praktycznych pozycji

• Wireshark / tshark — interaktywna i skryptowa analiza PCAP.
• Zeek — parsowanie PCAP → conn/dns/http/files logi do szybkiej korelacji.
• Suricata — analiza PCAP/na żywo z generowaniem alertów (eve.json).
• Timesketch + Plaso (log2timeline) — budowanie i przeszukiwanie timeline.
• Elastic Stack — agregacja, korelacja i tworzenie dashboardów SOC.

12) Co wpisać do raportu końcowego (minimum)

• Zakres zebranych dowodów (PCAP, logi, IDS, obrazy).
• Chronologia kluczowych zdarzeń (timeline).
• Techniki ataku i artefakty (IP, domeny, obciążenia, nazwy plików).
• Ocena szkód (wyeksfiltrowane typy danych, zasięg).
• Rekomendacje (blokady sieciowe, zmiany konfiguracji, rotacja kluczy/hasel, aktualizacje, monitoring).

Przydatne linki do dokumentacji / dalszej nauki

• Zeek documentation (logs & monitoring).
• Suricata docs (PCAP mode, logging).
• Wireshark official / tutorials for PCAP analysis.
• NIST SP 800-61 r3 — aktualne wytyczne IR (lifecycle, dobre praktyki).
• Microsoft Event ID reference (4624, 4625, rekomendacje monitoringu).

Krótkie podsumowanie praktyczne

1. Zbieraj szybko, ale bez niszczenia dowodów (zrzut RAM → obraz dysku → logi).
2. Najpierw Zeek/Suricata/Wireshark — one dadzą ci strukturę i pierwsze hipotezy.
3. Korelacja z Windows Event Log i proxy pozwoli zidentyfikować „kto” i „skąd”.
4. Zbuduj timeline (Plaso → Timesketch) i wyciągnij wnioski, potem zaplanuj działania naprawcze.

Polecane wpisy

Ataki na łańcuch dostaw oprogramowania (Software Supply Chain Attacks): Nowe wektory zagrożeń w 2025 roku

🎯 Ataki na łańcuch dostaw oprogramowania (Software Supply Chain Attacks): Nowe wektory zagrożeń w 2025 roku 🔍 Czym są ataki Czytaj dalej

Jak działa szyfrowanie asymetryczne (klucza publicznego)?

🔐 Jak działa szyfrowanie asymetryczne (klucza publicznego)? Wyjaśnienie RSA, kryptografii krzywych eliptycznych (ECC), koncepcji kluczy publicznych i prywatnych oraz ich Czytaj dalej