Furto di Banda: Bandwidth Hijacking (T1496.002)

Per simulare T1496.002 in un esercizio red team autorizzato, l'approccio deve replicare i tre pattern principali: proxyjacking, partecipazione a botnet e scanning distribuito. Tutte le simulazioni vanno eseguite in ambiente segregato con esplicita autorizzazione scritta.

Sul fronte proxyjacking, esistono client legittimi di servizi commerciali che si possono installare in laboratorio per osservare il pattern di traffico generato: mantengono connessioni TLS persistenti verso pool di control server e instradano richieste HTTP/SOCKS provenienti da terzi. Per emulare il comportamento senza aderire a un servizio reale, è possibile deployare 3proxy (open source) o microsocks (open source) su un host vittima simulato e generare traffico proxy verso di esso da un secondo host, misurando l'aumento del volume egress.

Per la componente scanning distribuito, tool come masscan (open source) e zmap (open source) permettono di generare traffico SYN a rate elevatissimi. Un esempio operativo in ambiente lab su Linux:

masscan -p80,443 10.0.0.0/8 --rate 10000 -oX scan.xml

Questo comando emette pacchetti SYN a 10.000 pps verso il blocco privato, replicando il pattern di banda che un attore userebbe su Internet pubblico. Su Windows, l'equivalente si ottiene con nmap (open source) usando -T5 e liste target ampie, sebbene con rate inferiori.

Per emulare botnet DDoS, framework didattici come Byob (open source, solo per scopi educativi) permettono di orchestrare nodi in laboratorio e osservare la generazione di traffico UDP flood o HTTP flood. Su ESXi compromessi, uno scenario realistico prevede l'esecuzione di container o VM leggere con client proxyware: l'ipervisore diventa un moltiplicatore di banda, e la telemetria di esxtop mostra saturazione delle vNIC.

Sul versante macOS, il proof-of-concept prevede l'installazione di un binario non firmato che apre socket persistenti verso endpoint remoti. Un semplice nc -l (open source, incluso nel sistema) in modalità listener combinato con iperf3 (open source) come generatore di carico permette di misurare il throughput sostenibile.

In container, il pattern realistico è il deploy di un'immagine apparentemente innocua che in realtà avvia un client proxy. La verifica si fa con docker stats (open source) osservando le colonne NET I/O crescere in modo anomalo rispetto alla funzione dichiarata del container. L'esercizio deve documentare baseline di traffico pre-infezione e delta post-infezione, fornendo al blue team materiale di detection tuning.

La detection di Bandwidth Hijacking si fonda su analisi comportamentale del traffico piuttosto che su signature statiche, perché i tool coinvolti sono spesso legittimi o polimorfi. La rilevazione DET0028 fornisce quattro analitiche per piattaforma che vanno adattate al contesto.

Su Windows (analitica AN0080), la telemetria chiave arriva da Sysmon (open source) con configurazione che includa gli EventID 3 (network connection) e EventID 22 (DNS query). L'indicatore forte è un processo che invoca figli network-intensive o carica grandi volumi in sessioni TCP/UDP long-lived verso destinazioni inusuali. La query in SIEM va costruita aggregando bytes_out per process_name su finestre di 5-15 minuti, con soglia dinamica basata sul baseline dell'host. Falsi positivi tipici: tool di backup (Veeam, Duplicati), client di sincronizzazione cloud, aggiornamenti Windows Update — questi processi vanno esclusi via allowlist esplicita.

Su Linux (AN0081), le fonti sono auditd per gli eventi SYSCALL (in particolare connect, sendto, sendmsg) e la telemetria NSM di flusso (Zeek open source, Suricata open source). I pattern da cercare includono esecuzioni di curl, wget, masscan, proxychains o 3proxy con traffico sostenuto verso porte non standard, spesso fuori orario lavorativo. Il tuning richiede soglie di traffic rate specifiche per ambiente e liste di tool pattern aggiornate.

Su macOS (AN0082), il unified logging permette di correlare processi non firmati Apple con socket aperti a lungo termine. L'indicatore di alta confidenza è un binario senza firma o con firma developer sconosciuta che mantiene throughput superiore a soglie di MB/s per periodi prolungati. La combinazione firma-throughput-durata riduce sensibilmente il rumore.

Su container (AN0083), osquery (open source) e docker stats (open source) forniscono metriche di interfaccia. L'indicatore è l'aumento improvviso di NET I/O in container dormienti o a bassa utilizzazione tipica. Immagini pull da registry pubblici non ufficiali meritano scrutinio aggiuntivo.

In IaaS (AN0084), AWS CloudTrail e VPC Flow Logs (a pagamento, inclusi nel servizio AWS) permettono di rilevare istanze con egress sostenuto verso endpoint TOR, VPN commerciali o range noti di proxyware. Cross-correlare con eventi IAM anomali (creazione di ruoli, chiavi di accesso nuove) e con cron job che invocano client proxy aumenta la confidenza. Le soglie vanno tarate sui billing alert del provider: spesso è l'anomalia di costo a innescare l'indagine.

Dal punto di vista D3FEND, i controlli difensivi rilevanti includono Network Traffic Analysis, Outbound Traffic Filtering e Process Analysis, tutti mappati agli artefatti Network Traffic e Process.

L'analisi forense di T1496.002 ricostruisce la timeline di installazione del client abusivo, il pattern di traffico generato e l'eventuale monetizzazione. Gli artefatti variano per piattaforma ma condividono il focus su persistenza di rete.

Su Windows, i punti di partenza sono i log Sysmon EventID 1 (process creation) per identificare il binario iniziale, EventID 3 per le connessioni sostenute e EventID 13 per modifiche registry di persistenza. Le chiavi HKLM\Software\Microsoft\Windows\CurrentVersion\Run e HKCU\...\Run, insieme ai Scheduled Tasks in C:\Windows\System32\Tasks, spesso ospitano l'entry di autostart del client proxyware. Il Prefetch in C:\Windows\Prefetch fornisce timestamp di prima esecuzione. Le ShimCache e AmCache.hve confermano l'esecuzione anche se il binario è stato rimosso. L'analisi di NetworkUsage nel database SRUM (C:\Windows\System32\sru\SRUDB.dat) è particolarmente preziosa perché fornisce contabilità storica di byte per processo, permettendo di quantificare l'abuso retroattivamente. Tool come srum-dump (open source) estraggono i dati in formato analizzabile.

Su Linux, la timeline si costruisce da auditd log in /var/log/audit/audit.log correlati con journalctl. I file di persistenza da esaminare includono unit systemd in /etc/systemd/system/, cron entries in /etc/cron./* e /var/spool/cron/, e file rc.local legacy. La bash history dell'utente compromesso (~/.bash_history) spesso rivela il download iniziale via curl o wget. /proc/net/tcp e /proc/net/udp al momento del triage mostrano socket attivi; ss -tunap (open source, incluso) fornisce mapping processo-connessione. Il file system timeline con fls e mactime di The Sleuth Kit (open source) permette di ricostruire la sequenza di creazione dei binari.

Su macOS, gli artefatti chiave sono i LaunchAgents e LaunchDaemons in /Library/LaunchAgents/, /Library/LaunchDaemons/ e nelle equivalenti user directory. Il unified log interrogato con log show --predicate filtra eventi di rete per processo. Gli attributi estesi com.apple.quarantine rivelano l'origine di download del binario. Il database TCC.db mostra permessi concessi al processo abusivo.

In ambienti container, gli artefatti sono le immagini pull (docker history), i log container (docker logs), e la configurazione dei volumi che potrebbero contenere binari persistenti. Per IaaS, CloudTrail fornisce la timeline API di deployment dell'istanza compromessa, mentre VPC Flow Logs quantificano l'egress. Cross-referenziare con billing detail permette di stimare l'impatto economico.

La correlazione finale unisce: timestamp installazione (Prefetch/Amcache/journalctl), pattern traffico (SRUM/Flow Logs) e persistenza (Run keys/systemd/LaunchAgents) in una timeline coesa per il report.

I dati MITRE ATT&CK per T1496.002 - Bandwidth Hijacking non riportano gruppi APT, software specifici né campagne formalmente attribuite. Questa assenza non riflette una mancanza di attività nel panorama reale, ma piuttosto la natura opportunistica e commercialmente motivata della tecnica, che ricade prevalentemente in ecosistemi cybercriminali piuttosto che in operazioni di espionage state-sponsored tipicamente tracciate nel framework.

Dal punto di vista di threat modeling, il Bandwidth Hijacking si colloca all'intersezione tra tre economie criminali distinte. La prima è quella del proxyware residenziale, dove operatori vendono banda residenziale a mercati grigi usata per bypass di geoblocking, credential stuffing e scraping. La seconda è l'economia botnet-as-a-service, dove operatori affittano capacità DDoS a clienti terzi. La terza è quella dei crypto-mining bandwidth-adjacent, dove la banda serve non per mining diretto (che è coperto da T1496.001) ma per coordinamento pool e propagazione.

In assenza di attribuzioni formali, l'analista TI dovrebbe monitorare pattern piuttosto che attori. Gli indicatori strategici includono: aumento di offerte proxyware su forum underground, pubblicazione di nuovi client proxyware con schemi di referral aggressivi, e picchi di infezioni tramite software supply chain compromessa (npm, PyPI) che nasconde funzionalità di bandwidth sharing. Casi noti nella threat intelligence pubblica hanno documentato pacchetti npm malevoli che installavano silenziosamente client proxyware nei sistemi build dei developer.

Sul piano geografico, il pattern osservato nel settore è che gli IP residenziali di paesi occidentali (Stati Uniti, Regno Unito, Germania) hanno valore di mercato più alto perché aggirano geo-restrictions e reputazione IP. Gli attori target quindi in modo sproporzionato sistemi consumer e SMB in queste regioni. In parallelo, gli ambienti IaaS mal configurati — istanze cloud esposte con credenziali deboli o SSRF sfruttabile — sono target preferenziali per proxyjacking a causa della banda elevata e della fatturazione a consumo che viene scaricata sulla vittima.

Dal punto di vista dei trend, si osserva convergenza tra operatori ransomware e proxyjacking: alcuni loader di prima fase includono ora moduli di monetizzazione secondaria via proxyware, monetizzando anche vittime che non pagano il ransom o durante la fase di ricognizione. Questo ibrido richiede detection layered che consideri non solo l'obiettivo primario dell'intrusion ma anche indicatori di monetizzazione parallela.

Per un CISO, la raccomandazione strategica è includere metriche di traffico egress e billing anomaly detection nel dashboard di sicurezza, trattando picchi inspiegati come indicatori di compromissione al pari di alert EDR classici.

MITRE ATT&CK: T1496.002 (Bandwidth Hijacking), tattica TA0040 (Impact). MITRE D3FEND: mapping Network Traffic Analysis e Outbound Traffic Filtering. Detection strategy DET0028 con analitiche AN0080-AN0084 per Windows, Linux, macOS, Containers e IaaS. Tool citati verificati su repository pubblici: Sysmon, Zeek, Suricata, osquery, masscan, zmap, nmap, 3proxy, microsocks, The Sleuth Kit, srum-dump, iperf3. Alcune procedure operative derivano da conoscenza professionale consolidata in ambito DFIR e red team.