Ricognizione DNS: DNS (T1590.002)

Sul piano operativo, la ricognizione DNS in un ingaggio red team parte sempre dalla mappatura dei record pubblici. Su Linux e macOS lo strumento di riferimento è dig: un'enumerazione ordinata prevede dig +short NS dominio.tld per i name server, dig MX dominio.tld per i mail exchanger e dig TXT dominio.tld per intercettare record SPF che rivelano provider SaaS in uso.

Il test più significativo è il tentativo di trasferimento di zona. Una volta individuato un name server, si prova:

dig AXFR dominio.tld @nameserver

Se il server è mal configurato, restituisce l'intera zona con tutti i sottodomini e host interni. È lo scenario descritto esplicitamente dalla tecnica e, quando funziona, fa risparmiare all'attaccante ore di enumerazione.

Su Windows lo stesso lavoro si fa con nslookup in modalità interattiva, impostando set type=mx o set type=ns e poi ls -d dominio.tld per tentare l'AXFR. Per esercizi lab-safe conviene però standardizzare su tool dedicati:

• dnsrecon (open source): automatizza enumerazione record, tentativi AXFR e brute force di sottodomini.
• dnsenum (open source): combina query standard, trasferimento di zona e ricerche Google.
• fierce (open source): scanner pensato per individuare host non contigui e spazi IP correlati.
• amass di OWASP (open source): correla passive DNS, certificati e fonti aperte per una mappa d'attacco completa.
• massdns (open source): risolutore ad alta velocità per validare grandi liste di sottodomini generate offline.

La catena tipica in laboratorio parte dalla raccolta passiva con amass in modalità intel e enum -passive, così da non generare traffico verso il bersaglio, prosegue con dnsrecon per i tentativi AXFR mirati e si chiude con un brute force di sottodomini validato da massdns su una wordlist come quelle del progetto SecLists.

Un ethical hacker maturo documenta ogni provider SaaS emerso dai record MX/TXT, perché ognuno rappresenta un potenziale punto di ingresso per campagne di phishing mirate o abuso di servizi di autenticazione federata. Tutte queste attività, essendo di pura ricognizione, vanno confinate al perimetro autorizzato dallo scope: le query passive non toccano la vittima, ma i tentativi AXFR e il brute force attivo sì, e devono rientrare nelle regole d'ingaggio concordate.

Difendere da questa tecnica è complesso perché gran parte dell'attività avviene fuori dalla visibilità dell'organizzazione. Le query passive verso archivi di terze parti non generano alcun log lato vittima, e le interrogazioni DNS lecite hanno un volume enorme con un tasso di falsi positivi altissimo. La detection AN1975 riconosce apertamente questa difficoltà e suggerisce di spostare l'attenzione sulle fasi successive del ciclo d'attacco, come l'Initial Access.

Esiste però un evento che il SOC può e deve intercettare direttamente: il trasferimento di zona (AXFR) verso un server autoritativo. A differenza delle query passive, l'AXFR colpisce l'infrastruttura dell'organizzazione e lascia traccia. Su BIND, con il query logging attivo, si osservano voci di tipo zone transfer o AXFR provenienti da indirizzi IP non autorizzati; su Windows DNS Server, l'Analytical log del canale Microsoft-Windows-DNSServer registra le richieste di trasferimento.

Le fonti di log prioritarie sono:

• I log del server DNS autoritativo (BIND query log, DNS Analytical log di Windows).
• I flussi di rete verso la porta 53 in TCP, dato che AXFR usa TCP e non UDP: un picco di connessioni TCP/53 verso i name server pubblici è un segnale forte.
• I log dei firewall perimetrali e dei resolver, per correlare origini anomale.

Una regola SIEM efficace, ad esempio in Splunk (freemium/a pagamento), correla richieste AXFR da IP esterni non presenti in una allowlist di server secondari validati. Il falso positivo tipico è il traffico legittimo tra primario e secondari o l'attività di servizi di monitoraggio DNS gestiti: per questo la allowlist è indispensabile.

Sul fronte della prevenzione, la mitigazione M1054 (Software Configuration) è chiara: applicare Zone Transfer Policies che limitino l'AXFR a un elenco di server esplicitamente autorizzati. In pratica significa configurare la direttiva allow-transfer su BIND o restringere i trasferimenti sul DNS di Windows ai soli server secondari noti. Vale inoltre ridurre la quantità di informazione esposta nei record pubblici, evitando naming interni descrittivi nei sottodomini e nei record TXT.

Poiché la ricognizione passiva resta invisibile, il valore aggiunto del SOC è il monitoraggio continuo di ciò che accade dopo: un'ondata di autenticazioni verso i provider SaaS rivelati dai record MX/SPF, o scansioni attive verso host emersi da un AXFR riuscito, sono i segnali che la ricognizione si è trasformata in un attacco concreto.

Dal punto di vista forense, la ricognizione DNS lascia pochissime tracce sull'endpoint, perché è un'attività che si consuma in gran parte su infrastrutture esterne alla vittima. L'analista deve quindi ragionare su fonti esterne e su artefatti che emergono solo nelle fasi successive dell'intrusione.

Le fonti di indagine più utili sono gli archivi che conservano la storia del DNS nel tempo. Il Passive DNS permette di ricostruire quali risoluzioni siano state osservate e quando, evidenziando sottodomini apparsi o scomparsi. Servizi come VirusTotal (freemium) e SecurityTrails (freemium) offrono cronologie di record DNS e WHOIS storico, utili per correlare l'infrastruttura del bersaglio con quella dell'attaccante. I log di Certificate Transparency, consultabili tramite il database di crt.sh (gratuito), rivelano sottodomini certificati che spesso coincidono con host interni esposti inavvertitamente.

Sul server DNS autoritativo dell'organizzazione, l'artefatto centrale è la registrazione di un eventuale trasferimento di zona. Su BIND, il query log conserva la traccia dell'operazione AXFR con timestamp e IP di origine; su Windows DNS Server l'Analytical log del provider Microsoft-Windows-DNSServer fornisce l'equivalente. Ricostruire la timeline significa individuare il momento dell'AXFR e collegarlo alle attività successive: scansioni attive verso gli host rivelati, tentativi di connessione ai servizi remoti, o campagne di phishing indirizzate ai domini di posta emersi dai record MX.

Gli artefatti digitali rilevanti in questa fase sono essenzialmente i DNS Record, il Domain Name e i Network Traffic verso la porta 53. Sull'endpoint, tracce indirette possono comparire solo dopo il contatto con l'infrastruttura malevola: nella cache DNS locale, interrogabile con ipconfig /displaydns su Windows, o nei log del resolver di sistema su Linux quando systemd-resolved è configurato per il logging. Non bisogna forzare la ricerca di artefatti endpoint che semplicemente non esistono per una tecnica di pura ricognizione.

L'approccio corretto è la correlazione: confrontare i sottodomini presenti negli archivi passive DNS e nei CT log con quelli effettivamente contattati durante l'incidente aiuta a stabilire quali informazioni l'attaccante possedeva già prima dell'accesso iniziale. Questo consente di distinguere ciò che è stato ricavato tramite ricognizione DNS da ciò che è stato scoperto successivamente, dando all'analista una misura di quanto il bersaglio fosse profilato in anticipo.

Per questa sotto-tecnica il set di dati MITRE ATT&CK fornito non associa alcun gruppo APT, alcun software né alcuna campagna documentata: le statistiche riportano 0 gruppi, 0 software e 0 campagne, a fronte di una sola mitigazione, M1054 (Software Configuration). Di conseguenza non è possibile, restando fedeli ai dati, tracciare profili di attori specifici, pattern geografici o sovrapposizioni di tooling attribuiti a questa tecnica.

Questa assenza non va interpretata come irrilevanza operativa, ma come una caratteristica intrinseca della fase di ricognizione (TA0043). La raccolta di informazioni DNS è così comune, silenziosa e priva di visibilità lato vittima che raramente viene attribuita in modo formale a un attore preciso. È un'attività preparatoria trasversale, condivisa da praticamente qualsiasi avversario strutturato prima di un'operazione, e proprio per questo difficile da collegare a una singola matrice di intrusione.

Per un Threat Intelligence Officer il valore di questa tecnica sta nel suo ruolo di abilitatore. Le informazioni ricavate dal DNS alimentano fasi successive ben più tracciabili: l'individuazione di provider SaaS tramite record MX e SPF indirizza campagne di phishing mirato e abuso di servizi di autenticazione federata; la scoperta di sottodomini e host tramite AXFR o brute force prepara l'Active Scanning e la selezione dei bersagli per l'External Remote Services in fase di accesso iniziale.

Sul piano dell'intelligence difensiva, il suggerimento è costruire correlazioni indirette. Poiché la ricognizione passiva non è osservabile, il monitoraggio dell'infrastruttura propria attraverso servizi di brand e attack surface monitoring permette di sapere quando i propri domini compaiono in archivi passive DNS o in log di Certificate Transparency, segnalando un possibile interesse esterno. L'analisi delle registrazioni di domini simili (typosquatting) rispetto ai propri asset è un altro indicatore anticipatorio: un attore che studia i record DNS di un'organizzazione spesso registra domini fraudolenti coerenti con l'infrastruttura osservata.

Il trend generale è chiaro: la ricognizione DNS resta un componente stabile e a basso costo del ciclo d'attacco, indipendente da mode tecnologiche. Per questo la strategia di intelligence più efficace non è inseguire l'attribuzione di questa singola tecnica, ma ridurre l'esposizione informativa a monte e vigilare sulle fasi a valle, dove gli attori diventano finalmente visibili e attribuibili.

MITRE ATT&CK: tecnica T1590.002 (DNS), tattica TA0043 (Reconnaissance), mitigazione M1054 (Software Configuration), detection DET0843 e analytic AN1975. Tool di ricognizione e detection citati: dig, nslookup, dnsrecon, dnsenum, fierce, OWASP amass, massdns, Splunk, VirusTotal, SecurityTrails, crt.sh. Per comandi, sintassi dei tool e procedure operative è stata utilizzata conoscenza professionale di cybersecurity verificabile tramite documentazione ufficiale e repository pubblici.