Traffico Spazzatura nei Canali C2: Junk Data (T1001.001)

Simulare l'iniezione di junk data in laboratorio è fondamentale per validare la capacità del SOC di distinguere traffico C2 offuscato da traffico legittimo rumoroso. L'obiettivo non è semplicemente "aggiungere byte": è farlo in modo che le firme IDS esistenti falliscano, replicando i pattern documentati nelle campagne reali.

Il punto di partenza più diretto è Cobalt Strike (a pagamento), che permette di personalizzare i profili Malleable C2. All'interno di un profilo, i blocchi http-get e http-post accettano direttive come prepend e append per iniettare stringhe arbitrarie prima e dopo il payload codificato. Questo replica esattamente il comportamento documentato per SUNBURST, che aggiungeva junk bytes al traffico HTTP verso il C2, e per BeaverTail, che anteponeva caratteri dummy alle stringhe codificate.

Per chi preferisce un framework open source, Sliver (open source) offre la possibilità di configurare trasporti HTTP personalizzati. Attraverso il file di configurazione del profilo HTTP è possibile definire header aggiuntivi e padding nel body delle richieste, ottenendo un effetto simile.

Un approccio più granulare prevede l'uso di script Python con la libreria scapy (open source) per costruire pacchetti UDP con padding casuale, replicando il pattern di P2P ZeuS che aggiungeva junk data ai pacchetti UDP tra peer. Un esempio minimale:

*python3 -c "from scapy.all import ; send(IP(dst='')/UDP(dport=8443)/Raw(load=b'LEGIT_CMD' + os.urandom(64)))"

Per simulare il pattern di Downdelph — che inseriva caratteri pseudo-casuali tra ogni carattere originale — basta uno script che intercali byte random nella stringa di comando prima dell'invio:

python3 -c "import random,string; cmd='whoami'; print(''.join(c + random.choice(string.ascii_lowercase) for c in cmd))"

Il framework Caldera (open source) di MITRE consente di definire ability custom che implementano T1001.001, schedulandole in un adversary profile completo per testare l'intera catena di detection.

Durante l'esercizio, monitorate tre metriche chiave: quante sessioni C2 il NIDS ha intercettato, quanto tempo ha impiegato il SOC a correlare il traffico anomalo, e se le signature Suricata o Snort esistenti hanno generato almeno un alert. Se nessuna regola ha reagito, il test ha dimostrato esattamente il valore di questa tecnica per l'avversario.

Le firme statiche sono esattamente ciò che la tecnica Junk Data intende neutralizzare. Il difensore deve quindi spostare l'attenzione dalla corrispondenza di pattern alla profilazione comportamentale del traffico di rete, sfruttando metriche statistiche e correlazione tra log eterogenei.

Il pilastro della detection su Windows è la combinazione di Sysmon EventCode 3 (Network Connection) con dati di flusso NSM. Il principio operativo è identificare processi che generano connessioni outbound con un rapporto sproporzionato tra bytes inviati e ricevuti. Un implant che inietta junk data tende a produrre payload più voluminosi rispetto alla risposta del server C2. In Sysmon, correlate il campo Image con DestinationPort e DestinationIp per individuare binari inattesi che parlano con host non categorizzati.

Il parametro di tuning critico è la soglia di entropia Shannon del payload: il traffico HTTP legittimo ha un'entropia tipica tra 4.5 e 5.5, mentre payload con junk data intercalato tendono a superare 6.0. Tool come Zeek (open source) permettono di calcolare l'entropia per connessione tramite script personalizzati, e RITA (open source) esegue analisi di beaconing e anomalie sui log Zeek.

Su Linux, la detection si appoggia a auditd con regole sulle syscall connect e sendto, filtrate per processi non appartenenti alla whitelist dei servizi di rete legittimi. Il tuning del parametro DataRatioThreshold — il rapporto minimo tra byte inviati e ricevuti — è determinante: un valore iniziale di 3:1 cattura la maggior parte dei pattern C2 con padding, ma va calibrato sull'ambiente.

Per macOS, i log unificati (log stream) combinati con query osquery (open source) permettono di rilevare applicazioni mai viste prima che generano flussi outbound anomali. La tabella process_open_sockets di osquery, incrociata con i dati di flusso, fornisce visibilità sufficiente.

L'ambiente ESXi merita attenzione specifica: i demoni hostd e vpxa non dovrebbero mai generare traffico HTTPS verso destinazioni esterne al vCenter. Monitorate i log vmkernel e hostd per mismatch nei fingerprint TLS e per connessioni verso porte non standard.

Per la mitigazione attiva, Suricata (open source) e Snort (open source) in modalità IPS possono bloccare traffico che corrisponde a pattern noti di junk padding. Tuttavia, dato che ogni famiglia malware usa un proprio algoritmo di generazione junk, le regole vanno aggiornate continuamente. La mitigazione M1031 (Network Intrusion Prevention) è l'unica formalizzata: il filtraggio basato su signature di rete rimane un layer necessario, ma non sufficiente senza analisi comportamentale.

La sfida forense con la tecnica Junk Data è che i byte spazzatura esistono solo nel traffico di rete: una volta che la comunicazione C2 è conclusa, gli artefatti principali risiedono nelle catture di pacchetti e nei log, non sul disco. Questo rende la disponibilità di full packet capture (PCAP) un prerequisito quasi obbligatorio per un'analisi completa.

Partendo dalla cattura di rete, il primo passo è isolare i flussi sospetti con Wireshark (open source) o tshark (open source). Cercate sessioni TCP o UDP con payload ad alta entropia verso IP non categorizzati. Il comando:

tshark -r <file.pcap> -Y "ip.dst==" -T fields -e frame.time -e tcp.len -e data

permette di estrarre timestamp, dimensione e contenuto grezzo dei payload per ogni pacchetto verso una destinazione specifica. Se il rapporto tra dimensione del payload e contenuto decodificabile è anomalo, siete probabilmente davanti a junk padding.

Per malware che impiegano HTTP come trasporto — come GoldMax, che generava traffico decoy attorno alle comunicazioni reali, o Kevin, che produceva richieste HTTP fittizie — l'analisi dei log proxy e dei PCAP HTTP rivela pattern di richieste ritmiche verso URL non esistenti o con body inspiegabilmente voluminosi.

Sul lato endpoint Windows, gli artefatti da cercare nella timeline sono:

• Prefetch del binario sospetto, per stabilire la prima e l'ultima esecuzione
• Sysmon EventCode 3 storico (se Sysmon era attivo), per ricostruire le connessioni di rete del processo
• ETL traces di rete (netsh trace), se abilitati, che contengono metadata delle connessioni

Su Linux, i log auditd con le syscall connect, sendto e sendmsg forniscono il PID e il socket descriptor per ogni connessione outbound. Correlando il PID con i log di processo (/proc o journal), potete ricostruire quale binario ha originato il traffico con junk data.

Un artefatto particolarmente utile è il file DLL o binario stesso dell'implant. Nel caso di Mori, la DLL FML.dll era offuscata con 200 MB di dati spazzatura — un indicatore forense evidente: un file DLL legittimo raramente raggiunge dimensioni simili. L'analisi statica con PE-bear (open source) o DIE — Detect It Easy (open source) rivela immediatamente sezioni con entropia anomala e dimensioni incoerenti.

Per ricostruire l'algoritmo di junk removal — come quello usato da APT28, che assegnava a ogni implant un "junk length" univoco — è necessario il reverse engineering del sample con Ghidra (open source) o IDA Free (gratuito). Il parametro di lunghezza junk spesso risiede nella configurazione embedded dell'implant.

Il panorama degli attori che impiegano Junk Data è dominato da un unico gruppo APT formalmente attribuito, ma il numero di famiglie malware — 16 — racconta una storia più ampia: questa tecnica è un mattone fondamentale dell'ingegneria C2 moderna, trasversale a molteplici cluster di attività.

APT28 (alias Fancy Bear, Sofacy, gruppo associato al GRU russo) utilizza la tecnica in modo strutturale e sofisticato. Non si limita ad aggiungere byte casuali: ogni implant riceve un valore di "junk length" al momento della creazione, tracciato dal controller software. Questo significa che il server C2 sa esattamente quanti byte spazzatura rimuovere da ogni comunicazione, creando un protocollo custom per ogni impianto. Questo approccio impedisce l'analisi anche quando l'analista ha accesso al traffico in chiaro: senza conoscere l'algoritmo di rimozione e la lunghezza junk specifica dell'impianto, la decodifica non è banale.

Dal punto di vista delle famiglie malware, emergono tre pattern distinti di implementazione. Il primo è il padding a livello di trasporto: P2P ZeuS aggiunge junk ai pacchetti UDP, SUNBURST ai body HTTP, GrimAgent ai messaggi C2. È l'approccio più semplice e diffuso.

Il secondo pattern è l'interleaving di caratteri, più sofisticato: Downdelph inserisce caratteri pseudo-casuali tra ogni carattere originale, e Turian fa qualcosa di simile durante il setup della crittografia di rete. Uroburos aggiunge caratteri extra nelle stringhe codificate per mimare richieste DNS legittime — una combinazione di junk data e mimetismo protocollare.

Il terzo pattern è il traffico decoy: GoldMax genera traffico fittizio che circonda le comunicazioni reali, e Kevin produce sequenze di richieste HTTP dummy. Qui il junk non è dentro il singolo pacchetto, ma è l'intera sessione ad essere "rumore" progettato per mascherare il segnale.

La presenza di SUNBURST e TrailBlazer in questo elenco è significativa: entrambi sono associati a operazioni di supply chain di alto profilo. L'uso di junk data in operazioni di questa portata conferma che la tecnica non è un espediente rudimentale, ma un componente deliberato di toolchain sofisticate. BeaverTail, associato a campagne di social engineering nel settore tech, dimostra invece che anche operazioni con vettori iniziali diversi convergono sulle stesse necessità di offuscamento C2.

Per l'analista di intelligence, il valore operativo sta nel riconoscere l'implementazione specifica: un implant che usa interleaving piuttosto che padding racconta qualcosa sullo sviluppatore e sul cluster di appartenenza. La lunghezza del junk, l'algoritmo di generazione, e la posizione nel payload sono tutti indicatori utili per il clustering di campagne non ancora attribuite.

Framework MITRE ATT&CK v16 — Tecnica T1001.001 (Junk Data), Tattica TA0011, Mitigazione M1031, Gruppo G0007, Software S0016, S0022, S0134, S0435, S0514, S0559, S0574, S0588, S0626, S0632, S0647, S0682, S1020, S1047, S1164, S1246. Integrato con conoscenza professionale per tool e procedure operative.