Server DNS Malevoli: DNS Server (T1583.002)

Trattandosi di una tecnica pre-compromise (TA0042), l'obiettivo in un ingaggio red team non è compromettere sistemi ma simulare in modo controllato l'allestimento di un canale DNS proprietario, dentro un laboratorio isolato e autorizzato.

Il punto di partenza è la registrazione di un dominio dedicato all'esercizio e la delega di un sottodominio verso una VM che ospita il proprio name server autoritativo. Strumenti maturi per costruire tunnel DNS includono iodine (open source), che crea un tunnel IP-over-DNS, e dnscat2 (open source), pensato specificamente per canali C2 cifrati su DNS. Un tipico avvio lato server di dnscat2 richiede l'indicazione del dominio delegato:

ruby dnscat2.rb

Lato client, sull'host di test, ci si aggancia al medesimo dominio per instaurare il canale. Con iodine il server si avvia assegnando una subnet privata al tunnel e specificando il dominio delegato, mentre il client vi si connette puntando al name server.

Per emulare risposte condizionali — comportamento citato tra le capacità di questi server — si può configurare un name server autoritativo standard come BIND9 (open source) o CoreDNS (open source) con viste (views) che restituiscono record diversi in base all'IP sorgente o al pattern della query. Questo replica la logica con cui un server malevolo risponde solo al proprio malware, restando silente verso i sistemi di analisi.

Per la parte di esfiltrazione via record TXT, tecnica associata a HEXANE, il framework DNSExfiltrator (open source) permette di trasferire dati incapsulandoli in query DNS, utile per misurare quanto il SOC riesca a rilevare volumi anomali.

Uno scenario avanzato è la simulazione adversary-in-the-middle DNS, avvicinabile all'operato di Sea Turtle: in laboratorio si può usare dnschef (open source), un proxy DNS che falsifica le risposte per reindirizzare un client verso servizi civetta e valutare la cattura di credenziali su un portale clonato.

Suggerimenti operativi di laboratorio:

• Isolare la rete di test per evitare che il tunnel raggiunga Internet in produzione.
• Registrare volumi, frequenze e lunghezze delle query per fornire al blue team un baseline realistico.
• Variare i tipi di record (TXT, A, CNAME, NULL) per testare più profili di detection.

L'obiettivo finale è misurare la capacità difensiva di intercettare traffico DNS anomalo, non l'infrastruttura in sé.

Poiché l'allestimento del server DNS avviene fuori dal perimetro, la detection efficace si concentra su ciò che il SOC può realmente osservare: l'utilizzo dell'infrastruttura durante le fasi di Command and Control ed esfiltrazione. La detection mappata (AN1994) lo dice esplicitamente, spostando l'attenzione sulle fasi correlate del ciclo d'attacco.

L'artefatto digitale centrale è il DNS Record e la Network Traffic associata alle query. Le principali sorgenti di log sono i DNS Query Logs dei resolver interni, i log del firewall e dei proxy, e su endpoint Windows l'EventCode 22 di Sysmon (DNS query), che correla il processo che genera la richiesta al dominio interrogato. Su ambienti Windows Server è utile abilitare l'Analytical logging del ruolo DNS.

Gli indicatori comportamentali da modellare sono diversi. Un volume anomalo di query verso un singolo dominio di secondo livello suggerisce tunneling; query con nomi host insolitamente lunghi ad alta entropia indicano dati codificati; l'uso ricorrente di record TXT o NULL verso destinazioni non note richiama il pattern di esfiltrazione osservato in HEXANE. Anche la periodicità regolare (beaconing) e un rapporto sbilanciato tra query uniche e risposte cacheable sono segnali forti.

Sul piano dell'ispirazione difensiva D3FEND, le contromisure rilevanti sono la DNS Traffic Analysis e la Network Traffic Analysis, che correlano frequenza, entropia e lunghezza dei sottodomini per distinguere il tunneling dal traffico legittimo. Sul fronte hardening rientrano DNSSEC e la restrizione dei resolver: forzare tutti gli endpoint a usare solo resolver aziendali (bloccando DNS in uscita diretto sulla porta 53 e il DoH non autorizzato) riduce drasticamente i canali disponibili all'attaccante.

Per l'implementazione pratica si possono usare Zeek (open source), che produce log DNS ricchi e permette script di scoring sull'entropia, e regole Suricata (open source) per pattern noti di tunneling. Le query su record TXT anomali si intercettano bene con logica di correlazione in SIEM.

Attenzione ai falsi positivi: molti servizi legittimi generano traffico DNS insolito. CDN, sistemi antispam che usano blocklist DNS, software antivirus con reputation cloud, e piattaforme di telemetria producono query lunghe o frequenti verso domini poco familiari. È essenziale costruire un baseline per dominio e processo prima di alzare alert, ed escludere esplicitamente i domini dei servizi cloud aziendali per evitare rumore ingestibile.

Per l'analista forense la sfida è che la predisposizione del server DNS malevolo non lascia tracce sui sistemi della vittima: gli artefatti utili emergono solo dopo il contatto con l'infrastruttura e da fonti esterne. L'indagine si struttura quindi su due binari paralleli.

Sul versante esterno, la ricostruzione dell'infrastruttura passa da WHOIS storico e passive DNS, che permettono di mappare quali IP hanno ospitato un dominio nel tempo e di individuare cluster di domini condivisi — approccio prezioso contro attori come Axiom, che ha acquisito servizi di dynamic DNS. I registri di Certificate Transparency, consultabili tramite il database di crt.sh, aiutano a scoprire domini lookalike usati per impersonificazione, pattern coerente con le operazioni adversary-in-the-middle DNS di Sea Turtle. Piattaforme come VirusTotal (freemium) e il passive DNS di servizi threat intel arricchiscono la timeline dell'infrastruttura.

Sul versante endpoint e rete, gli artefatti chiave ruotano attorno al DNS Record e ai processi che lo generano. Su Windows la cache DNS locale, ispezionabile con

ipconfig /displaydns

conserva risoluzioni recenti, mentre gli eventi EventCode 22 di Sysmon offrono la correlazione processo-dominio più affidabile per la timeline. I log del resolver aziendale e del firewall consentono di datare la prima e l'ultima query verso l'infrastruttura sospetta, definendo la finestra di attività C2.

Su Linux le tracce si cercano nei log di systemd-resolved o nei file di journald, oltre che nei log del resolver locale se configurato. La presenza di record TXT anomali nei log di query è un forte indicatore di esfiltrazione, riconducibile al modus operandi di HEXANE.

Una timeline forense ben costruita incrocia queste evidenze:

• Data di registrazione e delega del dominio (WHOIS/passive DNS).
• Prima risoluzione osservata lato resolver aziendale.
• Processo endpoint che ha generato le query (Sysmon EventCode 22).
• Volume e tipo di record nel tempo, per distinguere beaconing da esfiltrazione massiva.

Per l'analisi dei pcap è utile Wireshark (open source), che permette di isolare le query DNS e ricostruire i payload codificati nei sottodomini o nei record TXT. Zeek (open source) genera log DNS strutturati ideali per correlazioni retrospettive su grandi finestre temporali. L'obiettivo è provare la relazione tra l'infrastruttura esterna e l'attività interna, senza forzare artefatti inesistenti sulla fase di setup.

L'analisi dei server DNS gestiti dagli attaccanti offre spunti preziosi al threat intelligence officer, perché l'infrastruttura DNS tende a essere riutilizzata tra campagne e diventa un pivot per l'attribuzione. Nei dati disponibili emergono tre profili con approcci distinti ma complementari.

Axiom rappresenta l'uso pragmatico di servizi dynamic DNS acquisiti per colpire le vittime designate. Il dynamic DNS consente di cambiare rapidamente l'IP associato a un hostname, complicando il blocco basato su indicatori statici e allungando la vita operativa dell'infrastruttura. Per il TI officer questo significa privilegiare indicatori a livello di dominio e pattern, non singoli IP effimeri.

HEXANE mostra una capacità più artigianale e mirata: ha configurato server DNS custom per inviare comandi agli host compromessi tramite record TXT. Questo pattern — il TXT record come contenitore di comandi — è una firma comportamentale che, correlata alla telemetria di rete, permette di distinguere il gruppo dal rumore di fondo e di anticipare l'esfiltrazione basata su DNS.

Sea Turtle rappresenta il caso più sofisticato: ha costruito server DNS di tipo adversary-in-the-middle per impersonare servizi legittimi e catturare credenziali. Qui il DNS non è solo canale C2 ma strumento di redirection attiva, spostando le vittime verso repliche fraudolente. Questo eleva il DNS da infrastruttura di supporto a vettore primario di initial access, un salto qualitativo che merita attenzione strategica.

Il pattern comune ai tre attori è chiaro: il DNS viene scelto perché il suo traffico è quasi sempre consentito in uscita e raramente ispezionato in profondità. Le differenze riguardano invece l'obiettivo — controllo remoto silenzioso per Axiom e HEXANE, furto di credenziali su scala per Sea Turtle — e il grado di personalizzazione dell'infrastruttura, che va dai servizi commerciali di dynamic DNS ai name server interamente autogestiti.

Sul piano difensivo strategico, l'unica mitigazione mappata (M1056, Pre-compromise) sottolinea un limite strutturale: non esistono controlli preventivi interni efficaci contro un'attività che si svolge fuori dal perimetro. Il valore aggiunto del TI officer sta quindi nel monitoraggio proattivo dell'infrastruttura avversaria tramite passive DNS, tracking di domini lookalike e feed condivisi.

Il trend consolidato è l'adozione di DNS over HTTPS e resolver crittografati anche da parte degli attaccanti, che riducono ulteriormente la visibilità e spingono le difese verso analisi comportamentale e threat intelligence collaborativa piuttosto che blocco per indicatore.

MITRE ATT&CK: tecnica T1583.002 (DNS Server), tattica TA0042 (Resource Development); gruppi G0001 (Axiom), G1001 (HEXANE), G1041 (Sea Turtle); mitigazione M1056 (Pre-compromise); detection DET0862 e analitica AN1994. Tool di detection e analisi citati: Zeek, Suricata, Wireshark, Sysmon (EventCode 22). Parte dei comandi, tool e artefatti forensi deriva da conoscenza professionale di cybersecurity, nel rispetto delle regole su strumenti reali e verificabili.