Compromissione di Server DNS di Terze Parti: DNS Server (T1584.002)

La compromissione di un DNS server di terze parti non è un attacco che si simula con un singolo exploit: è un'operazione composita che parte dal ricognizione del registrar, prosegue con l'accesso al pannello di gestione DNS e culmina nella manipolazione dei record. In laboratorio, il modo più realistico per replicarla è costruire un ambiente con un server DNS autorevole (ad esempio BIND9 o PowerDNS) e un dominio di test.

Fase 1 — Ricognizione del bersaglio DNS. L'obiettivo è identificare chi gestisce i Name Server autoritativi di un dominio. Con dig si estrae la catena di delega:

dig NS dominio-target.lab +trace

Questo comando mostra l'intera catena di risoluzione, dai root server fino ai NS autoritativi. In un ingaggio reale, l'attaccante cerca NS ospitati presso provider con pannelli di gestione accessibili via web — punti d'ingresso ideali per credential stuffing o social engineering.

Fase 2 — Accesso al pannello di gestione. In laboratorio si può simulare compromettendo un'istanza locale di un DNS management panel. Tool come SpiderFoot (open source) permettono di enumerare le relazioni tra dominio, NS, registrar e contatti tecnici, identificando la superficie d'attacco. Recon-ng (open source) offre moduli specifici per raccogliere record WHOIS e dati di delega DNS tramite i suoi moduli della categoria recon/domains-hosts.

Fase 3 — Manipolazione dei record. Una volta ottenuto l'accesso, l'attaccante modifica i record per redirigere il traffico. In un lab con BIND9, la modifica diretta del file di zona illustra l'effetto:

nsupdate -k /path/to/chiave-tsig.key

All'interno della sessione interattiva, comandi come update add sottodominio.target.lab 300 A <IP-attaccante> dimostrano la creazione silenziosa di sottodomini malevoli. Con PowerDNS la stessa operazione si esegue tramite la sua API REST.

Fase 4 — Validazione dell'hijack. Per verificare che la redirezione funzioni, si interroga direttamente il NS compromesso:

dig @ns-compromesso.lab A sottodominio.target.lab

Per replicare lo scenario completo di Sea Turtle, si modifica il record NS del dominio target affinché punti a un server DNS sotto il proprio controllo. A quel punto, qualunque query per quel dominio transita attraverso il DNS dell'attaccante — una posizione di man-in-the-middle a livello di risoluzione nomi. Strumenti come dnschef (open source) consentono di creare un DNS proxy trasparente che risponde selettivamente a determinate query, ideale per simulare redirezione mirata senza interrompere la risoluzione legittima.

La detection diretta di questa tecnica è, per ammissione dello stesso framework, estremamente difficile: la compromissione avviene fuori dal perimetro aziendale. La strategia vincente è la detection indiretta, focalizzata sugli effetti osservabili quando l'infrastruttura DNS compromessa viene usata contro l'organizzazione.

Monitoraggio delle modifiche ai record DNS autoritativi. Il controllo più critico è il tracciamento continuo dei record NS, A, AAAA, MX e CNAME dei propri domini. Servizi di DNS monitoring come DomainTools (a pagamento) o SecurityTrails (freemium) possono generare alert quando un record cambia rispetto a una baseline nota. Un approccio più accessibile prevede uno script periodico che interroga i propri NS e confronta le risposte con un file di riferimento. Un cron job che esegue dig NS dominio-aziendale.com +short e compara l'output con il valore atteso è un controllo rudimentale ma efficace.

Log source critici. I resolver DNS interni sono la prima sorgente: un cambio di NS autoritativo per i domini aziendali deve generare un alert ad alta priorità. I log dei resolver, raccolti tramite Syslog verso il SIEM, vanno correlati con i flussi di rete: se il traffico verso un servizio aziendale inizia improvvisamente a transitare per un IP diverso dal solito, la combinazione di DNS anomalo e cambio di rotta IP è un indicatore forte.

Le piattaforme di Certificate Transparency rappresentano un altro canale di detection prezioso. Se un avversario sfrutta il controllo DNS per emettere certificati TLS fraudolenti per i domini aziendali, il certificato comparirà nei log CT. Strumenti come CertStream (open source) permettono di monitorare in tempo reale l'emissione di nuovi certificati e generare alert quando un certificato per un dominio aziendale viene emesso da una CA inattesa.

Gestione dei falsi positivi. Le migrazioni DNS pianificate, i cambi di provider hosting e i rinnovi di certificati sono le fonti principali di falsi positivi. La mitigazione è procedurale: ogni modifica DNS pianificata deve essere tracciata in un change management ticket e il SOC deve avere visibilità sul calendario delle modifiche infrastrutturali. L'implementazione di DNSSEC sui propri domini riduce drasticamente la superficie d'attacco, perché qualsiasi modifica non firmata con la chiave legittima verrebbe rifiutata dai resolver validanti. Come controllo preventivo, l'abilitazione di SPF, DKIM e DMARC protegge il canale email da abusi derivanti dal controllo DNS.

L'analisi forense di un DNS hijack presenta una sfida peculiare: gli artefatti primari non risiedono sugli endpoint dell'organizzazione, ma in fonti esterne e nei log di sistema che registrano gli effetti della redirezione. La ricostruzione della timeline si sviluppa su due assi paralleli — dati esterni e artefatti endpoint.

Fonti esterne: la memoria storica del DNS. I servizi di passive DNS come Farsight DNSDB (a pagamento), SecurityTrails (freemium) o la piattaforma VirusTotal (freemium) conservano snapshot storici delle risoluzioni DNS. Interrogandoli per il dominio compromesso, si ottiene la sequenza temporale delle modifiche ai record: quando il record NS è stato alterato, verso quale IP puntava, e quando è stato ripristinato. Questa è la spina dorsale della timeline.

I log di Certificate Transparency, consultabili tramite il servizio crt.sh (gratuito), mostrano se durante la finestra di compromissione sono stati emessi certificati TLS per il dominio bersaglio. La presenza di un certificato emesso da una CA diversa da quella abituale, in corrispondenza temporale con il cambio NS, è un artefatto estremamente significativo.

I record WHOIS storici, disponibili tramite DomainTools (a pagamento), completano il quadro mostrando eventuali modifiche ai contatti tecnici o ai nameserver registrati a livello di registrar.

Artefatti endpoint: le tracce post-contatto. Sulle workstation che hanno interagito con l'infrastruttura durante il periodo di hijack, la cache DNS locale è il primo artefatto da acquisire. Su Windows:

ipconfig /displaydns > cache_dns_export.txt

Questa esportazione, se effettuata tempestivamente, mostra le risoluzioni che la macchina ha ricevuto dal DNS compromesso — inclusi gli IP malevoli verso cui il traffico è stato rediretto.

I browser conservano anch'essi informazioni preziose. La cronologia di navigazione e il certificate store locale possono mostrare certificati TLS anomali che l'utente ha accettato durante la finestra di compromissione. Su sistemi Windows, l'Event Log con EventCode 36882 (Schannel) segnala errori o negoziazioni TLS insolite.

Per i sistemi Linux, il file /var/log/syslog o il journal di systemd possono contenere messaggi dal resolver locale. Se l'organizzazione utilizza un resolver caching come Unbound o dnsmasq, i relativi log registrano le risposte ricevute dai NS autoritativi.

La correlazione temporale tra il cambio NS documentato dal passive DNS e gli artefatti endpoint (cache DNS, log TLS, connessioni di rete verso IP anomali nei log firewall) costruisce la narrativa forense completa dell'incidente.

Due gruppi distinti hanno dimostrato la capacità e la volontà di compromettere server DNS di terze parti, ma con motivazioni e modus operandi profondamente diversi.

Sea Turtle (G1041) rappresenta il caso da manuale di DNS hijacking come operazione di intelligence. Il gruppo ha modificato i record NS dei bersagli in modo che puntassero a server DNS sotto il proprio controllo. Questa manovra — alterare non il singolo record A, ma l'intera delega NS — garantisce il controllo totale sulla risoluzione di tutti i sottodomini del bersaglio. È un approccio chirurgico che richiede accesso privilegiato al registrar o al pannello di gestione DNS, il che implica una catena d'attacco precedente (credential theft o compromissione del provider). Il profilo operativo suggerisce un attore con obiettivi di raccolta intelligence a lungo termine: il controllo della risoluzione DNS è la premessa per intercettazione email, furto di credenziali VPN e accesso a risorse cloud.

LAPSUS$ (G1004) ha utilizzato la riconfigurazione DNS con un approccio più diretto e rumoroso: redirigere i record DNS delle vittime verso domini e siti web controllati dal gruppo. Rispetto alla sofisticazione di Sea Turtle, LAPSUS$ ha tipicamente operato con un approccio più opportunistico, sfruttando credenziali ottenute tramite social engineering e insider threat piuttosto che catene di compromissione tecniche elaborate. La redirezione DNS nel loro caso serviva spesso a obiettivi di defacement, dimostrazione pubblica o accesso a servizi cloud.

Pattern analitici rilevanti. Il DNS hijacking come tecnica di Resource Development presenta un pattern geografico significativo: colpisce prevalentemente organizzazioni che si affidano a provider DNS o registrar con controlli di sicurezza deboli. L'assenza di DNSSEC, autenticazione multi-fattore sul pannello del registrar e monitoraggio delle modifiche ai record sono i fattori abilitanti comuni. Il threat intelligence officer dovrebbe tracciare attivamente le modifiche ai record NS dei domini di interesse tramite piattaforme come MISP (open source) integrate con feed di passive DNS.

La convergenza tra compromissione DNS e abuso di certificati digitali è un trend consolidato: il controllo del DNS consente di superare la validazione di dominio richiesta dalle CA per l'emissione di certificati, creando un circolo vizioso di legittimità apparente. Il monitoraggio dei log CT per i propri domini non è solo un controllo SOC, ma un indicatore di intelligence che segnala potenziali operazioni in corso.

Framework MITRE ATT&CK v16 — Tecnica T1584.002 (DNS Server), Tattica TA0042 (Resource Development), Mitigazione M1056, Gruppi G1041 e G1004. Tool di detection e monitoraggio: CertStream (open source), MISP (open source), SpiderFoot (open source), Recon-ng (open source), DomainTools (a pagamento), SecurityTrails (freemium), Farsight DNSDB (a pagamento), crt.sh (gratuito), VirusTotal (freemium). Integrato con conoscenza professionale per tool e procedure operative.