Estensioni IDE Malevole: IDE Extensions (T1176.002)

La simulazione di questa tecnica in laboratorio richiede di comprendere due vettori distinti: l'installazione di un'estensione malevola e l'abuso di funzionalità legittime di tunneling. Entrambi i percorsi producono persistenza senza modificare chiavi di registro o servizi di sistema, il che li rende particolarmente interessanti per testare la maturità dei controlli di un'organizzazione.

Vettore 1 — Side-loading di estensione malevola. Visual Studio Code (open source) consente l'installazione di estensioni da file VSIX locale. In un esercizio red team, si può confezionare un'estensione con payload personalizzato e installarla dalla riga di comando:

code --install-extension payload.vsix --force

Il flag --force sovrascrive un'eventuale versione già presente. L'estensione finisce nella directory ~/.vscode/extensions/ su Linux e macOS, oppure %USERPROFILE%\.vscode\extensions\ su Windows. Il file extension.js (o activate() nel modulo principale) viene eseguito ogni volta che l'IDE si avvia, garantendo persistenza automatica.

Per confezionare il VSIX, lo strumento ufficiale è vsce (open source), il CLI di packaging per estensioni VS Code. La struttura minimale prevede un package.json con l'entry point e un modulo JavaScript che invoca il payload — ad esempio una reverse shell Node.js.

Vettore 2 — IDE Tunneling con VS Code. Questo è il percorso documentato per Mustang Panda. Il comando chiave è:

code.exe tunnel

Questo abilita una reverse shell integrata che sfrutta l'infrastruttura Microsoft per stabilire un tunnel autenticato. L'operatore remoto può accedere al filesystem, eseguire comandi nel terminale integrato e trasferire file — il tutto mascherato da traffico legittimo verso i domini di Visual Studio.

Procedura lab-safe completa. Per un test realistico, combinate i due vettori in sequenza: installate un'estensione che abilita il tunneling al primo avvio dell'IDE, verificando che il traffico in uscita raggiunga i servizi VS Code Remote. Monitorate con Wireshark (open source) le connessioni verso i domini marketplace e tunnel per validare che il vostro SOC le intercetti.

Per ambienti JetBrains, il percorso equivalente utilizza JetBrains Gateway (freemium) con i plugin remote. Le estensioni risiedono in ~/.config/JetBrains/ su Linux e il meccanismo di attivazione automatica è analogo. Simulate l'installazione via CLI e verificate se le regole di detection coprono anche questo IDE.

Il cuore della detection per questa tecnica è una correlazione a catena su tre dimensioni: processo, filesystem e rete. Nessuna delle tre, presa singolarmente, è sufficiente a distinguere un'installazione malevola da un aggiornamento legittimo. La combinazione, invece, racconta una storia chiara.

Punto di partenza — processo IDE su host anomali. L'alert più immediato e con il miglior rapporto segnale/rumore consiste nel monitorare l'avvio di binari IDE su macchine dove non dovrebbero esistere. Su Windows, Sysmon EventID 1 (Process Create) cattura l'esecuzione di code.exe, idea64.exe, eclipse.exe o jetbrains-gateway.exe. La regola deve filtrare per host appartenenti a zone server, domain controller e sistemi di produzione — ambienti dove nessuno sviluppa codice. Questo singolo controllo elimina la maggior parte dei falsi positivi che affliggono regole più generiche.

Secondo livello — flag CLI sospetti. Quando il processo IDE è legittimo (workstation sviluppatore), il discriminante diventa la riga di comando. I flag --install-extension, --force, --user-data-dir e soprattutto tunnel meritano un alert dedicato. Su Windows, correlate Sysmon EventID 1 con il campo CommandLine; su Linux, le registrazioni auditd di tipo SYSCALL su execve forniscono lo stesso dettaglio.

La finestra di correlazione consigliata è di 15-30 minuti tra l'avvio del processo, la scrittura di file nelle directory di estensione e la prima connessione in uscita verso i servizi IDE remoti.

Terzo livello — traffico di rete. Le connessioni verso domini come quelli dei marketplace Visual Studio, i servizi JetBrains o endpoint tunnel/WebSocket devono essere monitorate tramite log proxy o NSM flow. Su macchine non autorizzate, queste connessioni sono immediatamente sospette. Su workstation sviluppatore, confrontate la lista di domini contattati con una allowlist aziendale dei repository approvati.

Per macOS, i log unificati (macos:unifiedlog) tracciano sia l'avvio dei processi sia le modifiche ai file plist e alle directory di estensione sotto ~/Library/Application Support/Code/. Se l'organizzazione usa un MDM che installa estensioni centralmente, inserite quegli eventi in una allowlist per evitare falsi positivi.

Gestione dei falsi positivi. Il tuning principale riguarda la distinzione tra sviluppatori autorizzati e utenti generici. Mantenete una lista aggiornata di account con permesso di installare estensioni IDE e usatela come filtro di soppressione. Ogni installazione da parte di un utente non in lista deve generare un alert di priorità alta.

L'analisi forense di un'intrusione basata su estensioni IDE ruota attorno a tre cluster di artefatti: il filesystem delle estensioni, i log di processo e le tracce di rete. La buona notizia è che gli IDE sono piuttosto verbosi nel registrare la propria attività — se si sa dove guardare.

Filesystem — la scena primaria. Su Windows, la directory chiave è %USERPROFILE%\.vscode\extensions\. Ogni estensione installata ha una sottocartella con nome e versione. I timestamp NTFS di creazione ($STANDARD_INFORMATION e $FILE_NAME nel record MFT) della cartella dell'estensione sospetta stabiliscono il momento dell'installazione. Confrontate questo timestamp con la timeline di accesso iniziale per verificare la coerenza della catena d'attacco.

Il file extensions.json nella stessa directory mantiene un registro delle estensioni con i relativi metadata. Per JetBrains, i percorsi equivalenti sono %APPDATA%\JetBrains\ su Windows e ~/.config/JetBrains/ su Linux. Su macOS, cercate sotto ~/Library/Application Support/Code/ e nelle directory Application Support di JetBrains.

Log di processo — la catena di esecuzione. Su Windows, gli eventi Sysmon EventID 1 documentano l'intera catena di parent-child process. L'elemento critico è identificare se code.exe ha generato processi figli anomali: ssh, node, powershell.exe o cmd.exe eseguiti nel contesto dell'IDE sono indicatori forti di abuso. Ricostruite la sequenza cronologica partendo dal primo avvio di code.exe con flag tunnel e mappate ogni processo figlio successivo.

Su Linux, i record auditd di tipo SYSCALL con syscall execve forniscono la stessa visibilità. Filtrate per il PID del processo IDE e ricostruite l'albero dei processi figli. Prestate attenzione a processi node generati dall'IDE: le estensioni VS Code eseguono codice JavaScript in un runtime Node.js integrato, quindi un processo Node anomalo potrebbe essere il payload in esecuzione.

Connessioni di rete — la conferma dell'esfiltrazione. I log di connessione (Sysmon EventID 3 su Windows, flow NSM su Linux) completano la timeline collegando l'attività locale ai servizi remoti. Per il vettore tunnel documentato per Mustang Panda, cercate connessioni HTTPS/WebSocket originate dal processo IDE verso l'infrastruttura dei servizi VS Code Remote. I log del proxy, se disponibili, forniscono i dettagli degli URL e permettono di distinguere traffico tunnel da normali aggiornamenti di estensioni.

Su macOS, i log unificati (log show --predicate) consentono di filtrare per processo e categoria di rete, ricostruendo le connessioni in uscita con timestamp precisi al microsecondo.

Mustang Panda (G0129) è il gruppo di riferimento documentato per questa tecnica. Noto per operazioni di cyber-espionage con focus geografico sul Sud-Est asiatico e l'Europa, il gruppo ha dimostrato una notevole capacità di adattamento tattico adottando l'abuso delle funzionalità di tunneling di Visual Studio Code. L'utilizzo del comando code.exe tunnel per stabilire una reverse shell sfrutta l'infrastruttura Microsoft come canale C2, rendendo il traffico estremamente difficile da distinguere da attività di sviluppo legittima.

Questo approccio rivela una tendenza strategica significativa: i gruppi APT stanno migrando da infrastrutture C2 custom verso servizi cloud legittimi, tecnica spesso denominata "living off trusted services". L'uso di VS Code tunnel è particolarmente efficace perché il traffico è cifrato, transita su domini ad alta reputazione e non richiede l'installazione di tool aggiuntivi — l'IDE stesso diventa l'impianto di persistenza.

Pattern operativo e implicazioni. L'interesse di Mustang Panda per questa tecnica suggerisce che il gruppo opera in ambienti dove la presenza di Visual Studio Code è comune e dove il traffico verso i servizi Microsoft non viene ispezionato. Organizzazioni con team di sviluppo numerosi, aziende tecnologiche e istituzioni accademiche rientrano nel profilo di targeting ideale.

Dal punto di vista dell'evoluzione della minaccia, è ragionevole aspettarsi che altri gruppi con capability simili adottino questa tecnica. La superficie d'attacco è ampia: ogni IDE con supporto per estensioni e funzionalità remote rappresenta un potenziale vettore. Il marketplace delle estensioni, nonostante i processi di review, ha dimostrato di essere vulnerabile all'inserimento di componenti malevoli mascherati da tool legittimi.

Indicatori strategici da monitorare. Per anticipare campagne future che sfruttino questa tecnica, i team di threat intelligence dovrebbero tracciare la pubblicazione di estensioni sospette sui marketplace VS Code e JetBrains, prestando attenzione a pacchetti con nomi simili a estensioni popolari (typosquatting) o con permessi eccessivi rispetto alla funzionalità dichiarata. L'analisi delle estensioni rimosse dai marketplace per violazione delle policy può fornire early warning su campagne in corso. Infine, il monitoraggio delle connessioni tunnel IDE originanti da reti non di sviluppo rappresenta un indicatore tattico prezioso per identificare compromissioni attive.

Framework MITRE ATT&CK v16 — Tecnica T1176.002, Tattica TA0003, Gruppo G0129, Mitigazioni M1038, M1051, M1047, M1033, M1017, Detection DET0561 (AN1548, AN1549, AN1550). Integrato con conoscenza professionale per tool e procedure operative.