\n| Kwantyfikacja eksfiltracji<\/td>\n | Wolumen outbound i rzadko obserwowane cele<\/td>\n | Szacowany timeline transferu danych<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\nKrok 1 \u2014 Pivot od alertu do pierwszego flow<\/h3>\nPierwszym krokiem jest potwierdzenie, czy komunikacja opisana w alercie jest widoczna w danych flow. Alert mo\u017ce zawiera\u0107 wewn\u0119trzny host, zewn\u0119trzny adres IP, domen\u0119, destination port, protok\u00f3\u0142, timestamp lub kategori\u0119 detekcji. Pocz\u0105tkowe zapytanie powinno by\u0107 wystarczaj\u0105co w\u0105skie, aby ograniczy\u0107 noise, i wystarczaj\u0105co precyzyjne, aby zweryfikowa\u0107 zdarzenie.<\/p>\n Przyk\u0142adowe filtry:<\/strong><\/p>\nsrc_ip = suspected_internal_host\r\ndst_ip = external_ioc\r\ndst_port = 443\r\nprotocol = TCP\r\ntime between alert_time - 30 minutes and alert_time + 30 minutes<\/code><\/pre>\nNa tym etapie analityk powinien przeanalizowa\u0107 czas rozpocz\u0119cia i zako\u0144czenia flow, liczb\u0119 bajt\u00f3w, liczb\u0119 pakiet\u00f3w, czas trwania sesji, kierunek i powtarzalno\u015b\u0107. Pojedyncze po\u0142\u0105czenie z zewn\u0119trznym adresem IP mo\u017ce wymaga\u0107 dodatkowego kontekstu, natomiast powtarzaj\u0105ce si\u0119 po\u0142\u0105czenia z tym samym rzadko obserwowanym celem \u2014 szczeg\u00f3lnie przy podobnej liczbie bajt\u00f3w lub regularnych interwa\u0142ach \u2014 mog\u0105 wskazywa\u0107 na bardziej ustrukturyzowan\u0105 aktywno\u015b\u0107 atakuj\u0105cego.<\/p>\n Pierwszy potwierdzony flow staje si\u0119 punktem odniesienia dla dochodzenia. \u0141\u0105czy alert z zaobserwowanym zachowaniem sieciowym i definiuje pierwszy wiarygodny punkt timeline\u2019u. Od tego momentu analityk mo\u017ce cofn\u0105\u0107 si\u0119, aby znale\u017a\u0107 wcze\u015bniejsz\u0105 aktywno\u015b\u0107, oraz przej\u015b\u0107 do przodu, aby zrozumie\u0107, co wydarzy\u0142o si\u0119 p\u00f3\u017aniej.<\/p>\n Przydatny rezultat tego kroku:<\/strong><\/p>\n\n- potwierdzone \u017ar\u00f3d\u0142o i cel;<\/li>\n
- czas pierwszej zaobserwowanej komunikacji w pobli\u017cu momentu alertu;<\/li>\n
- destination port i protok\u00f3\u0142;<\/li>\n
- liczba bajt\u00f3w i pakiet\u00f3w;<\/li>\n
- powtarzalno\u015b\u0107 w oknie alertu;<\/li>\n
- wst\u0119pna ocena kierunku i rzadko\u015bci komunikacji.<\/li>\n<\/ul>\n
Krok 2 \u2014 Ustalenie patient zero i initial access<\/h3>\nPo potwierdzeniu pierwszego podejrzanego flow dochodzenie powinno ustali\u0107, czy host wskazany w alercie by\u0142 pierwszym przej\u0119tym systemem, czy jedynie pierwszym systemem, kt\u00f3ry wygenerowa\u0142 detekcj\u0119. To rozr\u00f3\u017cnienie ma znaczenie, poniewa\u017c containment i remediation zale\u017c\u0105 od rzeczywistego punktu pocz\u0105tkowego, a nie wy\u0142\u0105cznie od pierwszego widocznego alertu.<\/p>\n Analityk powinien rozszerzy\u0107 wyszukiwanie wok\u00f3\u0142 IOC i podejrzanego hosta. Historyczne dane flow mog\u0105 pokaza\u0107, czy inne systemy wewn\u0119trzne komunikowa\u0142y si\u0119 z tym samym celem przed hostem wskazanym w alercie, czy podejrzany cel komunikowa\u0142 si\u0119 z wieloma assetami albo czy host odebra\u0142 nietypow\u0105 komunikacj\u0119 inbound, zanim rozpocz\u0105\u0142 ruch outbound.<\/p>\n Przyk\u0142adowe pivoty:<\/strong><\/p>\n\n- wszystkie wewn\u0119trzne hosty komunikuj\u0105ce si\u0119 z IOC;<\/li>\n
- komunikacja first-seen mi\u0119dzy dowolnym wewn\u0119trznym hostem a IOC;<\/li>\n
- po\u0142\u0105czenia inbound do podejrzanego hosta przed alertem;<\/li>\n
- protoko\u0142y uwierzytelniaj\u0105ce lub administracyjne zaobserwowane przed podejrzanym flow outbound;<\/li>\n
- komunikacja z nietypowych sieci zewn\u0119trznych do us\u0142ug wewn\u0119trznych;<\/li>\n
- inne hosty, kt\u00f3re komunikowa\u0142y si\u0119 z tym samym celem w dniach lub tygodniach przed detekcj\u0105.<\/li>\n<\/ul>\n
Przyk\u0142adowe filtry:<\/strong><\/p>\ndst_ip = external_ioc OR src_ip = external_ioc\r\ninternal_host in all hosts communicating with external_ioc\r\ntime between first_seen_ioc - 14 days and alert_time\r\ndst_port in 22, 445, 3389, 5985, 5986<\/code><\/pre>\nNetFlow zwykle nie jest w stanie samodzielnie potwierdzi\u0107 dok\u0142adnego mechanizmu exploita lub kradzie\u017cy credentials, ale mo\u017ce zidentyfikowa\u0107 najwcze\u015bniejsz\u0105 widoczn\u0105 aktywno\u015b\u0107 sieciow\u0105 i wskaza\u0107 systemy wymagaj\u0105ce g\u0142\u0119bszej analizy endpointowej lub analizy log\u00f3w. Jest to szczeg\u00f3lnie przydatne, gdy pokrycie EDR jest niepe\u0142ne albo initial access obejmowa\u0142 niezarz\u0105dzane assety, wystawione us\u0142ugi, infrastruktur\u0119 VPN, narz\u0119dzia zdalnej administracji lub integracje SaaS.<\/p>\n Rezultatem tego etapu powinno by\u0107 kr\u00f3tkie, poparte dowodami stwierdzenie dotycz\u0105ce najwcze\u015bniejszej zaobserwowanej podejrzanej komunikacji oraz system\u00f3w zaanga\u017cowanych przed wygenerowaniem alertu.<\/p>\n Krok 3 \u2014 \u015aledzenie C2 i beaconingu<\/h3>\nAktywno\u015b\u0107 command-and-control cz\u0119sto pozostawia w danych flow rozpoznawalny wzorzec. Zawarto\u015b\u0107 komunikacji mo\u017ce by\u0107 zaszyfrowana, ale zachowanie wok\u00f3\u0142 niej nadal mo\u017ce by\u0107 widoczne: powtarzaj\u0105ce si\u0119 po\u0142\u0105czenia, sp\u00f3jny timing, podobna liczba bajt\u00f3w lub podobne wolumeny flow, d\u0142ugotrwa\u0142e sesje, rzadko obserwowane cele albo ruch wyst\u0119puj\u0105cy w nietypowych godzinach.<\/p>\n Analityk powinien skoncentrowa\u0107 si\u0119 na powtarzalno\u015bci i rytmie. Po\u0142\u0105czenia stacji roboczej z popularn\u0105 platform\u0105 SaaS w godzinach pracy mog\u0105 by\u0107 oczekiwane. Stacja robocza \u0142\u0105cz\u0105ca si\u0119 z rzadko obserwowanym dostawc\u0105 hostingu co dziesi\u0119\u0107 minut przez kilka tygodni, przy podobnej liczbie bajt\u00f3w i bez wyra\u017anego uzasadnienia biznesowego, wymaga dok\u0142adniejszej analizy.<\/p>\n Przydatne wska\u017aniki w danych flow:<\/strong><\/p>\n\n- powtarzaj\u0105ce si\u0119 po\u0142\u0105czenia z tym samym zewn\u0119trznym celem;<\/li>\n
- regularne interwa\u0142y mi\u0119dzy flow;<\/li>\n
- niewielkie r\u00f3\u017cnice w timingu, kt\u00f3re mog\u0105 wskazywa\u0107 na jitter;<\/li>\n
- sesje outbound o niskim wolumenie przez HTTPS, DNS lub inne dozwolone protoko\u0142y;<\/li>\n
- komunikacja z rzadko obserwowanym ASN, krajem lub dostawc\u0105 hostingu;<\/li>\n
- aktywno\u015b\u0107 poza normalnymi godzinami pracy;<\/li>\n
- po\u0142\u0105czenia rozpoczynaj\u0105ce si\u0119 po podejrzanym zdarzeniu inbound lub wewn\u0119trznym pivocie;<\/li>\n
- wiele host\u00f3w wewn\u0119trznych komunikuj\u0105cych si\u0119 z tym samym zewn\u0119trznym celem po lateral movement.<\/li>\n<\/ul>\n
Przyk\u0142adowe podej\u015bcie analityczne:<\/strong><\/p>\n\n \n\n\n| Wska\u017anik C2<\/th>\n | Obserwacja oparta na flow<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Okresowy beaconing<\/td>\n | Ten sam host \u0142\u0105czy si\u0119 z tym samym celem w regularnych interwa\u0142ach.<\/td>\n<\/tr>\n | \n| Jitter<\/td>\n | Interwa\u0142y r\u00f3\u017cni\u0105 si\u0119 nieznacznie wok\u00f3\u0142 sta\u0142ej \u015bredniej.<\/td>\n<\/tr>\n | \n| Zachowanie low-and-slow<\/td>\n | Niewielka liczba bajt\u00f3w powtarzana przez d\u0142ugi czas.<\/td>\n<\/tr>\n | \n| Szyfrowane C2<\/td>\n | Powtarzaj\u0105ce si\u0119 sesje TLS bez widoczno\u015bci payloadu.<\/td>\n<\/tr>\n | \n| Ponowne wykorzystanie infrastruktury<\/td>\n | Wiele wewn\u0119trznych host\u00f3w \u0142\u0105czy si\u0119 z tym samym rzadko obserwowanym celem zewn\u0119trznym.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n Przyk\u0142adowe filtry:<\/strong><\/p>\nsrc_ip = suspected_host\r\ndst_ip = external_destination\r\ngroup by 5-minute, 15-minute or 1-hour intervals\r\ncount flows by interval\r\nsum bytes_out by destination\r\nshow first_seen and last_seen for host-destination pair<\/code><\/pre>\nAnaliza C2 powinna zawsze obejmowa\u0107 walidacj\u0119. Wiele legalnych narz\u0119dzi generuje okresowy ruch: aktualizacje oprogramowania, agenci telemetryczni, platformy monitoringu, klienty VPN, narz\u0119dzia wsp\u00f3\u0142pracy i us\u0142ugi cloud. R\u00f3\u017cnica zwykle wynika z reputacji celu, jego rzadko\u015bci, roli hosta, timingu, regularno\u015bci, zwi\u0105zku z alertem oraz korelacji z innymi dowodami.<\/p>\n Rezultatem tego kroku powinno by\u0107 jasne podsumowanie wzorca: kiedy rozpocz\u0119\u0142a si\u0119 komunikacja, jak cz\u0119sto wyst\u0119powa\u0142a, jaki cel by\u0142 zaanga\u017cowany, ile danych przes\u0142ano, czy inne hosty wykazywa\u0142y to samo zachowanie oraz w jaki spos\u00f3b wzorzec wi\u0105\u017ce si\u0119 z pierwotnym alertem.<\/p>\n Krok 4 \u2014 Mapowanie lateral movement i blast radius<\/h3>\nPo zrozumieniu komunikacji zewn\u0119trznej dochodzenie powinno przenie\u015b\u0107 si\u0119 do wn\u0119trza sieci. Lateral movement jest cz\u0119sto widoczny w NetFlow jako nowa lub nietypowa komunikacja east-west mi\u0119dzy systemami wewn\u0119trznymi. Najwa\u017cniejsze sygna\u0142y to zmiany relacji host-to-host, wykorzystanie port\u00f3w administracyjnych, komunikacja mi\u0119dzy segmentami oraz aktywno\u015b\u0107 system\u00f3w, kt\u00f3re zwykle nie inicjuj\u0105 takich po\u0142\u0105cze\u0144.<\/p>\n Analityk powinien por\u00f3wna\u0107 ruch z okna incydentu z zachowaniem historycznym. Serwer komunikuj\u0105cy si\u0119 codziennie z baz\u0105 danych przez wiele miesi\u0119cy jest mniej podejrzany ni\u017c stacja robocza u\u017cytkownika, kt\u00f3ra po po\u0142\u0105czeniu z podejrzanym celem zewn\u0119trznym nagle zaczyna \u0142\u0105czy\u0107 si\u0119 z kilkoma serwerami przez SMB, RDP lub WinRM.<\/p>\n Przydatne pivoty:<\/strong><\/p>\n\n- wszystkie wewn\u0119trzne cele, z kt\u00f3rymi podejrzany host komunikowa\u0142 si\u0119 po initial access;<\/li>\n
- nowe pary host-to-host w por\u00f3wnaniu z poprzednimi 30 dniami;<\/li>\n
- komunikacja z subnet\u00f3w u\u017cytkownik\u00f3w do subnet\u00f3w serwerowych;<\/li>\n
- ruch mi\u0119dzy security zones;<\/li>\n
- po\u0142\u0105czenia z portami administracyjnymi;<\/li>\n
- wewn\u0119trzne wzorce komunikacji one-to-many;<\/li>\n
- wewn\u0119trzne hosty, kt\u00f3re p\u00f3\u017aniej komunikowa\u0142y si\u0119 z t\u0105 sam\u0105 zewn\u0119trzn\u0105 infrastruktur\u0105 C2.<\/li>\n<\/ul>\n
Przyk\u0142adowe filtry:<\/strong><\/p>\nsrc_ip = suspected_host\r\ndst_ip in internal_ranges\r\ntime after first_suspicious_flow\r\ndst_port in 22, 135, 139, 445, 3389, 5985, 5986\r\nshow conversations not observed in previous 30 days<\/code><\/pre>\nPraktyczna analiza lateral movement powinna oddziela\u0107 oczekiwane zale\u017cno\u015bci od podejrzanych zmian. Cz\u0119\u015b\u0107 komunikacji wewn\u0119trznej jest elementem normalnych operacji biznesowych: uwierzytelniania domenowego, wdra\u017cania oprogramowania, backupu, monitoringu, dost\u0119pu do baz danych lub zale\u017cno\u015bci aplikacyjnych. Analiza flow staje si\u0119 skuteczniejsza, gdy zostanie wzbogacona o role asset\u00f3w, strefy sieciowe, baseline zachowania i znane relacje mi\u0119dzy us\u0142ugami.<\/p>\n Blast radius powinien zosta\u0107 udokumentowany jako sekwencja, a nie p\u0142aska lista. Raport powinien pokazywa\u0107, kt\u00f3ry system komunikowa\u0142 si\u0119 jako pierwszy, z jakimi systemami wewn\u0119trznymi nawi\u0105zano nast\u0119pnie po\u0142\u0105czenia, jakich port\u00f3w u\u017cyto oraz czy kt\u00f3rykolwiek z tych system\u00f3w wykaza\u0142 p\u00f3\u017aniej komunikacj\u0119 zewn\u0119trzn\u0105 lub dalszy lateral movement.<\/p>\n Przydatny rezultat mo\u017ce wygl\u0105da\u0107 nast\u0119puj\u0105co:<\/strong><\/p>\n\n \n\n\n| Sekwencja<\/th>\n | \u0179r\u00f3d\u0142o<\/th>\n | Cel<\/th>\n | Port\/protok\u00f3\u0142<\/th>\n | Obserwacja<\/th>\n<\/tr>\n<\/thead>\n | \n\n| 1<\/td>\n | Stacja robocza A<\/td>\n | Zewn\u0119trzny adres IP<\/td>\n | TCP\/443<\/td>\n | Powtarzaj\u0105ca si\u0119 komunikacja outbound<\/td>\n<\/tr>\n | \n| 2<\/td>\n | Stacja robocza A<\/td>\n | Serwer B<\/td>\n | TCP\/445<\/td>\n | Nowe po\u0142\u0105czenie SMB po aktywno\u015bci C2<\/td>\n<\/tr>\n | \n| 3<\/td>\n | Serwer B<\/td>\n | Serwer C<\/td>\n | TCP\/3389<\/td>\n | Po\u0142\u0105czenie RDP niewidoczne w baseline<\/td>\n<\/tr>\n | \n| 4<\/td>\n | Serwer C<\/td>\n | Zewn\u0119trzny adres IP<\/td>\n | TCP\/443<\/td>\n | Transfer outbound o wysokim wolumenie<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n Tego rodzaju timeline pomaga zespo\u0142om incident response ustala\u0107 priorytety dla containment, endpoint imaging, resetowania credentials i analizy log\u00f3w.<\/p>\n Krok 5 \u2014 Kwantyfikacja eksfiltracji<\/h3>\nDane flow s\u0105 szczeg\u00f3lnie przydatne do szacowania aktywno\u015bci zwi\u0105zanej z transferami outbound. Mog\u0105 pokaza\u0107, kt\u00f3re systemy wysy\u0142a\u0142y dane poza \u015brodowisko, kiedy transfer mia\u0142 miejsce, jak d\u0142ugo trwa\u0142, jaki cel odebra\u0142 ruch, jakiego protoko\u0142u u\u017cyto i ile danych przes\u0142ano.<\/p>\n Analiza powinna koncentrowa\u0107 si\u0119 na wolumenie outbound, rzadko\u015bci celu, czasie transferu i zwi\u0105zku z wcze\u015bniejszymi etapami incydentu. Du\u017cy transfer do znanego dostawcy backupu mo\u017ce by\u0107 oczekiwany. Du\u017cy transfer z serwera bazodanowego do nowo zaobserwowanego dostawcy VPS w nocy stanowi sygna\u0142 o wy\u017cszym ryzyku, szczeg\u00f3lnie je\u015bli zosta\u0142 poprzedzony lateral movement.<\/p>\n Przydatne pivoty:<\/strong><\/p>\n\n- bajty outbound z podejrzanych host\u00f3w;<\/li>\n
- najwa\u017cniejsze zewn\u0119trzne cele wed\u0142ug wolumenu uploadu;<\/li>\n
- cele zaobserwowane po raz pierwszy w oknie incydentu;<\/li>\n
- rzadko obserwowane ASN-y, kraje lub dostawcy cloud;<\/li>\n
- d\u0142ugotrwa\u0142e sesje;<\/li>\n
- nietypowe proporcje upload-to-download;<\/li>\n
- transfery poza godzinami pracy;<\/li>\n
- ruch z system\u00f3w wra\u017cliwych do sieci zewn\u0119trznych;<\/li>\n
- powtarzaj\u0105ce si\u0119 mniejsze transfery, kt\u00f3re \u0142\u0105cznie reprezentuj\u0105 znacz\u0105cy wolumen.<\/li>\n<\/ul>\n
Przyk\u0142adowe filtry:<\/strong><\/p>\nsrc_ip in suspected_hosts\r\ndst_ip not in internal_ranges\r\nsum bytes_out by dst_ip, dst_port, ASN, country\r\ntime between compromise_start and containment_time\r\nshow destinations first seen during incident window\r\nsort by bytes_out descending<\/code><\/pre>\nDane flow nale\u017cy wykorzystywa\u0107 ostro\u017cnie w raportowaniu eksfiltracji. Mog\u0105 wspiera\u0107 oszacowanie, ile danych opu\u015bci\u0142o \u015brodowisko, ale identyfikacja dok\u0142adnej zawarto\u015bci zwykle wymaga korelacji z logami dost\u0119pu do plik\u00f3w, logami baz danych, storage audit logs, DLP, endpoint telemetry, logami aplikacyjnymi lub packet capture. Najsilniejszy wniosek wynikaj\u0105cy z NetFlow dotyczy zwykle zakresu i timingu transferu: \u017ar\u00f3d\u0142a, celu, wolumenu, protoko\u0142u i czasu trwania.<\/p>\n Podsumowanie eksfiltracji mo\u017cliwe do obrony powinno zawiera\u0107:<\/strong><\/p>\n\n- zaanga\u017cowane systemy \u017ar\u00f3d\u0142owe;<\/li>\n
- docelowe adresy IP, ASN-y, kraje lub dostawc\u00f3w cloud;<\/li>\n
- czas rozpocz\u0119cia i zako\u0144czenia transferu;<\/li>\n
- ca\u0142kowit\u0105 liczb\u0119 bajt\u00f3w outbound;<\/li>\n
- protok\u00f3\u0142 i porty;<\/li>\n
- informacj\u0119, czy cel by\u0142 wcze\u015bniej obserwowany;<\/li>\n
- zwi\u0105zek z aktywno\u015bci\u0105 C2 lub lateral movement;<\/li>\n
- poziom pewno\u015bci i wymagane dowody uzupe\u0142niaj\u0105ce.<\/li>\n<\/ul>\n
Informacje te s\u0105 warto\u015bciowe dla oceny wp\u0142ywu incydentu, analizy prawnej, decyzji dotycz\u0105cych zg\u0142osze\u0144 i raportowania zarz\u0105dczego. Nawet je\u015bli potwierdzenie na poziomie zawarto\u015bci pochodzi z innego systemu, NetFlow cz\u0119sto zapewnia pierwsze wiarygodne oszacowanie skali transferu.<\/p>\n <\/span>Mapowanie dowod\u00f3w do MITRE ATT&CK<\/span><\/h2>\nDowody oparte na flow staj\u0105 si\u0119 bardziej u\u017cyteczne, gdy s\u0105 mapowane do wsp\u00f3lnego frameworka. MITRE ATT&CK pomaga prze\u0142o\u017cy\u0107 obserwacje sieciowe na uznane taktyki i techniki, dzi\u0119ki czemu raport ko\u0144cowy jest \u0142atwiejszy do zrozumienia dla zespo\u0142\u00f3w SOC, incident responder\u00f3w, audytor\u00f3w i os\u00f3b zarz\u0105dzaj\u0105cych bezpiecze\u0144stwem.<\/p>\n NetFlow wspiera mapowanie ATT&CK na poziomie behawioralnym. Nie potwierdza automatycznie konkretnej techniki, ale mo\u017ce dostarczy\u0107 dowod\u00f3w zgodnych z technikami posiadaj\u0105cymi widoczny komponent sieciowy.<\/p>\n \n \n\n\n| Ustalenie z dochodzenia<\/th>\n | Dowody flow<\/th>\n | Mo\u017cliwe mapowanie MITRE ATT&CK<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Powtarzaj\u0105ca si\u0119 komunikacja outbound przez HTTPS, DNS lub inne protoko\u0142y application-layer z rzadko obserwowan\u0105 infrastruktur\u0105<\/td>\n | Okresowe flow, sp\u00f3jne interwa\u0142y, podobna liczba bajt\u00f3w, ten sam cel<\/td>\n | T1071 \u2013 Application Layer Protocol<\/td>\n<\/tr>\n | \n| Dane przesy\u0142ane tym samym kana\u0142em, kt\u00f3ry s\u0142u\u017cy\u0142 do zewn\u0119trznej komunikacji atakuj\u0105cego<\/td>\n | Wolumen outbound do celu C2 po aktywno\u015bci zwi\u0105zanej z przej\u0119ciem systemu<\/td>\n | T1041 \u2013 Exfiltration Over C2 Channel<\/td>\n<\/tr>\n | \n| Przemieszczanie si\u0119 z jednego wewn\u0119trznego hosta do drugiego<\/td>\n | Nowe konwersacje east-west, porty administracyjne, sekwencja po\u0142\u0105cze\u0144 wewn\u0119trznych<\/td>\n | TA0008 \u2013 Lateral Movement<\/td>\n<\/tr>\n | \n| Wykorzystanie RDP, SSH, SMB lub WinRM mi\u0119dzy systemami wewn\u0119trznymi<\/td>\n | Flow do port\u00f3w remote services z nietypowych \u017ar\u00f3de\u0142 lub w nietypowych godzinach<\/td>\n | T1021 \u2013 Remote Services i powi\u0105zane sub-techniques<\/td>\n<\/tr>\n | \n| Wewn\u0119trzny scanning lub zachowanie podobne do discovery<\/td>\n | Po\u0142\u0105czenia one-to-many, wiele port\u00f3w, kr\u00f3tkie sesje w wewn\u0119trznych zakresach adresowych<\/td>\n | Techniki zwi\u0105zane z Discovery, zale\u017cnie od kontekstu<\/td>\n<\/tr>\n | \n| Zewn\u0119trzny transfer do nietypowej infrastruktury cloud, hostingowej lub zagranicznej<\/td>\n | Wysoka liczba bajt\u00f3w outbound, rzadko obserwowany ASN lub kraj, cel first-seen<\/td>\n | Techniki zwi\u0105zane z Exfiltration, zale\u017cnie od kana\u0142u<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n Sformu\u0142owania u\u017cywane w raportach powinny pozosta\u0107 precyzyjne. Dane flow mog\u0105 wspiera\u0107 ustalenie, wskazywa\u0107 zachowanie zgodne z okre\u015blon\u0105 technik\u0105 lub uzasadnia\u0107 dalsz\u0105 analiz\u0119. Silniejsze wnioski zwykle wymagaj\u0105 korelacji z logami endpointowymi, danymi identity, analiz\u0105 malware, packet capture lub dowodami aplikacyjnymi.<\/p>\n Dobrze napisany raport z dochodzenia mo\u017ce zawiera\u0107 nast\u0119puj\u0105ce stwierdzenie:<\/strong><\/p>\n\n\u201eRekordy flow pokazuj\u0105 okresow\u0105 komunikacj\u0119 outbound przez TLS z hosta 10.10.4.25 do rzadko obserwowanego celu zewn\u0119trznego co 10\u201312 minut mi\u0119dzy 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\u0142 nowe po\u0142\u0105czenia SMB z trzema wewn\u0119trznymi serwerami, kt\u00f3rych nie obserwowano w baseline z poprzednich 30 dni, co uzasadnia dalsz\u0105 analiz\u0119 pod k\u0105tem lateral movement\u201d.<\/p>\n<\/blockquote>\n Taki spos\u00f3b opisu \u0142\u0105czy dowody techniczne z uznanym frameworkiem, zachowuj\u0105c jednocze\u015bnie rozr\u00f3\u017cnienie mi\u0119dzy zaobserwowanym faktem a interpretacj\u0105 analityczn\u0105.<\/p>\n <\/span>Przekszta\u0142canie flow w dowody mo\u017cliwe do obrony \u2014 timeline, integralno\u015b\u0107 i retencja<\/span><\/h2>\nAby NetFlow m\u00f3g\u0142 wspiera\u0107 raport z incydentu, przegl\u0105d regulacyjny lub analiz\u0119 post-incident, musi by\u0107 traktowany jako dow\u00f3d, a nie wy\u0142\u0105cznie jako telemetria operacyjna. Analityk powinien by\u0107 w stanie wyja\u015bni\u0107, sk\u0105d pochodz\u0105 dane, w jaki spos\u00f3b zosta\u0142y zebrane, jaki przedzia\u0142 czasowy obejmuj\u0105, czy by\u0142y sampled, jakich filtr\u00f3w u\u017cyto i w jaki spos\u00f3b wyci\u0105gni\u0119to wnioski.<\/p>\n Dochodzenie oparte na flow, kt\u00f3rego wyniki mo\u017cna obroni\u0107, powinno dokumentowa\u0107:<\/strong><\/p>\n\n- \u017ar\u00f3d\u0142o flow: router, switch, firewall, probe, virtual appliance lub eksporter cloud;<\/li>\n
- format: NetFlow v5, NetFlow v9, IPFIX, sFlow lub inne \u017ar\u00f3d\u0142o telemetrii;<\/li>\n
- zakres zbierania danych: obj\u0119te segmenty, interfejsy, VLAN-y, sieci cloud lub punkty egress;<\/li>\n
- fidelity: dla NetFlow v9\/IPFIX \u2014 czy eksport jest sampled, czy 1:1 unsampled; dla sFlow \u2014 skonfigurowany sampling rate;<\/li>\n
- okres retencji: dost\u0119pne historyczne okno dochodzenia;<\/li>\n
- obs\u0142ug\u0119 czasu: stref\u0119 czasow\u0105, synchronizacj\u0119 zegar\u00f3w i sp\u00f3jno\u015b\u0107 timestamp\u00f3w;<\/li>\n
- zapytania: filtry, pivoty i logik\u0119 agregacji wykorzystywane przez analityka;<\/li>\n
- eksporty: zachowane surowe rekordy lub fragmenty raport\u00f3w;<\/li>\n
- korelacj\u0119: powi\u0105zania z alertami, logami, zdarzeniami EDR, DNS, proxy, firewallem lub PCAP;<\/li>\n
- notatki analityka: za\u0142o\u017cenia, poziomy pewno\u015bci i nierozwi\u0105zane luki.<\/li>\n<\/ul>\n
Timeline dochodzenia powinien by\u0107 ustrukturyzowany i mo\u017cliwy do odtworzenia. Silny timeline obejmuje pierwsz\u0105 zaobserwowan\u0105 podejrzan\u0105 komunikacj\u0119, pierwszy powtarzaj\u0105cy si\u0119 wzorzec zewn\u0119trzny, pierwszy wewn\u0119trzny pivot, pierwsze po\u0142\u0105czenie z systemami wra\u017cliwymi, pocz\u0105tek i koniec podejrzewanej eksfiltracji, dzia\u0142ania containment oraz ostatni zaobserwowany podejrzany flow.<\/p>\n Praktyczny timeline dowodowy mo\u017ce zawiera\u0107 nast\u0119puj\u0105ce pola:<\/strong><\/p>\n\n \n\n\n| Pole timeline\u2019u<\/th>\n | Dlaczego ma znaczenie<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Timestamp<\/td>\n | Ustala sekwencj\u0119 i umo\u017cliwia korelacj\u0119 z innymi systemami.<\/td>\n<\/tr>\n | \n| Source IP \/ asset<\/td>\n | Identyfikuje zaanga\u017cowany system.<\/td>\n<\/tr>\n | \n| Destination IP \/ asset<\/td>\n | Pokazuje cel komunikacji.<\/td>\n<\/tr>\n | \n| Port i protok\u00f3\u0142<\/td>\n | Pomagaj\u0105 okre\u015bli\u0107 us\u0142ug\u0119 lub kana\u0142.<\/td>\n<\/tr>\n | \n| Bajty i pakiety<\/td>\n | Wspieraj\u0105 analiz\u0119 wolumenu i transferu.<\/td>\n<\/tr>\n | \n| Kierunek<\/td>\n | Rozr\u00f3\u017cnia ruch inbound, outbound i wewn\u0119trzny.<\/td>\n<\/tr>\n | \n| Enrichment<\/td>\n | Dodaje kontekst ASN, kraju, roli assetu lub strefy.<\/td>\n<\/tr>\n | \n| Notatka analityka<\/td>\n | Wyja\u015bnia, dlaczego zdarzenie jest istotne.<\/td>\n<\/tr>\n | \n| Skorelowane \u017ar\u00f3d\u0142o<\/td>\n | \u0141\u0105czy zdarzenie flow z dowodami EDR, SIEM, DNS, proxy, firewalla lub PCAP.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n Nale\u017cy r\u00f3wnie\u017c uwzgl\u0119dni\u0107 integralno\u015b\u0107 danych. Je\u015bli dane flow s\u0105 eksportowane na potrzeby analizy prawnej, regulacyjnej, ubezpieczeniowej lub zarz\u0105dczej, nale\u017cy zachowa\u0107 surowe dowody. Dost\u0119p powinien by\u0107 kontrolowany, eksporty udokumentowane, a przekszta\u0142cenia wykonywane przez analityk\u00f3w oddzielone od oryginalnych rekord\u00f3w. Dashboardy i wizualizacje s\u0105 przydatne w analizie, ale rekordy \u017ar\u00f3d\u0142owe powinny pozosta\u0107 dost\u0119pne do weryfikacji.<\/p>\n Retencja jest ostatnim fundamentem. Platforma flow mo\u017ce wspiera\u0107 rekonstrukcj\u0119 wy\u0142\u0105cznie wtedy, gdy odpowiedni przedzia\u0142 czasowy jest nadal dost\u0119pny. Organizacje powinny definiowa\u0107 retencj\u0119 na podstawie realistycznych czas\u00f3w detekcji, ryzyka biznesowego i oczekiwa\u0144 regulacyjnych. Dla wielu \u015brodowisk od 30 do 90 dni przeszukiwalnych danych flow stanowi praktyczne minimum dla incident response. D\u0142u\u017csza retencja jest warto\u015bciowa dla \u015brodowisk o wysokim ryzyku, infrastruktury krytycznej, sektor\u00f3w regulowanych i organizacji, kt\u00f3re musz\u0105 wykonywa\u0107 lookback po op\u00f3\u017anionej detekcji lub op\u00f3\u017anionej publikacji threat intelligence.<\/p>\n <\/span>Jak wygl\u0105da to w praktyce z Sycope<\/span><\/h2>\nW praktyce rekonstrukcja ataku z wykorzystaniem NetFlow wymaga czego\u015b wi\u0119cej ni\u017c samo przechowywanie rekord\u00f3w. Analitycy potrzebuj\u0105 efektywnych mo\u017cliwo\u015bci wyszukiwania, filtrowania, enrichment, korelacji i wizualizacji, aby m\u00f3c przej\u015b\u0107 od alertu do timeline\u2019u bez r\u0119cznego \u0142\u0105czenia rozproszonych eksport\u00f3w z wielu narz\u0119dzi.<\/p>\n Sycope wspiera ten workflow, wykorzystuj\u0105c dane flow jako podstaw\u0119 network visibility i dochodze\u0144 dotycz\u0105cych incydent\u00f3w. Przechowywane dane NetFlow, IPFIX i sFlow mo\u017cna przeszukiwa\u0107 historycznie, filtrowa\u0107 wed\u0142ug hosta, portu, protoko\u0142u, konwersacji, kierunku, przedzia\u0142u czasowego lub innego kontekstu oraz wykorzystywa\u0107 do rekonstrukcji wzorc\u00f3w komunikacji przed pierwszym alertem i po nim.<\/p>\n Praktyczne dochodzenie w Sycope mo\u017ce przebiega\u0107 zgodnie z nast\u0119puj\u0105cym workflow:<\/strong><\/p>\n\n- Rozpocznij od security indicatora, anomalii, podejrzanego celu lub hosta.<\/li>\n
- Wykonaj pivot do powi\u0105zanych konwersacji sieciowych w odpowiednim przedziale czasowym.<\/li>\n
- Przeanalizuj historyczn\u0105 komunikacj\u0119 tego samego hosta, celu lub us\u0142ugi.<\/li>\n
- Zidentyfikuj aktywno\u015b\u0107 first-seen i powtarzaj\u0105ce si\u0119 wzorce komunikacji.<\/li>\n
- Rozszerz zakres na wewn\u0119trzny ruch host-to-host.<\/li>\n
- Por\u00f3wnaj zaobserwowane zachowanie z normalnymi baseline\u2019ami komunikacji.<\/li>\n
- Oblicz wolumen transferu outbound wed\u0142ug \u017ar\u00f3d\u0142a, celu, protoko\u0142u i czasu.<\/li>\n
- Zbuduj timeline, kt\u00f3ry mo\u017ce wspiera\u0107 dokumentacj\u0119 incydentu.<\/li>\n<\/ul>\n
Workflow ten jest warto\u015bciowy, gdy pierwszy sygna\u0142 jest niekompletny. Analityk SOC mo\u017ce rozpocz\u0105\u0107 wy\u0142\u0105cznie od zewn\u0119trznego adresu IP pochodz\u0105cego z threat intelligence. Zesp\u00f3\u0142 NetOps mo\u017ce zauwa\u017cy\u0107 nietypowy wolumen ruchu, nie wiedz\u0105c, czy jest on z\u0142o\u015bliwy. Analityk DFIR mo\u017ce potrzebowa\u0107 potwierdzenia, czy przej\u0119ty host komunikowa\u0142 si\u0119 z serwerami wewn\u0119trznymi przed containment. Analiza flow \u0142\u0105czy te punkty wyj\u015bcia z historycznymi dowodami komunikacji.<\/p>\n ![\"\"](\"https:\/\/www.sycope.com\/wp-content\/uploads\/2026\/07\/Untitled1-1024x686.png\") <\/p>\n
![\"\"](\"https:\/\/www.sycope.com\/wp-content\/uploads\/2026\/07\/Untitled-1024x689.png\") <\/p>\n
Security indicators mog\u0105 stanowi\u0107 punkt wej\u015bcia, ale g\u0142\u00f3wna warto\u015b\u0107 wynika z kolejnych pivot\u00f3w:<\/strong><\/p>\n\n- od jednego IOC do wszystkich wewn\u0119trznych host\u00f3w, kt\u00f3re si\u0119 z nim komunikowa\u0142y;<\/li>\n
- od jednego hosta do wszystkich zewn\u0119trznych cel\u00f3w, z kt\u00f3rymi komunikowa\u0142 si\u0119 w oknie incydentu;<\/li>\n
- od jednego podejrzanego flow do wcze\u015bniejszych wyst\u0105pie\u0144 tego samego wzorca;<\/li>\n
- od jednego przej\u0119tego systemu do wszystkich nowych po\u0142\u0105cze\u0144 wewn\u0119trznych;<\/li>\n
- od jednego transferu o wysokim wolumenie do szerszej oceny eksfiltracji;<\/li>\n
- od jednego alertu do timeline\u2019u dowodowego, kt\u00f3rego wyniki mo\u017cna obroni\u0107.<\/li>\n<\/ul>\n
Dla zespo\u0142\u00f3w SOC skraca to triage i pomaga ustali\u0107, czy alert reprezentuje izolowan\u0105 aktywno\u015b\u0107, czy element szerszego przej\u0119cia \u015brodowiska. Dla zespo\u0142\u00f3w DFIR wspiera rekonstrukcj\u0119 post-incident i zbieranie dowod\u00f3w. Dla zespo\u0142\u00f3w NetOps zapewnia kontekst, kt\u00f3ry pomaga odr\u00f3\u017cni\u0107 oczekiwane zachowanie sieci od b\u0142\u0119dnej konfiguracji, nadu\u017cycia lub przej\u0119cia systemu.<\/p>\n Rezultatem jest bardziej ustrukturyzowane dochodzenie. Zamiast traktowa\u0107 alert jako samodzielne zdarzenie, zesp\u00f3\u0142 mo\u017ce wykorzysta\u0107 dane flow do rekonstrukcji otaczaj\u0105cej go \u015bcie\u017cki komunikacji, zweryfikowania zakresu dotkni\u0119tych system\u00f3w i udokumentowania dowod\u00f3w stoj\u0105cych za ko\u0144cowym wnioskiem.<\/p>\n <\/span>FAQ<\/span><\/h2>\nCzy mo\u017cna prowadzi\u0107 network forensics wy\u0142\u0105cznie z wykorzystaniem NetFlow?<\/h3>\nNetFlow mo\u017ce wspiera\u0107 wiele zada\u0144 z zakresu network forensics, szczeg\u00f3lnie rekonstrukcj\u0119 timeline\u2019u, mapowanie komunikacji, analiz\u0119 lateral movement, detekcj\u0119 beaconingu i ocen\u0119 wolumenu eksfiltracji. Jest szczeg\u00f3lnie przydatny, gdy analitycy potrzebuj\u0105 szerokiej historycznej widoczno\u015bci w wielu segmentach sieci.<\/p>\n W przypadku pe\u0142nego incident response NetFlow powinien by\u0107 korelowany z innymi \u017ar\u00f3d\u0142ami dowod\u00f3w, takimi jak EDR, logi SIEM, DNS, proxy, firewall, logi identity, logi cloud, logi aplikacyjne i packet capture. Dane flow dostarczaj\u0105 struktury komunikacyjnej incydentu, natomiast inne \u017ar\u00f3d\u0142a zapewniaj\u0105 kontekst u\u017cytkownika, procesu, payloadu i aplikacji.<\/p>\n Czy NetFlow rejestruje packet payload lub zawarto\u015b\u0107 zaszyfrowanego ruchu?<\/h3>\nNetFlow rejestruje metadane dotycz\u0105ce komunikacji, a nie packet payload. Mo\u017ce pokaza\u0107 \u017ar\u00f3d\u0142o i cel, porty, protok\u00f3\u0142, timestampy, czas trwania, pakiety i bajty. Nie pokazuje zawarto\u015bci wymienianej mi\u0119dzy systemami.<\/p>\n W przypadku ruchu szyfrowanego NetFlow nadal mo\u017ce pokaza\u0107, \u017ce wyst\u0105pi\u0142a sesja TLS, jak cz\u0119sto si\u0119 powtarza\u0142a, jak d\u0142ugo trwa\u0142a i ile danych przes\u0142ano. Zaszyfrowana zawarto\u015b\u0107 aplikacyjna pozostaje poza rekordem flow i wymaga innych \u017ar\u00f3de\u0142 telemetrii lub mo\u017cliwo\u015bci inspekcji.<\/p>\n Jak d\u0142ugo nale\u017cy przechowywa\u0107 dane flow na potrzeby dochodze\u0144?<\/h3>\nPraktycznym baseline\u2019em dla wielu organizacji jest od 30 do 90 dni przeszukiwalnych danych flow. Takie okno retencji wspiera dochodzenia typu lookback, op\u00f3\u017anion\u0105 detekcj\u0119, retro-hunting na podstawie threat intelligence i rekonstrukcj\u0119 post-incident.<\/p>\n Organizacje o wy\u017cszym poziomie ryzyka, dzia\u0142alno\u015bci regulowanej, infrastrukturze krytycznej, danych wra\u017cliwych lub d\u0142u\u017cszych oczekiwanych czasach detekcji mog\u0105 potrzebowa\u0107 d\u0142u\u017cszej retencji. Internet egress, ruch data center, infrastruktura identity, sieci zarz\u0105dzaj\u0105ce i \u0142\u0105czno\u015b\u0107 cloud s\u0105 szczeg\u00f3lnie wa\u017cnymi obszarami wymagaj\u0105cymi rozszerzonej widoczno\u015bci.<\/p>\n NetFlow vs PCAP \u2014 co jest bardziej przydatne w incident response?<\/h3>\nNetFlow i PCAP odpowiadaj\u0105 na r\u00f3\u017cne pytania. NetFlow zapewnia szerok\u0105, skalowaln\u0105 widoczno\u015b\u0107 i d\u0142u\u017csz\u0105 retencj\u0119, dzi\u0119ki czemu jest przydatny do identyfikowania, kto komunikowa\u0142 si\u0119 z kim, kiedy komunikacja mia\u0142a miejsce i ile danych przes\u0142ano. PCAP zapewnia szczeg\u00f3\u0142owo\u015b\u0107 na poziomie pakiet\u00f3w i mo\u017ce wspiera\u0107 g\u0142\u0119bok\u0105 analiz\u0119 wybranych sesji tam, gdzie dost\u0119pne s\u0105 dane pakietowe, a payload jest technicznie dost\u0119pny.<\/p>\n Praktyczny model incident response wykorzystuje NetFlow do zidentyfikowania odpowiedniego hosta, celu, przedzia\u0142u czasowego i wzorca komunikacji, a nast\u0119pnie PCAP do g\u0142\u0119bszej inspekcji, gdy dane pakietowe s\u0105 dost\u0119pne.<\/p>\n Czy dane flow mog\u0105 wskaza\u0107, jakie dane zosta\u0142y skradzione?<\/h3>\nDane flow mog\u0105 zwykle pokaza\u0107, \u017ce dane opu\u015bci\u0142y \u015brodowisko, kt\u00f3ry system je wys\u0142a\u0142, dok\u0105d trafi\u0142y, kiedy transfer mia\u0142 miejsce, jakiego protoko\u0142u u\u017cyto i ile danych przes\u0142ano. Zwykle nie mog\u0105 zidentyfikowa\u0107 dok\u0142adnych nazw plik\u00f3w, rekord\u00f3w ani zawarto\u015bci payloadu.<\/p>\n Aby ustali\u0107, jakie dane zosta\u0142y skradzione, analitycy musz\u0105 skorelowa\u0107 dowody flow z logami dost\u0119pu do plik\u00f3w, logami baz danych, logami aplikacyjnymi, alertami DLP, endpoint telemetry, storage audit logs lub packet capture. NetFlow dostarcza timeline\u2019u i wolumenu transferu, natomiast inne \u017ar\u00f3d\u0142a zapewniaj\u0105 potwierdzenie na poziomie zawarto\u015bci.<\/p>\n","protected":false},"excerpt":{"rendered":" Ta rekonstrukcja jest jednym z najwa\u017cniejszych element\u00f3w incident response. Zesp\u00f3\u0142 musi ustali\u0107, kiedy rozpocz\u0119\u0142a si\u0119 podejrzana aktywno\u015b\u0107, kt\u00f3ry system zosta\u0142 zaanga\u017cowany jako pierwszy, w jaki spos\u00f3b atakuj\u0105cy komunikowa\u0142 si\u0119 ze \u015brodowiskiem, czy dosz\u0142o do lateral movement, do kt\u00f3rych system\u00f3w uzyskano dost\u0119p oraz czy dane opu\u015bci\u0142y organizacj\u0119. Ustalenia te musz\u0105 by\u0107 poparte dowodami, kt\u00f3re mo\u017cna przeanalizowa\u0107, […]<\/p>\n","protected":false},"author":2,"featured_media":1397,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[99],"tags":[114,205],"product":[165,166],"topic":[167],"sycope_author":[251],"class_list":["post-4264","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","tag-analizy-netflow","tag-bezpieczenstwo-sieci","product-security-pl","product-visibility-pl","topic-bezpieczenstwo-sieci","sycope_author-pawel-drzewiecki"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.sycope.com\/pl\/wp-json\/wp\/v2\/posts\/4264","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.sycope.com\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.sycope.com\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.sycope.com\/pl\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.sycope.com\/pl\/wp-json\/wp\/v2\/comments?post=4264"}],"version-history":[{"count":2,"href":"https:\/\/www.sycope.com\/pl\/wp-json\/wp\/v2\/posts\/4264\/revisions"}],"predecessor-version":[{"id":4272,"href":"https:\/\/www.sycope.com\/pl\/wp-json\/wp\/v2\/posts\/4264\/revisions\/4272"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.sycope.com\/pl\/wp-json\/wp\/v2\/media\/1397"}],"wp:attachment":[{"href":"https:\/\/www.sycope.com\/pl\/wp-json\/wp\/v2\/media?parent=4264"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.sycope.com\/pl\/wp-json\/wp\/v2\/categories?post=4264"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.sycope.com\/pl\/wp-json\/wp\/v2\/tags?post=4264"},{"taxonomy":"product","embeddable":true,"href":"https:\/\/www.sycope.com\/pl\/wp-json\/wp\/v2\/product?post=4264"},{"taxonomy":"topic","embeddable":true,"href":"https:\/\/www.sycope.com\/pl\/wp-json\/wp\/v2\/topic?post=4264"},{"taxonomy":"sycope_author","embeddable":true,"href":"https:\/\/www.sycope.com\/pl\/wp-json\/wp\/v2\/sycope_author?post=4264"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}} | |
|
|
|