Proxy a Catena: Multi-hop Proxy (T1090.003)

La simulazione di un multi-hop proxy in laboratorio è fondamentale per validare le capacità di detection della propria organizzazione. L'obiettivo non è semplicemente "usare Tor", ma costruire catene realistiche che rispecchino le configurazioni osservate nelle campagne documentate.

Catena SOCKS con ProxyChains. Il tool ProxyChains-ng (open source) è il punto di partenza più immediato. Configura il file /etc/proxychains4.conf impostando la modalità dynamic_chain e inserendo almeno tre nodi SOCKS5 — possono essere VPS di laboratorio o istanze locali. Poi lancia qualsiasi binario attraverso la catena:

proxychains4 curl -s ifconfig.me

Il comando mostra l'IP dell'ultimo nodo, dimostrando l'offuscamento. Per simulare scenari più complessi, concatena nodi SSH con port forwarding multiplo. Il primo hop apre un tunnel locale:

ssh -D 1080 -f -N user@hop1

Il secondo hop si aggancia al primo tramite ProxyChains, creando un tunnel dentro il tunnel. Questo schema replica quanto osservato nella campagna CostaRicto (C0004), dove gli attori costruivano layer di proxy e tunnel SSH per gestire il C2.

Chisel per tunnel HTTP. Chisel (open source) è perfetto per simulare relay su porta 443 camuffati da traffico HTTPS. Sul nodo server:

chisel server --reverse --port 8443

Sul nodo client:

chisel client :8443 R:socks

Concatenando due o tre istanze Chisel, si ottiene un multi-hop che attraversa segmenti di rete diversi — scenario analogo al proxying osservato nelle ORB network della campagna FLORAHOX Activity (C0053).

Tor come C2 relay. Per replicare il comportamento di malware come WannaCry, Industroyer o GreyEnergy, configura un Tor hidden service sul sistema target che inoltra il traffico verso porte locali. Nel file torrc:

HiddenServiceDir /var/lib/tor/hidden_c2/
HiddenServicePort 443 127.0.0.1:4443

Questo schema ricorda la backdoor di APT29, che esponeva porte RDP (3389), NetBIOS (139) e SMB (445) attraverso hidden service Tor, garantendo accesso remoto completo dall'esterno.

FRP per relay su VPS. Il tool FRP — Fast Reverse Proxy (open source) — consente di configurare il client per connettersi al server attraverso un proxy intermedio, simulando scenari ORB. Configura il file frpc.toml specificando il server remoto e un proxy HTTP o SOCKS5 come hop intermedio. È particolarmente utile per replicare infrastrutture dove il traffico C2 transita da VPS commerciali prima di raggiungere l'operatore.

Per ogni esercizio, documenta gli artefatti generati — connessioni persistenti sulla porta 9050, query DNS verso domini .onion, binari non firmati che avviano connessioni SOCKS — perché saranno il materiale di validazione per le regole SOC.

La detection del multi-hop proxy richiede un approccio stratificato: non esiste un singolo evento che gridi "proxy chain in corso", ma una costellazione di segnali deboli che, correlati, producono alert ad alta confidenza.

Log source primari. Su Windows il riferimento è Sysmon con focus sugli EventCode 3 (Network Connection) e EventCode 1 (Process Create). Cerca processi che aprono connessioni persistenti verso porte note del circuito Tor — 9050, 9150 — o che generano traffico cifrato sostenuto verso IP classificati come nodi Tor o exit relay. Le query DNS verso domini .onion o resolver I2P sono un indicatore precoce e vanno monitorate tramite log DNS.

Su Linux, i log auditd con la syscall connect rivelano quando binari come tor, proxychains, chisel o daemon personalizzati iniziano sessioni verso nodi multipli in rapida successione. I flow di rete (NetFlow/IPFIX) sono essenziali per tracciare il pattern di chaining: un host che contatta più di due IP distinti in sequenza, senza risoluzione DNS corrispondente, rappresenta un'anomalia significativa.

Su macOS, monitora i LaunchAgent e LaunchDaemon che avviano processi con connessioni SOCKS. I log unificati macOS e query tramite osquery (open source) permettono di individuare binari non firmati che ascoltano sulle porte proxy locali.

Logica di correlazione. L'analytic AN1020 suggerisce tre assi di tuning particolarmente efficaci:

• DomainCategory: filtra query verso domini .onion, I2P o CDN sospetti che fungono da relay
• ProcessParent: distingui le catene di spawn legittime da quelle anomale — ad esempio, mshta.exe che avvia un client Tor è un red flag immediato
• ConnectionDuration: imposta soglie per connessioni persistenti oltre i 30 minuti su porte relay note

Per i dispositivi di rete, l'analytic AN1024 evidenzia un segnale spesso trascurato: il tunneling ICMP ad alta entropia. Pacchetti ICMP con payload cifrato che transitano tra router interni e IP esterni sconosciuti indicano possibile onion routing implementato a livello firmware — lo scenario descritto nella tecnica stessa.

Gestione dei falsi positivi. Sviluppatori, ricercatori di sicurezza e utenti con esigenze di privacy legittima generano traffico Tor e VPN che attiva le stesse regole. La whitelist per processo e per utente è indispensabile: mantieni una lista aggiornata di binari autorizzati e account con giustificazione documentata. Il filtraggio per range IP di VPS commerciali noti (come previsto dalla mitigazione M1037) riduce ulteriormente il rumore, ma va bilanciato perché il domain fronting può aggirare blocchi basati su IP.

Per l'ambiente ESXi, qualsiasi comunicazione cifrata originata dalla shell dell'hypervisor o da agent VM sconosciuti verso infrastrutture VPS merita indagine immediata — è uno scenario raro che non ha quasi mai giustificazione operativa legittima.

L'analisi forense di un multi-hop proxy si sviluppa su due piani: gli artefatti endpoint che testimoniano l'installazione e l'uso degli strumenti di proxying, e le tracce di rete che rivelano la catena dei nodi.

Artefatti Windows. Cerca nella directory utente e nelle cartelle temporanee i residui dell'installazione Tor: la struttura tipica include il binario tor.exe, il file di configurazione torrc e la directory Data/Tor contenente i file di stato del circuito. I log Sysmon con EventCode 1 registrano la creazione del processo, mentre gli EventCode 3 documentano le connessioni in uscita — porta 9050 per il proxy SOCKS locale e porta 9001/9030 verso i nodi relay. Il Prefetch di Windows (C:\Windows\Prefetch) conserva evidenza dell'esecuzione anche dopo la rimozione del binario.

Nel caso di APT29, l'artefatto chiave è la configurazione dell'hidden service Tor che inoltra traffico verso le porte 3389, 139 e 445 locali. Il file torrc con le direttive HiddenServicePort è la prova diretta dell'intento di accesso remoto completo. Analizza anche le chiavi crittografiche nella directory dell'hidden service — identificano univocamente il servizio e possono essere correlate con osservazioni da altre fonti.

Artefatti Linux. I log auditd con syscall connect e execve documentano l'avvio dei tool di proxy. Cerca nella cronologia della shell (~/.bash_history, ~/.zsh_history) comandi relativi a ProxyChains, Chisel, o configurazioni SSH con flag -D (dynamic forwarding). I file di configurazione /etc/proxychains4.conf o le configurazioni personalizzate in directory temporanee rivelano la topologia della catena — numero di hop, indirizzi dei nodi, tipo di proxy.

Per campagne come Operation Wocao (C0014), dove i comandi venivano eseguiti tramite web shell attraverso nodi exit Tor, la correlazione tra i log del web server (access log con IP di exit node Tor) e i comandi eseguiti sul sistema è fondamentale per ricostruire la timeline.

Artefatti di rete e infrastruttura. I flow NetFlow/IPFIX sono la fonte primaria per ricostruire la catena dei nodi. Cerca pattern di connessioni sequenziali: un host interno che contatta un primo IP, il quale a sua volta inoltra verso un secondo, e così via. Per le ORB network — come quelle documentate nelle campagne SPACEHOP Activity (C0052) e FLORAHOX Activity (C0053) — le connessioni transitano attraverso VPS commerciali e router SOHO compromessi; il WHOIS storico e il passive DNS dei nodi intermedi spesso rivelano hosting provider ricorrenti.

Sui dispositivi di rete compromessi, come nel caso della campagna RedPenguin (C0056) dove venivano installate versioni custom di backdoor TINYSHELL su router Juniper, l'analisi forense richiede l'estrazione e la comparazione dell'immagine firmware con quella originale del vendor. Le differenze rivelano il codice di routing aggiuntivo.

Per malware P2P come Uroburos o basati su blockchain come NKAbuse e NGLite, gli artefatti includono i database locali dei peer, le chiavi crittografiche di rete e i log di comunicazione con l'infrastruttura decentralizzata.

Il multi-hop proxy è trasversale a motivazioni e geografie diverse, ma emergono cluster di utilizzo ben definiti che permettono di profilare gli attori e anticipare le evoluzioni.

Il cluster cinese delle ORB network. ZIRCONIUM ha operato attraverso la rete FLORAHOX (C0053), un'infrastruttura ibrida che combina router SOHO compromessi, dispositivi IoT, VPS commerciali e nodi Tor personalizzati. Volt Typhoon utilizza multi-hop proxy per il C2, coerentemente con il suo profilo di pre-posizionamento su infrastrutture critiche. La campagna SPACEHOP Activity (C0052) ha documentato come le ORB network servano attori diversi — tra cui APT5 e Ke3chang — per scanning e exploitation, con target in Nord America, Europa e Medio Oriente. La campagna Quad7 Activity (C0055), nota anche come CovertNetwork-1658, illustra un modello operativo in espansione: una botnet di router SOHO compromessi (inizialmente TP-Link, poi Asus) usata come rete di IP di uscita per operazioni di password spray. Storm-0940 ha sfruttato le credenziali ottenute tramite Quad7 per colpire agenzie governative, ONG, studi legali e settore difesa. Questo schema suggerisce una convergenza: le ORB network cinesi stanno diventando infrastrutture condivise tra più gruppi, aumentando la difficoltà di attribuzione.

Il cluster russo e l'uso sistematico di Tor. APT28 instrada il traffico su Tor e server VPN. APT29 ha costruito hidden service Tor per esporre accesso RDP/SMB completo dall'esterno — un approccio sofisticato che trasforma Tor da semplice canale di anonimizzazione a infrastruttura di accesso remoto persistente. Gamaredon Group utilizza Tor per il C2 in modo più convenzionale, mentre Ember Bear configura catene ProxyChains all'interno degli ambienti vittima, muovendosi lateralmente attraverso proxy locali.

Operazioni finanziarie e mercenarie. FIN4 ha usato Tor per accedere agli account email delle vittime — un uso mirato all'esfiltrazione piuttosto che al C2 tradizionale. La campagna CostaRicto (C0004), attribuita a sospetti mercenari informatici, ha colpito istituzioni finanziarie in Sud Asia con reti complesse di proxy e tunnel SSH. La campagna Salesforce Data Exfiltration (C0059) mostra un'evoluzione: gli attori UNC6040/UNC6240 hanno usato IP Tor sia per le chiamate di vishing che per la raccolta dei dati rubati, combinando ingegneria sociale e anonimizzazione in un'unica catena operativa.

Pattern evolutivi. Leviathan e Inception rappresentano due varianti significative: il primo usa multi-hop proxy per mascherare il traffico, il secondo concatena router compromessi per il C2 verso cloud provider. La campagna RedPenguin (C0056) introduce il deployment di backdoor custom su router Juniper MX — un salto qualitativo che porta il multi-hop direttamente nell'infrastruttura di rete della vittima. Il trend è chiaro: dagli exit node Tor si passa a infrastrutture ORB condivise, e da queste all'abuso di protocolli blockchain (come documentato in NKAbuse e NGLite). La prossima frontiera probabile è la convergenza tra ORB network e protocolli decentralizzati, che renderebbe il takedown delle infrastrutture C2 ancora più complesso.

Framework MITRE ATT&CK: tecnica T1090.003, tattica TA0011. Campagne: C0004, C0014, C0052, C0053, C0055, C0056, C0059. Mitigazione M1037 (Filter Network Traffic). Analytic di detection: AN1020, AN1021, AN1022, AN1023, AN1024. Tool di detection: Sysmon, auditd, osquery, NetFlow/IPFIX. Integrato con conoscenza professionale per tool e procedure operative.