GlassWorm OpenVSX 'Sleeper' Extensions: Supply Chain Attack Detection and Remediation

A resurgence of the GlassWorm campaign has been identified, specifically targeting the developer ecosystem via the OpenVSX extension registry. Security researchers have detected 73 malicious "sleeper" extensions designed to appear benign during initial installation. These extensions lie dormant until a seemingly routine update is delivered, at which point they weaponize the development environment with malicious payloads.

For SOC analysts and DevSecOps engineers, this represents a critical supply chain risk. Unlike traditional malware, this threat compromises the integrity of the tools developers trust daily—Integrated Development Environments (IDEs) like VS Code and Eclipse Theia. If these extensions are executed within a corporate network, they provide attackers with a privileged foothold to steal source code, inject backdoors, or move laterally.

Technical Analysis

Affected Products and Platforms:

• IDE Platforms: Eclipse Theia, Visual Studio Code (when configured to use the OpenVSX registry), and any IDE utilizing the OpenVSX extension marketplace.
• Operating Systems: Windows, macOS, and Linux (cross-platform via the Node.js-based extension host).

CVE and CVSS:

• CVE: N/A (This is a supply chain abuse/poisoning rather than a software vulnerability in a specific binary, though the impact mirrors a remote code execution flaw).
• CVSS Score: N/A (Rated High severity based on impact potential).

Attack Chain (Defender Perspective):

1. Initial Compromise: The threat actor publishes malicious extensions to the OpenVSX registry.
2. Establishment (The "Sleeper"): Users install the extensions, often mimicking popular tools (themes, linters, or utilities). Initially, the code is benign or minimally functional to pass basic scrutiny and gain installation counts.
3. Activation (The Trigger): The attacker pushes an update. The extension fetches and executes a second-stage payload.
4. Execution: The payload runs within the context of the IDE's extension host process (often node.exe, electron, or extensionHost.exe).
5. Objectives: The malware establishes persistence, performs command-and-control (C2) communication, or engages in data exfiltration (credentials, source code).

Exploitation Status:

• Confirmed Active Exploitation: Yes. The 73 extensions are currently live in the repository, and the "update" mechanism is the primary vector for turning the sleeper malicious.

Detection & Response

━━━ DETECTION CONTENT ━━━

Detecting "sleeper" malware requires focusing on behavioral anomalies rather than static signatures, as the initial code may be clean. The primary indicators of compromise (IOCs) for this campaign are the unauthorized spawning of shells or obfuscated script execution by the IDE processes.

SIGMA Rules

---
title: Potential Malicious VSCode/OpenVSX Extension Spawning Shell
id: 8a4b9c1d-5e6f-4a7b-8c9d-0e1f2a3b4c5d
status: experimental
description: Detects Visual Studio Code or Eclipse Theia spawning a command shell, a common TTP for malicious extensions executing payloads.
references:
  - https://www.bleepingcomputer.com/news/security/glassworm-malware-attacks-return-via-73-openvsx-sleeper-extensions/
author: Security Arsenal
date: 2025/02/26
tags:
  - attack.execution
  - attack.t1059.001
  - attack.t1059.003
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|contains:
      - '\Code.exe'
      - '\Code - Insiders.exe'
      - '\Theia.exe'
      - '\electron.exe'
  selection_child:
    Image|endswith:
      - '\powershell.exe'
      - '\cmd.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate developer debugging or terminal usage within the IDE
level: high
---
title: Suspicious Child Process of Extension Host
id: 9b5c0d2e-6f7a-5b8c-9d0e-1f2a3b4c5d6e
status: experimental
description: Detects the VS Code Extension Host or Node.js spawning suspicious network tools or utilities often used in post-exploitation.
references:
  - https://attack.mitre.org/techniques/T1055/
author: Security Arsenal
date: 2025/02/26
tags:
  - attack.defense_evasion
  - attack.t1055
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|contains:
      - '\extensionHost.exe'
      - '\node.exe'
  selection_cli:
    CommandLine|contains:
      - 'Invoke-WebRequest'
      - 'IEX'
      - 'DownloadString'
      - 'whoami'
      - 'net user'
  condition: selection_parent and selection_cli
falsepositives:
  - Legitimate extension functionality (rare for these specific CLI flags)
level: medium

KQL (Microsoft Sentinel / Defender)

// Hunt for suspicious processes spawned by Code Editors
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("Code.exe", "Code - Insiders.exe", "Theia.exe", "extensionHost.exe", "node.exe")
| where ProcessFileName in~ ("powershell.exe", "cmd.exe", "pwsh.exe", "bash")
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, ProcessFileName, ProcessCommandLine, InitiatingProcessCommandLine
| order by Timestamp desc

Velociraptor VQL

-- Hunt for suspicious process relationships indicative of malicious extension execution
SELECT Pid, Name, CommandLine, Exe, Username, Parent.Pid AS ParentPid, Parent.Name AS ParentName, Parent.CommandLine AS ParentCmd
FROM pslist()
WHERE Parent.Name =~ "Code.exe" 
   OR Parent.Name =~ "extensionHost.exe"
   OR Parent.Name =~ "Theia.exe"
AND Name =~ "powershell" 
   OR Name =~ "cmd" 
   OR Name =~ "bash" 
   OR Name =~ "sh"

Remediation Script (PowerShell)

This script audits the VS Code extensions directory for recently modified files, which helps identify "sleeper" extensions that may have updated recently with malicious payloads.

<#
.SYNOPSIS
    Audits VS Code Extensions for recent modifications (Sleeper Malware Check).
.DESCRIPTION
    Checks the .vscode/extensions directory for extensions updated within the last X days.\#>

$DaysToCheck = 7
$UserExtensionsPath = "$env:USERPROFILE\.vscode\extensions"

if (Test-Path $UserExtensionsPath) {
    Write-Host "[+] Checking extensions modified in the last $DaysToCheck days..." -ForegroundColor Cyan
    
    $ModifiedExtensions = Get-ChildItem -Path $UserExtensionsPath -Directory | 
        Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-$DaysToCheck) }

    if ($ModifiedExtensions) {
        Write-Host "[!] Found recently updated extensions:" -ForegroundColor Yellow
        foreach ($Ext in $ModifiedExtensions) {
            Write-Host "Name: $($Ext.Name)" -ForegroundColor White
            Write-Host "Path: $($Ext.FullName)" -ForegroundColor Gray
            Write-Host "Last Write Time: $($Ext.LastWriteTime)" -ForegroundColor Gray
            Write-Host "----------------------------------------"
        }
        Write-Host "[WARNING] Please manually verify these extensions against known IOCs or uninstall if unrecognized." -ForegroundColor Red
    } else {
        Write-Host "[+] No extensions modified in the last $DaysToCheck days." -ForegroundColor Green
    }
} else {
    Write-Host "[-] VS Code Extensions directory not found." -ForegroundColor Gray
}

Remediation

Immediate Actions:

1. Audit Installed Extensions: Cross-reference installed extensions in VS Code (Extensions: Installed view) against the list of identified malicious extensions provided by the OpenVSX maintainers or threat intelligence feeds (BleepingComputer report).
2. Removal: If a suspicious extension is found, disable it immediately and click "Uninstall." Do not simply disable, as the update mechanism may still trigger.
3. Review Extension Source: Ensure that the extensions. settings do not auto-install extensions from untrusted sources.

System Hardening:

1. Restrict Marketplace: Configure VS Code to use the trusted Visual Studio Marketplace (https://marketplace.visualstudio.com/vscode) instead of OpenVSX if OpenVSX is not strictly required for your toolchain.
2. Workspace Trust: Enforce "Workspace Trust" features in VS Code to restrict code execution by extensions when opening untrusted folders.
3. Network Segmentation: If possible, restrict the network access of developer workstations to prevent C2 callbacks, although this is difficult in dev environments.

Official Advisory & References:

• Vendor Advisory: OpenVSX Registry (Eclipse Foundation) – Refer to their security notices for the specific list of the 73 publisher names and extension IDs.
• Action: Review and remove any extensions originating from the publishers identified in the GlassWorm report.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub