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 się sypie

Przy braku SIEM‑a częstym problemem jest „czas z innej planety” w każdym logu. Kilka prostych zasad:

• ustaw NTP na wszystkich urządzeniach (firewall, DNS, serwery, stacje),
• upewnij się, że logi trafiają na serwer w tej samej strefie czasowej lub są oznaczone UTC,
• jeśli eksportujesz do CSV, zawsze trzymaj kolumnę z timestampem w jednym formacie (np. ISO 8601).

Automatyzacja małymi krokami – od jednorazowych komend do stałych zadań

Ręczne „klepanie” komend ma sens na początku, ale szybko staje się męczące. Lepiej zamienić powtarzalne czynności w małe, przewidywalne zadania. Prosty schemat:

1. Spisujesz, co faktycznie robisz ręcznie (np. „codziennie rano sprawdzam top zapytań DNS i hosty z największą liczbą NXDOMAIN”).
2. Dla każdego kroku budujesz jedno polecenie lub krótki skrypt.
3. Pakujesz to w cron albo systemd timer i zapisujesz wyniki do katalogu typu /var/log/raporty_c2/.

Przykład prostego zadania cron, które codziennie o 06:00 generuje raport z top domen DNS:

0 6 * * * root /usr/local/bin/raport_dns.sh > 
  /var/log/raporty_c2/raport_dns_$(date +%Y%m%d).txt

Sam skrypt raport_dns.sh może być banalny:

#!/bin/bash
echo "Top 50 domen z pliku dns.log"
grep "QUERY" /var/log/dns.log | 
  awk '{print $8}' | sort | uniq -c | sort -nr | head -50

Nagle poranny przegląd nie oznacza przeklikiwania konsoli firewalla, tylko szybkie less raport_dns_20260215.txt i przejście po kilku gotowych listach.

Łączenie wielu źródeł bez magicznej „korelacji” SIEM

Bez SIEM‑a korelacja oznacza w zasadzie pracę na dwóch oknach terminala i jednym arkuszu kalkulacyjnym. I to wciąż działa. Kluczowe są stabilne identyfikatory:

• adres IP hosta (SRC/DST),
• domena (z DNS/proxy),
• timestamp w jednej strefie czasowej,
• opcjonalnie nazwa hosta.

Prosty workflow korelacji „DNS → proxy → EDR”:

1. W DNS znajdujesz podejrzaną domenę, np. z topki lub po wzorcu (dużo losowych znaków).
2. Wyciągasz listę hostów, które o nią pytały: awk '{print $5}' | sort | uniq -c.
3. W logach proxy filtrujesz po tej domenie i sprawdzasz URLe, metody, rozmiary odpowiedzi.
4. Na hostach z największą aktywnością patrzysz w EDR/netstat, jaki proces utrzymuje połączenia do IP z tej domeny.

Cała magia polega na tym, żeby mieć te dane pod ręką, a nie rozsiane po dziesięciu panelach administracyjnych różnych producentów. Nawet prosty zrzut do CSV z proxy robi różnicę.

Mini‑„playbooki” na papierze zamiast rozbudowanego SOAR

Zamiast wdrażać platformę SOAR za pół budżetu IT, da się oprzeć na kilku prostych scenariuszach spisanych w wiki lub nawet w notatniku. Przy podejrzeniu C2 reagujesz według prostego schematu, bez wymyślania kroków za każdym razem. Przykładowy playbook „podejrzana domena C2”:

1. Identyfikacja: domena pojawia się w:
   • top listach DNS z nietypowym wzorcem (np. wiele poddomen z losowym ciągiem),
   • albo w logach proxy jako monotonne połączenia co kilka minut.
2. Scope: wyciągasz listę hostów pytających o domenę + liczbę zapytań w ciągu doby.
3. Weryfikacja: na 1–2 hostach z największą liczbą zapytań:
   • sprawdzasz procesy utrzymujące połączenia do tej domeny/IP,
   • patrzysz w Harmonogram zadań, autostart, ostatnio uruchamiane aplikacje.
4. Reakcja techniczna: tymczasowo blokujesz domenę na DNS/proxy, obserwujesz:
   • czy host zaczyna generować masowe NXDOMAIN,
   • czy pojawiają się próby połączeń do alternatywnych domen/IP (fallback C2).
5. Dokumentacja: zapisujesz wyniki (hosty, procesy, URI, IP) w jednym pliku/karcie incydentu.

Brzmi prymitywnie w porównaniu do automatycznych playbooków SOAR, ale w realu średnich firm daje często podobny efekt: powtarzalność i mniej chaosu przy analizie.

Jednolity format logów – mała normalizacja, duża ulga

Problem bez SIEM‑a to różne formaty logów: każdy vendor „wie lepiej”, jak zapisać timestamp albo nazwę pola. Minimalna normalizacja robi ogromną różnicę. Można przyjąć prosty model „docelowego” CSV:

• timestamp (ISO 8601, UTC),
• src_ip, dst_ip, src_port, dst_port,
• proto,
• domain (dla DNS/HTTP),
• url (dla proxy),
• bytes_sent, bytes_received.

Potem prostymi filtrami awk/Python można z surowych logów generować „uładzone” CSV do dalszej analizy. Przykładowy szkic dla logu firewalla w formacie zbliżonym do:

2026-02-15T10:15:30Z ALLOW TCP 10.0.1.5 443 192.0.2.10 51515 1200 800

Można przekształcić to w:

timestamp,src_ip,src_port,dst_ip,dst_port,proto,bytes_sent,bytes_received
2026-02-15T10:15:30Z,10.0.1.5,51515,192.0.2.10,443,TCP,1200,800

Nawet tak skromna normalizacja pozwala potem jednym skryptem analizować logi z kilku firewalli bez każdorazowego dopasowywania formatu.

Analiza ruchu DNS krok po kroku – polowanie na sprytne C2

Co wyciągnąć z samego DNS, zanim odpalisz cokolwiek cięższego

DNS to złoto w wykrywaniu C2, bo duża część implantów musi w jakiś sposób „znaleźć” serwer dowodzenia, często właśnie przez domeny. Pierwszy etap to wyciągnięcie prostych statystyk:

• liczba zapytań per host (SRC IP),
• liczba zapytań per domena/poddomena,
• liczba NXDOMAIN (nieistniejących domen) per host,
• typy rekordów (A, AAAA, TXT, MX, itp.) per host/domena.

Wystarczy, że log DNS ma pola typu: timestamp, klient, typ zapytania, nazwa domeny, kod odpowiedzi. Prosty przykład komendy, która wyciągnie top hosty po liczbie zapytań w pliku dns.log:

awk '{print $5}' dns.log | sort | uniq -c | sort -nr | head -20

(tu przyjmujemy, że 5. kolumna to adres IP klienta – trzeba to dopasować do swojego formatu).

Szum vs. sygnał – czemu „dużo DNS” nie zawsze oznacza problem

Nowoczesne systemy i aplikacje potrafią generować spore ilości zapytań DNS w pełni legalnie: telemetria, aktualizacje, chmura. Zanim uznasz host za „podejrzanie gadatliwy”, dobrze jest:

• porównać go do innych urządzeń tej samej klasy (laptop vs. laptop, serwer vs. serwer),
• sprawdzić, ile zapytań idzie do znanych domen typu Microsoft, Google, dostawcy AV itp.,
• odsiać ruch do domen lokalnych/korporacyjnych.

Przykładowy trik: przygotowujesz prostą listę „zaufanych” sufiksów (np. microsoft.com, office365.com, domena firmowa) i filtrujesz je z top listy. Cokolwiek zostaje w topce po takim odfiltrowaniu, jest ciekawsze do analizy.

Polowanie na DGA – domeny, które wyglądają jak losowe śmieci

Spora część malware używa DGA (Domain Generation Algorithm), generując masę dziwnych nazw domen. Nie trzeba modelu ML, żeby znaleźć część z nich. Kilka prostych heurystyk:

• długość etykiet (poddomen) – np. ponad 20–25 znaków bez sensownego słowa,
• duży udział cyfr i rzadkich liter,
• brak „słownikowych” fragmentów (update, cloud, cdn itp.).

Można to zrealizować małym skryptem w Pythonie, który:

1. parsuje log DNS i zbiera unikalne nazwy domen/poddomen,
2. dla każdej etykiety (np. abcxyz123 w abcxyz123.example.com) liczy:
   • długość,
   • udział cyfr,
   • udział znaków spoza alfabetu łacińskiego (jeśli używany jest IDN).
3. wyrzuca listę etykiet i domen spełniających proste kryteria (np. długość > 20, cyfry > 30%).

Przykładowy szkic w Pythonie (bez pełnej obsługi wyjątków, ale działa jako punkt startu):

import re

def suspicious_label(label):
    if len(label) < 15:
        return False
    digits = sum(c.isdigit() for c in label)
    ratio = digits / len(label)
    return ratio > 0.3

seen = set()
with open("dns.log") as f:
    for line in f:
        parts = line.split()
        domain = parts[7]  # dopasuj indeks do swojego formatu
        if domain in seen:
            continue
        seen.add(domain)
        labels = domain.split(".")
        for lbl in labels:
            if suspicious_label(lbl):
                print(domain)
                break

Po odpaleniu takiego skryptu na dzień lub dwa logów często nagle pojawia się garść domen, które wyglądają jak klawiatura kota. To dobry punkt wyjścia do dalszej weryfikacji.

Częstotliwość zapytań – „tikanie” w DNS

Implant, który korzysta z DNS do komunikacji, może stosować beaconing właśnie na poziomie zapytań nazw domen. Zamiast gapić się w pojedyncze rekordy, można spojrzeć na rozkład w czasie:

1. Filtrujesz log po jednym hostcie i jednej domenie:

grep "10.0.1.5" dns.log | grep "example-c2.com" > host_dns_c2.log

2. Wyciągasz czasy zapytań i liczysz odstępy między nimi (timestamp_i – timestamp_i-1).
3. Patrzysz, czy odstępy są w miarę stałe (np. 300–320 s przez cały dzień).

Tak jak przy HTTP, można to zrobić w Excelu albo małym skryptem. Jeżeli implant jest sprytny i dorzuca jitter, odstępy nie będą identyczne, ale i tak widać „bicie serca” – powtarzalność rzędu minut/kilkudziesięciu minut, bez powiązania z normalnym użyciem komputera.

Nietypowe typy rekordów – TXT, NULL i reszta „egzotyki”

Standardowy ruch DNS to głównie rekordy A/AAAA, NS, MX. Gdy pojawia się dużo zapytań o TXT albo inne nietypowe typy, warto się temu przyjrzeć. C2 często używa TXT jako kanału danych (np. polecenia albo wyciekane informacje w treści rekordu). Prosty zestaw pytań:

• które hosty wykonują najwięcej zapytań TXT?
• do jakich domen idą te zapytania?
• jakie są odpowiedzi – czy przypominają base64/zaszyfrowane ciągi?

Identyfikacja hostów z największą liczbą zapytań TXT wygląda np. tak:

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

Jeśli na szczycie listy stoi jeden, dwa laptopy z biura, które „nagminnie” pytają o TXT do pojedynczej domeny zewnętrznej, to już jest materiał do głębszej analizy.

NXDOMAIN i szybkie „skanowanie” domen przez malware

Malware korzystające z DGA zwykle generuje wiele nazw, które nie istnieją. Widać to jako wysoki poziom NXDOMAIN z jednego hosta. Oczywiście aplikacje typu przeglądarka też czasem produkują NXDOMAIN (literówki, śmieci w pasku adresu), ale:

• u normalnego użytkownika NXDOMAIN są „rozmyte” po różnych domenach,
• przy DGA widać serię podobnych, losowawych nazw w krótkim czasie.

Workflow jest prosty:

1. Wyciągasz z logu DNS tylko odpowiedzi NXDOMAIN.
2. Licisz, ile takich odpowiedzi przypada na każdy SRC IP.
3. Sortujesz po liczbie NXDOMAIN i sprawdzasz top hosty.

Najczęściej zadawane pytania (FAQ)

Jak wykryć C2 w sieci bez SIEM w małej firmie?

Najprostsza metoda to regularne przeglądanie kilku kluczowych logów: DNS, firewall/UTM i proxy. Z tych trzech źródeł da się wyciągnąć większość śladów prostych kanałów C2 – nawet jeśli nie masz centralnej platformy do korelacji.

W praktyce sprowadza się to do powtarzalnych kroków: generowania top-list hostów łączących się na zewnątrz, szukania nietypowych destynacji (egzotyczne kraje, rzadko używane ASN), analizowania powtarzalnych połączeń co X minut (beaconing) oraz przeglądania logów DNS pod kątem dziwnych domen i masowych błędów NXDOMAIN.

Jakie logi są najważniejsze do wykrywania C2 bez drogiego SIEM?

Jeśli masz ograniczone zasoby, priorytet to:

• DNS – bo widzi prawie wszystkie wywołania domen, w tym DGA i tunelowanie DNS,
• firewall/UTM – ruch wychodzący, porty, ilość danych, kierunki,
• proxy / bramka web – szczegóły HTTP(S): host, URI, user-agent, kody odpowiedzi.

Drugą linią są logi z EDR/antywirusa oraz systemowe (Windows/Linux), używane głównie do korelacji: który host i który proces generuje podejrzany ruch. Bez porządnych logów DNS i HTTP walka z C2 zamienia się jednak w zgadywankę.

Po czym poznać, że ruch HTTP/HTTPS może być kanałem C2?

Ruch C2 po HTTP/HTTPS często „udaje” normalną przeglądarkę, ale ma kilka charakterystycznych cech: powtarzalne połączenia w równych odstępach czasu (np. co 5 minut), połączenia do jednego lub kilku mało popularnych hostów, mały i podobny rozmiar żądań/odpowiedzi oraz nietypowe lub identyczne user-agenty z wielu stacji.

W logach warto więc filtrować: pojedyncze hosty, które łączą się bardzo często do tej samej domeny/IP, ruch HTTPS do egzotycznych sieci oraz nietypowe URI (bardzo długie, z losowo wyglądającymi parametrami). Jeśli jeden komputer gada godzinami do jakiegoś mało znanego serwera w równych odstępach – to przynajmniej wymaga wyjaśnienia.

Jak wykryć C2 po DNS bez zaawansowanych narzędzi?

Na początek wystarczy eksport logów DNS do pliku i kilka prostych zapytań lub skryptów. Szukaj przede wszystkim: domen i subdomen o bardzo „losowym” wyglądzie (wysoka entropia), dużej liczby błędów NXDOMAIN dla danego hosta oraz nietypowych domen, które pojawiają się tylko na jednym komputerze w całej sieci.

Praktyczny trik: raz dziennie wygeneruj listę „top domen per host” i „top NXDOMAIN per host”. Jeżeli widzisz stację, która pyta o setki dziwnych subdomen jak asd9f8a7sd.example.com, podczas gdy inni użytkownicy tego nie mają – to kandydat do ręcznego sprawdzenia, bo tak właśnie wygląda wiele DGA i tuneli DNS.

Czy da się wykryć beaconing C2 bez analityki behawioralnej i ML?

Tak, pod warunkiem że skupisz się na kilku hostach lub wybranych destynacjach, a nie na całej sieci naraz. Wystarczy wyciągnąć z firewall/proxy logi połączeń danego hosta do Internetu i pogrupować je po adresie docelowym oraz czasie – nawet w zwykłym arkuszu kalkulacyjnym.

Szukasz powtarzalnych wzorców: połączeń co 1, 5, 10 minut, często z bardzo małą ilością przesyłanych danych. Jeśli widzisz linię zdarzeń wyglądającą jak metronom, a użytkownik raczej nie klika w coś co 5 minut jak robot – to mocny sygnał, że aplikacja lub implant „meldje się” do C2.

Na ile skuteczne jest wykrywanie C2 bez SIEM, a gdzie kończą się możliwości?

Przy dobrze zorganizowanych logach DNS/HTTP można wychwycić sporą część „normalnych” kampanii: proste implanty, wiele rodzin ransomware, masowe malware korzystające z taniej infrastruktury. Szczególnie dobrze widać głośne, powtarzalne kampanie oraz błędnie skonfigurowane C2.

Znacznie trudniej będzie z bardzo cichymi, ręcznie prowadzonymi operacjami APT, kreatywnym tunelowaniem przez popularne SaaS czy ruchem idealnie wtopionym w zachowanie użytkownika. Bez SIEM (i ludzi od analityki) przegrywasz tam na detalu i czasie reakcji, ale nadal możesz złapać atak na wcześniejszym etapie – właśnie dzięki prostym check-listom na logach sieciowych.

Jak często analizować logi, żeby miało to sens przy małym zespole?

Dla większości małych i średnich organizacji realistyczny rytm to przynajmniej: krótki przegląd raz dziennie (top hosty, top nietypowe destynacje, szybki rzut okiem na DNS) oraz głębsza analiza 1–2 razy w tygodniu dla wybranych hostów lub zdarzeń. Lepiej mieć prostą, ale wykonywaną rutynę niż ambitny plan, do którego nikt nie usiądzie.

Dobrym kompromisem jest też reagowanie na „triggery”: nowy alert z EDR, zgłoszenie od użytkownika, podejrzany mail. Wtedy jako część procedury incydentowej od razu odpalasz przygotowane zapytania na firewallu, DNS i proxy. Taki półautomatyczny workflow da się utrzymać nawet w zespole „admin plus pies służbowy”.

Co warto zapamiętać

• Wykrywanie C2 bez SIEM jest realne, jeśli zamiast „magii narzędzi” postawisz na porządek w logach, proste procedury i regularne patrzenie w dane, które już masz.
• C2 to krytyczny etap ataku – stały kanał między zainfekowaną stacją a atakującym; bez niego napastnik często traci dostęp po jednorazowym exploicie, więc jego ruch zwykle jest powtarzalny i da się go wyłapać.
• Niemal każdy incydent zostawia ślady w sieci: powtarzające się połączenia na zewnątrz, zapytania DNS do dziwnych domen czy nietypowe wykorzystanie protokołów, co widać nawet w bardzo prostych zestawieniach logów.
• Najczęstsze kanały C2 (HTTP/HTTPS, DNS, e‑mail, tunelowanie przez SaaS) są sprytnie „wciśnięte” w normalny ruch, ale zdradzają się m.in. wzorcami beaconingu, rzadkimi destynacjami i nietypowym zachowaniem protokołów.
• Nawet mała firma może zbudować sensowne minimum detekcji, opierając się na logach z firewalla, DNS, proxy, EDR/antywirusa i systemów operacyjnych – pod warunkiem ich centralnego zbierania i trzymania choćby przez kilka–kilkanaście dni.
• Prawdziwy problem to zwykle chaos: logi „gdzieś są”, ale bez retencji, formatu i prostych szablonów zapytań; uporządkowanie tego bałaganu daje więcej niż dokładanie kolejnych „magicznych” urządzeń.