DNS Passivo: DNS/Passive DNS (T1596.001)

Trattandosi di una tecnica pre-compromise, l'obiettivo in un ingaggio red team è simulare la raccolta DNS in modo lab-safe, ricostruendo la superficie esterna del bersaglio senza generare rumore anomalo verso la sua infrastruttura.

Il punto di partenza classico sono le interrogazioni dirette ai name server. Su Linux e macOS dig NS dominio-bersaglio rivela i name server autoritativi, mentre dig ANY dominio-bersaglio e dig MX dominio-bersaglio espongono record generici e mail server. Il tentativo di trasferimento di zona — spesso l'errore di configurazione più fruttuoso — si prova con:

dig AXFR dominio-bersaglio @nameserver

Se il name server accetta la richiesta senza autenticazione, restituisce l'intera zona con tutti i sottodomini. Su Windows lo strumento nativo è nslookup in modalità interattiva, con set type=ns e ls -d dominio per tentare l'enumerazione.

Per l'enumerazione massiva di sottodomini si usano tool consolidati: dnsrecon (open source) automatizza AXFR, brute force e reverse lookup; Amass di OWASP (open source) correla passive DNS, certificati e sorgenti OSINT; subfinder (open source) di ProjectDiscovery è veloce nell'aggregare fonti passive. Un flusso tipico:

• amass enum -passive -d dominio-bersaglio per raccolta senza traffico diretto
• subfinder -d dominio-bersaglio -silent per un elenco pulito di host
• dnsrecon -d dominio-bersaglio -t axfr per verificare i trasferimenti di zona

La dimensione passiva vera e propria sfrutta gli archivi storici. I framework OSINT come Recon-ng (open source) e SpiderFoot (freemium) integrano moduli che interrogano provider di passive DNS e portali come VirusTotal e SecurityTrails (freemium) tramite API, restituendo record storici A, CNAME e MX senza mai contattare i name server della vittima.

Parallelamente, i log di Certificate Transparency — consultabili tramite crt.sh o l'apposito modulo di Amass — svelano spesso sottodomini che non compaiono nel DNS pubblico, perché emergono dai certificati TLS emessi.

In laboratorio conviene allestire una zona DNS BIND deliberatamente vulnerabile ad AXFR per verificare l'efficacia della detection, e correlare i risultati passivi con la mappatura della superficie esterna prima di passare a qualsiasi attività attiva sull'infrastruttura reale. La regola d'oro dell'ingaggio: prima tutto ciò che è passivo, poi — solo se autorizzato — le interrogazioni dirette.

Il paradosso difensivo di questa tecnica, riconosciuto anche dalla detection DET0877 (analitica AN2009), è che gran parte dell'attività avviene fuori dalla visibilità dell'organizzazione. Le interrogazioni verso archivi di passive DNS, i portali OSINT e i log di Certificate Transparency non toccano i sistemi aziendali, quindi non lasciano tracce nei log interni. Va inoltre considerato l'altissimo tasso di falsi positivi: il traffico DNS legittimo è massivo e scanner benigni, crawler e servizi di monitoraggio generano rumore costante.

La detection realistica si concentra quindi sulle interrogazioni dirette ai name server aziendali e sugli abusi rilevabili. Gli artefatti digitali chiave sono i DNS Record, il Domain Name e i Network Traffic verso i name server autoritativi. Le principali sorgenti di log sono:

• I log di query dei server DNS autoritativi (BIND query log, Windows DNS EventCode 256/257 con Analytical logging attivo)
• Il traffico di rete verso la porta 53 TCP, indicatore tipico di tentativi di trasferimento di zona
• I log dei firewall perimetrali e dei resolver ricorsivi

L'indicatore comportamentale più significativo è la richiesta AXFR verso un name server autoritativo proveniente da un IP non presente nella lista dei server secondari autorizzati. Un singolo evento di questo tipo merita un alert ad alta priorità, perché rappresenta un tentativo di esfiltrazione dell'intera zona. Altri segnali sono picchi di query verso sottodomini inesistenti (pattern di brute force) e un volume anomalo di reverse lookup PTR su interi blocchi di indirizzi.

Sul fronte dei controlli preventivi (Harden/Isolate), la difesa più efficace resta la corretta configurazione: limitare i trasferimenti di zona ai soli secondari autorizzati tramite direttiva allow-transfer, attivare DNSSEC per garantire l'integrità dei record ed evitare che il DNS interno (split-horizon mal configurato) esponga nomenclature di rete verso l'esterno. Sul piano organizzativo, la mitigazione M1056 raccomanda il monitoraggio proattivo della superficie esterna con piattaforme come Shodan e Censys (freemium) e la sorveglianza di domini lookalike tramite servizi come DomainTools (a pagamento).

Poiché la fase di ricognizione è difficilmente intercettabile, l'analitica AN2009 suggerisce esplicitamente di spostare l'attenzione sulle fasi successive: correlare eventuali interrogazioni sospette con i tentativi di accesso iniziale che seguono, così da riconoscere l'attaccante quando passa dalla raccolta all'azione sui servizi esposti individuati.

L'analisi forense di una ricognizione DNS presenta un limite strutturale: le consultazioni passive lasciano poche o nessuna traccia sull'endpoint della vittima. Per questo il lavoro dell'analista si sposta su fonti esterne e su artefatti che emergono solo dopo il primo contatto con l'infrastruttura malevola.

Le sorgenti esterne sono la spina dorsale dell'indagine retrospettiva. Gli archivi di passive DNS (SecurityTrails, VirusTotal, Farsight — tutti freemium/a pagamento) permettono di ricostruire lo storico dei record A, CNAME e MX di un dominio, evidenziando quali host erano risolvibili in un dato momento. Il WHOIS storico consente di datare cambi di registrar, name server e contatti, mentre i log di Certificate Transparency interrogabili tramite crt.sh (gratuito) rivelano sottodomini esposti da certificati TLS emessi in periodi precisi. La correlazione di queste fonti costruisce una timeline della superficie esterna così come l'attaccante l'ha potuta osservare.

Sul versante interno, gli artefatti digitali rilevanti sono i DNS Record interrogati e il Network Traffic verso i name server. Se il DNS aziendale ha il query logging attivo, i file di log — su BIND tipicamente in /var/log/named/ e su Windows nel canale DNS Server con EventCode 256 e 257 — vanno acquisiti e normalizzati in timeline. La ricerca si concentra su richieste AXFR/IXFR anomale, su burst di query verso host inesistenti e sugli indirizzi sorgente esterni ricorrenti. La porta 53 TCP nei log firewall è un marcatore forense di tentato trasferimento di zona.

Gli artefatti endpoint diventano utili solo nella fase post-contatto: cache DNS locale (ipconfig /displaydns su Windows), voci nel file hosts alterate, e connessioni verso gli host precedentemente individuati dall'attaccante. È qui che la ricognizione DNS si salda alle fasi di accesso iniziale, e la timeline esterna aiuta a spiegare perché l'attaccante conoscesse un preciso sottodominio o mail server.

Sul piano procedurale conviene preservare gli output delle query passive con timestamp e hash, perché gli archivi esterni cambiano nel tempo e il dato raccolto oggi potrebbe non essere riproducibile domani. Tool di aggregazione come Amass (open source), eseguito in modalità passiva, e theHarvester (open source) consolidano in un unico dataset record DNS, sottodomini e informazioni di registrazione, fornendo materiale strutturato per il report. In assenza di gruppi o campagne documentate associati a questa tecnica nei dati MITRE, l'attribuzione resta demandata alla correlazione con le fasi successive dell'intrusione.

I dati MITRE ATT&CK per la tecnica T1596.001 non riportano gruppi, software o campagne specificamente associati. Questo non significa che la raccolta di dati DNS sia rara — al contrario, è quasi ubiqua nelle fasi preparatorie — ma riflette la natura stessa della ricognizione passiva: avviene fuori dal perimetro della vittima, non genera artefatti attribuibili e raramente viene documentata come fase autonoma nei report di intrusione. Per un Threat Intelligence Officer questa è un'informazione operativa importante: l'assenza di attribuzione va comunicata al CISO come limite intrinseco della fase, non come lacuna del monitoraggio.

Il valore intelligence si sposta quindi dalla telemetria della vittima alla sorveglianza proattiva dell'infrastruttura avversaria. La mitigazione M1056 (Pre-compromise) indica esplicitamente questa direzione, raccomandando l'uso di piattaforme di threat intelligence per tracciare infrastruttura, strumenti e attività degli attaccanti. Piattaforme come MISP (open source), Recorded Future e Anomali (entrambe a pagamento) permettono di correlare indicatori DNS — domini lookalike, name server ricorrenti, pattern di registrazione — con cluster di attività note.

L'analisi di passive DNS è essa stessa uno strumento difensivo di controintelligence: monitorare gli archivi storici consente di individuare quando un dominio malevolo viene predisposto per colpire l'organizzazione, ad esempio riconoscendo domini typosquatting registrati poco prima di una campagna di phishing. Il monitoraggio dei domini simili tramite servizi come DomainTools o RiskIQ (a pagamento) rientra nella stessa logica preventiva.

Sul piano dei pattern osservabili, il ciclo tipico prevede che la ricognizione DNS preceda l'acquisizione o compromissione di infrastruttura e l'accesso iniziale tramite servizi remoti esposti o relazioni di fiducia. Un TI Officer dovrebbe quindi costruire ipotesi di correlazione: se un archivio di passive DNS mostra interrogazioni o registrazioni anomale attorno ai propri asset, è ragionevole anticipare tentativi successivi verso i mail server o i sottodomini individuati.

In sintesi, la produzione intelligence su questa tecnica si fonda sull'arricchimento della superficie esterna e sulla condivisione di indicatori infrastrutturali tramite feed e piattaforme collaborative, più che sull'attribuzione a un attore specifico. La raccomandazione strategica è ridurre al minimo l'esposizione di dati DNS sensibili — nomenclature interne, sottodomini di staging, record che rivelano fornitori tecnologici — perché ogni informazione esposta abbassa il costo di ricognizione per qualunque avversario.

MITRE ATT&CK: tecnica T1596.001 (DNS/Passive DNS), tattica TA0043 (Reconnaissance), mitigazione M1056 (Pre-compromise), detection DET0877 e analitica AN2009. Per comandi, tool di detection e procedure operative (dig, nslookup, dnsrecon, Amass, subfinder, Recon-ng, SpiderFoot, theHarvester, MISP, Shodan, Censys, crt.sh) è stata utilizzata conoscenza professionale di cybersecurity basata su documentazione ufficiale e repository pubblici dei rispettivi progetti.