Canali di Ripiego: Fallback Channels (T1008)
La tecnica Fallback Channels descrive la capacità degli attaccanti di predisporre canali di comunicazione alternativi per il Command and Control, da attivare quando il canale primario viene bloccato, compromesso o risulta inaccessibile. Rientra nella tattica TA0011 (Command and Control) e rappresenta un meccanismo di resilienza operativa: garantisce continuità del controllo remoto anche quando le difese di rete interrompono il flusso principale o quando l'esfiltrazione supera soglie di volume che rischiano di generare alert.
L'implementazione varia per sofisticazione. Alcuni malware si limitano a due domini hard-coded contattati in sequenza, altri gestiscono liste rotanti di dieci o più server, altri ancora cambiano protocollo (da HTTPS a DNS tunneling, da HTTP a ICMP) per aggirare filtri specifici. Alcuni attori sfruttano servizi legittimi come Steam, Twitter, GitHub o Google Search come canali secondari, sfruttando la difficoltà di bloccare piattaforme mainstream.
I numeri raccontano la centralità della tecnica: 47 famiglie di malware documentate la implementano, 5 gruppi APT la impiegano stabilmente, con la campagna Night Dragon che ne ha fatto uso operativo attraverso extranet aziendali riconvertiti a C2 secondari. L'impatto difensivo è significativo: un blocco reattivo del solo canale primario spesso non interrompe l'intrusione, e la detection richiede correlazione comportamentale su finestre temporali estese piuttosto che signature statiche.
In un esercizio red team, la simulazione di Fallback Channels consente di valutare la resilienza del monitoraggio di rete e la maturità delle procedure di containment. L'obiettivo non è aggirare un singolo controllo, ma verificare cosa accade quando il blue team blocca il canale primario: l'operazione prosegue silenziosamente o l'IR rileva la migrazione?
La piattaforma di riferimento per lo scenario è Mythic (open source), C2 framework modulare che supporta nativamente liste di URL di fallback per singolo payload. Nel profilo del payload è possibile definire più endpoint HTTP/HTTPS che il beacon prova in sequenza, con timeout configurabili. Un'alternativa consolidata è Sliver (open source), che tramite il comando generate --mtls host1,host2,host3 --http host4 --dns host5.example.com produce implant multi-protocollo capaci di degradare da mTLS a HTTP a DNS tunneling.
Per laboratori più realistici, Cobalt Strike (a pagamento) permette la definizione di Malleable C2 profiles con blocchi host_stage e http-config multipli, e supporta il DNS Beacon come canale secondario attivabile via comando mode dns dal teamserver. La progettazione dello scenario dovrebbe prevedere almeno tre livelli di degrado.
Sul lato Windows, la simulazione realistica richiede di generare traffico su porte non standard dopo il blocco del primario. Uno script PowerShell che tenti Test-NetConnection -ComputerName
Su Linux, la simulazione può includere fallback su ICMP tramite hans (open source) o icmptunnel (open source), coerenti con quanto documentato per Exaramel. Su ESXi, uno scenario avanzato prevede l'uso di interfacce di management come canale alternativo, riproducendo il pattern osservato per UNC3886: la connessione shell da un vmkernel port secondario simula la ridondanza di accesso su hypervisor.
La checklist operativa per l'esercizio dovrebbe includere: documentazione del tempo intercorso tra blocco primario e detection del secondario, verifica della capacità del SOC di correlare eventi di processi che cambiano protocollo, e test della procedura di full network isolation dell'host come contromisura definitiva.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo
2 minuti · 7 domande
Che professionista cyber sei?
Scopri il profilo più vicino al tuo modo di pensare e inizia dal percorso giusto.