Wykrywanie C2 w sieci: proste metody, które zrobisz bez drogiego SIEM

Cel czytelnika: prosty, powtarzalny sposób na wykrywanie C2 bez SIEM

Bezpieczeństwo sieci rzadko przegrywa na polu „braku technologii”. Znacznie częściej przegrywa na polu braku porządku, prostych procedur i konsekwencji. Wykrywanie C2 w sieci bez drogiego SIEM jest jak szukanie włamywacza z latarką zamiast z termowizją – da się to zrobić, jeśli wiesz, gdzie świecić i czego szukać.

Celem jest zbudowanie takiego minimum detekcji, które da się utrzymać w małej lub średniej organizacji: opartych na logach firewalli, DNS, proxy i kilku prostych skryptach. Bez budowy NASA w serwerowni i bez czarów.

Czym jest C2 w praktyce i dlaczego to czuć w sieci

Model ataku a rola Command & Control

C2 (Command & Control) to kanał komunikacji między zainfekowaną stacją (implantem, malware) a infrastrukturą atakującego. Dzięki C2 atakujący może:

• wydawać polecenia: pobieranie dodatkowych modułów, wykonywanie komend, przechwytywanie danych,
• aktualizować konfigurację i logikę malware,
• utrzymywać trwały dostęp – nawet po restarcie, zmianie IP czy aktualizacjach,
• koordynować wiele zainfekowanych hostów jednocześnie.

Bez stabilnego C2 atakujący często ma jednorazowe „okno okazji” – exploit zadziałał, ale po chwili dostęp przepada. Dlatego większość poważnych kampanii, od ransomware po APT, dąży do uzyskania cichego, możliwie trudnego do wykrycia kanału C2.

Od infekcji do stabilnego kanału – krótki łańcuch ataku

W dużym uproszczeniu łańcuch ataku, w którym pojawia się C2, wygląda tak:

1. Wejście – phishing, exploit w przeglądarce, podatny serwer, błędna konfiguracja VPN.
2. Dropper / loader – mały kawałek kodu, który pobiera „właściwe” malware lub implant.
3. Ustanowienie C2 – pierwszy kontakt z serwerem atakującego: rejestracja, pobranie konfiguracji, kluczy, identyfikatora hosta.
4. Rozpoznanie i ruch boczny – skanowanie sieci, zbieranie danych, nadużywanie kont.
5. Utrwalenie – mechanizmy persistence i redundantne kanały C2 na wypadek blokady jednego z nich.

Każdy z tych etapów może zostawić ślady w logach, ale C2 jest szczególnie wdzięcznym elementem do detekcji – pojawiają się powtarzalne wzorce ruchu, nietypowe destynacje, dziwne domeny, anomalne zachowanie protokołów. To właśnie ten moment, w którym Twoje logi zaczynają „mówić” – pod warunkiem, że ich słuchasz.

Typowe kanały C2: HTTP/S, DNS, e‑mail i tunelowanie

Atakujący wybierają kanały C2 tak, aby:

• mieściły się w normalnym ruchu sieciowym,
• przechodziły przez firewalle i proxy bez większych problemów,
• były tanie i łatwe do utrzymania po ich stronie.

Dlatego najczęściej pojawiające się kanały C2 to:

• HTTP/HTTPS – malware „udaje” przeglądarkę lub zwykłego klienta API, komunikuje się z zewnętrznym serwerem, często w chmurze lub na popularnym hostingu.
• DNS – dane komend i odpowiedzi są zakodowane w nazwach domen (subdomenach), a sam serwer C2 „siedzi” za serwerem DNS kontrolowanym przez atakującego.
• e‑mail / SMTP / IMAP – implant wysyła i odbiera zaszyfrowane komendy w treści e‑maili lub ich nagłówkach.
• Tunelowanie przez legalne usługi – np. Slack, Telegram, OneDrive, Google Sheets; ruch wygląda jak normalne użycie SaaS.

Bez SIEM‑a nie zawsze wychwycisz złożone tunelowanie w chmurze, ale solidnie zrobione logi DNS i HTTP pomagają wyłapać naprawdę sporą część aktywności C2, szczególnie tej mniej wysublimowanej.

Dlaczego niemal każdy incydent zostawia ślady w sieci

Największa przewaga obrony opartej na sieci jest prosta: trudno „nie gadać”. Atakujący może być świetny w uniku na poziomie endpointa, szyfrowaniu plików i zaciemnianiu kodu, ale prędzej czy później musi:

• połączyć się gdzieś na zewnątrz,
• rozwiązać domenę,
• wysłać jakieś pakiety w sposób powtarzalny.

Ruch C2 bywa minimalny, zaszyfrowany i porozrzucany w czasie, ale:
powtarza się, ma konkretny cel i nie wygląda jak normalna praca użytkownika. Te trzy cechy da się wyłapać nawet bardzo prostymi metodami: porównaniem „top najczęściej komunikujących się hostów”, analizą beaconingu czy prostą heurystyką na poziomie DNS.

Co można zrobić bez SIEM – realistyczne założenia i ograniczenia

Mała organizacja, mały budżet, duży bałagan w logach

Typowy obraz w małej lub średniej firmie:

• firewall loguje wszystko „gdzieś tam” – na lokalny dysk lub sysloga bez planu retencji,
• DNS (wewnętrzny lub w AD) loguje zapytania, ale nikt ich nie ogląda, dopóki coś się nie wyłoży,
• proxy działa, ale logi są przechowywane tyle, ile starczy miejsca,
• EDR/antywirus wysyła alerty w e‑mailach do wspólnej skrzynki, którą wszyscy ignorują,
• brak centralnej korelacji, brak spójnych źródeł czasu, brak szablonów zapytań.

To nie przekreśla szans na sensowne wykrywanie C2. Trzeba jednak zejść z chmur „idealnego SOC‑a” i ułożyć realistyczny plan: co logować, jak długo, w jakim formacie i jak z tego potem ręcznie lub półautomatycznie coś wyciągać.

Jakie dane są zwykle dostępne „za darmo”

Bez inwestowania w SIEM możesz wykorzystać to, co najprawdopodobniej już masz:

• Firewall / UTM / router brzegowy – logi połączeń wychodzących i przychodzących, czas sesji, ilość danych, informacja o regułach.
• Serwery DNS – zapytania, odpowiedzi, kody błędów, adresy IP klientów.
• Proxy / bramka web – logi HTTP(S), host, URI, metoda, kod odpowiedzi, user‑agent.
• EDR / antywirus – alerty o podejrzanych połączeniach, wykrytych modułach, exploitach przeglądarki.
• Logi systemowe (Windows/Linux) – szczególnie przydają się do korelacji: który proces nawiązał dane połączenie.

Kluczowe jest, aby te źródła centralnie zbierać (syslog, eksport CSV, API) i przechowywać przynajmniej kilka–kilkanaście dni w formie umożliwiającej szybkie filtrowanie. To już tworzy prosty fundament analizy ruchu sieciowego bez SIEM.

Brak SIEM a korelacja zdarzeń i czas reakcji

SIEM daje:

• wspólny silnik zapytań,
• automatyczne reguły korelacji,
• centralną oś czasu zdarzeń.

Bez niego musisz zaakceptować kilka ograniczeń:

• część korelacji będzie „manualna” – na zasadzie: kopiuj IP z DNS, szukaj w firewallu, potem w proxy,
• czas reakcji bywa dłuższy, szczególnie przy braku szablonów zapytań,
• nie wykryjesz wielu subtelnych anomalii, które wymagają historycznych porównań i zaawansowanych statystyk.

Z drugiej strony, nie potrzebujesz SIEM‑a, aby wyłapać najbardziej oczywiste i typowe kanały C2. Wystarczy konsekwentnie używane kilka prostych zasad: top‑listy, progi częstości, analizę beaconingu, prostą heurystykę na domeny i adresy IP.

Co jest realne ręcznie, a co już nie

Bez SIEM‑a wciąż jest realne, aby:

• raz dziennie lub raz na kilka dni wygenerować zestawienie top hostów komunikujących się na zewnątrz,
• przeglądać nietypowe destynacje (kraje, ASN, rzadko odwiedzane sieci),
• szukać powtarzalnych wzorców beaconingu dla kilku wybranych hostów,
• analizować logi DNS w poszukiwaniu domen o wysokiej entropii i masowych NXDOMAIN.

Znacznie trudniejsze (albo całkiem nierealne) staje się:

• analiza pełnego PCAP z wielu dni,
• korelacja tysięcy zdarzeń różnych typów w czasie rzeczywistym,
• zaawansowane modele anomalii oparte o uczenie maszynowe.

Dlatego tak ważne jest ustalenie priorytetów: zamiast próbować zrobić „mini‑SIEM”, lepiej wybrać 2–3 kluczowe źródła logów i opracować dla nich konkretne, powtarzalne check‑listy detekcji C2.

Priorytety: które logi i które typy C2 mają największy sens

Jeżeli masz ograniczone zasoby (czyli normalną firmę, nie laboratorium badawcze), najbardziej opłaca się skoncentrować na:

• logach DNS – bo obejmują prawie cały ruch do domen, w tym C2 typu DGA/DNS‑tunnel,
• ruchu HTTP/HTTPS – główny kanał komunikacji wielu implantów,
• ruchu wychodzącym z serwerów – szczególnie takich, które z natury nie powinny gadać z internetem.

Jeżeli musisz wybrać tylko jedną klasę problemów C2 do polowania „na start”, rozsądny wybór to:

• HTTP(S) beaconing do podejrzanych domen/hostów,
• DNS z długimi, losowymi subdomenami i wysoką liczbą błędów NXDOMAIN.

Kluczowe źródła danych do wykrywania C2 w typowej sieci

Firewall i routery jako pierwsza linia wglądu

Logi firewalla to podstawowe narzędzie do wykrywania C2 w sieci. Aby naprawdę coś z nich wyciągnąć, trzeba wiedzieć, które pola są kluczowe:

• SRC IP / SRC port – kto inicjuje połączenie i z jakiego portu lokalnego.
• DST IP / DST port – dokąd idzie ruch i na jaki port docelowy.
• Action – accept/allow/deny, szczególnie ważne, gdy masz polityki blokujące.
• Bytes sent/received (lub packets) – ile danych naprawdę przepłynęło.
• Session time / duration – jak długo utrzymywana była sesja.
• Protocol – TCP/UDP, czasem ICMP lub inne egzotyki.

Po stronie firewalla interesuje Cię obraz „kto się z kim i jak intensywnie komunikuje”. C2 rzadko generuje ogromne transfery (przynajmniej na początku), za to często widać:

• cykliczne krótkie sesje na stały zewnętrzny adres,
• dziwne kombinacje portów,
• stałą niewielką ilość przesyłanych danych przy wielu sesjach.

Normalny vs podejrzany ruch wychodzący w logach firewalla

Normalny ruch wychodzący z punktu widzenia firewalla to najczęściej:

• wiele różnych destynacji (wiele domen, serwerów CDN, chmury),
• zmienny rozmiar sesji – od krótkich zapytań HTTP po dłuższe sesje VPN lub streamingu,
• zmienny czas trwania – sesje kilka sekund, kilkanaście minut, czasem dłuższe w przypadku aplikacji SaaS.

Podejrzany ruch C2 często wygląda inaczej:

• ten sam host (SRC IP) kontaktuje się z tym samym DST IP lub bardzo wąskim zestawem IP / portów,
• sesje są raczej krótkie, ale bardzo regularne (co 1, 5, 10, 30 minut),
• ilość danych jest mała, ale podobna między sesjami (np. 1–5 KB w jedną stronę),
• pojawiają się połączenia wychodzące z serwerów, które normalnie mają tylko ruch przychodzący (np. serwer bazodanowy „dzwoni” na jakiś zewnętrzny IP).

Czasem pojedynczy wpis logu nic nie mówi. Potrzebne jest agregowanie po SRC IP i DST IP, liczenie liczby sesji, średniego czasu trwania i sumy przesłanych danych. To wszystko można zrobić prostym skryptem lub nawet w Excelu, jeśli logów jest niewiele.

DNS – radar dla ukrytej komunikacji C2

DNS jest wyjątkowo wdzięcznym źródłem do wykrywania C2. Większość malware, zanim połączy się z serwerem C2, musi rozwiązać nazwę domenową. Tymczasem logi DNS:

Jakie pola w logach DNS oglądać na chłodno

Surowy log DNS na pierwszy rzut oka wygląda jak ściana tekstu. Po kilku sesjach polowania na C2 zaczynasz jednak widzieć pewne „magiczne” pola, na których można oprzeć proste detekcje:

• Timestamp – kiedy padło zapytanie; przyda się do analizy wzorców czasowych.
• Client IP / nazwa hosta – kto pyta; najlepiej od razu rozwiązywać IP na nazwy maszyn.
• Query name (QNAME) – pełna domena, razem z subdomeną.
• Query type (QTYPE) – A, AAAA, TXT, MX, SRV, czasem egzotyki (np. NULL, które budzą czujność).
• Response code (RCODE) – NOERROR, NXDOMAIN, SERVFAIL itd.
• Odpowiedź – docelowy adres IP, rekord TXT itd.

Skupiając się tylko na QNAME, QTYPE, RCODE i kliencie, można już zbudować całkiem użyteczne filtry. Dodanie czasu otwiera drogę do wykrywania beaconingu po samych zapytaniach DNS, bez oglądania ruchu TCP/HTTP.

DNS z perspektywy „normalnej” aktywności

Żeby wyłapać nietypowe wzorce, trzeba mieć wyczucie, co w DNS jest zwykłą nudą. Typowe cechy zdrowego ruchu DNS:

• dużo powtarzających się, znanych domen: popularne serwisy, dostawcy SaaS, aktualizacje systemów, CDN‑y,
• dominuje typ A/AAAA, okazjonalnie MX, TXT, SRV (szczególnie w środowiskach AD/Exchange),
• stosunkowo mało błędów NXDOMAIN w relacji do wszystkich zapytań,
• subdomeny są zwykle krótkie czy czytalne: api, cdn, login, nazwy regionów itd.

Ruch „biznesowy” często ma też swoje pory: rano eksplozja zapytań, potem spadek, w nocy relatywny spokój z wyjątkiem serwerów i backupów. Zdarza się oczywiście, że jeden użytkownik potrafi wygenerować pół logu DNS, bo ma 200 zakładek w przeglądarce – ale i to zwykle da się odróżnić od uporządkowanego C2.

DNS w wersji C2 – na co patrzeć

Implanty i frameworki C2 lubią DNS z kilku powodów: przechodzi przez większość sieci, rzadko jest filtrowany na poziomie treści, bywa ignorowany przy monitoringu. Najczęstsze obserwowalne wzorce:

• Windows artefaktów z generatorów domen (DGA) – masa zapytań o pseudo‑losowe nazwy, często kończące się NXDOMAIN,
• tunelowanie danych w subdomenach – długie, „zaszumione” ciągi znaków przed domeną nadrzędną,
• częste zapytania o jedną domenę (lub małą pulę domen) z nienaturalną regularnością czasową,
• nietypowe typy rekordów – np. gwałtowny wzrost zapytań TXT z jednego hosta klienckiego,
• „te same” długie subdomeny od niewielu hostów – kilka zainfekowanych maszyn gada do tego samego C2.

Nawet jeśli nie masz zaawansowanych algorytmów, już prosta statystyka: „kto generuje najwięcej NXDOMAIN”, „kto ma najdłuższe subdomeny” i „kto pyta najczęściej o jedną domenę” potrafi wyciągnąć na wierzch ciekawe przypadki.

Proxy i logi HTTP(S) – co da się zobaczyć mimo szyfrowania

C2 bardzo chętnie udaje zwykły ruch webowy. Nawet jeśli treść jest zaszyfrowana (HTTPS), z logów proxy lub bramki web da się wycisnąć sporo informacji:

• host – nazwa domenowa, często kluczowa do identyfikacji C2,
• URI – ścieżka żądania; niektóre C2 używają specyficznych wzorców (np. bardzo długie parametry, ciągi Base64),
• metoda – GET, POST, PUT; C2 często używa prostych, powtarzalnych schematów,
• user‑agent – czasem losowy, czasem bardzo stary (IE6 w 2025 r. nie wygląda zdrowo),
• rozmiar odpowiedzi – niewielkie, stałe odpowiedzi (np. 200–500 bajtów) powtarzające się cyklicznie,
• kody odpowiedzi – seria 404/500 w bardzo regularnych odstępach może sugerować fallback C2.

Do wychwycenia C2 nie trzeba czytać każdego URLa. Wystarczą proste agregaty:

• top domen per host,
• top hostów pytających o daną domenę,
• najbardziej „monotonne” sesje: ten sam URI, ten sam rozmiar odpowiedzi, wiele razy na godzinę.

Jedna z częstszych scenek z praktyki: pojedynczy host kliencki wysyła co 5 minut żądanie POST do tej samej domeny, z identycznym rozmiarem body i odpowiedzi, user‑agentem „Mozilla/5.0” bez reszty ciągu. Użytkownik nie pamięta żadnej aplikacji, która wymaga „aktualizacji co 5 minut”. Tu nawet Sherlock nie jest potrzebny.

EDR i logi systemowe – kto naprawdę inicjuje połączenia C2

Firewall i DNS pokażą, że dany host gada w dziwny sposób. EDR lub logi systemowe odpowiadają na ważniejsze pytanie: który proces to robi. Przy braku SIEM‑a przydają się dwa proste scenariusze:

• na maszynie podejrzanej o beaconing sprawdzasz logi EDR (lub ręcznie narzędziem typu netstat, tcpview, Get-NetTCPConnection),
• szukasz procesów, które utrzymują połączenia do konkretnych IP/domen, szczególnie w momencie kolejnego „tiknięcia” beaconu.

Jeśli podejrzany ruch wychodzący generuje svchost.exe lub rundll32.exe z nietypową linią komend – to już bardzo mocny sygnał. Przydatne są też logi systemowe dotyczące:

• tworzenia nowych zadań zadań Harmonogramu (Scheduled Tasks),
• zmian w autostarcie (Run/RunOnce, usługi),
• tworzenia nowych usług systemowych z nietypowymi ścieżkami.

Tu wchodzi w grę korelacja ręczna: masz podejrzaną domenę z DNS/proxy, sprawdzasz po IP w logach EDR, potem wchodzisz na hosta i patrzysz, który proces jest „przyspawany” do tego endpointa.

Wzorce zachowań C2, które da się wychwycić prostymi metodami

Beaconing – serce większości kanałów C2

Beaconing to regularne „odzywanie się” implantu do serwera dowodzenia. Typowy wzorzec:

• krótkie połączenie wychodzące co określony czas,
• mała ilość danych (zapytanie + skromna odpowiedź),
• często do jednej domeny lub jednego IP,
• czasem z jitterem – małym, losowym opóźnieniem, żeby ruch wyglądał bardziej naturalnie.

Jak to wyłapać bez SIEM‑a? Prosta procedura:

1. W logach firewalla lub proxy wybierz jednego hosta, który wzbudza choć cień podejrzenia (np. z topki połączeń do „egzotycznych” krajów).
2. Wyciągnij listę jego połączeń do jednego zewnętrznego IP/domeny w danym dniu.
3. Policz odstępy czasowe między kolejnymi połączeniami.
4. Jeśli odstępy są prawie równe (np. 300 ± 20 sekund), masz mocny kandydat na beaconing.

Tę analizę można zrobić nawet w Excelu: kolumna z timestampami, formuła licząca różnicę między wierszami, prosty wykres. Nie jest to piękny dashboard SOC‑a, ale działa.

Nietypowe destynacje i geolokalizacja

Drugim prostym kryterium jest „gdzie w ogóle lecą te pakiety”. Kilka praktycznych punktów startowych:

• lista krajów, do których firma naprawdę ma biznesowe powody się łączyć,
• top ASN (dostawców) według ilości ruchu wychodzącego,
• osobno – ruch z serwerów krytycznych na zewnątrz.

Jeśli serwer bazodanowy w polskim banku zaczyna nagle wysyłać ruch HTTP do hostingu w Ameryce Południowej, to nie wymaga skomplikowanego machine learningu, żeby zapaliła się lampka kontrolna. Tego typu rzeczy wychodzą w prostych tabelach: SRC IP, DST kraj, liczba sesji.

Mały, ale uporczywy strumień danych

Wiele C2 stara się nie rzucać w oczy. Zamiast jednego dużego zrzutu danych – wiele małych, dyskretnych porcji. W logach widać to jako:

• wiele sesji do tego samego hosta,
• bardzo podobna wartość bytes sent/received,
• brak większych „pików” transferu, ale ciągła, uporczywa aktywność.

Można to złapać, grupując po SRC IP + DST IP/port i licząc:

• liczbę sesji w godzinie/dniu,
• średnią ilość danych na sesję,
• odchylenie standardowe rozmiaru sesji (niskie = wszystkie sesje podobne).

Nawet prosty arkusz kalkulacyjny albo skrypt w Pythonie z biblioteką pandas załatwi temat dla rozsądnej wielkości logów (np. 100–200 tys. rekordów na dzień).

Dziwne pory aktywności

C2, które wykonuje zadania (np. zrzuty plików, rekonesans, lateral movement), często jest aktywne poza godzinami pracy, gdy operatorom jest łatwiej działać bez reakcji użytkowników. Prosty pomysł:

• podziel dobę na przedziały (np. 00–06, 06–12, 12–18, 18–24),
• policz liczbę sesji wychodzących per host w każdym przedziale,
• znajdź hosty, które mają relatywnie większą aktywność w „martwych” godzinach niż w normalnych (odwrócony profil).

Nagłe ożywienie ruchu HTTP/HTTPS z dwóch laptopów biurowych od 2:00 do 4:00, do tej samej niszowej domeny, wygląda podejrzanie nawet bez szczegółowej wiedzy o treści ruchu.

Jak ogarnąć logi bez SIEM – proste workflowy i narzędzia

Minimalna „platforma logowa” na bieda‑budżecie

Żeby w ogóle zacząć, trzeba mieć jedno miejsce, gdzie lądują logi. Prosty, realistyczny zestaw:

• serwer z Linuxem (fizyczny lub VM),
• rsyslog/syslog‑ng do zbierania logów z firewalla, routerów, DNS,
• zrzuty logów DNS/proxy w formacie CSV lub JSON (np. raz dziennie na SFTP),
• narzędzia tekstowe: grep, awk, sed, sort, uniq,
• opcjonalnie SQLite lub prosty Elasticsearch + Kibana na małą skalę.

Nie trzeba od razu budować klastra. Już sama konsolidacja logów na jednym serwerze eliminuje 80% bólu: koniec z logami w 15 miejscach, z których każde trzyma 2 dni historii.

Stałe „widoki” i zapytania, zamiast ręcznego przeklikiwania

Dużo czasu zjada powtarzanie tych samych kroków. Warto przygotować kilka powtarzalnych widoków:

• top „gadające” hosty (liczba połączeń wychodzących per SRC IP),
• top destynacje (DST IP, domeny z DNS/proxy),
• hosty z największą liczbą NXDOMAIN,
• hosty z największą liczbą zapytań TXT.

Jeśli używasz prostych narzędzi tekstowych, takie widoki to często jedno polecenie w stylu:

grep "QUERY" dns.log | awk '{print $8}' | sort | uniq -c | sort -nr | head

Potem można to zapisać w skrypcie .sh i odpalać codziennie automatycznie, zapisując output do pliku „raport_dzienny.txt”. Zero elegancji, dużo praktyczności.

Porządkowanie czasu i stref – bez tego korelacja s