Supply Chain Risk: Zig Dropper Masquerading as WakaTime Extension
Hey everyone, catching up on the latest IOCs regarding the GlassWorm campaign. It looks like they've shifted tactics to a Zig-based dropper embedded in a malicious Open VSX extension: specstudio.code-wakatime-activity-tracker.
What makes this nasty is the cross-platform potential. Since it targets the Open VSX registry, it doesn't just stop at VS Code; it potentially hits Eclipse, Theia, or any IDE configured to pull from there. The Zig language allows them to compile small, static binaries without the usual runtime dependencies (like Python or Node), which might help slip past some EDR heuristics that flag script interpreters.
I've put together a quick PowerShell snippet to hunt for the specific malicious extension ID on your dev workstations:
# Hunt for the malicious extension in VS Code extensions folder
$MaliciousID = "specstudio.code-wakatime-activity-tracker"
$Extensi
if (Test-Path $ExtensionsPath) {
Get-ChildItem $ExtensionsPath -Directory |
Where-Object { $_.Name -like "*$MaliciousID*" } |
Select-Object FullName, LastWriteTime
}
Also, keep an eye out for unexpected zig.exe or zig process executions in your SIEM, especially spawning from the IDE process tree.
How are your orgs handling third-party extension vetting? Are you relying on the VS Marketplace, or have you moved to strict internal registries?
Solid hunt script. We've seen a rise in these 'dev-tools-as-malware' vectors. We added a KQL rule to our Sentinel instance to flag any execution of the Zig compiler where the parent process isn't an authorized CI/CD runner or a known developer workstation.
Process
| where ProcessVersionInfoOriginalFileName == "zig.exe"
| where InitiatingProcessFileName !in ("cmd.exe", "powershell.exe", "code.exe", "bash")
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName
Since Zig isn't standard in most enterprise images, false positives have been low.
This is exactly why we enforce the --disable-extensions flag on our build servers. It's a pain for the devs initially, but it creates a necessary air gap. For local dev boxes, we proxy the Open VSX registry through an internal Sonatype Nexus instance. We manually review and whitelist extensions before they sync to the internal repo.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access