Od alertu do dowodów: rekonstrukcja ataku z wykorzystaniem NetFlow

Ta rekonstrukcja jest jednym z najważniejszych elementów incident response. Zespół musi ustalić, kiedy rozpoczęła się podejrzana aktywność, który system został zaangażowany jako pierwszy, w jaki sposób atakujący komunikował się ze środowiskiem, czy doszło do lateral movement, do których systemów uzyskano dostęp oraz czy dane opuściły organizację. Ustalenia te muszą być poparte dowodami, które można przeanalizować, zakwestionować i skorelować z innymi źródłami.

NetFlow odgrywa w tym procesie określoną rolę. Zapewnia historyczny zapis komunikacji sieciowej oparty na metadanych: kto komunikował się z kim, kiedy komunikacja miała miejsce, jakich portów i protokołów użyto, jak długo trwało połączenie oraz ile danych przesłano. Nie dostarcza packet payloadu, zawartości plików ani komend na poziomie aplikacji, ale daje analitykom skalowalny sposób rekonstrukcji aktywności w całej sieci, często w znacznie dłuższych przedziałach czasowych niż full packet capture.

Dla zespołów SOC, DFIR i NetOps sprawia to, że NetFlow jest szczególnie przydatny w analizie post-incident. Gdy endpoint telemetry jest niepełna, packet capture jest niedostępny lub logi zostały już nadpisane, dane flow nadal mogą pokazać timeline komunikacji łączący pierwszy alert z szerszą ścieżką ataku.

Luka forensic — dlaczego alert nie jest dowodem

Alert jest punktem wyjścia do dochodzenia, a nie pełnym wyjaśnieniem incydentu. Zwykle odzwierciedla regułę, warunek lub anomalię wykrytą przez narzędzie bezpieczeństwa. Alert może zawierać wewnętrzny adres IP, zewnętrzny cel komunikacji, timestamp, nazwę sygnatury, konto użytkownika, kategorię detekcji lub severity score. Informacje te są przydatne na etapie triage, ale nie wyjaśniają automatycznie sekwencji aktywności, która doprowadziła do detekcji.

Luka forensic pojawia się wtedy, gdy dochodzenie przechodzi od detekcji do rekonstrukcji. Zespół musi zrozumieć kontekst alertu: komunikację, która miała miejsce przed nim, systemy zaangażowane po jego wystąpieniu oraz wzorce, które mogą wskazywać na ruch command-and-control, lateral movement lub eksfiltrację. Taka praca wymaga historycznych dowodów, a nie wyłącznie payloadu alertu.

Luka ta występuje często, ponieważ najbardziej szczegółowe źródła dowodów są zazwyczaj ograniczone pod względem retencji, zakresu lub dostępności. Endpoint telemetry może nie obejmować niezarządzanych assetów, serwerów, systemów legacy lub urządzeń, które zostały przejęte przed instalacją agenta EDR. Lokalne logi mogły zostać nadpisane lub usunięte przez atakującego. Logi firewalla i proxy często zapewniają dobrą widoczność na perymetrze, ale mogą nie wyjaśniać w pełni ruchu east-west wewnątrz środowiska. Logi cloud mogą znajdować się w oddzielnych konsolach, podlegać różnym politykom retencji i wymagać dodatkowej korelacji. Full packet capture zapewnia najgłębszy poziom szczegółowości technicznej, jednak przechowywanie pakietów na dużą skalę przez długi czas jest kosztowne i zwykle ogranicza się do wybranych segmentów lub krótkich przedziałów czasowych.

NetFlow pomaga wypełnić tę lukę, zachowując kompaktowy, przeszukiwalny zapis komunikacji sieciowej. Pozwala analitykom przejść od pojedynczej detekcji do szerszej aktywności wokół niej: wcześniejszych połączeń z tym samym celem, innych wewnętrznych hostów, które komunikowały się z tą samą infrastrukturą, powtarzających się wzorców outbound, nietypowych połączeń wewnętrznych oraz transferów o dużym wolumenie do sieci zewnętrznych. Dzięki temu dane flow są szczególnie przydatne wtedy, gdy dochodzenie wymaga spojrzenia wstecz.

Co NetFlow rzeczywiście rejestruje — a czego nie rejestruje

NetFlow rejestruje metadane dotyczące konwersacji obserwowanych w sieci. Flow jest zwykle definiowany przez zestaw wspólnych cech, takich jak source IP, destination IP, source port, destination port i protokół. W zależności od eksportera, wersji NetFlow, template’u IPFIX lub warstwy enrichment mogą być dostępne dodatkowe pola, w tym timestampy, liczba pakietów, liczba bajtów, flagi TCP, interfejsy, VLAN-y, numery autonomous system, informacje next-hop, identyfikatory aplikacji lub kierunek ruchu.

Uproszczony rekord flow może zawierać:

Przydatną analogią jest rachunek telefoniczny. Rekord pokazuje, że rozmowa miała miejsce, kto w niej uczestniczył, kiedy się rozpoczęła, jak długo trwała i jak często występowały podobne rozmowy. Treść rozmowy pozostaje poza rekordem. W ten sam sposób NetFlow pokazuje wzorce komunikacji, a nie rzeczywisty payload wymieniany między systemami.

To rozróżnienie jest kluczowe dla analizy forensic. Dane flow mogą pokazać, że wewnętrzny serwer wysłał 40 GB danych do zewnętrznego adresu IP między 01:15 a 02:05. Mogą pokazać, że stacja robocza łączyła się z tym samym rzadko obserwowanym celem co dziesięć minut przez kilka tygodni. Mogą również pokazać, że przejęty host zaczął komunikować się z wieloma systemami wewnętrznymi przez porty administracyjne. Nie mogą jednak samodzielnie wskazać dokładnych nazw plików, komend, credentials ani application payloadu wykorzystywanego w tej komunikacji.

Ruch szyfrowany podlega tej samej zasadzie. NetFlow może nadal opisywać metadane sesji TLS: endpointy, timing, częstotliwość, czas trwania i wolumen. Zaszyfrowana zawartość aplikacyjna pozostaje niedostępna na poziomie flow. Dlatego NetFlow jest najbardziej wartościowy przy rekonstrukcji timeline’u, ocenie zakresu i analizie behawioralnej, natomiast interpretacja na poziomie payloadu wymaga packet capture, endpoint telemetry, logów proxy, logów aplikacyjnych, możliwości deszyfrowania lub innych źródeł uzupełniających.

NetFlow vs full packet capture vs logi — kiedy korzystać z poszczególnych źródeł

NetFlow, full packet capture i logi służą różnym celom forensic. Traktowanie ich jako konkurencyjnych źródeł zwykle prowadzi do nierealistycznych oczekiwań. Traktowanie ich jako uzupełniających się warstw dowodowych zapewnia dochodzeniu pełniejsze podstawy.

NetFlow jest szczególnie skuteczny wtedy, gdy analityk musi zrozumieć kształt incydentu w całej sieci. Może ujawnić komunikację, która nigdy nie została zarejestrowana przez narzędzie endpointowe, połączenia między systemami wewnętrznymi, które nigdy nie przeszły przez firewall, albo historyczną aktywność występującą przed pierwszą detekcją o wysokim poziomie pewności.

Full packet capture zapewnia większą głębię tam, gdzie dostępne są dane pakietowe. Może wspierać inspekcję payloadu, dekodowanie protokołów, ekstrakcję malware, analizę komend lub walidację zawartości. W praktyce PCAP jest jednak często przechowywany przez krótszy czas ze względu na wymagania dotyczące storage’u i wydajności. Sprawia to, że jest bardzo skuteczny dla wybranych przedziałów czasowych i segmentów, ale mniej praktyczny jako jedyne długoterminowe źródło forensic.

Logi dodają kontekst, którego nie mogą zapewnić dane flow. Mogą wyjaśnić, który użytkownik się uwierzytelnił, jaki proces został uruchomiony, jakie wywołanie API wykonano, która polityka firewalla została zastosowana lub do którego zasobu cloud uzyskano dostęp. Dobrze prowadzone dochodzenie wykorzystuje NetFlow do ustalenia timeline’u komunikacji, a następnie koreluje go z logami i danymi pakietowymi wszędzie tam, gdzie są one dostępne.

Przewaga retencji — dlaczego lookback ma znaczenie

Wartość NetFlow znacząco rośnie, gdy dane są przechowywane wystarczająco długo, aby wspierać dochodzenia typu lookback. Wiele incydentów zostaje wykrytych już po pierwotnym przejęciu systemu. Detekcja, która pojawia się dzisiaj, może dotyczyć aktywności atakującego rozpoczętej kilka dni lub tygodni wcześniej. Bez historycznych metadanych sieciowych dochodzenie może obejmować wyłącznie ostatni widoczny etap ataku.

Dane flow są znacznie lżejsze niż full packet capture, ponieważ przechowują metadane zamiast packet payloadu. Dokładny rozmiar rekordu flow zależy od eksportera, template’u, wersji protokołu i włączonych pól, ale różnica operacyjna jest wyraźna: rekordy flow są wystarczająco kompaktowe, aby wspierać szeroki zakres zbierania danych i dłuższą retencję w środowiskach, w których full packet capture na każdym segmencie byłby niepraktyczny.

Dłuższa retencja umożliwia wykonywanie kilku ważnych działań dochodzeniowych:

• przeszukiwanie historycznej komunikacji z nowo zidentyfikowanym IOC;
• sprawdzanie, czy ten sam cel pojawiał się przed alertem;
• identyfikowanie innych wewnętrznych hostów, które komunikowały się z tą samą infrastrukturą;
• analizowanie wzorców komunikacji przed incydentem, w jego trakcie i po nim;
• porównywanie bieżącego zachowania z wcześniejszymi baseline’ami;
• rekonstruowanie aktywności po nadpisaniu logów z innych systemów;
• wspieranie raportowania regulacyjnego, prawnego lub zarządczego za pomocą dłuższego śladu dowodowego.

Dla wielu organizacji przeszukiwalna retencja danych flow na poziomie od 30 do 90 dni stanowi praktyczny baseline dla incident response. Środowiska o podwyższonym ryzyku, infrastruktura krytyczna, usługi finansowe, ochrona zdrowia, organizacje rządowe oraz firmy z dłuższymi czasami detekcji mogą wymagać rozszerzonej retencji, szczególnie dla internet egress, ruchu data center, sieci zarządzających, infrastruktury identity i łączności cloud.

Sampling i flow fidelity — dlaczego sampling może osłabiać dochodzenie

Sampling jest często wykorzystywany do zmniejszenia wolumenu telemetrii, ale działa inaczej w poszczególnych technologiach flow. NetFlow v9 i IPFIX mogą być eksportowane zarówno w trybie sampled, jak i w trybie 1:1 unsampled, w zależności od eksportera i jego konfiguracji. sFlow z założenia zawsze opiera się na samplingu — tryb unsampled sFlow nie istnieje. W traffic engineering, capacity planning i high-level visibility dane sampled mogą być wystarczające do identyfikowania trendów, głównych celów i dużych zmian w ruchu. W przypadku analizy forensic kompromis jest poważniejszy, ponieważ dochodzenie może zależeć od niewielkich, rzadkich lub występujących z niską częstotliwością sygnałów.

Wiele zachowań atakujących jest celowo subtelnych. Ruch command-and-control może wykorzystywać niewielkie, okresowe sesje. Lateral movement może występować jako krótkie połączenia administracyjne między wewnętrznymi hostami. Credential access lub discovery mogą obejmować krótkie bursty zamiast utrzymującego się ruchu. Eksfiltracja danych może być dzielona na mniejsze transfery, aby uniknąć prostych progów wolumetrycznych. Gdy sampling usuwa część tych rekordów, timeline może stać się niekompletny lub mylący.

Wpływ samplingu jest szczególnie widoczny w dochodzeniach wymagających precyzji:

• komunikacja first-seen z podejrzanym celem;
• beaconing o niskim wolumenie;
• krótkotrwałe połączenia wewnętrzne;
• rzadkie pary host-to-host;
• dokładna sekwencja lateral movement;
• niewielkie transfery z wrażliwych systemów;
• porównanie normalnego i nietypowego zachowania.

Sampled NetFlow/IPFIX oraz sFlow nadal mogą wspierać szeroką detekcję i analizę ruchu. Jednak tam, gdzie wymagana jest precyzyjna rekonstrukcja forensic, NetFlow v9 lub IPFIX powinny być zbierane w trybie 1:1 unsampled wszędzie tam, gdzie pozwalają na to wydajność eksportera i architektura. W tym kontekście „full-fidelity flow” odnosi się konkretnie do unsampled NetFlow v9 lub IPFIX, a nie do sFlow, który z założenia zawsze jest sampled. Jest to szczególnie istotne w segmentach krytycznych, w tym w sieciach serwerowych, połączeniach data center, internet egress, management VLAN-ach, infrastrukturze identity, cloud interconnects i środowiskach przechowujących dane wrażliwe.

Decyzja praktyczna ma zwykle charakter architektoniczny, a nie ideologiczny. Organizacje mogą wybrać NetFlow v9 lub IPFIX w trybie 1:1 dla ścieżek krytycznych oraz sampled NetFlow/IPFIX lub sFlow dla obszarów o niższym ryzyku i wysokim wolumenie. Najważniejsze jest, aby analitycy rozumieli, które źródła telemetrii są sampled, jaki jest skonfigurowany sampling rate i jak wpływa to na poziom pewności wniosków.

Od alertu do dowodów — rekonstrukcja krok po kroku

Skuteczne dochodzenie z wykorzystaniem NetFlow przebiega zgodnie z ustrukturyzowaną ścieżką. Analityk rozpoczyna od najsilniejszego faktu zawartego w alercie, potwierdza powiązaną komunikację w danych flow, ostrożnie rozszerza zakres i buduje timeline, który można skorelować z innymi źródłami dowodów.

Celem jest przejście od pojedynczego sygnału do udokumentowanej rekonstrukcji:

Krok 1 — Pivot od alertu do pierwszego flow

Pierwszym krokiem jest potwierdzenie, czy komunikacja opisana w alercie jest widoczna w danych flow. Alert może zawierać wewnętrzny host, zewnętrzny adres IP, domenę, destination port, protokół, timestamp lub kategorię detekcji. Początkowe zapytanie powinno być wystarczająco wąskie, aby ograniczyć noise, i wystarczająco precyzyjne, aby zweryfikować zdarzenie.

Przykładowe filtry:

src_ip = suspected_internal_host
dst_ip = external_ioc
dst_port = 443
protocol = TCP
time between alert_time - 30 minutes and alert_time + 30 minutes

Na tym etapie analityk powinien przeanalizować czas rozpoczęcia i zakończenia flow, liczbę bajtów, liczbę pakietów, czas trwania sesji, kierunek i powtarzalność. Pojedyncze połączenie z zewnętrznym adresem IP może wymagać dodatkowego kontekstu, natomiast powtarzające się połączenia z tym samym rzadko obserwowanym celem — szczególnie przy podobnej liczbie bajtów lub regularnych interwałach — mogą wskazywać na bardziej ustrukturyzowaną aktywność atakującego.

Pierwszy potwierdzony flow staje się punktem odniesienia dla dochodzenia. Łączy alert z zaobserwowanym zachowaniem sieciowym i definiuje pierwszy wiarygodny punkt timeline’u. Od tego momentu analityk może cofnąć się, aby znaleźć wcześniejszą aktywność, oraz przejść do przodu, aby zrozumieć, co wydarzyło się później.

Przydatny rezultat tego kroku:

• potwierdzone źródło i cel;
• czas pierwszej zaobserwowanej komunikacji w pobliżu momentu alertu;
• destination port i protokół;
• liczba bajtów i pakietów;
• powtarzalność w oknie alertu;
• wstępna ocena kierunku i rzadkości komunikacji.

Krok 2 — Ustalenie patient zero i initial access

Po potwierdzeniu pierwszego podejrzanego flow dochodzenie powinno ustalić, czy host wskazany w alercie był pierwszym przejętym systemem, czy jedynie pierwszym systemem, który wygenerował detekcję. To rozróżnienie ma znaczenie, ponieważ containment i remediation zależą od rzeczywistego punktu początkowego, a nie wyłącznie od pierwszego widocznego alertu.

Analityk powinien rozszerzyć wyszukiwanie wokół IOC i podejrzanego hosta. Historyczne dane flow mogą pokazać, czy inne systemy wewnętrzne komunikowały się z tym samym celem przed hostem wskazanym w alercie, czy podejrzany cel komunikował się z wieloma assetami albo czy host odebrał nietypową komunikację inbound, zanim rozpoczął ruch outbound.

Przykładowe pivoty:

• wszystkie wewnętrzne hosty komunikujące się z IOC;
• komunikacja first-seen między dowolnym wewnętrznym hostem a IOC;
• połączenia inbound do podejrzanego hosta przed alertem;
• protokoły uwierzytelniające lub administracyjne zaobserwowane przed podejrzanym flow outbound;
• komunikacja z nietypowych sieci zewnętrznych do usług wewnętrznych;
• inne hosty, które komunikowały się z tym samym celem w dniach lub tygodniach przed detekcją.

Przykładowe filtry:

dst_ip = external_ioc OR src_ip = external_ioc
internal_host in all hosts communicating with external_ioc
time between first_seen_ioc - 14 days and alert_time
dst_port in 22, 445, 3389, 5985, 5986

NetFlow zwykle nie jest w stanie samodzielnie potwierdzić dokładnego mechanizmu exploita lub kradzieży credentials, ale może zidentyfikować najwcześniejszą widoczną aktywność sieciową i wskazać systemy wymagające głębszej analizy endpointowej lub analizy logów. Jest to szczególnie przydatne, gdy pokrycie EDR jest niepełne albo initial access obejmował niezarządzane assety, wystawione usługi, infrastrukturę VPN, narzędzia zdalnej administracji lub integracje SaaS.

Rezultatem tego etapu powinno być krótkie, poparte dowodami stwierdzenie dotyczące najwcześniejszej zaobserwowanej podejrzanej komunikacji oraz systemów zaangażowanych przed wygenerowaniem alertu.

Krok 3 — Śledzenie C2 i beaconingu

Aktywność command-and-control często pozostawia w danych flow rozpoznawalny wzorzec. Zawartość komunikacji może być zaszyfrowana, ale zachowanie wokół niej nadal może być widoczne: powtarzające się połączenia, spójny timing, podobna liczba bajtów lub podobne wolumeny flow, długotrwałe sesje, rzadko obserwowane cele albo ruch występujący w nietypowych godzinach.

Analityk powinien skoncentrować się na powtarzalności i rytmie. Połączenia stacji roboczej z popularną platformą SaaS w godzinach pracy mogą być oczekiwane. Stacja robocza łącząca się z rzadko obserwowanym dostawcą hostingu co dziesięć minut przez kilka tygodni, przy podobnej liczbie bajtów i bez wyraźnego uzasadnienia biznesowego, wymaga dokładniejszej analizy.

Przydatne wskaźniki w danych flow:

• powtarzające się połączenia z tym samym zewnętrznym celem;
• regularne interwały między flow;
• niewielkie różnice w timingu, które mogą wskazywać na jitter;
• sesje outbound o niskim wolumenie przez HTTPS, DNS lub inne dozwolone protokoły;
• komunikacja z rzadko obserwowanym ASN, krajem lub dostawcą hostingu;
• aktywność poza normalnymi godzinami pracy;
• połączenia rozpoczynające się po podejrzanym zdarzeniu inbound lub wewnętrznym pivocie;
• wiele hostów wewnętrznych komunikujących się z tym samym zewnętrznym celem po lateral movement.

Przykładowe podejście analityczne:

Przykładowe filtry:

src_ip = suspected_host
dst_ip = external_destination
group by 5-minute, 15-minute or 1-hour intervals
count flows by interval
sum bytes_out by destination
show first_seen and last_seen for host-destination pair

Analiza C2 powinna zawsze obejmować walidację. Wiele legalnych narzędzi generuje okresowy ruch: aktualizacje oprogramowania, agenci telemetryczni, platformy monitoringu, klienty VPN, narzędzia współpracy i usługi cloud. Różnica zwykle wynika z reputacji celu, jego rzadkości, roli hosta, timingu, regularności, związku z alertem oraz korelacji z innymi dowodami.

Rezultatem tego kroku powinno być jasne podsumowanie wzorca: kiedy rozpoczęła się komunikacja, jak często występowała, jaki cel był zaangażowany, ile danych przesłano, czy inne hosty wykazywały to samo zachowanie oraz w jaki sposób wzorzec wiąże się z pierwotnym alertem.

Krok 4 — Mapowanie lateral movement i blast radius

Po zrozumieniu komunikacji zewnętrznej dochodzenie powinno przenieść się do wnętrza sieci. Lateral movement jest często widoczny w NetFlow jako nowa lub nietypowa komunikacja east-west między systemami wewnętrznymi. Najważniejsze sygnały to zmiany relacji host-to-host, wykorzystanie portów administracyjnych, komunikacja między segmentami oraz aktywność systemów, które zwykle nie inicjują takich połączeń.

Analityk powinien porównać ruch z okna incydentu z zachowaniem historycznym. Serwer komunikujący się codziennie z bazą danych przez wiele miesięcy jest mniej podejrzany niż stacja robocza użytkownika, która po połączeniu z podejrzanym celem zewnętrznym nagle zaczyna łączyć się z kilkoma serwerami przez SMB, RDP lub WinRM.

Przydatne pivoty:

• wszystkie wewnętrzne cele, z którymi podejrzany host komunikował się po initial access;
• nowe pary host-to-host w porównaniu z poprzednimi 30 dniami;
• komunikacja z subnetów użytkowników do subnetów serwerowych;
• ruch między security zones;
• połączenia z portami administracyjnymi;
• wewnętrzne wzorce komunikacji one-to-many;
• wewnętrzne hosty, które później komunikowały się z tą samą zewnętrzną infrastrukturą C2.

Przykładowe filtry:

src_ip = suspected_host
dst_ip in internal_ranges
time after first_suspicious_flow
dst_port in 22, 135, 139, 445, 3389, 5985, 5986
show conversations not observed in previous 30 days

Praktyczna analiza lateral movement powinna oddzielać oczekiwane zależności od podejrzanych zmian. Część komunikacji wewnętrznej jest elementem normalnych operacji biznesowych: uwierzytelniania domenowego, wdrażania oprogramowania, backupu, monitoringu, dostępu do baz danych lub zależności aplikacyjnych. Analiza flow staje się skuteczniejsza, gdy zostanie wzbogacona o role assetów, strefy sieciowe, baseline zachowania i znane relacje między usługami.

Blast radius powinien zostać udokumentowany jako sekwencja, a nie płaska lista. Raport powinien pokazywać, który system komunikował się jako pierwszy, z jakimi systemami wewnętrznymi nawiązano następnie połączenia, jakich portów użyto oraz czy którykolwiek z tych systemów wykazał później komunikację zewnętrzną lub dalszy lateral movement.

Przydatny rezultat może wyglądać następująco:

Tego rodzaju timeline pomaga zespołom incident response ustalać priorytety dla containment, endpoint imaging, resetowania credentials i analizy logów.

Krok 5 — Kwantyfikacja eksfiltracji

Dane flow są szczególnie przydatne do szacowania aktywności związanej z transferami outbound. Mogą pokazać, które systemy wysyłały dane poza środowisko, kiedy transfer miał miejsce, jak długo trwał, jaki cel odebrał ruch, jakiego protokołu użyto i ile danych przesłano.

Analiza powinna koncentrować się na wolumenie outbound, rzadkości celu, czasie transferu i związku z wcześniejszymi etapami incydentu. Duży transfer do znanego dostawcy backupu może być oczekiwany. Duży transfer z serwera bazodanowego do nowo zaobserwowanego dostawcy VPS w nocy stanowi sygnał o wyższym ryzyku, szczególnie jeśli został poprzedzony lateral movement.

Przydatne pivoty:

• bajty outbound z podejrzanych hostów;
• najważniejsze zewnętrzne cele według wolumenu uploadu;
• cele zaobserwowane po raz pierwszy w oknie incydentu;
• rzadko obserwowane ASN-y, kraje lub dostawcy cloud;
• długotrwałe sesje;
• nietypowe proporcje upload-to-download;
• transfery poza godzinami pracy;
• ruch z systemów wrażliwych do sieci zewnętrznych;
• powtarzające się mniejsze transfery, które łącznie reprezentują znaczący wolumen.

Przykładowe filtry:

src_ip in suspected_hosts
dst_ip not in internal_ranges
sum bytes_out by dst_ip, dst_port, ASN, country
time between compromise_start and containment_time
show destinations first seen during incident window
sort by bytes_out descending

Dane flow należy wykorzystywać ostrożnie w raportowaniu eksfiltracji. Mogą wspierać oszacowanie, ile danych opuściło środowisko, ale identyfikacja dokładnej zawartości zwykle wymaga korelacji z logami dostępu do plików, logami baz danych, storage audit logs, DLP, endpoint telemetry, logami aplikacyjnymi lub packet capture. Najsilniejszy wniosek wynikający z NetFlow dotyczy zwykle zakresu i timingu transferu: źródła, celu, wolumenu, protokołu i czasu trwania.

Podsumowanie eksfiltracji możliwe do obrony powinno zawierać:

• zaangażowane systemy źródłowe;
• docelowe adresy IP, ASN-y, kraje lub dostawców cloud;
• czas rozpoczęcia i zakończenia transferu;
• całkowitą liczbę bajtów outbound;
• protokół i porty;
• informację, czy cel był wcześniej obserwowany;
• związek z aktywnością C2 lub lateral movement;
• poziom pewności i wymagane dowody uzupełniające.

Informacje te są wartościowe dla oceny wpływu incydentu, analizy prawnej, decyzji dotyczących zgłoszeń i raportowania zarządczego. Nawet jeśli potwierdzenie na poziomie zawartości pochodzi z innego systemu, NetFlow często zapewnia pierwsze wiarygodne oszacowanie skali transferu.

Mapowanie dowodów do MITRE ATT&CK

Dowody oparte na flow stają się bardziej użyteczne, gdy są mapowane do wspólnego frameworka. MITRE ATT&CK pomaga przełożyć obserwacje sieciowe na uznane taktyki i techniki, dzięki czemu raport końcowy jest łatwiejszy do zrozumienia dla zespołów SOC, incident responderów, audytorów i osób zarządzających bezpieczeństwem.

NetFlow wspiera mapowanie ATT&CK na poziomie behawioralnym. Nie potwierdza automatycznie konkretnej techniki, ale może dostarczyć dowodów zgodnych z technikami posiadającymi widoczny komponent sieciowy.

Sformułowania używane w raportach powinny pozostać precyzyjne. Dane flow mogą wspierać ustalenie, wskazywać zachowanie zgodne z określoną techniką lub uzasadniać dalszą analizę. Silniejsze wnioski zwykle wymagają korelacji z logami endpointowymi, danymi identity, analizą malware, packet capture lub dowodami aplikacyjnymi.

Dobrze napisany raport z dochodzenia może zawierać następujące stwierdzenie:

„Rekordy flow pokazują okresową komunikację outbound przez TLS z hosta 10.10.4.25 do rzadko obserwowanego celu zewnętrznego co 10–12 minut między 3 a 17 maja. Wzorzec jest zgodny z zachowaniem command-and-control na poziomie aplikacji i wspiera mapowanie do MITRE ATT&CK T1071. W tym samym przedziale czasowym host zainicjował nowe połączenia SMB z trzema wewnętrznymi serwerami, których nie obserwowano w baseline z poprzednich 30 dni, co uzasadnia dalszą analizę pod kątem lateral movement”.

Taki sposób opisu łączy dowody techniczne z uznanym frameworkiem, zachowując jednocześnie rozróżnienie między zaobserwowanym faktem a interpretacją analityczną.

Przekształcanie flow w dowody możliwe do obrony — timeline, integralność i retencja

Aby NetFlow mógł wspierać raport z incydentu, przegląd regulacyjny lub analizę post-incident, musi być traktowany jako dowód, a nie wyłącznie jako telemetria operacyjna. Analityk powinien być w stanie wyjaśnić, skąd pochodzą dane, w jaki sposób zostały zebrane, jaki przedział czasowy obejmują, czy były sampled, jakich filtrów użyto i w jaki sposób wyciągnięto wnioski.

Dochodzenie oparte na flow, którego wyniki można obronić, powinno dokumentować:

• źródło flow: router, switch, firewall, probe, virtual appliance lub eksporter cloud;
• format: NetFlow v5, NetFlow v9, IPFIX, sFlow lub inne źródło telemetrii;
• zakres zbierania danych: objęte segmenty, interfejsy, VLAN-y, sieci cloud lub punkty egress;
• fidelity: dla NetFlow v9/IPFIX — czy eksport jest sampled, czy 1:1 unsampled; dla sFlow — skonfigurowany sampling rate;
• okres retencji: dostępne historyczne okno dochodzenia;
• obsługę czasu: strefę czasową, synchronizację zegarów i spójność timestampów;
• zapytania: filtry, pivoty i logikę agregacji wykorzystywane przez analityka;
• eksporty: zachowane surowe rekordy lub fragmenty raportów;
• korelację: powiązania z alertami, logami, zdarzeniami EDR, DNS, proxy, firewallem lub PCAP;
• notatki analityka: założenia, poziomy pewności i nierozwiązane luki.

Timeline dochodzenia powinien być ustrukturyzowany i możliwy do odtworzenia. Silny timeline obejmuje pierwszą zaobserwowaną podejrzaną komunikację, pierwszy powtarzający się wzorzec zewnętrzny, pierwszy wewnętrzny pivot, pierwsze połączenie z systemami wrażliwymi, początek i koniec podejrzewanej eksfiltracji, działania containment oraz ostatni zaobserwowany podejrzany flow.

Praktyczny timeline dowodowy może zawierać następujące pola:

Należy również uwzględnić integralność danych. Jeśli dane flow są eksportowane na potrzeby analizy prawnej, regulacyjnej, ubezpieczeniowej lub zarządczej, należy zachować surowe dowody. Dostęp powinien być kontrolowany, eksporty udokumentowane, a przekształcenia wykonywane przez analityków oddzielone od oryginalnych rekordów. Dashboardy i wizualizacje są przydatne w analizie, ale rekordy źródłowe powinny pozostać dostępne do weryfikacji.

Retencja jest ostatnim fundamentem. Platforma flow może wspierać rekonstrukcję wyłącznie wtedy, gdy odpowiedni przedział czasowy jest nadal dostępny. Organizacje powinny definiować retencję na podstawie realistycznych czasów detekcji, ryzyka biznesowego i oczekiwań regulacyjnych. Dla wielu środowisk od 30 do 90 dni przeszukiwalnych danych flow stanowi praktyczne minimum dla incident response. Dłuższa retencja jest wartościowa dla środowisk o wysokim ryzyku, infrastruktury krytycznej, sektorów regulowanych i organizacji, które muszą wykonywać lookback po opóźnionej detekcji lub opóźnionej publikacji threat intelligence.

Jak wygląda to w praktyce z Sycope

W praktyce rekonstrukcja ataku z wykorzystaniem NetFlow wymaga czegoś więcej niż samo przechowywanie rekordów. Analitycy potrzebują efektywnych możliwości wyszukiwania, filtrowania, enrichment, korelacji i wizualizacji, aby móc przejść od alertu do timeline’u bez ręcznego łączenia rozproszonych eksportów z wielu narzędzi.

Sycope wspiera ten workflow, wykorzystując dane flow jako podstawę network visibility i dochodzeń dotyczących incydentów. Przechowywane dane NetFlow, IPFIX i sFlow można przeszukiwać historycznie, filtrować według hosta, portu, protokołu, konwersacji, kierunku, przedziału czasowego lub innego kontekstu oraz wykorzystywać do rekonstrukcji wzorców komunikacji przed pierwszym alertem i po nim.

Praktyczne dochodzenie w Sycope może przebiegać zgodnie z następującym workflow:

• Rozpocznij od security indicatora, anomalii, podejrzanego celu lub hosta.
• Wykonaj pivot do powiązanych konwersacji sieciowych w odpowiednim przedziale czasowym.
• Przeanalizuj historyczną komunikację tego samego hosta, celu lub usługi.
• Zidentyfikuj aktywność first-seen i powtarzające się wzorce komunikacji.
• Rozszerz zakres na wewnętrzny ruch host-to-host.
• Porównaj zaobserwowane zachowanie z normalnymi baseline’ami komunikacji.
• Oblicz wolumen transferu outbound według źródła, celu, protokołu i czasu.
• Zbuduj timeline, który może wspierać dokumentację incydentu.

Workflow ten jest wartościowy, gdy pierwszy sygnał jest niekompletny. Analityk SOC może rozpocząć wyłącznie od zewnętrznego adresu IP pochodzącego z threat intelligence. Zespół NetOps może zauważyć nietypowy wolumen ruchu, nie wiedząc, czy jest on złośliwy. Analityk DFIR może potrzebować potwierdzenia, czy przejęty host komunikował się z serwerami wewnętrznymi przed containment. Analiza flow łączy te punkty wyjścia z historycznymi dowodami komunikacji.

Security indicators mogą stanowić punkt wejścia, ale główna wartość wynika z kolejnych pivotów:

• od jednego IOC do wszystkich wewnętrznych hostów, które się z nim komunikowały;
• od jednego hosta do wszystkich zewnętrznych celów, z którymi komunikował się w oknie incydentu;
• od jednego podejrzanego flow do wcześniejszych wystąpień tego samego wzorca;
• od jednego przejętego systemu do wszystkich nowych połączeń wewnętrznych;
• od jednego transferu o wysokim wolumenie do szerszej oceny eksfiltracji;
• od jednego alertu do timeline’u dowodowego, którego wyniki można obronić.

Dla zespołów SOC skraca to triage i pomaga ustalić, czy alert reprezentuje izolowaną aktywność, czy element szerszego przejęcia środowiska. Dla zespołów DFIR wspiera rekonstrukcję post-incident i zbieranie dowodów. Dla zespołów NetOps zapewnia kontekst, który pomaga odróżnić oczekiwane zachowanie sieci od błędnej konfiguracji, nadużycia lub przejęcia systemu.

Rezultatem jest bardziej ustrukturyzowane dochodzenie. Zamiast traktować alert jako samodzielne zdarzenie, zespół może wykorzystać dane flow do rekonstrukcji otaczającej go ścieżki komunikacji, zweryfikowania zakresu dotkniętych systemów i udokumentowania dowodów stojących za końcowym wnioskiem.

FAQ

Czy można prowadzić network forensics wyłącznie z wykorzystaniem NetFlow?

NetFlow może wspierać wiele zadań z zakresu network forensics, szczególnie rekonstrukcję timeline’u, mapowanie komunikacji, analizę lateral movement, detekcję beaconingu i ocenę wolumenu eksfiltracji. Jest szczególnie przydatny, gdy analitycy potrzebują szerokiej historycznej widoczności w wielu segmentach sieci.

W przypadku pełnego incident response NetFlow powinien być korelowany z innymi źródłami dowodów, takimi jak EDR, logi SIEM, DNS, proxy, firewall, logi identity, logi cloud, logi aplikacyjne i packet capture. Dane flow dostarczają struktury komunikacyjnej incydentu, natomiast inne źródła zapewniają kontekst użytkownika, procesu, payloadu i aplikacji.

Czy NetFlow rejestruje packet payload lub zawartość zaszyfrowanego ruchu?

NetFlow rejestruje metadane dotyczące komunikacji, a nie packet payload. Może pokazać źródło i cel, porty, protokół, timestampy, czas trwania, pakiety i bajty. Nie pokazuje zawartości wymienianej między systemami.

W przypadku ruchu szyfrowanego NetFlow nadal może pokazać, że wystąpiła sesja TLS, jak często się powtarzała, jak długo trwała i ile danych przesłano. Zaszyfrowana zawartość aplikacyjna pozostaje poza rekordem flow i wymaga innych źródeł telemetrii lub możliwości inspekcji.

Jak długo należy przechowywać dane flow na potrzeby dochodzeń?

Praktycznym baseline’em dla wielu organizacji jest od 30 do 90 dni przeszukiwalnych danych flow. Takie okno retencji wspiera dochodzenia typu lookback, opóźnioną detekcję, retro-hunting na podstawie threat intelligence i rekonstrukcję post-incident.

Organizacje o wyższym poziomie ryzyka, działalności regulowanej, infrastrukturze krytycznej, danych wrażliwych lub dłuższych oczekiwanych czasach detekcji mogą potrzebować dłuższej retencji. Internet egress, ruch data center, infrastruktura identity, sieci zarządzające i łączność cloud są szczególnie ważnymi obszarami wymagającymi rozszerzonej widoczności.

NetFlow vs PCAP — co jest bardziej przydatne w incident response?

NetFlow i PCAP odpowiadają na różne pytania. NetFlow zapewnia szeroką, skalowalną widoczność i dłuższą retencję, dzięki czemu jest przydatny do identyfikowania, kto komunikował się z kim, kiedy komunikacja miała miejsce i ile danych przesłano. PCAP zapewnia szczegółowość na poziomie pakietów i może wspierać głęboką analizę wybranych sesji tam, gdzie dostępne są dane pakietowe, a payload jest technicznie dostępny.

Praktyczny model incident response wykorzystuje NetFlow do zidentyfikowania odpowiedniego hosta, celu, przedziału czasowego i wzorca komunikacji, a następnie PCAP do głębszej inspekcji, gdy dane pakietowe są dostępne.

Czy dane flow mogą wskazać, jakie dane zostały skradzione?

Dane flow mogą zwykle pokazać, że dane opuściły środowisko, który system je wysłał, dokąd trafiły, kiedy transfer miał miejsce, jakiego protokołu użyto i ile danych przesłano. Zwykle nie mogą zidentyfikować dokładnych nazw plików, rekordów ani zawartości payloadu.

Aby ustalić, jakie dane zostały skradzione, analitycy muszą skorelować dowody flow z logami dostępu do plików, logami baz danych, logami aplikacyjnymi, alertami DLP, endpoint telemetry, storage audit logs lub packet capture. NetFlow dostarcza timeline’u i wolumenu transferu, natomiast inne źródła zapewniają potwierdzenie na poziomie zawartości.