MasterDnsVPN: la VPN che trasforma il DNS in un canale C2 invisibile

MasterDnsVPN non è un proof-of-concept da laboratorio. È un tunnel VPN completo che trasporta traffico TCP arbitrario dentro query e risposte DNS. Con 4.500 stelle su GitHub, più di 1.000 commit, binari precompilati per 20+ architetture tra cui MIPS, RISC-V e MikroTik RouterOS. 

Avevo già analizzato e letto articoli tecnici per l’utilizzo di query DNS legittime per incapsulare chunk di file allo scopo di esfiltrare dati in modo stealth. Tutte i report però convergevano sul fatto che la tecnica era poco “efficiente”.

Ho letto la documentazione di MasterDnsVPN e vale la pena capire come funziona tecnicamente, perché le implicazioni per chi difende le reti sono concrete.

Il protocollo: ARQ custom sopra DNS, con 5–7 byte di overhead

La prima cosa da capire è che MasterDnsVPN non è un wrapper thin sopra DNS. È un protocollo di trasporto affidabile progettato from scratch per vivere dentro il payload delle query DNS. Il traffico TCP da tunnelizzare viene cifrato, opzionalmente compresso, suddiviso in chunk e codificato come label di sottodominio nelle query DNS.

Una query tipo appare così al resolver: a7f3k9m2p1.v.example.com dove il prefisso è il chunk di payload. Il server risponde con dati codificati nel campo risposta.

La gestione dell’affidabilità è delegata a un meccanismo ARQ (Automatic Repeat reQuest) implementato interamente nel protocollo applicativo. Ogni stream ha la propria finestra ARQ indipendente. L’overhead di questo protocollo è 5–7 byte per pacchetto contro i 24-59 byte di tool analoghi quali DNSTT e SlipStream. Una differenza dell’88% non è un’ottimizzazione marginale, ridurre l’overhead significa quasi raddoppiare il payload utile per richiesta.

Ancora più interessanti i benchmark dichiarati sul repository: download di 10MB in 0,270 secondi contro 0,978s di SlipStream e 2,492s di DNSTT. Circa 9 volte più veloce di DNSTT.

Multi-resolver, bilanciamento e failover

L’architettura del client, non usa un resolver DNS come punto di uscita, ma altresì accetta una lista di resolver (IP singoli, range CIDR, con porta opzionale) e li gestisce con ben 8 strategie di bilanciamento distinte:

• Round Robin (0/2)
• Random (1)
• Least Loss (3)
• Lowest Latency (4)
• Hybrid Score — latenza e perdita pesate (5)
• Loss Then Latency — prima filtra per perdita, poi ordina il tutto per latenza (6)
• Least Loss Top Random e Top Round Robin (7/8) — si tratta di varianti che ruotano sul tier migliore

Per garantire le massime prestazioni ogni resolver passa attraverso una fase di MTU discovery automatica prima di essere usati. Se i parametri di MTU non raggiungono livelli minimi, il client scarta i resolver non utilizzabili e disabilita temporaneamente quelli “degradati” per poi riattivali in automatico durante la sessione.

Questo significa che bloccare un singolo resolver pubblico non risolve nulla. Il client è progettato esplicitamente per operare su pool di decine o centinaia di resolver interscambiabili.

MasterDnsVPN implementa anche la duplicazione dei pacchetti: lo stesso chunk viene inviato su più resolver in parallelo per aumentare la probabilità di consegna su reti con alto packet loss. Il “PACKET_DUPLICATION_COUNT” è configurabile separatamente per i pacchetti normali e per quelli critici di setup della sessione. Su reti stabili si disabilita; su reti degradate aumenta il volume ma garantisce la connessione.

Sessioni, cifratura e gestione delle chiavi

Il client MasterDnsVPN inizia con un handshake, il server risponde con un SESSION_ACCEPT dove vengono negoziati MTU, parametri ARQ ecc. Poi viene applicata la cifratura del traffico usando una chiave condivisa tra client e server (distribuita fuori banda, scritta in encrypt_key.txt al setup del server). Gli algoritmi di criptazione del traffico sono diversi, dal più “delle”leggero” XOR al più evoluto AES-256-GCM.

Con AES-256-GCM il contenuto è opaco a qualsiasi DPI passiva. Il traffico DNS risultante, non rivela nulla sul contenuto trasportato.

Setup infrastrutturale: DNS delegation e deployment

Lato server, la configurazione DNS richiede:

1. Un record A che punta il nameserver all’IP del server (ns.example.com → 1.2.3.4)
2. Un record NS che delega il sottodominio tunnel a quel nameserver (v.example.com → ns.example.com)

Da quel momento, qualsiasi query verso *.v.example.com viene instradata al server da qualsiasi resolver pubblico nel mondo, perché è la normale procedura di risoluzione DNS ricorsiva. I resolver pubblici diventano relay inconsapevoli.

La componente server di MasterDnsVPN si installa con un singolo script bash o via Docker. Ascolta su UDP/TCP 53; può girare anche in container su MikroTik RouterOS via port forwarding, rendendo potenzialmente un router di rete il punto di ingresso del tunnel.

Il client espone un proxy SOCKS5 locale (default 127.0.0.1:18000). Con LISTEN_IP = 0.0.0.0 diventa accessibile da tutta la rete locale. C’è anche un’opzione per esporre un resolver DNS locale che instrada le sue query verso l’esterno attraverso il tunnel — nascondendo anche il traffico DNS dell’host all’osservatore locale.

Perché è difficile da rilevare e da bloccare

Il problema per chi difende non è il contenuto del traffico, con cifratura AES-GCM quello è opaco. Il problema è che il canale si nasconde dentro un protocollo che non si può bloccare, ma deve essere attentamente monitorato.

Le anomalie esistono ma richiedono un’infrastruttura di analisi piuttosto evoluta:

• Pattern volumetrico per dominio: le sessioni tunnel producono molte query verso lo stesso dominio delegato in poco tempo, con sottodomini sempre diversi. Un SIEM con baseline DNS lo nota se il dominio non è in whitelist. La distribuzione multi-resolver complica la correlazione perché le query partono verso IP diversi.
• Alta entropia nelle label: i sottodomini codificati hanno distribuzione statistica diversa da quelli reali. Strumenti di DNS anomaly detection (PassiveDNS, Zeek con analisi di entropia) possono flaggare il pattern. Non è un rilevamento certo, ma è un segnale.
• Delega NS verso IP non noti: un dominio con record NS che punta a un IP residenziale o a un VPS sconosciuto è anomalo. Il monitoring della tabella di delega DNS è pratico solo con DNS recursion logging attivo.

Il repository menziona esplicitamente l’uso durante gli 88 giorni di blackout internet in Iran, dove le autorità avevano fisicamente staccato la banda internazionale. MasterDnsVPN ha funzionato perché i resolver DNS governativi locali hanno fatto da relay verso il nameserver esterno senza saperlo. I resolver non hanno visibilità sul fatto che stiano trasportando VPN traffic: si limitano a risolvere query che sembrano DNS valide.

Nei forum underground post e articoli tecnici che menzionano l’utilizzo del traffico DNS per l’esfiltrazione dei dati sono discussioni che più volte ho seguito; tuttavia la dimensione molto piccola dei chunk incapsulabili su una richiesta DNS era molto piccola e quindi richiedeva grandissime quantità di tempo per l’esfiltrazione di quantità di dati anche modeste.

MasterDNSVpn con l’88% in più di dati trasportabili per singola richiesta e la velocità di trasferimento 9 volte più superiore fa presagire con molta probabilità che questo tool entrerà nelle TTPs di qualche attore RaaS.

Il codice è Go, licenza MIT, binari precompilati per Windows/Linux/macOS/Android/MIPS/RISC-V. Non richiede software aggiuntivo. L’installazione del server è automatizzata. La community è su Telegram. Ci aspettiamo che tool di post-exploitation inizino a integrare questo vettore nei framework standard di C2 over DNS.

Fonti: Repository GitHub MasterDnsVPN

Luca Stivali

Cyber Security Enthusiast e imprenditore nel settore IT da 25 anni, esperto nella progettazione di reti e gestione di sistemi IT complessi. Passione per un approccio proattivo alla sicurezza informatica: capire come e da cosa proteggersi è fondamentale.

Aree di competenza: Cyber Threat Intelligence, Architectural Design, Divulgazione