GlassWorm Campaign: Zig Dropper Targets Developer IDEs Through Malicious Extensions

The GlassWorm malware campaign has taken a significant turn, now leveraging a new Zig-based dropper to silently compromise developer workstations. By disguising itself as a legitimate productivity tool, the campaign specifically targets integrated development environments (IDEs), putting both source code and software supply chains at risk. Understanding this technique is critical for businesses that rely on internal development teams or third-party software vendors.

Key Takeaways

• GlassWorm now uses a Zig dropper to deliver malware and infect multiple IDEs on a single machine.
• A malicious Open VSX extension impersonating a WakaTime activity tracker was used to distribute the payload.
• Development environments and code repositories face heightened risk, including supply chain compromise.
• Businesses must harden developer machines with extension vetting, endpoint security, and strict access controls.

How the GlassWorm Campaign Evolved

The GlassWorm campaign is an ongoing malware operation that has adapted over time to evade detection and maximize reach. The latest wave introduces a Zig-based dropper, a small program written in the Zig programming language, designed to act as a flexible and stealthy delivery mechanism for additional malicious components.

Instead of directly deploying obvious malware, the attackers use the dropper to establish a foothold, perform environment checks, and selectively download or execute payloads. This modular design gives the attackers better control and helps them bypass traditional security tools that focus on known signatures or static patterns.

Why Target Developer Environments?

Developer workstations are uniquely valuable targets. They typically host:

• Source code for proprietary applications and services
• API keys, credentials, and configuration files
• Build tools and deployment pipelines that can be abused for supply chain attacks

By compromising a single developer IDE, threat actors can potentially introduce backdoors into production code, steal intellectual property, or pivot deeper into an organization’s infrastructure.

The Malicious Open VSX Extension Disguise

Researchers identified the new technique within an Open VSX extension named "specstudio.code-wakatime-activity-tracker". This extension impersonates WakaTime, a widely used coding activity tracker that integrates with various IDEs to monitor development time and productivity.

Because WakaTime is familiar and trusted in many developer communities, a fake extension using a similar name and description can easily pass as legitimate—especially when busy developers are simply searching for “WakaTime” or “activity tracking” in the marketplace.

“The attackers bank on developer trust in popular extensions, weaponizing productivity tools to gain long-term, silent access to development environments.”

Distribution Through Open VSX

Open VSX is an open-source marketplace for extensions primarily used by IDEs like VSCodium, Eclipse Theia, and other VS Code-compatible tools. By publishing the malicious extension there, the attackers gain broad reach across multiple platforms that support the same extension ecosystem.

Once installed, the extension can execute the Zig dropper under the guise of normal extension behavior, making it far less obvious than a traditional standalone executable.

The Role of the Zig Dropper in the Attack Chain

The Zig dropper is a small but powerful component at the core of this GlassWorm variant. Written in the Zig language, it benefits from:

• Low-level control over system resources
• Performance and portability across platforms
• A relatively low profile compared to more common malware languages

Multi-IDE Infection Strategy

Once executed, the dropper’s goal is to infect all IDEs present on the developer’s machine. This may include:

• Visual Studio Code or VSCodium
• JetBrains IDEs (e.g., IntelliJ IDEA, WebStorm, PyCharm)
• Eclipse-based IDEs
• Other development tools that support compatible extensions or configuration scripts

By targeting multiple IDEs, the attackers increase their persistence and coverage. Even if a developer switches tools or reinstalls one IDE, the compromise can persist in others, making the infection harder to fully eradicate.

Stealth and Persistence Techniques

The Zig dropper can perform a variety of actions depending on the attacker’s objectives and the security posture of the host system, such as:

• Modifying configuration files or startup scripts to ensure persistence
• Deploying additional malicious plugins or scripts into IDE directories
• Establishing command-and-control (C2) communication for remote control
• Scanning for SSH keys, tokens, or other sensitive credentials stored locally

Because these operations are tied to everyday development tools and workflows, anomalous behavior may be difficult for users to spot without specialized monitoring.

Risks for Businesses and Development Teams

This campaign is not just a technical curiosity; it has direct implications for businesses that rely on software development, whether in-house or through vendors. A compromised developer environment can become a gateway to broader organizational compromise.

Supply Chain and Intellectual Property Threats

Once attackers gain access to developer IDEs, they can:

• Insert backdoors or malicious code into applications before build and deployment
• Exfiltrate source code and proprietary algorithms
• Harvest secrets from configuration files, environment variables, and build scripts
• Manipulate CI/CD pipelines to distribute tainted software to customers or internal systems

For organizations that distribute software or operate SaaS platforms, this kind of compromise can lead to large-scale security incidents, reputational damage, and regulatory consequences.

Impact on Security and Compliance

From a cybersecurity and compliance standpoint, a campaign like GlassWorm touches multiple areas:

• Data protection: Unauthorized access to source code and customer-related logic
• Access control: Abuse of developer privileges to move laterally in the network
• Audit and logging: Difficulty in tracing subtle code-level changes or injected behavior
• Regulatory compliance: Potential violations of data handling and security standards

These risks make it essential for organizations to treat developer endpoints as high-value assets requiring the same rigor as production servers and critical infrastructure.

Defensive Measures: Securing Developer IDEs

Mitigating threats like the GlassWorm Zig dropper requires a combination of technical controls, process improvements, and user awareness. Both business leaders and technical teams should align on a strategy that treats development environments as part of the broader security perimeter.

Harden Extension and Tooling Management

Organizations should implement safeguards around how extensions and tools are installed on developer machines:

• Adopt a trusted extension list and restrict installations to vetted publishers.
• Use centralized configuration management (e.g., policies for IDEs and package managers).
• Audit existing extensions regularly for anomalies in names, publishers, or permissions.

Where possible, consider mirroring or proxying extension repositories through an internal, controlled registry that allows security teams to review new tools before adoption.

Strengthen Endpoint and Network Security

Developer endpoints should be protected with enterprise-grade security tools:

• Deploy EDR/XDR solutions capable of detecting unusual process behavior and network connections.
• Enforce least privilege on developer accounts and local system access.
• Use network segmentation and zero-trust principles to limit lateral movement.

Monitoring outbound traffic from developer machines can also help identify suspicious C2 communication related to droppers or installed malware.

Integrate Security into the SDLC

Adding security checks directly into the software development lifecycle (SDLC) can help detect issues introduced by compromised environments:

• Implement code signing and verify signatures in build pipelines.
• Use static and dynamic application security testing (SAST/DAST) in CI/CD workflows.
• Require peer review and approvals for critical code paths and configuration changes.

Combined with robust logging and version control practices, these measures make it easier to spot unusual or malicious modifications originating from infected IDEs.

Conclusion: Treat Developer Workstations as Critical Infrastructure

The latest evolution of the GlassWorm campaign, powered by a Zig-based dropper embedded in a fake WakaTime-like extension, demonstrates how attackers are targeting the heart of modern software development: the IDE. By infiltrating the tools developers rely on every day, threat actors can quietly compromise entire software supply chains.

For businesses, the lesson is clear. Developer environments must be defended with the same rigor as production systems. That means controlling extension usage, investing in endpoint and network security, and embedding security controls into your development process. Ignoring these risks can turn a single malicious extension into a widespread organizational breach.