Fast Flux DNS: Rotazione Rapida di Indirizzi IP (T1568.001)
Fast Flux DNS è una tecnica di Dynamic Resolution che rientra nella tattica TA0011 (Command and Control) del framework MITRE ATT&CK. L'attaccante nasconde il canale di comando dietro un insieme di indirizzi IP che ruotano con altissima frequenza, tutti risolti dallo stesso Fully Qualified Domain Name. Il trucco tecnico combina due elementi: un round-robin aggressivo sui record DNS di tipo A e valori di TTL molto bassi, tipicamente attorno ai 300 secondi, così che ogni cache locale scada in pochi minuti forzando una nuova query al resolver autoritativo.
Esistono due varianti principali. Il single-flux limita la rotazione ai record A, registrando e deregistrando IP in modo continuo. Il double-flux aggiunge la rotazione anche sui record NS del name server autoritativo, creando un doppio strato di proxy che rende molto più complessa l'identificazione del vero host C2. Nel double-flux i bot compromessi fungono da reverse proxy, isolando il backend reale.
L'impatto operativo è significativo per la difesa: le blocklist basate su IP diventano obsolete nel giro di minuti, le analisi di reputazione tramite passive DNS producono grafi enormi e la takedown richiede coordinamento con i registrar. La tecnica è impiegata da almeno 3 gruppi APT documentati e 3 famiglie malware, tra cui banking trojan e RAT usati sia da attori statali che criminali.
In un ingaggio red team la simulazione di Fast Flux DNS va condotta esclusivamente in ambiente di laboratorio isolato, poiché richiede la gestione di un name server autoritativo controllato e di più endpoint C2. L'obiettivo è validare che i controlli DNS del cliente identifichino pattern di rotazione anomali, non ospitare infrastruttura persistente su internet pubblico.
Il setup minimale prevede un dominio di test registrato tramite un registrar che consenta aggiornamenti API rapidi ai record A, e un name server autoritativo self-hosted. BIND (open source) o NSD (open source) permettono di configurare TTL bassi impostando la direttiva $TTL 60 nella zona e ruotando i record via nsupdate. Uno script Python con la libreria dnspython (open source) può automatizzare la rotazione, chiamando nsupdate ogni due minuti con IP presi da un pool di VM lab.
Per la componente offensiva controllata, framework come Cobalt Strike (a pagamento), Sliver (open source) o Mythic (open source) supportano listener HTTPS con host header configurabili, così il beacon può risolvere il dominio flux e connettersi al redirector attivo del momento. In Sliver si configura il listener con https --domain flux.lab.local --lport 443 e i redirector nginx sui nodi ruotati inoltrano al team server reale.
Per testare la resilienza del double-flux si può usare PowerDNS Authoritative (open source) come backend dinamico, popolato da un database MySQL aggiornato via script che modifica sia i record A del FQDN sia i record NS della zona. Questo espone al SOC un pattern in cui perfino i name server cambiano, replicando fedelmente il comportamento osservato in gh0st RAT e njRAT.
Sul lato client di lab, per generare traffico osservabile, uno script che esegue nslookup flux.lab.local ogni 60 secondi su Windows, oppure dig +short flux.lab.local su Linux, produce query DNS ripetute utili al blue team. In macOS l'equivalente è dscacheutil -q host -a name flux.lab.local, anche se il cache locale può interferire e richiede sudo killall -HUP mDNSResponder per essere svuotato.
Durante l'esercizio è utile misurare quanti IP unici vengono restituiti in finestre di 5 e 10 minuti e confrontarli con la baseline dei domini legittimi ad alta rotazione, come CDN e servizi cloud, per verificare la capacità di tuning delle regole di detection prima del debrief con il cliente.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo