Proxy Multi-hop: Multi-hop Proxy (T1090.003)
La tecnica T1090.003 — Multi-hop Proxy rientra nella tattica TA0011 (Command and Control) e descrive l'incatenamento di più proxy per mascherare la vera origine del traffico malevolo. L'idea è semplice ma efficace: il difensore riesce a identificare l'ultimo hop che tocca il perimetro, ma risalire ai nodi precedenti diventa un lavoro forense complesso, spesso impossibile senza cooperazione internazionale.
Le implementazioni osservate spaziano dall'uso di reti pubbliche di onion routing come Tor, all'adozione di infrastrutture ORB (Operational Relay Box) composte da VPS, dispositivi IoT, router SOHO end-of-life e smart device compromessi. In scenari più sofisticati gli attori impiantano codice custom su apparati di rete tramite tecniche di Patch System Image, realizzando onion routing tra router compromessi che sfruttano protocolli come ICMP come canale di trasporto. Un filone più recente riguarda l'abuso di reti peer-to-peer e blockchain — come NKN — per implementare un routing decentralizzato non riconducibile a server C2 statici.
I dati MITRE registrano 11 gruppi APT, 20 famiglie di malware e 7 campagne documentate che sfruttano questa tecnica, con una singola mitigazione formale (M1037 — Filter Network Traffic). La distribuzione geografica delle campagne copre Nord America, Europa, Medio Oriente e Asia meridionale, con una prevalenza di attori nexus-cinese e russo.
In un contesto red team autorizzato la simulazione di T1090.003 parte quasi sempre da ProxyChains (open source), citato esplicitamente nell'uso di Ember Bear. La configurazione tipica in /etc/proxychains4.conf alterna modalità strict_chain e dynamic_chain con una lista di SOCKS5 endpoint; l'esecuzione avviene poi con proxychains4 nmap -sT -Pn -n target. Su ambienti Linux compromessi in laboratorio, questa catena permette di validare quanto un SOC riesca a correlare il traffico in uscita quando la sorgente reale è offuscata da tre o più hop.
Per emulare l'uso di Tor — adottato da APT28, APT29, Gamaredon, Medusa e da malware come Uroburos, WannaCry, Ursnif, Attor — si installa il pacchetto Tor (open source) e si espone un servizio SOCKS locale su porta 9050. Un hidden service che rimappa RDP interno (come fatto da APT29) si costruisce con poche righe nel torrc: direttiva HiddenServiceDir e HiddenServicePort 3389 127.0.0.1:3389. Verificare la propagazione con curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org (comando standard documentato).
Per scenari che replicano il pivoting su reti interne tramite tunnel reverse — pattern osservato in Lotus Blossom con HTran e nelle simulazioni con FRP (Fast Reverse Proxy, open source) — si configura un frps su VPS controllata e un frpc sull'host compromesso, esponendo servizi interni attraverso NAT. Un'alternativa moderna è Chisel (open source), che tunnela TCP/UDP su WebSocket HTTPS e regge bene contro DPI base: chisel client
Per la parte più avanzata — emulazione di canali basati su blockchain in stile NGLite o NKAbuse — non esistono tool red team maturi pubblici; l'approccio consigliato è scrivere un PoC in Go usando la libreria ufficiale NKN (open source) che invii messaggi di comando su topic pubblici, così da misurare la visibilità del SOC verso protocolli P2P non convenzionali.
Infine, per la simulazione di catene ICMP-tunneling che riproducono il pattern Network Boundary Bridging su router, ptunnel-ng (open source) resta lo strumento di riferimento in laboratorio isolato. Ogni test va condotto con logging completo per il debrief con il blue team, con particolare attenzione a tempi di connessione persistente e volume di dati incapsulati — le due metriche che il SOC dovrà imparare a riconoscere.
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.