DNS tunneling: detekcja tuneli DNS i C2

DNS tunneling wykorzystuje zapytania i odpowiedzi Domain Name System do przenoszenia danych lub komunikacji command-and-control. MITRE ATT&CK klasyfikuje użycie DNS jako T1071.004 i wskazuje, że polecenia oraz wyniki mogą być osadzane między innymi w zapytaniach i rekordach odpowiedzi. Skuteczna detekcja nie polega jednak na jednym progu „długa domena = malware”. Potrzebuje resolverowej telemetrii, kontekstu endpointu, modelu normalnego ruchu oraz korelacji wielu słabych sygnałów.

Ten przewodnik pokazuje, jak zaprojektować detekcję tuneli DNS, od danych źródłowych przez cechy statystyczne po triage i walidację. Koncentruje się na ochronie i testach w kontrolowanym środowisku; nie zawiera instrukcji budowania kanału eksfiltracji.

Dlaczego DNS nadaje się do komunikacji ukrytej

DNS jest niezbędny w prawie każdej sieci. Zapytania wychodzące są często dozwolone, a ruch do resolvera bywa traktowany jako infrastruktura zaufana. Nazwa domenowa składa się z etykiet, więc klient może generować wiele unikalnych subdomen pod domeną kontrolowaną przez operatora. Odpowiedzi mogą używać typów takich jak A, AAAA, CNAME lub TXT, zależnie od implementacji i celu.

RFC 1035 opisuje format wiadomości, nazw i rekordów. Sam nietypowy rekord nie jest dowodem ataku: TXT wspiera legalne mechanizmy pocztowe i weryfikacyjne, a długie, unikalne nazwy występują w CDN, tracking, antyfraudzie i service discovery. Detekcja musi zatem odpowiedzieć nie tylko „jak wygląda query”, ale także „który host je wysłał, jaki proces był źródłem, do jakiej domeny bazowej, w jakim rytmie i z jaką odpowiedzią”.

MITRE wskazuje dwa praktyczne warianty zachowania:

beaconing, czyli okresowe sprawdzanie poleceń przez DNS;
tunneling, w którym dane są kodowane w polach zapytań lub odpowiedzi.

Granica między nimi nie zawsze jest ostra. Niskoprzepustowy kanał C2 może przenosić tylko identyfikator hosta i komendy, podczas gdy eksfiltracja generuje większy wolumen i więcej unikalnych etykiet.

Architektura widoczności DNS

Najlepszym punktem obserwacji jest kontrolowany resolver organizacji, który widzi logiczne zapytania klientów i odpowiedzi upstream. Sensory sieciowe, takie jak Zeek, dostarczają dodatkowy kontekst połączenia. Zeek dns.log może rejestrować między innymi host źródłowy i docelowy, nazwę query, typ, kod odpowiedzi, odpowiedzi, TTL i czas RTT dla niezaszyfrowanego DNS.

Minimalny rekord analityczny powinien zawierać:

Pole	Znaczenie dla detekcji
timestamp	rytm, serie i korelacja z procesem
client / device ID	źródło zapytania, również poza biurem
resolver	wykrycie omijania firmowego punktu
query i domena rejestrowalna	cechy etykiet oraz agregacja kampanii
qtype	A, AAAA, TXT, CNAME i nietypowe typy
rcode	udział NXDOMAIN, SERVFAIL i NOERROR
answers i TTL	charakter odpowiedzi oraz zmienność
bytes in/out	asymetria i przybliżona przepustowość
process / user	odróżnienie przeglądarki, agenta i nieznanego binarium

Log tylko z publicznego firewalla może pokazać wiele pakietów UDP/53 do jednego resolvera, lecz nie nazwy klientów za NAT ani procesów. Z kolei log endpointowy bez odpowiedzi DNS utrudnia analizę. Łącz warstwy przez stabilny identyfikator urządzenia i synchronizację czasu.

Najważniejsze cechy tunelu DNS

Żadna cecha nie jest wystarczająca samodzielnie. Dobra analityka agreguje je per host i domena rejestrowalna w kilku oknach czasowych.

Długość i liczba etykiet

Kanał przenoszący dane często wykorzystuje dłuższe subdomeny lub więcej etykiet. Mierz długość pełnego QNAME, długość najdłuższej etykiety, liczbę etykiet oraz udział nazw zbliżających się do limitów protokołu. Nie ustawiaj uniwersalnego progu bez baseline’u — legalny telemetry endpoint może wyglądać podobnie.

Entropia i alfabet

Zakodowane lub zaszyfrowane dane mają zwykle wyższą losowość niż słowa naturalne. Oblicz entropię etykiet, udział cyfr, stosunek samogłosek, liczbę unikalnych znaków oraz zgodność z alfabetami przypominającymi Base32, Base64url lub zapis szesnastkowy. To heurystyki, nie dekoder. Hash w nazwie zasobu CDN również może mieć wysoką entropię.

Unikalność subdomen

Policz unikalne subdomeny dla domeny bazowej i współczynnik powtórzeń. Tunel wysyłający kolejne fragmenty danych może generować niemal wyłącznie nowe nazwy. Legalny cache-busting, tracking i DNS-based service discovery tworzą jednak ten sam sygnał, dlatego potrzebny jest kontekst właściciela i procesu.

NXDOMAIN i kody odpowiedzi

Wysoki udział NXDOMAIN bywa skutkiem algorytmów DGA, literówek, aplikacji z błędną konfiguracją lub kanału wykorzystującego samą obserwację zapytania po stronie autorytatywnego DNS. Mierz NXDOMAIN per host, domena i proces, ale nie myl detekcji DGA z detekcją tunelu. Tunel może odpowiadać NOERROR na każde zapytanie.

Typy rekordów i kierunek danych

Seria TXT o nietypowej długości jest warta analizy, ale skupienie wyłącznie na TXT pomija tunele korzystające z A, AAAA lub CNAME. Mierz qtype mix, rozmiary odpowiedzi, liczbę odpowiedzi i asymetrię. Dla eksfiltracji większa część informacji może płynąć w query; dla downloadu lub C2 więcej danych może pojawiać się w odpowiedzi.

Timing i regularność

Beacon może wysyłać zapytanie co zbliżony interwał, czasem z jitterem. Analizuj rozkład odstępów, autokorelację, aktywność poza godzinami pracy i utrzymywanie wzorca mimo braku aktywności użytkownika. Cron, monitoring i aktualizatory także są regularne, ale zwykle mają znanego właściciela i stabilny proces.

TTL i infrastruktura domeny

Nietypowo niski lub stały TTL może wzmacniać sygnał, lecz CDN również używają krótkich wartości. Dodaj wiek domeny, historię pierwszego wystąpienia w organizacji, zmiany serwerów nazw i relację z innymi IOC, ale nie pozwól, by reputacja zastąpiła zachowanie. Nowa domena biznesowa nie jest automatycznie złośliwa, a stara domena może zostać przejęta.

Model scoringowy zamiast jednej reguły

Praktyczna detekcja przypisuje punkty kilku niezależnym cechom. Przykładowy model koncepcyjny — do kalibracji na danych organizacji — może wyglądać tak:

Sygnał	Przykładowa waga
wysoka entropia najdłuższej etykiety	2
wysoki udział unikalnych subdomen	3
regularny rytm przez dłuższy okres	2
nowa domena dla całej organizacji	1
proces nietypowy dla DNS	3
bezpośredni DNS poza firmowym resolverem	4
anomalny wolumen bajtów per host–domena	3

Wartości nie są gotową polityką. Najpierw wyznacz percentyle per klasa urządzeń, a potem oceń precision i recall na oznaczonym zbiorze. Laptop dewelopera, serwer DNS, kontroler domeny i terminal kiosku wymagają innych baseline’ów.

Reguła powinna również mieć warunki obniżające wynik: zatwierdzony proces, znany mechanizm EDR, domena należąca do używanej usługi i spójny wzorzec całej floty. Allowlista musi być precyzyjna — domena rejestrowalna plus właściciel i proces — oraz okresowo przeglądana. Globalne wykluczenie całej infrastruktury chmurowej tworzy dużą martwą strefę.

Przykład bezpiecznej logiki analitycznej

Poniższy pseudokod opisuje analizę obronną, bez zależności od konkretnego SIEM:

GROUP DNS events BY device_id, registered_domain IN 15 minutes
CALCULATE query_count, unique_subdomain_ratio,
          p95_label_length, mean_label_entropy,
          nxdomain_ratio, qtype_distribution,
          interval_regularity, total_query_bytes
JOIN endpoint process telemetry ON device_id AND time_window
ALERT WHEN multi_feature_score >= environment_threshold
  AND NOT approved_domain_process_pair

Wykonaj agregację także w oknie 24-godzinnym. Tunel o małej przepustowości może nie przekroczyć krótkiego progu, ale utrzyma nietypową kombinację cech przez wiele godzin. Z drugiej strony masowa anomalia w jednej minucie może wskazywać źle działający agent, nie C2.

DNS over HTTPS i DNS over TLS

RFC 8484 definiuje DNS over HTTPS, a szyfrowany DNS zmienia punkt widoczności. Sensor sieciowy nie zobaczy QNAME wewnątrz poprawnie zaszyfrowanego DoH. Nie oznacza to, że organizacja powinna blokować całe HTTPS. Potrzebuje polityki rozwiązywania nazw: zarządzane endpointy korzystają z zatwierdzonego resolvera lub klienta, a nieautoryzowane resolvery są wykrywane po domenie, adresie, SNI/telemetrii TLS, konfiguracji przeglądarki i zdarzeniach endpointu.

Współczesna architektura może zapewnić prywatność i widoczność jednocześnie przez firmowy encrypted resolver z logowaniem zgodnym z polityką. Kontroluj retencję i dostęp, ponieważ pełna historia DNS ujawnia zachowanie użytkowników. Zasada minimalizacji danych powinna określać, które pola i jak długo są potrzebne do detekcji.

Nie zapominaj o aplikacjach implementujących własny DoH. Egzekwowanie wyłącznie portu 53 nie zatrzyma zapytań ukrytych w HTTPS. EDR, kontrola aplikacji i egress proxy dostarczają kontekst, którego nie ma klasyczny firewall.

Obchodzenie firmowego resolvera

Najwyższej jakości szybka detekcja często nie szuka tunelu, lecz naruszenia architektury: zwykły endpoint wysyła UDP/TCP 53 bezpośrednio do Internetu albo łączy się z niezatwierdzonym DoH. Jeśli wszystkie urządzenia mają używać wewnętrznego resolvera, taki ruch jest silnym sygnałem i jednocześnie błędem kontroli egress.

Na firewallu zezwól na DNS outbound tylko resolverom. Na endpointach rejestruj zmianę konfiguracji DNS i proces otwierający połączenie. Dla użytkowników zdalnych zapewnij tę samą politykę przez secure web gateway, VPN lub agent resolvera. Mechanizm ochronny nie może blokować captive portal czy procedur awaryjnych bez testu operacyjnego.

Takie podejście wpisuje się w Zero Trust i segmentację sieci: host nie otrzymuje dowolnego egress tylko dlatego, że znajduje się w sieci firmowej.

Korelacja z endpointem i tożsamością

Najważniejsze pytanie triage brzmi: jaki proces wygenerował zapytania? Przeglądarka odwiedzająca legalną aplikację, klient EDR i niepodpisane binarium uruchomione z katalogu tymczasowego zasługują na różne priorytety.

Koreluj DNS z:

drzewem procesów i podpisem pliku;
użytkownikiem oraz typem sesji;
pierwszym uruchomieniem programu;
połączeniami sieciowymi tego samego procesu;
utworzeniem persistence lub zaplanowanego zadania;
alertami e-mail, identity i cloud;
historią domeny w całej organizacji.

Nie opieraj reakcji na reverse DNS ani nazwie procesu. Atakujący może wybrać podobną nazwę, a wiele legalnych aplikacji korzysta z host process. Potrzebne są hash, signer, ścieżka, parent i dane instalacyjne.

Triage alertu DNS tunneling

Analityk powinien wykonać powtarzalny proces:

potwierdzić jakość i kompletność logu, w tym utratę pakietów i NAT;
wyznaczyć pierwsze oraz ostatnie wystąpienie host–domena;
porównać wzorzec z innymi urządzeniami tej samej klasy;
ustalić proces, użytkownika, parent i reputację pliku;
sprawdzić qtype, rcode, odpowiedzi, TTL, timing i wolumen;
ustalić właściciela domeny i legalną usługę, bez automatycznego zaufania reputacji;
wyszukać podobne etykiety lub domeny w całej organizacji;
jeśli ryzyko jest wysokie, odizolować host zgodnie z playbookiem i zabezpieczyć dane do analizy.

Nie wykonuj aktywnych zapytań do podejrzanej domeny z własnej stacji analityka. Użyj kontrolowanej infrastruktury, pasywnych danych lub resolvera badawczego. Bezpośredni kontakt może poinformować operatora i zanieczyścić dowody.

Walidacja reguły bez ryzyka eksfiltracji

Test detekcji nie wymaga przesyłania prawdziwych danych ani użycia publicznej infrastruktury. W kontrolowanej strefie wygeneruj syntetyczne zapytania o cechach zbliżonych do tunelu do domeny należącej do zespołu testowego. Zmieniaj jedną cechę: długość, entropię, qtype, NXDOMAIN, częstotliwość lub proces. Potwierdź, czy log dociera, agregacja działa, alert zawiera kontekst i playbook prowadzi do właściwego hosta.

Następnie wykonaj testy benign: CDN, system aktualizacji, EDR, telemetria i aplikacje deweloperskie. Mierz:

precision, czyli udział prawdziwie podejrzanych alertów;
recall na kontrolowanym zbiorze wariantów;
czas od zapytania do alertu;
odsetek zdarzeń z dostępnym procesem;
liczbę wyjątków i ich wiek;
koszt zapytania w SIEM.

Detekcja, której nikt nie jest w stanie utrzymać lub przetriage’ować, nie jest ukończona. Przenieś ją do procesu detection engineering i Sigma, wersjonuj i testuj regresyjnie.

Najczęstsze błędy implementacyjne

Jeden próg długości

Generuje alerty dla legalnych usług i nie wykrywa kanałów o krótkich fragmentach. Użyj agregacji oraz kombinacji cech.

Analiza tylko TXT

Pomija inne typy rekordów. Utrzymuj logikę niezależną od qtype i dodawaj specyficzne sygnały jako wzmacniające.

Globalna allowlista domeny

Przejęta subdomena lub nietypowy proces może zostać ukryty. Wiąż wyjątek z procesem, właścicielem i spodziewanym wzorcem.

Brak widoczności DoH

Port 53 wygląda czysto, lecz aplikacja korzysta z własnego resolvera HTTPS. Zarządzaj resolverami i telemetrią endpointową.

Brak baseline’u per urządzenie

Serwer DNS i laptop mają inne rozkłady. Segmentuj populację i aktualizuj profil ostrożnie, aby anomalia nie „nauczyła” modelu złego zachowania.

Checklista wdrożenia

Kieruj zarządzane urządzenia przez zatwierdzone resolvery.
Blokuj zwykły DNS do Internetu z wyjątkiem resolverów.
Zbieraj query, qtype, rcode, answer, TTL, rozmiary i identyfikator klienta.
Łącz resolver z procesem EDR oraz user/device identity.
Agreguj po domenie rejestrowalnej i hoście w wielu oknach.
Łącz entropię, długość, unikalność, timing, NXDOMAIN i wolumen.
Oddziel wykrywanie DGA, beaconingu i tunelowania, ale koreluj wyniki.
Kontroluj DoH/DoT i aplikacje używające własnego resolvera.
Wersjonuj reguły, wyjątki i progi; przypisz właściciela.
Testuj syntetycznie bez danych produkcyjnych.
Zachowuj prywatność, retencję i ograniczony dostęp do logów DNS.
Mierz skuteczność triage, nie tylko liczbę alertów.

Najczęstsze pytania

Czy wysoka entropia domeny oznacza tunel DNS?

Nie. Hashowane nazwy CDN, tracking i telemetria mogą wyglądać podobnie. Entropia jest jednym z sygnałów i wymaga agregacji z procesem, timingiem, unikalnością oraz wolumenem.

Czy DNSSEC blokuje tunneling?

DNSSEC zapewnia autentyczność i integralność wybranych danych DNS, nie zabrania właścicielowi domeny tworzenia rekordów ani klientowi wysyłania zapytań. Nie jest kontrolą anty-tunnelingową.

Czy blokada TXT rozwiązuje problem?

Nie. Łamie legalne zastosowania i nie zatrzymuje kanałów używających innych typów. Lepsza jest kontrola resolverów, egress i analiza zachowania.

Jak wykrywać tunel przy DoH?

Korzystaj z zarządzanego resolvera, polityki dozwolonych endpointów DoH, telemetrii procesu i egress proxy. Sensor pasywny nie odszyfruje prawidłowego HTTPS bez punktu kontroli.

Detekcja DNS wymaga danych z sieci i endpointu

Breachroad pomaga projektować i weryfikować analityki w ramach purple team, testów segmentacji i monitoringu bezpieczeństwa. Wynikiem nie jest statyczna reguła na „długą domenę”, lecz mierzalny pipeline: źródło danych, scoring, kontekst procesu, playbook i test regresyjny.