Compromissione Server DNS: DNS Server (T1584.002)

In un contesto red team, la simulazione di T1584.002 richiede estrema cautela perché la compromissione reale di server DNS di terze parti è illegale e fuori scope. L'obiettivo dell'esercizio è dimostrare l'impatto potenziale in un ambiente controllato, tipicamente un lab con BIND, PowerDNS o Unbound (tutti open source) che simulano il ruolo di authoritative server della vittima.

Una catena tipica in laboratorio parte dal reconnaissance dell'infrastruttura DNS del target. Strumenti come dnsrecon (open source), dnsenum (open source) e amass (open source) di OWASP permettono enumerazione dei name server autoritativi e dei record esistenti. Un comando base è amass enum -d dominio-target.tld -active per ottenere l'inventario dei sottodomini, mentre dig NS dominio-target.tld +short restituisce i name server delegati.

Una volta identificato il name server, in lab si simula l'accesso amministrativo (ad esempio via credenziali deboli sul pannello del registrar o SSH compromesso sul server BIND). Le azioni post-compromise includono modifica di record NS per delegare zone a resolver controllati e creazione di sottodomini shadow. Con BIND, l'aggiunta di record avviene editando il file di zona e ricaricando con rndc reload zona.tld, oppure via aggiornamento dinamico con nsupdate (incluso in bind-utils).

Per dimostrare l'impatto in combinazione con certificati validi, si può utilizzare Certbot (open source) di Let's Encrypt per emettere certificati sul dominio dirottato tramite challenge DNS-01, sfruttando il controllo appena ottenuto sui record TXT. Il flusso è certbot certonly --manual --preferred-challenges dns -d target-shadow.tld.

Una variante interessante riguarda il takeover di sottodomini abbandonati, scenario correlato ma tecnicamente distinto. Tool come subjack (open source) e subzy (open source) automatizzano il rilevamento di CNAME orfani puntati verso servizi cloud dismessi, dimostrando come un attaccante possa rivendicare risorse SaaS senza compromettere direttamente il DNS.

Durante l'engagement è fondamentale documentare tempistiche di propagazione, TTL manipolati e finestra di detection. La modifica di TTL a valori bassi (60 secondi) prima dell'attacco reale è un pattern operativo osservato in campagne reali come quella di Sea Turtle, dove i record NS venivano riscritti per far rispondere resolver controllati dagli attaccanti. Il red team deve simulare questa fase di preparazione per validare la capacità del blue team di individuare anomalie nei parametri DNS pubblici.

La detection di T1584.002 è intrinsecamente indiretta: la compromissione avviene su infrastruttura esterna e il SOC osserva solo le conseguenze. La strategia efficace combina monitoraggio continuo dei propri record DNS pubblici con correlazione verso fasi successive della kill chain.

Il primo livello di controllo riguarda l'integrità dei record autoritativi del proprio dominio. Un job schedulato che interroga periodicamente dig NS dominio.tld @8.8.8.8 e dig SOA dominio.tld da più vantage point geografici, confrontando i risultati con un baseline firmato, rileva modifiche non autorizzate a name server o serial number. Servizi come DNSPerf (freemium), RIPE Atlas (gratuito per membri) e Cisco Umbrella Investigate (a pagamento) offrono viste distribuite utili per identificare risoluzioni divergenti tra regioni, spia di DNS hijacking mirato.

Il secondo livello è la sorveglianza dei certificati emessi sul proprio dominio. Il monitoraggio dei log Certificate Transparency intercetta certificati anomali emessi da CA su sottodomini non autorizzati, spesso conseguenza diretta di controllo DNS ostile. Strumenti come certstream (open source) permettono l'ingestione real-time del feed CT, mentre servizi come crt.sh (gratuito) consentono query storiche. Un alert deve scattare per ogni certificato emesso su sottodomini non registrati nel CMDB.

Sul perimetro interno, il SOC monitora traffico DNS uscente verso resolver non autorizzati. Log Sysmon EventID 22 (DNS query) su endpoint Windows e query log di BIND o Unbound su resolver interni permettono di identificare risoluzioni verso domini appena comparsi (newly observed domains) o verso name server insoliti. La correlazione con feed di passive DNS come Farsight DNSDB (a pagamento) o Mnemonic PassiveDNS (freemium) arricchisce il contesto.

Sul fronte MITRE D3FEND, le contromisure rilevanti includono Domain Name Reputation Analysis, Certificate Analysis e Homoglyph Detection. L'artefatto digitale centrale è il DNS Record insieme al Certificate e al Domain Name.

Alert prioritari da configurare sul SIEM:

• Variazione non pianificata dei record NS, MX o SOA del proprio dominio
• Comparsa in Certificate Transparency di certificati per sottodomini non censiti
• Riduzione anomala del TTL sui propri record autoritativi
• Query DNS interne verso domini con age inferiore a 7 giorni

I falsi positivi principali derivano da migrazioni DNS legittime, attivazione di nuovi servizi cloud e rotazioni programmate di certificati wildcard. Un processo di change management ben integrato con la piattaforma di detection riduce drasticamente il rumore, consentendo di trattare ogni scostamento come evento ad alta priorità.

L'analisi forense di T1584.002 si sviluppa prevalentemente su fonti esterne all'endpoint, perché l'azione ostile avviene su infrastruttura DNS non gestita dalla vittima. La ricostruzione della timeline richiede quindi correlazione tra dati pubblici storici e artefatti endpoint che emergono nelle fasi successive di sfruttamento.

Il punto di partenza è il WHOIS storico del dominio compromesso o dei domini dirottati. Servizi come WhoisXML API (freemium), DomainTools Iris (a pagamento) e SecurityTrails (freemium) mantengono snapshot che permettono di individuare il momento esatto della modifica dei name server o del contact administrativo. La combinazione con passive DNS consente di ricostruire quali IP hanno risposto per un determinato hostname in ogni finestra temporale, elemento cruciale per stabilire quando il dirottamento è iniziato e quali utenti sono stati esposti.

I log di Certificate Transparency costituiscono un secondo pilastro. Interrogando crt.sh (gratuito) è possibile identificare certificati emessi durante il periodo di compromissione, in particolare da CA che utilizzano challenge DNS-01. Ogni certificato anomalo diventa un indicatore temporale preciso, perché la sua emissione dimostra controllo sul DNS in quel momento.

Sugli endpoint, gli artefatti utili emergono quando la vittima ha effettivamente contattato l'infrastruttura ostile. Su Windows sono rilevanti:

• Cache DNS locale ispezionabile con ipconfig /displaydns e log Microsoft-Windows-DNS-Client/Operational (EventID 3006, 3008)
• Eventi Sysmon EventID 22 che documentano query DNS con timestamp, PID e nome processo
• Artefatti browser (history, cache, cookie) che testimoniano visite a domini dirottati
• Certificati installati nello store utente o macchina, ispezionabili con certutil -store

Su sistemi Linux, il file /var/log/syslog o il journal di systemd contengono le query gestite da systemd-resolved, mentre /etc/resolv.conf e i log di eventuali resolver locali (dnsmasq, unbound) forniscono contesto sulla catena di risoluzione. Il file /var/log/auth.log può rivelare accessi anomali a server DNS interni compromessi come pivot.

Sul fronte MITRE D3FEND, gli artefatti digitali chiave da preservare sono DNS Record, Domain Name, Certificate e Network Traffic. La timeline forense deve incrociare timestamp WHOIS, emissioni CT, primi hit passive DNS verso IP ostili e prime query risolte dagli endpoint interni.

Nel caso della campagna condotta da Sea Turtle, l'analisi forense ha ricostruito modifiche ai record NS di zone target, con reindirizzamento verso resolver controllati dall'attaccante che rispondevano selettivamente. Per LAPSUS$, la riconfigurazione di record DNS verso siti controllati dal gruppo è stata utilizzata per defacement e coercizione delle vittime, lasciando tracce evidenti nei log CT e passive DNS.

Il panorama dei gruppi che sfruttano attivamente T1584.002 è ristretto ma significativo, perché la compromissione di infrastruttura DNS di terze parti richiede capacità tecniche non banali e produce impatto sproporzionato rispetto allo sforzo.

Sea Turtle (G1041) è l'attore più emblematico associato a questa tecnica. Il gruppo ha condotto operazioni di DNS hijacking su larga scala colpendo registrar, provider di servizi DNS e organizzazioni governative in Medio Oriente e Nord Africa. Il modus operandi documentato prevede la modifica di record Name Server (NS) delle zone target per delegare la risoluzione a server DNS controllati dagli attaccanti, che rispondevano a tutte le query di lookup con risposte manipolate. Questa manipolazione consentiva intercettazione di credenziali attraverso pagine di autenticazione clonate, protette da certificati validi ottenuti sfruttando il controllo DNS per superare le challenge di validazione. L'infrastruttura vittima includeva ministeri, agenzie di intelligence e provider di telecomunicazioni, con obiettivi coerenti con attività di spionaggio state-sponsored.

LAPSUS$ (G1004) rappresenta un profilo radicalmente diverso: gruppo di estorsione con motivazioni economiche e reputazionali, composto da attori giovani con base geografica in Sud America ed Europa. L'uso di T1584.002 da parte di LAPSUS$ è documentato in riconfigurazioni di record DNS delle vittime verso domini e siti web controllati dal gruppo, tipicamente per finalità di defacement pubblico durante negoziazioni di riscatto o per esporre dati sottratti. L'accesso ai pannelli DNS delle vittime avveniva generalmente attraverso credenziali sottratte con SIM swapping, social engineering di help desk e acquisto di accessi da insider, evidenziando una supply chain di intrusione basata più su compromissione umana che su exploit tecnici.

Il contrasto tra i due gruppi illustra due archetipi distinti nell'uso della stessa tecnica. Sea Turtle opera con obiettivi strategici a lungo termine, mantenendo persistenza silenziosa sull'infrastruttura DNS per raccogliere intelligence. LAPSUS$ utilizza la stessa capability in modo dirompente e visibile, come strumento di pressione e amplificazione del danno reputazionale.

Dal punto di vista dei trend, la compromissione DNS resta una tecnica ad alto rendimento per attori con capacità di penetrare registrar o provider intermedi. L'adozione crescente di DNSSEC, CAA record e monitoraggio Certificate Transparency ha aumentato il costo operativo per gli attaccanti, ma non ha eliminato la superficie di rischio, in particolare presso registrar di piccole dimensioni con controlli di autenticazione deboli.

Per i team di threat intelligence è essenziale mantenere feed aggiornati su compromissioni di registrar e provider DNS, correlare cambi improvvisi di name server con TTP note e monitorare forum underground dove vengono commercializzati accessi a pannelli di controllo DNS.

MITRE ATT&CK T1584.002 (DNS Server), tattica TA0042 (Resource Development), mitigazione M1056 (Pre-compromise), detection DET0891. Gruppi: G1004 (LAPSUS$), G1041 (Sea Turtle). Framework MITRE D3FEND per contromisure difensive e artefatti digitali. Il documento integra conoscenza professionale di cybersecurity per comandi operativi, tool di detection e procedure forensi, verificati su documentazione ufficiale dei rispettivi progetti.