Canali C2 di Riserva: Fallback Channels (T1008)

Quando un impianto malevolo perde il contatto con il proprio server di comando e controllo, la partita non è finita: semplicemente cambia canale. La tecnica Fallback Channels descrive la capacità di un malware di passare a un meccanismo di comunicazione alternativo — un secondo dominio, un protocollo diverso, una porta di backup — nel momento in cui il canale primario viene bloccato, filtrato o reso irraggiungibile.

Inquadrata nella tattica Command and Control (TA0011), questa tecnica rappresenta un pilastro della resilienza offensiva. L'avversario progetta l'infrastruttura C2 con ridondanza fin dall'inizio: indirizzi IP multipli codificati nel binario, liste di domini da interrogare in sequenza, protocolli alternativi pronti a subentrare. Il risultato è un impianto che sopravvive al takedown parziale dell'infrastruttura e continua a operare anche quando il difensore crede di aver reciso la comunicazione.

I numeri parlano chiaro: 47 famiglie di software documentate implementano questa capacità, 5 gruppi APT noti la sfruttano attivamente, e almeno 1 campagna su larga scala ne ha fatto uso strategico. Il problema per i difensori è che il fallback, per design, si attiva proprio quando le contromisure funzionano — generando traffico su canali inattesi, spesso verso destinazioni mai osservate prima nella rete. Riconoscere questo pattern di "risveglio anomalo" è la chiave per trasformare un successo difensivo parziale in un contenimento completo.

L'obiettivo in un red team engagement è dimostrare che bloccare un singolo canale C2 non è sufficiente. La simulazione deve prevedere almeno due canali indipendenti — tipicamente HTTP/S come primario e DNS come fallback — per testare la capacità del blue team di rilevare il pivot.

Mythic (open source) è lo strumento ideale per questo scenario. Il framework C2 supporta nativamente profili di fallback: l'operatore definisce una lista di URL e, se il primo endpoint viene bloccato, l'agente scorre automaticamente verso il successivo. La configurazione avviene nel profilo dell'agente, specificando più callback host nel payload. In Mythic, durante la generazione del payload si possono inserire più indirizzi C2 separati da virgola nel campo dei callback hosts, così l'agente tenta ciascun indirizzo in sequenza quando il precedente fallisce.

Per un approccio più granulare, Cobalt Strike (a pagamento) permette di costruire Malleable C2 profiles con blocchi http-stager e dns-beacon separati. L'operatore configura il beacon per utilizzare HTTPS come canale primario e, in caso di fallimento dopo un numero definito di tentativi, passare a DNS. Il profilo Malleable consente di specificare nel blocco dns-beacon i parametri di comunicazione alternativa, inclusi i nameserver e i subdomain pattern.

Un test efficace prevede tre fasi operative. Prima si stabilisce il canale primario HTTP/S verso il C2 e si verifica la comunicazione. Poi il blue team blocca l'IP o il dominio primario a livello firewall. Infine si osserva se l'agente esegue il pivot sul canale secondario e si misura il tempo di failover — un parametro critico che il difensore deve conoscere.

Per la componente DNS tunneling come fallback, dnscat2 (open source) è un'opzione leggera. Sul server si avvia il listener con:

ruby dnscat2.rb --dns "domain=lab.example.local" --no-cache

Sul client si punta al dominio configurato. La bellezza di questo setup sta nel simulare esattamente il comportamento documentato per malware come quelli di OilRig e FIN7, che ricadono su DNS tunneling quando HTTP fallisce.

Per validare la detection, è utile generare traffico con Sliver (open source), altro framework C2 che supporta canali multipli (mTLS, WireGuard, HTTP, DNS) configurabili nello stesso impianto. L'operatore genera un beacon con più protocolli e verifica che il SOC rilevi il cambio di canale.

Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?

Scarica la guida gratuita e segui il percorso corretto fin dal primo passo