A developer's IDE sits close to source code, secrets and cloud credentials. T1176.002, IDE Extensions, is the sub-technique of Software Extensions where an adversary abuses IDE extensions to keep access. MITRE files it under persistence for Linux, macOS and Windows.
How attackers use it
IDEs such as Visual Studio Code, IntelliJ IDEA and Eclipse support extensions that add features like linting, auto-completion, task automation, or links to tools such as Git and Docker. A malicious one can arrive through an extension marketplace, which MITRE ties to compromising software dependencies and development tools (T1195.001), or it can be side-loaded into the IDE.
Trust is set at install. After that, the extension runs every time the IDE launches. MITRE says it can execute arbitrary code, set up a backdoor, mine cryptocurrency or exfiltrate data.
Benign extensions can be abused too. The page's example is using the VSCode Remote SSH extension to set up persistent SSH tunnels, which it relates to IDE tunneling (T1219.001). The page lists Mustang Panda and TeamPCP in connection with this technique.
How to detect it
MITRE's strategy covers malicious extension installs and IDE tunneling. The chain on Windows is:
- The IDE starts on a non-developer endpoint or a server, often with install, force or tunnel flags.
- Extension files and registrations appear under the user profile.
- The IDE or browser connects out to extension marketplaces, update endpoints or IDE remote and tunnel services.
- Optional child tools such as
ssh,nodeorpowershellrun in the IDE's context.
On Linux, MITRE points at auditd execve events for code, idea or eclipse with install or update flags, writes under ~/.vscode/extensions or ~/.config/JetBrains, and outbound flows to marketplace domains such as marketplace.visualstudio.com, .jetbrains.com and githubusercontent.com, or to SSH and WebSocket tunnel endpoints. On macOS, the same pattern appears with extension folders under ~/Library/Application Support/Code or ~/Library/Application Support/JetBrains.
The cleanest signal is the IDE showing up where no developer works, such as a production server, plus a new tunnel to a remote service.
How to reduce the risk
MITRE lists five mitigations.
- Allow list or deny list IDE extensions according to your security policy.
- Update software. Keep the OS and IDEs current.
- Audit. Check that installed extensions are the intended ones, since many malicious extensions masquerade as legitimate ones.
- Limit installation to trusted sources that can be verified.
- Train users to use few extensions and install only trusted ones.
Because extensions come from a marketplace, treat them like dependencies. Pin what you approve and review changes. Your projects' own dependencies deserve the same attention, and the free in-browser scan at gold.safeguard.sh/scan checks up to 100 dependencies with no login and keeps your file on your machine.
Check your own environment
VS Code, list installed extensions with versions (read-only):
code --list-extensions --show-versions
Look at the extension folders on Linux or macOS:
ls -la ~/.vscode/extensions
Then ask:
- Is there a list of approved IDE extensions, and is it enforced?
- Is the IDE installed on servers or machines where nobody develops?
- Do we log outbound connections to tunnel and marketplace services from developer machines?
Try it yourself
Extensions are packages from a registry, with the same risks as typosquats and malicious uploads. This demo shows how those are caught.
Click through it at your own pace, or open it full screen.
Quick check
When does a malicious IDE extension run?
Every time the IDE is launched, once it has been installed.
What is a strong sign of IDE tunneling abuse?
The IDE starting on a non-developer endpoint or server with tunnel flags, followed by connections to remote tunnel services.
Sources
- MITRE ATT&CK, T1176.002 IDE Extensions