DNS tunneling: una caccia basata su contesto e correlazioni

Una query DNS insolita è un punto di partenza. Per sostenere un’ipotesi di tunneling servono un’origine attribuibile, un comportamento ripetuto e una spiegazione alternativa verificata. La caccia deve produrre evidenze ripercorribili, non una lista di domini con punteggi opachi.

Definire l’ipotesi e il perimetro

MITRE ATT&CK descrive l’abuso di DNS per comunicazioni di comando e controllo in T1071.004. I dati possono essere inseriti nelle richieste o nelle risposte; record A e TXT sono possibili vettori. Il tipo TXT da solo non identifica un canale malevolo.

Per un primo esercizio, formulare questa ipotesi: un endpoint invia per ore sottodomini prevalentemente nuovi verso una stessa zona, con un pattern non spiegato dal software autorizzato. Specificare intervallo, segmento e gruppi di host prima di scegliere le soglie. Il confronto tra workstation e resolver ricorsivi sarebbe fuorviante.

Ricostruire la visibilità

Il dns.log di Zeek espone campi quali query, qtype_name, rcode_name, answers, uid e indirizzi della connessione. Il punto di cattura determina se l’origine osservata sia il client o il resolver. UID consente correlazioni con altri log della stessa connessione, non identifica un dispositivo nel tempo.

Preparare una mappa tra indirizzi e asset valida all’istante dell’evento. DHCP, NAT e resolver condivisi possono cambiare l’attribuzione. Se la cattura vede solo DNS tradizionale, non dedurre assenza di attività da un log vuoto: DoH e DoT richiedono telemetria del resolver, proxy o endpoint. Annotare questa lacuna nel risultato.

Una procedura di analisi riproducibile

1. Separare client, resolver e scanner; conservare timestamp e identificatori originali.
2. Aggregare per client e dominio registrabile usando una Public Suffix List mantenuta. Gli ultimi due label non bastano per tutte le zone.
3. Misurare query totali, sottodomini distinti, lunghezza dei label, errori e distribuzione temporale.
4. Confrontare lo stesso gruppo di asset e gli stessi orari su finestre successive.
5. Per ogni candidato recuperare risposte DNS, processo responsabile e connessioni successive.

Esempio di ispezione su log JSON già esportati; non è una regola di detection:

jq -r 'select(.query != null) | [.ts, .uid, .["id.orig_h"], .query, (.qtype_name // ""), (.rcode_name // "")] | @tsv' dns.log

Limiti e falsi positivi da mettere alla prova

In uno scenario di laboratorio, un agente di inventario può generare nomi contenenti identificatori variabili. CDN e sistemi antiabuso possono produrre richieste apparentemente casuali. Il controllo utile è individuare l’eseguibile, confermarne la funzione con il proprietario e verificare se il volume segue un’operazione nota.

Usare un’allowlist circoscritta a software, dominio e contesto, con data di revisione. Escludere un intero provider perché una query è stata spiegata nasconderebbe altri comportamenti. L’entropia resta una caratteristica statistica: non prova l’esfiltrazione e una bassa entropia non la esclude.

Mitigazione e criteri per escalare

Escalare quando più elementi convergono: origine inattesa, pattern persistente, processo non autorizzato o risposte compatibili con il canale ipotizzato. Conservare campioni e finestra temporale prima di un blocco. Il ticket dovrebbe riportare visibilità disponibile, spiegazioni escluse e livello di confidenza. Per i dati effettivamente trasferiti, distinguere ciò che si può dimostrare da ciò che rimane ipotesi.

Fonti essenziali

Riferimenti primari consultati il 3 ottobre 2026. Le procedure di analisi e gli scenari di laboratorio sono proposte editoriali: vanno adattati alla telemetria e alle versioni installate.

• MITRE ATT&CK — T1071.004
• Zeek — dns.log