How Malicious VS Code Extensions Are Used to Steal Developer Credentials

Contents

Developers trust their tools. That trust is what makes Visual Studio Code a productive workspace, and what attackers are quietly exploiting.

Recent security research shows a worrying trend: threat actors are slipping malicious code into what look like helpful VS Code extensions.

When a developer installs one of these packages, the extension can drop a tiny downloader, reach out to an attacker-controlled server, and pull a second piece that expands into a full-fledged information stealer or remote access tool.

Attack chain of the Evelyn campaign. Source: Trend Micro

Multiple vendors and independent researchers have documented active campaigns that used the extension ecosystem as an entry point for multi-stage malware.

The final payloads harvest browser credentials, development secrets, and other data that can let an intruder move from one developer machine into broader systems. I’ll walk through the typical attack chain in plain terms, then give realistic, usable guidance you can act on today.

How Malicious VS Code Extensions Reach Developers

Most people discover extensions the same way: through the Marketplace, GitHub, or a link shared by a colleague. Attackers copy that pattern and build trust by mimicking popular tools or publishers. They use techniques like typosquatting (a nearly identical name), fake publisher profiles, or packaging a small, seemingly useful feature with hidden code. In some campaigns, researchers found that extensions carried what looked like harmless image files or helper libraries that in fact contained encoded binaries.

Some extensions are uploaded directly to the official VS Code Marketplace; others land on alternative registries or GitHub and rely on users to install them manually. Once installed, an extension runs with the permissions available to VS Code and can execute Node.js code, shell out to the system, or write files under the user profile. That makes extensions a convenient launch point for a small downloader that contacts an attacker host and retrieves the next stage.

What happens after a malicious VS Code extension runs

A common pattern is multistage delivery. The extension’s initial code is typically small: it writes a file into a temporary folder or invokes a brief PowerShell or Node command to fetch another artifact. The second artifact is heavier, a loader that decrypts and injects a final payload directly into memory or into a running process.

By avoiding obvious disk footprints and using in-memory execution techniques, attackers make detection harder for traditional antivirus. Vendors have observed these loaders performing tasks such as capturing browser cookies, reading SSH keys and .git files, logging clipboard data, and taking screenshots.

Attackers also use public hosting like GitHub raw content, fast-changing domains, or even FTP servers as their control channels. Frequent rotation of payloads and short-lived repositories are deliberate: they reduce the opportunity for defenders to produce lasting signatures. Some campaigns include anti-analysis checks, the code looks for virtual machines, debuggers, or sandbox environments and delays or alters behavior if it suspects it’s being analyzed.

Why Developers and Organizations Should Pay Attention

When a developer machine is compromised, the effects can ripple outward. Developer workstations typically have keys, tokens, and connections to code repositories and cloud platforms.

An attacker who harvests a GitHub personal access token, SSH key, or stored credentials can access source, modify build scripts, or introduce backdoors. The compromise may begin as a single infected extension, but it can quickly become a foothold for supply chain abuse and lateral movement. Reports from multiple research groups have linked extension-based attacks to credential theft and broader intrusions.

Steps for Teams and Individual Developers

Addressing this requires both policy and habit changes. Here are practical measures that reduce exposure without blocking legitimate work:

Treat extension installs like software installs. In teams, use a curated list or a private extension gallery and restrict installs on sensitive developer machines. Enterprises can host a private extension marketplace and rehost trusted public extensions after a vetting step. That approach limits the attack surface while preserving developer productivity.
Monitor and log extension lifecycle events. Capture telemetry when extensions are installed, updated, or when they write executables to user profile directories. Centralized logs help you spot a pattern — for example, an extension that immediately drops a DLL into Temp and spawns a PowerShell process with encoded commands.
Harden endpoint controls. Use application allowlisting and tools that detect in-memory injection patterns (EDR solutions that surface CreateProcess with CREATE_SUSPENDED, WriteProcessMemory, or reflective DLL loads). Limit PowerShell to constrained modes and instrument its logging so suspicious download-and-execute chains are visible.
Protect developer secrets. Avoid storing tokens and credentials in plain files. Prefer hardware-backed keys or platform secret managers, and enable short-lived tokens where possible. Scan repositories and package manifests for accidental secrets and remove them.
Educate the team with relevant examples. Show engineers how a fake “formatter” or “theme” could contain hidden code. Practical, example-driven training (using anonymized excerpts from real reports) helps engineers make better installation choices without becoming overly suspicious.

What Defenders Should Hunt for now

There are high-value signals that usually appear early in these attacks. Look for extensions that create or modify executable files under %TEMP% or the user profile and then spawn interpreter processes with download flags.

Track network requests to raw content on public code hosts or to obscure domains and FTP servers. Alert on processes that write to browser profile directories or read known locations for SSH keys and .git metadata from non-browser, non-git processes, those are strong signals of data collection.

Vendors who tracked recent campaigns provide IoCs and behavioral signatures that teams can fold into SIEM and EDR rules.

How to Set Policy Without Slowing Engineering Down

The worst outcome is either unlimited installs with no oversight, or rigid bans that frustrate developers. A balanced approach works best:

Curate a short list of approved, battle-tested extensions and offer an easy process to request additions.
Use a private marketplace for sensitive teams and a monitored approval flow for general engineering.
Implement telemetry that can be turned into lightweight, automated checks rather than manual gates. That way, engineers keep momentum and security gains visibility. Microsoft and other tooling providers document how enterprises can host and manage private extension catalogs; those guides include scripts and configuration examples to automate rehosting and deployment.

Stay Practical and Proactive

Malicious VS Code extensions are a clear example of attackers exploiting trusted workflows, not new zero-day wizardry. The fixes are straightforward but require coordination: vet extensions, protect secrets, monitor the right signals, and give developers a simple path to install tools they need.

Security teams should integrate extension visibility into existing endpoint and log monitoring, while engineering leads should champion safe install practices. The effort is manageable, and the payoff is preventing a single compromised tool from turning into a larger breach.