Proxy Interno per il C2: Internal Proxy (T1090.001)

Il proxy interno è una delle tecniche più utili da padroneggiare in un red team engagement, perché trasforma una singola compromissione con accesso Internet nell'hub di comunicazione per l'intera operazione. L'obiettivo in laboratorio è dimostrare che, una volta ottenuto un foothold, è possibile raggiungere segmenti di rete isolati senza che ogni host debba parlare direttamente con il C2.

Il punto di partenza più immediato su Windows è il comando nativo usato da Volt Typhoon nelle operazioni reali. Con il solo netsh si può creare un port proxy che inoltra il traffico da un'interfaccia interna verso un altro host compromesso o verso il C2:

netsh interface portproxy add v4tov4 listenport=8443 listenaddress=0.0.0.0 connectport=443 connectaddress=192.168.1.50

Questo comando configura il sistema per ascoltare sulla porta 8443 e inoltrare tutto il traffico verso la porta 443 di un host interno. Per verificare le regole attive:

netsh interface portproxy show all

Per scenari più complessi, Cobalt Strike (a pagamento) offre nativamente la funzionalità di comunicazione peer-to-peer tra beacon tramite SMB named pipe. In un engagement si configura un SMB listener sul team server e si distribuiscono beacon "link" sugli host senza accesso diretto a Internet, concatenandoli al beacon con uscita. Questa è esattamente l'architettura usata durante la SolarWinds Compromise (C0024), dove APT29 configurò Cobalt Strike per usare network pipe su SMB.

Su Linux, la catena classica prevede l'uso di socat (open source) per creare relay bidirezionali:

socat TCP-LISTEN:4444,fork TCP:10.10.10.20:443

In alternativa, Chisel (open source) è uno strumento specificamente progettato per il tunneling TCP su HTTP, particolarmente utile quando le regole firewall interne consentono solo traffico web. Il server Chisel viene avviato sull'host con accesso Internet, mentre il client gira sugli host isolati, creando un tunnel inverso.

Per simulare il pattern peer-to-peer visto in malware come Duqu e Stuxnet, Sliver (open source) e Mythic (open source) offrono entrambi profili C2 peer-to-peer nativi. Con Sliver si può generare un implant configurato per comunicare via named pipe con un altro implant che ha accesso esterno, replicando fedelmente il modello a catena documentato nelle campagne reali.

Infine, per replicare lo scenario di Lazarus Group — che usò un router compromesso come ponte tra segmento corporate e segmento ristretto — si può usare Ligolo-ng (open source), che crea tunnel di livello 3 attraverso un agente intermedio, simulando esattamente il pivoting attraverso un dispositivo di rete.

La sfida nella detection del proxy interno è che il traffico malevolo viaggia su protocolli legittimi — SMB, RPC, HTTP — tra host che potrebbero normalmente comunicare. La chiave è costruire una baseline comportamentale del traffico est-ovest e cercare deviazioni, non firme.

La detection principale documentata (DET0075) si articola su cinque piattaforme. Su Windows (AN0204), il segnale più affidabile è un processo anomalo — tipicamente rundll32, svchost o cmd — che inizia connessioni verso host interni su porte inusuali. Le log source critiche sono Sysmon (open source, richiede installazione) e i log del Windows Firewall. L'EventCode 3 di Sysmon cattura ogni connessione di rete con il processo sorgente, consentendo di costruire grafi di comunicazione tra endpoint. Le porte da monitorare con attenzione includono 1080, 4444, 8080 e qualsiasi porta SMB non standard.

Su Linux (AN0205), i relay vengono tipicamente creati con socat, ssh -L, ncat o regole iptables. Il sistema auditd con regole mirate sulle syscall connect e bind cattura queste attività. Un alert efficace correla l'utente che esegue il tool di relay: se www-data o backup lanciano un socat, il segnale è forte. I log NSM di flusso completano la visibilità mostrando pattern di traffico anomali tra host che storicamente non comunicano.

Per il tuning dei falsi positivi, tre dimensioni sono fondamentali:

• Baseline delle comunicazioni host-to-host: le workstation raramente parlano tra loro direttamente. Un flusso workstation-to-workstation su porta alta è quasi sempre sospetto.
• Correlazione temporale: un burst di traffico interno immediatamente dopo l'esecuzione di un nuovo processo è un pattern da investigare.
• Volume e direzione: il proxy interno genera traffico bidirezionale sostenuto tra due host interni, un pattern diverso dalla normale comunicazione client-server.

Su ESXi (AN0207), attenzione all'esecuzione di nc, socat o script Perl dalla shell ESXi — un ambiente dove l'attività interattiva dovrebbe essere quasi inesistente. I log esxi:shell e esxi:vmkernel sono le fonti primarie, e qualsiasi comunicazione est-ovest anomala tra VM merita investigazione immediata.

Per i dispositivi di rete (AN0208), la detection si sposta sulle modifiche di configurazione: regole NAT o port forwarding create fuori dalle finestre di manutenzione programmata sono un indicatore critico. La mitigazione ufficiale (M1031 — Network Intrusion Prevention) raccomanda l'uso di firme IDS/IPS per il traffico C2, tenendo presente che gli avversari modificano regolarmente le firme dei propri protocolli.

L'analisi forense di un proxy interno richiede di ricostruire la catena di comunicazione: quale host faceva da pivot, verso quali peer interni, e dove terminava il traffico all'esterno. Gli artefatti si distribuiscono tra l'host-pivot e gli host-leaf, e la correlazione temporale tra i due lati è essenziale.

Su Windows, il primo artefatto da cercare sono le regole di port proxy persistenti. Il comando netsh interface portproxy — lo stesso usato da Volt Typhoon e nella campagna APT28 Nearest Neighbor (C0051) — lascia tracce nel registro di sistema alla chiave HKLM\SYSTEM\CurrentControlSet\Services\PortProxy\v4tov4\tcp. Ogni regola configurata viene memorizzata come valore con indirizzo e porta di ascolto e destinazione. Questo artefatto persiste anche dopo il reboot ed è uno dei reperti più affidabili.

I log Sysmon con EventCode 3 (Network Connection) permettono di ricostruire l'intero grafo di comunicazione del pivot. Per ogni connessione registrata si ottengono processo sorgente, IP e porta sorgente, IP e porta destinazione, con timestamp preciso. Filtrando per l'host sospetto, è possibile visualizzare contemporaneamente le connessioni in ingresso dagli host interni e quelle in uscita verso il C2. I log del Windows Firewall con profilo di audit attivo forniscono una seconda fonte indipendente per conferma.

Per le comunicazioni via named pipe — il meccanismo usato da Mafalda, metaMain, MiniDuke e FatDuke — l'EventCode 17 (Pipe Created) e EventCode 18 (Pipe Connected) di Sysmon registrano la creazione e la connessione ai pipe. Nomi di pipe inusuali, specialmente quelli non riconducibili a servizi Windows standard, sono indicatori forti.

Su Linux, il file /proc/net/tcp (o il suo snapshot nei dump di memoria) mostra le connessioni attive e le porte in ascolto al momento dell'acquisizione. I log auditd con regole sulle syscall connect, bind e listen forniscono la cronologia delle attività di rete per processo e utente. Le regole iptables persistenti vanno cercate nei file di configurazione — tipicamente /etc/iptables/rules.v4 o l'output salvato di iptables-save — e nelle crontab, dove possono essere reinserite al boot.

La timeline si costruisce partendo dall'host-pivot identificato e procedendo in entrambe le direzioni. Verso l'interno, si mappano tutti gli host che hanno comunicato con il pivot su porte non standard. Verso l'esterno, si identifica il flusso C2 uscente. Nella SolarWinds Compromise (C0024), APT29 usò SSH port forwarding su sistemi esposti e SMB pipe internamente — un pattern a due stadi che richiede di correlare artefatti SSH (log di autenticazione, known_hosts) con artefatti SMB (log di sessione, Sysmon pipe events) sullo stesso asse temporale.

Per Operation Wocao (C0014), gli attori proxavano traffico attraverso molteplici sistemi infetti: in questi casi la ricostruzione richiede l'analisi dei flussi NetFlow o dei log firewall interni per identificare la catena completa di hop, partendo dall'ultimo nodo noto e risalendo a ritroso.

L'Internal Proxy è un indicatore architetturale: rivela come un avversario organizza la propria infrastruttura C2 all'interno della rete vittima. Analizzare chi usa questa tecnica e come la implementa offre insight significativi sulla sofisticazione operativa e sugli obiettivi strategici del gruppo.

Volt Typhoon (G1017) rappresenta il paradigma del living-off-the-land applicato al proxy interno. Questo attore cinese, focalizzato su infrastrutture critiche, usa esclusivamente il comando nativo netsh portproxy — nessun tool aggiuntivo, nessun binario da distribuire. Questa scelta riduce drasticamente la superficie di detection e rende l'attività quasi indistinguibile dall'amministrazione legittima. Lo stesso pattern è emerso nella campagna Nearest Neighbor di APT28 (C0051), dove il gruppo russo ha usato lo stesso comando nativo per creare proxy interni mentre sfruttava reti Wi-Fi adiacenti al target. La convergenza sullo stesso strumento LOLBin da parte di due attori non correlati conferma un trend: i gruppi più maturi preferiscono tool nativi.

Velvet Ant (G1047), altro attore legato alla Cina, ha tunnelato il traffico vittima attraverso host interni compromessi verso nodi C2 esterni. Turla (G0010), gruppo russo di lunga tradizione, ha adottato un approccio simile compromettendo sistemi interni per farli funzionare da relay C2. Entrambi i gruppi operano in contesti di spionaggio a lungo termine dove la persistenza e la riduzione del rumore di rete sono priorità strategiche.

Lazarus Group (G0032) ha introdotto una variante particolarmente insidiosa: l'uso di un router compromesso come ponte tra il segmento corporate e quello ristretto della rete vittima. Questo approccio — operare a livello di dispositivo di rete anziché di endpoint — eleva la complessità di detection e suggerisce una ricognizione approfondita dell'architettura di rete del target prima dell'azione.

FIN13 (G1016) dimostra che la tecnica non è esclusiva dello spionaggio: questo gruppo a motivazione finanziaria ha impiegato tool di proxy per la comunicazione tra asset compromessi. Lotus Blossom (G0030) ha usato il tool pubblico Venom per il proxying del traffico, mentre Strider (G0041) ha sfruttato server locali con doppio accesso — rete interna e Internet — come nodi proxy per l'esfiltrazione. APT39 (G0087), attore iraniano, ha sviluppato tool custom per proxy SOCKS5 e protocolli proprietari tra host infetti.

Dal punto di vista software, il pattern dominante è la comunicazione peer-to-peer via named pipe o SMB: Cobalt Strike, Sliver, Mythic, Duqu, MiniDuke, FatDuke, Mafalda e metaMain implementano tutti varianti di questo modello. StarProxy rappresenta un'evoluzione recente, progettato specificamente per proxare traffico tra dispositivi infetti e i relativi C2. La convergenza di tre campagne documentate — SolarWinds Compromise (C0024), Operation Wocao (C0014) e APT28 Nearest Neighbor (C0051) — su questa tecnica conferma che il proxy interno è ormai una componente architetturale standard nelle operazioni di medio-alto livello, indipendentemente dalla motivazione dell'attore.

Framework MITRE ATT&CK v16 — T1090.001 Internal Proxy, TA0011 Command and Control. Campagne: C0024 (SolarWinds Compromise), C0014 (Operation Wocao), C0051 (APT28 Nearest Neighbor Campaign). Mitigazione M1031. Detection DET0075, analytics AN0204–AN0208. Integrato con conoscenza professionale per tool e procedure operative.