Open VSX Under Siege: Deconstructing GlassWorm's Transitive Abuse
Saw the report on the GlassWorm campaign shifting tactics. The move from direct payload embedding to abusing extensionPack and extensionDependencies is a clever evasion technique. It effectively uses the registry's trust in dependency resolution against developers. By chaining 72 extensions, the loader is obfuscated behind seemingly benign "utility" extensions that act as a transitive vector.
If you're running VSCodium or using the Open VSX registry, you need to audit your environment immediately. The malware executes only when the specific combination of dependencies is met, which bypasses basic static analysis of individual extensions.
I've whipped up a quick Python script to recursively scan your installed extension's package. files for specific dependency depth and known malicious namespace patterns mentioned in the IOCs.
import
import os
def check_dependencies(path):
try:
with open(path, 'r') as f:
data = .load(f)
# Check for extensionDependencies or extensionPack
deps = data.get('extensionDependencies', {})
packs = data.get('extensionPack', [])
if deps or packs:
print(f"[!] Suspicious configuration in {os.path.basename(path)}")
print(f" Dependencies: {deps}")
print(f" Packs: {packs}")
except Exception as e:
pass
# Run against your extensions directory
for root, dirs, files in os.walk('/path/to/.vscode/extensions'):
if 'package.' in files:
check_dependencies(os.path.join(root, 'package.'))
For those managing developer workstations, how are you validating the integrity of these transitive dependencies? Are you blocking Open VSX entirely or relying on marketplace signatures?
We started hunting for this immediately after the IOCs dropped. We're using a KQL query against our endpoint logs to detect the child processes spawned by the VS Code host binary that look like typical GlassWorm behavior (PowerShell obfuscation). It's tricky because the process tree looks legitimate.
DeviceProcessEvents
| where FolderPath endswith "Code.exe"
| join kind=child (DeviceProcessEvents
| where ProcessVersionInfoOriginalFileName in ("powershell.exe", "cmd.exe"))
| where InitiatingProcessCommandLine contains "--extensionDevelopmentPath"
This is exactly why we moved to an air-gapped internal extension marketplace. Relying on the public Open VSX registry is a nightmare for supply chain security. We fork the extensions we use, audit the code, and host them internally. It's more overhead, but it kills this "transitive infection" vector dead.
I have a few clients using VSCodium heavily. Is there a centralized way to push a blocklist via GPO or configuration management, or do I have to script an uninstall across 50+ machines? I'm worried about persistence if the extensions already dropped the loader.
@BackupBoss_Greg, since VSCodium stores extension data locally, a PowerShell scan across your fleet is your best bet for immediate triage. You can check package. files to spot that chaining behavior quickly.
Get-ChildItem "$env:USERPROFILE\.vscode\extensions" -Recurse -Filter "package." | Select-String "extensionDependencies" | Select-Object Path
This identifies extensions utilizing transitive dependencies so you can target removals effectively.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access