Tunnel IDE come Canale C2: IDE Tunneling (T1219.001)

La simulazione di questa tecnica in laboratorio è sorprendentemente accessibile: bastano il CLI di Visual Studio Code e un account GitHub gratuito. Il punto di forza per il red teamer è che l'intera catena si basa su binari firmati Microsoft e traffico verso domini di primo livello legittimi.

Il primo passo è ottenere il binario CLI di VS Code sulla macchina target. In uno scenario reale l'attaccante potrebbe trasferirlo via download diretto o sfruttare un'installazione preesistente. Su Windows, il comando fondamentale è:

code.exe tunnel --accept-server-license-terms

Alla prima esecuzione il CLI genera un codice di autenticazione da inserire nel portale GitHub per associare il tunnel a un account. Una volta completato il binding, il sistema target diventa raggiungibile tramite il portale VS Code web o da un client desktop remoto — con terminal integrato, file browser e debugger completi.

Su Linux il flusso è analogo. Dopo aver scaricato il CLI standalone (il pacchetto si chiama code-cli e non richiede l'installazione completa dell'IDE), si esegue:

./code tunnel --name lab-target --accept-server-license-terms

Il parametro --name assegna un alias al tunnel, rendendo più semplice gestire target multipli. L'attaccante che vuole persistenza può creare un servizio systemd o una entry crontab @reboot che rilanci il tunnel automaticamente.

Per simulare lo scenario JetBrains, il tool JetBrains Gateway (gratuito) consente di stabilire connessioni remote tramite SSH con port forwarding automatico verso l'IDE backend. Il red teamer può configurare un tunnel SSH inverso e poi collegare Gateway per ottenere un'esperienza di sviluppo remoto completa, indistinguibile da un uso legittimo.

Alcuni aspetti da validare durante l'esercizio:

• Visibilità DNS: verificare se il proxy o il DNS aziendale registra le query verso i domini devtunnels di Microsoft (pattern *.devtunnels.ms) o i gateway JetBrains
• Catena processi: controllare se l'EDR identifica code.exe lanciato da un processo non-interattivo (es. schtasks, cmd.exe da servizio)
• Autenticazione: testare se le policy Entra ID bloccano l'autenticazione da tenant non autorizzati

Per documentare il traffico generato, Wireshark (open source) è ideale per catturare i flussi TLS verso i domini tunnel e analizzare pattern di heartbeat e volume dati. Il red teamer dovrebbe confrontare il profilo di traffico del tunnel IDE con quello di una sessione di sviluppo legittima per valutare quanto siano realmente distinguibili.

La detection dell'IDE tunneling richiede un approccio stratificato perché il traffico è cifrato, firmato e diretto verso infrastruttura cloud Microsoft o JetBrains. Non si può semplicemente bloccare un IP malevolo: bisogna correlare comportamenti su processo, file system e rete.

Su Windows, la detection principale (AN0375) si basa su Sysmon e flussi di rete. Il primo indicatore è la creazione del profilo tunnel di VS Code: Sysmon EventCode 11 (FileCreate) deve catturare la scrittura del file code_tunnel.json all'interno della directory .vscode-cli nel profilo utente. Questo evento, seguito entro una finestra temporale configurabile da connessioni in uscita verso pattern *.devtunnels.ms o *.tunnels.api.visualstudio.com, genera un segnale ad alta confidenza.

La correlazione chiave è tra processo e rete: EventCode 1 (ProcessCreate) per code.exe con argomento tunnel nella command line, seguito da EventCode 3 (NetworkConnect) verso le porte 443 o 8443. Su Sysmon, una regola che filtra CommandLine contains 'tunnel' e Image ends with 'code.exe' riduce drasticamente il rumore.

Su Linux (AN0376), auditd con la syscall execve monitorata è il punto di partenza. La regola auditd deve catturare esecuzioni del binario code con argomenti tunnel-related. Il file artefatto da sorvegliare è ~/.vscode-cli/code_tunnel.json, la cui comparsa è anomala su server di produzione.

Su macOS (AN0377), i Unified Log filtrati per processo code o jetbrains-gateway con attività di rete persistente verso API devtunnel costituiscono il segnale primario. Particolare attenzione ai LaunchAgent: se l'IDE configura un plist in ~/Library/LaunchAgents/ per il riavvio automatico del tunnel, questo è un indicatore di persistenza forte.

Per gestire i falsi positivi — inevitabili in ambienti con sviluppatori attivi — il tuning si articola su tre parametri: una AuthorizedUserList di account sviluppatori approvati per l'uso dei tunnel, i TunnelDomainPatterns aggiornati alle versioni correnti degli IDE, e una TimeWindow di correlazione tra creazione profilo e connessione outbound. In ambienti dove i dev tunnel non sono mai legittimi, la regola più efficace è la più semplice: alertare su qualsiasi esecuzione di code tunnel o comparsa di code_tunnel.json, punto.

Come controllo preventivo, la mitigazione Execution Prevention (M1038) raccomanda di bloccare tramite AppLocker (integrato in Windows) o WDAC (integrato in Windows) l'esecuzione di code.exe da directory non autorizzate, e soprattutto di disabilitare la funzionalità Dev Tunnels via Group Policy, restringendo l'accesso ai soli tenant Entra ID approvati.

L'analisi forense di un IDE tunnel abusato produce artefatti distribuiti tra file system, registro eventi e traffico di rete. La buona notizia è che il meccanismo di tunneling lascia tracce piuttosto caratteristiche, a patto di sapere dove cercare.

L'artefatto più importante su Windows è il file code_tunnel.json, tipicamente situato in %USERPROFILE%\.vscode-cli\. Questo file contiene la configurazione del tunnel, incluso il nome assegnato, l'account di autenticazione (GitHub o Microsoft) e i parametri di connessione. I timestamp NTFS del file — creazione, ultima modifica, ultimo accesso — ancorano la timeline all'istante di prima attivazione del tunnel. Un secondo artefatto critico è la directory .vscode-server nella home dell'utente, che contiene i binari del server VS Code scaricati automaticamente durante la prima connessione remota: il suo timestamp di creazione indica quando l'attaccante ha stabilito la prima sessione interattiva.

Per la ricostruzione della command line, gli eventi Sysmon EventCode 1 nel canale Microsoft-Windows-Sysmon/Operational registrano l'intera riga di comando con cui code.exe è stato invocato, inclusi flag come tunnel e --name. Se Sysmon non era attivo, i log Security con auditing dei processi abilitato (EventCode 4688) forniscono informazioni analoghe, sebbene con meno dettaglio sulla command line nelle configurazioni predefinite.

Su Linux, l'indagine si concentra su ~/.vscode-cli/code_tunnel.json e sui log auditd. Se il tunnel è stato configurato per persistenza, cercare entry in crontab (crontab -l per l'utente sospetto) o file unit systemd in ~/.config/systemd/user/. La shell history (.bash_history, .zsh_history) potrebbe contenere i comandi di configurazione iniziale, a meno che l'attaccante non l'abbia ripulita.

Su macOS, l'analisi dei LaunchAgent è prioritaria: file plist in ~/Library/LaunchAgents/ che referenziano il binario code con argomenti tunnel indicano persistenza configurata. I Unified Log, interrogabili con il comando:

log show --predicate 'process == "code"' --style compact --last 7d

restituiscono l'attività del processo VS Code con timestamp precisi.

L'analisi di rete completa il quadro: i flussi verso i domini devtunnels Microsoft su porta 443, estratti da log proxy, NetFlow o catture PCAP, rivelano la durata delle sessioni tunnel e i volumi di dati trasferiti. Correlando il primo flusso di rete con il timestamp di code_tunnel.json e l'evento ProcessCreate, il forensic analyst ottiene una timeline solida dell'intera sequenza: installazione del CLI, configurazione del tunnel, autenticazione GitHub e inizio della sessione C2.

L'adozione dell'IDE tunneling come vettore C2 rappresenta un'evoluzione significativa nelle tattiche di gruppi già noti per la loro capacità di sfruttare strumenti legittimi. Il panorama attuale è ancora ristretto — un solo gruppo APT è stato formalmente associato a questa tecnica — ma i segnali indicano un potenziale di espansione rapido.

Mustang Panda (G0129), attore legato alla Cina con focus primario su spionaggio geopolitico nel sud-est asiatico ed Europa, ha integrato il tunneling VS Code nel proprio arsenale utilizzando un account GitHub preesistente per creare tunnel all'interno degli ambienti vittima tramite il comando code.exe tunnel. Questa scelta è coerente con il modus operandi del gruppo, che storicamente predilige l'abuso di software legittimo per evadere la detection e mimetizzarsi nel traffico normale. L'uso di un account GitHub già consolidato — anziché creato ad hoc — suggerisce una pianificazione operativa attenta alla credibilità dell'infrastruttura.

Dal punto di vista del profiling, l'IDE tunneling è una scelta logica per gruppi che operano contro target con workforce tecnica significativa: enti governativi con team IT interni, aziende tecnologiche, organizzazioni di ricerca. In questi ambienti, il traffico VS Code verso i server Microsoft è perfettamente normale, rendendo la detection basata su anomalie di rete particolarmente difficile.

Il pattern da monitorare per anticipare l'adozione più ampia di questa tecnica è l'intersezione tra tre fattori: gruppi APT che già utilizzano strumenti LOLBin (Living Off the Land Binaries), target con presenza documentata di ambienti di sviluppo, e infrastrutture C2 che sfruttano servizi cloud legittimi. Mustang Panda soddisfa tutti e tre i criteri, e non è irragionevole aspettarsi che altri attori con profilo simile valutino questa opzione.

L'intelligence operativa dovrebbe concentrarsi sul monitoraggio di account GitHub con pattern sospetti — creati o riattivati poco prima di campagne note, utilizzati esclusivamente per autenticazione tunnel e senza attività repository significativa. L'integrazione di indicatori derivati dalla telemetria dei Dev Tunnels Microsoft nei feed di threat intelligence rappresenta un passo naturale per maturare la capacità di detection su questa superficie d'attacco emergente.

Framework MITRE ATT&CK v16 — tecnica T1219.001 (IDE Tunneling), tattica TA0011 (Command and Control), mitigazione M1038 (Execution Prevention), detection DET0133 con analitiche AN0375, AN0376, AN0377. Gruppo G0129 (Mustang Panda). Integrato con conoscenza professionale per tool e procedure operative.