GlassWorm Campaign: Zig Dropper Infects Developer IDEs via Open VSX

A sophisticated Supply Chain Attack has been identified targeting the software development community. According to The Hacker News, researchers have uncovered a new evolution of the GlassWorm campaign. This iteration leverages a malicious extension hosted on the Open VSX Registry, an open-source alternative to the Visual Studio Marketplace. The extension, titled ‘specstudio.code-wakatime-activity-tracker,’ is specifically designed to impersonate the popular WakaTime utility, a legitimate tool used by developers to track coding metrics and productivity.

Analysis of the GlassWorm Zig Dropper Evolution

The most notable shift in this campaign is the adoption of the Zig programming language for the primary payload. By utilizing a Zig-based dropper, the threat actors have significantly enhanced their ability to bypass traditional EDR solutions and signature-based detection. Zig is an emerging system-level language that produces highly efficient, low-level binaries. For attackers, it provides a unique advantage: its relatively low adoption in mainstream malware development means that many security tools lack mature heuristics to flag its compiled output as malicious.

The dropper is delivered once the malicious extension is installed within an Integrated Development Environment (IDE) such as Visual Studio Code, VSCodium, or Eclipse-based editors. Unlike traditional TTP sets that target a specific application, the GlassWorm dropper is designed for persistence across the entire host machine. It scans for the configuration directories of multiple IDEs, attempting to inject malicious code into every development environment it finds. This ensures that even if a developer switches between different editors, the infection remains active.

Technical Mechanics of the specstudio Extension

When a developer installs ‘specstudio.code-wakatime-activity-tracker,’ the extension performs a series of environment checks to confirm it is running on a high-value workstation. If the conditions are met, it pulls a secondary payload from a remote C2 server. This payload is the Zig-compiled executable, which manages the local infection process. This multi-stage approach minimizes the IoC footprint during the initial installation phase.

The use of Zig allows the malware to perform low-level system calls while remaining portable. Security researchers have noted that the dropper implements a custom obfuscation routine for its string tables, further complicating manual analysis. The primary goal of this infection appears to be credential harvesting and the exfiltration of sensitive environment variables, such as API keys and cloud service credentials, which are often stored in plain text within developer configurations.

Identifying and Remediating GlassWorm Campaign Developer IDE Security

To effectively detect GlassWorm Zig dropper activity, SOC teams must look beyond standard file hashes. Because the dropper is often customized or recompiled for different targets, hash-based detection is insufficient. Analysts should instead monitor for unusual child processes spawned by IDE binaries (e.g., code.exe or vscodium.exe) that attempt to modify configuration files in other IDE directories. This cross-IDE interference is a primary indicator of compromise.

Furthermore, the GlassWorm campaign underscores the risks inherent in the modern developer workflow, where third-party plugins are often trusted implicitly. The ability of the malware to facilitate Lateral Movement within a corporate network—by stealing the very credentials used to deploy code to production—makes this a high-priority threat for DevOps and security engineering teams.

Mitigation and Defense Strategies

Protecting the development pipeline requires a Zero Trust approach to IDE extensions. Organizations should consider the following Open VSX extension supply chain mitigation steps:

• Extension Whitelisting: Implement a policy that allows only verified extensions from known publishers within the organization’s IDE configuration.
• Internal Registries: Use an internal proxy for Open VSX or the VS Code Marketplace, where extensions are vetted by security teams before being made available to staff.
• Environment Secret Management: Discourage the use of local .env files or hardcoded credentials. Transition to managed secret stores that can be accessed via secure tokens rather than persistent local files.
• Endpoint Monitoring: Configure SIEM alerts for any write operations targeting IDE configuration paths (like .vscode or .idea) originating from unknown binary sources.

Defenders must treat developer workstations as critical infrastructure. As threat actors move further ‘left’ in the software development lifecycle, the integrity of the IDE itself must be protected with the same rigor as the production server environment.