Bezpieczeństwo

DNS Tunneling

1998AktywnyOpublikowano: 28 września 2026Aktualizacja: 28 września 2026Opublikowany

Technika sieciowa enkapsulująca dane innych protokołów w zapytaniach i odpowiedziach DNS; używana do eksfiltracji danych, kanałów C2 i omijania zapór.

Kluczowa innowacja

Wykorzystanie protokołu DNS — traktowanego przez zapory jako zaufany i niemal zawsze przepuszczany — jako ukrytego, dwukierunkowego kanału transportu dowolnych danych.

Kategoria

Bezpieczeństwo

Poziom abstrakcji

Wzorzec

Poziom operacji

Środowisko agentoweWdrożenieSystem

Zastosowania

Eksfiltracja danychCommand-and-control (C2)Omijanie zapór i filtrowania ruchu wychodzącegoOmijanie portali przechwytujących (captive portal)Ukryty kanał komunikacji malwareWektor eksfiltracji/C2 dla agentów AI z dostępem sieciowym

Jak działa

1) Napastnik kontroluje domenę i jej autorytatywny serwer nazw. 2) Klient (implant lub skompromitowany agent) koduje ładunek w etykietach subdomen zapytania, np. <dane-base32>.tunnel.example.com. 3) Lokalny/rekurencyjny resolwer, nie mając odpowiedzi w cache, przekazuje zapytanie w górę łańcucha aż do serwera atakującego. 4) Serwer atakującego dekoduje dane z nazwy zapytania i odpowiada rekordem (TXT/NULL/CNAME/A), w którym koduje dane zwrotne lub polecenie. 5) Klient dekoduje odpowiedź i powtarza cykl, uzyskując dwukierunkowy kanał. Kompromis między przepustowością a wykrywalnością reguluje się typem rekordu, długością etykiet (limit 63 znaki/etykieta, 253 znaki/nazwa) oraz częstotliwością zapytań. Warianty obejmują heartbeat/beacon (potwierdzanie infekcji) oraz sygnalizację przez kody odpowiedzi (NXDOMAIN vs NOERROR).

Rozwiązany problem

Z perspektywy napastnika rozwiązuje problem omijania filtrowania ruchu wychodzącego (egress) i zapór: gdy bezpośrednie połączenia HTTP/HTTPS lub TCP są blokowane, DNS niemal zawsze pozostaje otwarty, co pozwala utrzymać komunikację i wyprowadzić dane bez wzbudzania alarmu. Z perspektywy obrony definiuje konkretny wektor zagrożenia wymagający monitorowania i ograniczania.

Komponenty

Klient tunelujący (koder)Koduje ładunek w etykietach subdomen i inicjuje zapytania DNS.

Komponent po stronie ofiary (implant, skrypt, skompromitowany agent), który dzieli dane na fragmenty, koduje je (Base32/Base64/hex) i osadza w nazwach zapytań kierowanych do kontrolowanej domeny.

INDowolne dane do wyprowadzenia lub żądanie polecenia.

OUTZapytanie DNS z zakodowanymi danymi w etykietach subdomeny.

Oficjalna

Autorytatywny serwer nazw atakującego (dekoder)Odbiera zapytania dla kontrolowanej domeny, dekoduje dane i odpowiada.

Serwer DNS ustawiony jako autorytatywny dla domeny napastnika. Rekonstruuje dane z nazw zapytań i koduje odpowiedzi w rekordach TXT/NULL/CNAME/A/AAAA, zamykając pętlę C2.

INZapytanie przekazane przez łańcuch resolwerów.

OUTRekord (TXT/NULL/CNAME/A) z danymi zwrotnymi lub poleceniem.

Schemat kodowania i wybór rekorduMapuje dowolne bajty na dozwolone znaki DNS i pojemne typy rekordów.

DNS nie dopuszcza dowolnych bajtów w nazwach, więc dane są kodowane (Base32/Base64/hex). Do transportu zwrotnego wybiera się rekordy o dużej pojemności (TXT, NULL) lub A/AAAA/CNAME dla dyskrecji.

Oficjalna

Łańcuch resolwerów rekurencyjnychNieświadomy pośrednik przekazujący zapytania do serwera atakującego.

Rekurencyjne resolwery ofiary (firmowe lub publiczne), które w normalnym trybie pracy przekazują niebuforowane zapytania w górę hierarchii DNS, umożliwiając tunel bez bezpośredniego połączenia klient-atakujący.

Implementacja

Implementacje referencyjne

iodine

C · Erik Ekman / Bjorn Andersson

Pułapki implementacyjne

Niska przepustowość i zawodność UDPŚrednia

DNS opiera się głównie na UDP bez retransmisji; duże transfery są wolne, zawodne i podatne na utratę pakietów.

Rozwiązanie:Fragmentacja i numeracja sekwencji, retransmisja na poziomie aplikacji, kompresja ładunku.

Wysoka wykrywalność przy dużym wolumenieWysoka

Duża liczba długich, losowo wyglądających zapytań do jednej domeny jest łatwa do wykrycia przez analizę entropii, długości nazw i wolumenu.

Rozwiązanie:Ograniczanie tempa, rotacja domen, mimikra ruchu legalnego; po stronie obrony — monitoring i limity.

Ewolucja

1998

Pierwsza publiczna koncepcja tunelowania przez DNS

Punkt przełomowy

Idea wykorzystania DNS jako kanału transmisji danych pojawia się publicznie na liście dyskusyjnej Bugtraq (Oskar Pearson).

2000

NSTX — jedno z pierwszych narzędzi IP-over-DNS

Powstaje NSTX, umożliwiające tunelowanie IP przez DNS i pokazujące praktyczność techniki.

2004

OzymanDNS (Dan Kaminsky) i DNScat-P

Punkt przełomowy

OzymanDNS Dana Kaminsky’ego pozwala na SSH i transfer plików przez DNS; DNScat-P (Tadeusz Pietraszek) rozwija narzędziownię.

2006

iodine — dojrzały tunel IPv4-over-DNS

iodine dostarcza stabilnego tunelu IPv4 przez DNS z obsługą interfejsów TUN/TAP i wielu typów rekordów.

2008

tcp-over-dns z kompresją

tcp-over-dns wprowadza kompresję (LZMA) dla zwiększenia efektywnej przepustowości tunelu.

2017

Adopcja w kampaniach APT (DNSMessenger, OilRig BONDUPDATER)

Tunelowanie DNS trafia do realnych kampanii: RAT DNSMessenger oraz BONDUPDATER grupy OilRig używają rekordów A i TXT jako kanału C2.

2024

Rozpoznanie jako wektor eksfiltracji dla agentów AI

W miarę upowszechniania autonomicznych agentów z dostępem do narzędzi sieciowych, tunelowanie DNS jest analizowane jako kanał eksfiltracji i C2 omijający filtrowanie ruchu wychodzącego.