GlassWorm Uses New Zig Dropper to Target Developer IDEs via Fake VS Code Extension

Executive Summary

A newly observed variant of the GlassWorm campaign is leveraging a custom Zig-based dropper embedded in a malicious Open VSX extension called specstudio.code-wakatime-activity-tracker. The extension pretends to be the legitimate WakaTime activity tracker for Visual Studio Code and other IDEs. Once installed, the dropper silently injects a payload into multiple development environments on the host, giving the adversary persistent code‑execution capability on developer workstations.

Technical Analysis

The malicious extension is distributed through the public Open VSX marketplace, where it mimics the naming and iconography of the genuine WakaTime plugin. Static analysis of the package revealed a compiled Zig binary (dropper.zig) that is executed during the extension's activation event. The dropper performs the following steps:

1. Environment enumeration – Detects installed IDEs (VS Code, JetBrains IDEs, Sublime Text) by scanning common installation paths and registry keys.
2. Privilege escalation – Attempts to gain write access to the IDE’s extension directory, falling back to user‑level execution if elevated rights are unavailable.
3. Payload delivery – Downloads an encrypted payload from a hard‑coded C2 domain (dlz9x[.]cloudfront.net) using TLS 1.2. The payload is decrypted with a XOR key derived from the host’s MAC address.
4. Persistence – Writes the payload as a hidden script (.vscode/extension.js) and registers it in the IDE’s startup configuration.
5. Command‑and‑control – Establishes a reverse HTTPS connection to the C2, allowing the attackers to execute arbitrary commands, exfiltrate source code, or deploy additional modules.

The use of Zig is noteworthy; the language compiles to a single static binary with minimal runtime dependencies, making detection by traditional AV heuristics more difficult. Researchers observed that the dropper disables its own file hash verification after the first run, reducing its footprint.

Tactics, Techniques & Procedures

Threat Actor Context

GlassWorm has been active since early 2024, primarily targeting software developers to gain early‑stage access to source code and intellectual property. The group’s previous campaigns used Go‑based droppers and leveraged compromised GitHub accounts. The shift to Zig suggests an effort to evade signature‑based detection and to produce smaller binaries. Attribution remains uncertain; however, the operational patterns align with previously observed activity linked to a loosely organized cyber‑crime forum based in Eastern Europe.

Mitigations & Recommendations

1. Validate extensions – Require developers to install extensions only from verified sources; enforce a whitelist in IDE policy settings.
2. Supply‑chain scanning – Integrate SAST/SCA tools that can detect compiled binaries within extension packages.
3. Network controls – Block outbound TLS connections to unknown CDNs unless explicitly required; monitor for unusual DNS queries to *.cloudfront.net from development workstations.
4. Endpoint hardening – Enable Application Control (e.g., Windows Defender Application Control) to block unsigned executables in user profile directories.
5. Incident response – If compromise is suspected, remove the malicious extension, delete hidden scripts, and rotate any credentials that may have been exposed in source repositories.