Che cos’è il tunneling DNS? Attacchi, rilevamento e prevenzione

Il Domain Name System (DNS) funge da directory fondamentale di Internet, traducendo i nomi host di facile comprensione per l’utente in indirizzi IP leggibili dai computer. Poiché quasi tutte le applicazioni di rete dipendono dalla risoluzione dei nomi, le organizzazioni consentono abitualmente il traffico DNS in uscita attraverso i propri perimetri con un controllo minimo. I firewall che bloccano la navigazione web non autorizzata, i trasferimenti di file e le connessioni SSH lasciano quasi sempre la porta 53 completamente aperta.

Gli autori delle minacce sfruttano questa fiducia predefinita. Inserendo dati non autorizzati all’interno di richieste di ricerca standard, un malintenzionato può comunicare in modo occulto con gli host interni e sottrarre proprietà intellettuale senza stabilire una connessione TCP diretta. Comprendere questi canali nascosti, insieme alle più ampie vulnerabilità del DNS, è essenziale per costruire una difesa aziendale resiliente.

Che cos’è il tunneling DNS?

Il tunneling DNS è una tecnica di attacco informatico che consiste nell'inserire programmi non DNS, payload di dati o comandi remoti all'interno di query e risposte DNS standard. Poiché i resolver ricorsivi instradano abitualmente queste ricerche attraverso i perimetri di rete, gli aggressori possono stabilire un canale di comunicazione bidirezionale stabile che aggira completamente i firewall perimetrali, i proxy di rete e i filtri dei contenuti.

A grandi linee, l’abuso del protocollo si basa su query dei client indirizzate verso un dominio gestito dall’autore dell’attacco. Quando il software compromesso deve trasmettere dati, li inserisce nell’etichetta del sottodominio di una ricerca. I resolver ricorsivi inoltrano la query a monte fino a quando non raggiunge il server autoritativo dell’autore dell’attacco, il quale estrae il payload e rinvia istruzioni incorporate all’interno di record di risposta DNS standard.

Come funziona un attacco di tunneling DNS

L'esecuzione di un tunnel DNS non richiede la compromissione dei resolver ricorsivi aziendali né la manomissione dei server root DNS principali. Si avvale invece dei meccanismi standard di instradamento DNS attraverso il seguente ciclo di vita:

1. Preparazione dell'infrastruttura: l'autore dell'attacco registra un nome di dominio pubblico (ad esempio attacker-c2.net) e configura un server dei nomi autorevole, da lui controllato, per gestire tutte le richieste relative a quel dominio e ai suoi sottodomini.

2. Distribuzione del payload: un endpoint interno viene compromesso tramite phishing, sfruttamento di vulnerabilità software o manomissione della catena di approvvigionamento. Il malware in esecuzione su tale endpoint contiene una logica specificamente progettata per impacchettare i dati locali in etichette conformi allo standard DNS.

3. Codifica e segmentazione dei dati: poiché gli standard del protocollo DNS (RFC 1035) limitano le singole etichette di dominio a 63 caratteri e i nomi di dominio completi a 253 caratteri, il malware frammenta grandi insiemi di dati in piccoli blocchi. Codifica ogni blocco utilizzando formati come Base32 o esadecimale, aggiungendo il risultato come sottodominio (ad esempio, 4d616c6963696f7573.data.attacker-c2.net). Il formato Base32 viene spesso scelto perché le ricerche DNS non distinguono tra maiuscole e minuscole.

4. Risoluzione ricorsiva: l'endpoint avvia una ricerca DNS standard. Poiché il computer è configurato per utilizzare il resolver DNS interno dell'azienda, la query viene inviata innanzitutto al server aziendale. Il server aziendale rileva una richiesta di routine, stabilisce di non avere il record in cache e inoltra la ricerca attraverso la gerarchia DNS globale.

5. Estrazione del payload: la query raggiunge infine il server dei nomi autoritativo dell’autore dell’attacco. Anziché fornire un indirizzo IP autentico relativo all’hosting del sito web, il server dell’autore dell’attacco elimina il nome di dominio principale, estrae la stringa del sottodominio codificata e ricompone i dati originali.

6. Invio di comandi tramite risposte: per inviare comandi alla rete aziendale, il server autorevole crea un record di risposta. Gli autori degli attacchi utilizzano spesso i record TXT, poiché consentono di inserire fino a 255 caratteri per stringa, oppure i record CNAME e NULL. Quando il resolver aziendale restituisce la risposta all’host infetto, il malware client estrae il payload ed esegue le istruzioni dell’operatore.

Durante l'intero scambio, l'endpoint infetto non avvia mai una connessione di rete diretta con l'infrastruttura dell'autore dell'attacco. Ogni byte passa in modo trasparente attraverso i server DNS aziendali legittimi.

A cosa serve il tunneling DNS per gli hacker

Mentre gli amministratori di rete utilizzano occasionalmente strumenti di tunneling a fini diagnostici, gli autori delle minacce sfruttano questa tecnica in diverse fasi critiche della catena di attacco informatico.

Estrazione dei dati

L'esfiltrazione dei dati rappresenta l'obiettivo più comune del tunneling DNS. Quando gli aggressori compromettono sistemi contenenti registrazioni relative ai pagamenti, credenziali o codice sorgente proprietario, l'accesso web in uscita è spesso sottoposto a un filtraggio o a un'ispezione rigorosa da parte dei proxy di prevenzione della perdita di dati (DLP).

Suddividendo i dati sensibili in parti serializzate e trasmettendoli tramite ricerche nei sottodomini, il malware è in grado di convogliare gradualmente gigabyte di informazioni senza mai aprire una sessione HTTP o FTP.

Comando e controllo (C2)

Una volta che il malware si è insediato nel sistema, ha bisogno di un canale affidabile per ricevere istruzioni dai propri operatori. Gli autori degli attacchi utilizzano spesso strumenti di tunneling come iodine o dnscat2 come canali di riserva in caso di interruzione delle connessioni HTTPS primarie. I team di sicurezza dovrebbero riconoscere le firme di questi strumenti durante la risposta agli incidenti.

Attraverso tunnel DNS bidirezionali, gli operatori possono impartire comandi amministrativi, caricare fasi secondarie di malware e coordinare movimenti laterali in profondità all’interno di reti segmentate.

Come aggirare i controlli di rete e i portali di accesso

In ambienti con restrizioni, come le reti Wi-Fi degli hotel, gli hotspot aeroportuali o le VLAN aziendali isolate riservate agli ospiti, gli switch di rete in genere bloccano tutto il traffico web in uscita finché l'utente non completa l'autenticazione su un captive portal.

Tuttavia, affinché la pagina del portale possa essere risolta, la rete deve consentire le richieste DNS sulla porta 53. Gli aggressori e gli utenti non autorizzati sfruttano i tunnel DNS per instradare il traffico Internet senza restrizioni attraverso questi resolver aperti, aggirando i sistemi di fatturazione captive e i controlli di isolamento della rete.

Esempi concreti di attacchi di tunneling DNS

Il tunneling DNS è tutt’altro che teorico. Gruppi di hacker sofisticati e attori statali hanno ripetutamente integrato le comunicazioni DNS in campagne informatiche su larga scala.

1. SUNBURST (Violazione della catena di approvvigionamento di SolarWinds)

Una delle violazioni della catena di approvvigionamento più gravi nella storia della sicurezza informatica si è basata in larga misura sulla segnalazione tramite DNS. Nel backdoor SUNBURST, diffuso tramite aggiornamenti dannosi del software SolarWinds Orion, il malware comunicava con gli autori dell’attacco utilizzando sottodomini dinamici sotto avsvmcloud.com.

La backdoor raccoglieva informazioni di base sull’host, codificava i dati in stringhe alfanumeriche e le anteponeva come sottodomini alle richieste di ricerca. Quando i server dei nomi autoritativi sotto il controllo dell’autore dell’attacco ricevevano tali query, rispondevano con record CNAME che puntavano a server di comando secondari o a specifici intervalli di indirizzi IP che ordinavano alla backdoor di entrare in modalità di sospensione, terminarsi o attivare canali HTTP secondari. L’intero ambito di questa tecnica operativa è documentato nell’avviso CISA AA20-352A.

2. Backdoor DNS di OilRig (APT34)

Il gruppo di hacker iraniano finanziato dallo Stato noto come OilRig (APT34) ha sistematicamente sfruttato il tunneling DNS sia per l’invio di comandi che per l’esfiltrazione di dati. Nel corso di numerose campagne rivolte a entità dei settori energetico, finanziario e governativo, OilRig ha impiegato famiglie di malware personalizzate quali ALMA Communicator, DNSpionage e Saitama.

Questi implant monitorano i computer delle vittime, estraggono file sensibili e strutturano i dati in query DNS ad alto volume indirizzate a server dei nomi controllati dagli autori dell'attacco. Se i protocolli di comunicazione standard falliscono o i firewall interrompono i canali web, il malware ricorre automaticamente al tunneling DNS per mantenere la persistenza e il controllo amministrativo.

Come individuare il tunneling DNS

Poiché le reti legittime elaborano milioni di transazioni DNS ogni giorno, individuare i tunnel dannosi richiede l’analisi sia delle caratteristiche delle singole query sia delle tendenze generali del traffico. Le strategie di rilevamento rientrano generalmente in due categorie principali: l’analisi del payload e l’analisi del traffico.

Analisi del carico utile

L'analisi del payload esamina le stringhe, le strutture e i record di risorse specifici contenuti nelle singole richieste e risposte DNS.

• Lunghezza e struttura dei sottodomini: i sottodomini standard sono solitamente brevi e facilmente comprensibili, come ad esempio mail.company.com o api.internal.local. Le query di tunneling ottimizzano il trasferimento dei dati comprimendo lunghe stringhe codificate nei sottodomini, spesso avvicinandosi al limite di 63 caratteri previsto per le etichette.
• Entropia delle informazioni: le stringhe crittografate o codificate presentano un’elevata entropia statistica (casualità) rispetto alle parole del linguaggio naturale. Le piattaforme di analisi della sicurezza valutano la distribuzione dei caratteri; le stringhe che presentano variazioni anomale dei caratteri, schemi alfanumerici ripetitivi o strutture vocali mancanti indicano chiaramente la presenza di dati codificati.
• Tipi di record di risorse insoliti: il traffico aziendale tipico utilizza prevalentemente record A, AAAA, MX e, occasionalmente, record CNAME. Un improvviso afflusso di richieste di ricerca relative a record TXT (che contengono stringhe di grandi dimensioni), record NULL (che contengono blob binari arbitrari) o record SRV provenienti da endpoint che non eseguono servizi di rete è indice di un uso improprio del protocollo.
• Set di caratteri non standard: le query che includono caratteri di riempimento Base32, sequenze esadecimali o distribuzioni di simboli non convenzionali devono essere immediatamente messe in quarantena e sottoposte a ispezione.

Analisi del traffico

L'analisi del traffico esamina i modelli aggregati delle query nel tempo, individuando comportamenti operativi anomali anche quando le singole query sembrano innocue.

• Volume anomalo di query verso un dominio specifico: l’utilizzo legittimo del DNS trae vantaggio dalla cache. Una volta che un host risolve example.com, il resolver ricorsivo memorizza il record nella cache per tutta la durata del suo Time to Live (TTL), evitando ulteriori ricerche esterne identiche. I tunnel DNS generano un flusso continuo di richieste perché ogni dato sottratto richiede un sottodominio nuovo e unico che non può essere fornito dalla cache.
• Elevata percentuale di nomi di dominio pienamente qualificati (FQDN): il fatto di osservare, nell’arco di un’ora, migliaia di sottodomini univoci che si risolvono sotto un unico dominio apice costituisce un indicatore affidabile della presenza di un tunnel attivo.
• Domini di nuova registrazione (NRD): gli autori delle minacce utilizzano sistematicamente domini effimeri per eludere le liste di blocco basate sulla reputazione statica. Le richieste indirizzate a domini creati nelle ultime 24-72 ore dovrebbero attivare un livello di controllo più rigoroso.
• Connessioni dirette in uscita verso la porta 53: in un’architettura aziendale sicura, le postazioni di lavoro standard degli utenti dovrebbero comunicare esclusivamente con i resolver interni designati. Qualsiasi postazione che tenti di inviare richieste DNS direttamente a resolver pubblici esterni (come 8.8.8.8 o 1.1.1.1) sta spesso cercando di aggirare il monitoraggio interno.

Strumenti e tecnologie utili

Per individuare il tunneling DNS su larga scala sono necessari strumenti di difesa appositamente progettati:

• Piattaforme DNS protettive (PDNS): i servizi PDNS cloud e ibridi si collocano tra i resolver interni e la rete Internet in generale, applicando informazioni sulle minacce in tempo reale e modelli comportamentali per intercettare le ricerche dannose prima che la risoluzione venga completata.
• Rilevamento e risposta di rete (NDR): i moderni strumenti NDR ispezionano in modo passivo i segmenti di rete, identificando sottodomini ad alta entropia e tunneling di protocollo tramite modelli di apprendimento automatico senza introdurre latenza.
• Gestione delle informazioni e degli eventi di sicurezza (SIEM): inoltrando i log di debug dei resolver DNS interni a un sistema SIEM, i team di ingegneri possono configurare regole di correlazione che segnalano gli endpoint che generano un numero anomalo di query su domini univoci.
• Monitoraggio unificato della sicurezza DNS: una difesa efficace va oltre l’ispezione del traffico in uscita; richiede anche il monitoraggio delle zone autoritative per garantire che gli autori delle minacce non abbiano manipolato i record aziendali. Soluzioni complete di monitoraggio della sicurezza DNS aiutano le aziende a individuare le alterazioni dei record, le modifiche non autorizzate all’infrastruttura e le lacune di conformità nei propri domini pubblici.

La soluzione completa di monitoraggio della sicurezza DNS di PowerDMARC aiuta le aziende a individuare le modifiche ai record, i cambiamenti non autorizzati all’infrastruttura e le lacune di conformità nei propri domini pubblici. Questo monitoraggio proattivo garantisce che le vostre zone DNS autoritative rimangano protette da eventuali manomissioni, fornendo al contempo la visibilità approfondita necessaria per individuare abusi nascosti del protocollo.

Come prevenire il tunneling DNS

Rilevare il tunneling è fondamentale, ma i controlli proattivi dell’architettura di rete possono bloccare molti tentativi di tunneling prima che i dati escano dall’ambiente. I team di sicurezza dovrebbero implementare le seguenti misure di rafforzamento della sicurezza:

• Limitare il routing DNS in uscita: configurare i firewall perimetrali in modo da bloccare tutto il traffico UDP e TCP in uscita sulla porta 53 proveniente da endpoint standard. Solo i resolver DNS interni designati e protetti dovrebbero essere autorizzati a stabilire connessioni in uscita verso Internet.
• Limitare i protocolli DoH e DoT non approvati: gli autori delle minacce ricorrono sempre più spesso al tunneling DNS over HTTPS (DoH) o DNS over TLS (DoT) per nascondere le query all’interno del traffico web crittografato. Bloccare le connessioni in uscita verso indirizzi IP noti di resolver DoH/DoT pubblici e applicare politiche di proxy aziendali che impongano l’ispezione interna dei certificati.
• Implementazione del filtraggio DNS e dei feed di intelligence sulle minacce: integrare feed dinamici di intelligence sulle minacce nei resolver aziendali. Le liste di blocco ad alta reputazione respingono immediatamente le query dirette a domini associati a campagne di malware appena identificate, a provider DNS dinamici o a infrastrutture C2 attive.
• Implementare il sinkholing DNS: quando i resolver ricorsivi rilevano query relative a domini noti come dannosi, il sinkholing reindirizza la richiesta verso un indirizzo IP fittizio interno e non instradabile. Ciò neutralizza l'attacco e segnala immediatamente al personale addetto alla sicurezza la presenza di un host interno infetto.
• Applicare il principio del privilegio minimo sugli endpoint: gli script e le utility di tunneling dannosi richiedono privilegi di esecuzione locali per manipolare i socket di rete o eseguire servizi in background. Limitare i diritti amministrativi, applicare liste di applicazioni consentite ed eseguire moderni agenti di rilevamento e risposta sugli endpoint (EDR) impedisce fin dall’inizio l’esecuzione di codice dannoso.
• Adottare misure di igiene DNS complete: mantenere aggiornato tutto il software DNS con le patch relative alle vulnerabilità note ed effettuare regolarmente verifiche delle configurazioni seguendo le migliori pratiche di sicurezza DNS consolidate.

Il tunneling DNS rispetto ad altri attacchi DNS

Poiché il Domain Name System è vulnerabile a diversi livelli architetturali, i team di sicurezza spesso confondono il tunneling con altre forme di manipolazione del DNS. La tabella seguente evidenzia le differenze operative:

Per approfondire il tema delle minacce che interessano l'infrastruttura di risoluzione dei nomi, consulta la nostra guida sui vari tipi di attacchi DNS.

Domande frequenti

Il tunneling DNS è illegale?

Sì, l'utilizzo del tunneling DNS per sottrarre dati non autorizzati, diffondere malware o ottenere un accesso occulto a una rete aziendale senza autorizzazione esplicita è illegale e viola le leggi in materia di crimini informatici a livello globale, come il Computer Fraud and Abuse Act (CFAA) negli Stati Uniti.

Un firewall tradizionale è in grado di bloccare il tunneling DNS?

I firewall standard raramente bloccano il tunneling DNS da soli. Poiché i firewall standard verificano solo le regole relative a origine, destinazione e porta (consentendo il traffico UDP/TCP sulla porta 53), trattano le query di tunneling come normali ricerche di nomi. Per bloccare il tunneling sono necessari firewall di nuova generazione (NGFW), l’ispezione approfondita dei pacchetti (DPI) o servizi DNS protettivi dedicati che valutino l’entropia del payload, la frequenza delle query e la reputazione del dominio.

Il DNS over HTTPS (DoH) rende più difficile individuare il tunneling?

Sì. Il DNS over HTTPS crittografa le query e le risposte all’interno di sessioni TLS standard sulla porta 443, rendendo il traffico DNS indistinguibile dalla normale navigazione web crittografata tramite HTTPS. Quando un malware utilizza il DoH per raggiungere resolver pubblici esterni, i tradizionali strumenti di monitoraggio della rete non sono in grado di ispezionare i sottodomini o il contenuto del payload senza proxy di decrittografia TLS attivi. Ciò rende fondamentale bloccare le connessioni DoH in uscita dirette verso resolver pubblici non autorizzati.

Qual è la differenza tra tunneling DNS ed esfiltrazione DNS?

L'esfiltrazione DNS è un obiettivo specifico, mentre il tunneling DNS rappresenta il meccanismo di trasporto più ampio. L'esfiltrazione DNS si riferisce esclusivamente alla trasmissione in uscita e al furto di dati sensibili tramite query DNS. Al contrario, il tunneling DNS può essere anche bidirezionale, consentendo di stabilire shell interattive di comando e controllo, trasmettere comandi in entrata da parte degli operatori e instradare il traffico IP generico attraverso reti soggette a restrizioni.

Conclusioni e prossimi passi

Il DNS rimane un protocollo essenziale che le organizzazioni moderne non possono semplicemente disattivare. Purtroppo, la sua diffusione universale e il trattamento permissivo da parte dei firewall garantiscono che gli aggressori continuino a utilizzarlo come backdoor per sottrarre proprietà intellettuale sensibile e mantenere un accesso continuo. Per contrastare il tunneling DNS sono necessari una visibilità continua della rete, un solido filtraggio in uscita sulla porta 53 e un’ispezione automatizzata in grado di individuare in tempo reale comportamenti anomali nelle query.

La protezione della rete della vostra organizzazione inizia con la comprensione dello stato attuale della vostra superficie di attacco esterna. Oltre a monitorare i modelli delle query in uscita, le aziende devono assicurarsi che l’infrastruttura dei domini esposti al pubblico e i protocolli di autenticazione delle e-mail siano pienamente protetti contro lo spoofing, la manomissione non autorizzata dei record e le configurazioni errate. Utilizzate l’analizzatore di domini gratuito di PowerDMARC per verificare immediatamente lo stato di salute del vostro dominio, controllare la conformità SPF e DMARC e individuare le vulnerabilità di sicurezza prima che gli aggressori possano sfruttarle.