CrowdStrike, Google & Shadowserver Dismantle GlassWorm Developer Botnet

In one of the most significant coordinated disruptions of developer-targeting malware infrastructure to date, CrowdStrike, in partnership with Google and the Shadowserver Foundation, has announced the simultaneous neutralisation of all command-and-control channels associated with GlassWorm, a persistent software supply chain campaign that has systematically targeted software developers since at least early 2025.

GlassWorm is not a conventional malware campaign. It was purpose-built to exploit the specific characteristics of software developer environments, targeting a population with privileged access to source code repositories, cloud platforms, CI/CD pipelines, and package registries. By compromising a single developer workstation, GlassWorm operators could leverage that access to propagate malicious code into software builds, package releases, and downstream organisational environments, creating a force multiplier effect that extends far beyond the initial victim.

How GlassWorm Operated

GlassWorm conducted a multi-pronged campaign across several attack vectors simultaneously. The primary delivery mechanism was trojanised VS Code extensions published on both the official Microsoft VS Code Marketplace and Open VSX, the extension registry used by VS Code forks including Cursor, Positron, Windsurf, and VSCodium. By publishing malicious extensions to both registries, the operators ensured that developers using any of the major VS Code variants were within the campaign's reach.

Alongside the extension-based delivery, GlassWorm introduced malicious code through compromised npm and Python packages, targeting developers across web development, data science, and backend engineering communities. The campaign also poisoned more than 300 GitHub repositories using stolen developer credentials, injecting malicious code into repositories that other developers and organisations would clone, fork, and incorporate into their own builds.

Once active on a compromised developer workstation, the malware conducted systematic credential harvesting, searching for GitHub tokens, npm access tokens, Open VSX credentials, and cryptocurrency wallet files. It also deployed a Websocket-based JavaScript remote access trojan called GlassWormRAT, which was capable of stealing web browser data, running arbitrary code, and installing a malicious Google Chrome extension that harvested screenshots, keystrokes, and clipboard content from the infected system.

Endor Labs researcher Kiran Raj documented the full scope of the post-compromise capability: "Once active, the malware searches the host for developer credentials, enabling further compromise of repositories and package uploads." Infected hosts were also converted into covert infrastructure, functioning as SOCKS proxies, hidden VNC servers, and remote execution nodes via WebRTC or spawned Node.js processes, giving operators anonymised network access into corporate and personal networks and a persistent platform for further propagation.

Four C2 Channels Built for Takedown Resilience

What made GlassWorm operationally distinctive was the sophistication of its command-and-control architecture. Rather than relying on a single C2 infrastructure layer, the operators built four separate resolution mechanisms designed to ensure the botnet could survive any single takedown attempt.

The first channel used the Solana blockchain as a dead drop resolver, storing C2 server addresses in the memo fields of blockchain transactions. Because blockchain data is immutable and globally distributed, this channel was specifically designed to be resistant to domain seizure or server shutdown.

The second channel queried the BitTorrent Distributed Hash Table peer-to-peer network to retrieve configuration data, again exploiting a decentralised infrastructure that cannot be taken offline through conventional means.

The third channel abused Google Calendar as a dead drop, fetching the C2 server address from the titles of calendar events. By using a legitimate and widely trusted Google service as a covert communication channel, the operators bypassed many corporate firewall and proxy inspection rules that would flag connections to unknown external infrastructure.

The fourth channel was direct connection to C2 infrastructure hosted on commercial VPS providers, the conventional fallback layer that the three alternative channels were designed to protect.

CrowdStrike described the architecture as "designed to be resilient against takedowns, a dynamic front protecting the actual C2 servers behind multiple layers of indirection." To neutralise GlassWorm effectively, all four channels had to be disrupted simultaneously, which is precisely what the coordinated operation achieved. Infected machines can no longer receive new instructions or payloads.

Attribution and Scale

CrowdStrike attributed GlassWorm to likely Russia-based cybercriminals based on two indicators: the malware terminates execution on systems located in Commonwealth of Independent States countries, a common technique used by Russian-speaking threat actors to avoid targeting domestic systems, and the malware source code contains Russian-language comments.

The full operational scope of GlassWorm is significant. More than 300 GitHub repositories were poisoned using stolen developer credentials. The campaign ran across multiple package ecosystems and extension registries simultaneously. The botnet infrastructure was built across four independent C2 channels. And the malware converted every infected developer workstation into a node within a covert network that could be used for anonymised access, further propagation, and credential relay.

This is precisely the software supply chain risk that security teams across the GCC and MENA region have been warned about. As AI-powered vulnerability detection tools accelerate the pace at which defenders can identify weaknesses, threat actors are responding by embedding themselves deeper into the development pipeline itself, where conventional security tooling has limited visibility.

Why This Matters for GCC Development Teams

CrowdStrike's conclusion from the investigation is direct: "The software supply chain remains one of the most consequential attack surfaces in modern computing. Adversaries are turning an organisation's dependencies on tools, updates, and libraries into weaponised delivery mechanisms and force multipliers. The barrier to poisoning a package or extension is low; the potential blast radius is enormous."

For GCC enterprises with software development teams, this is an operational warning, not a theoretical one. Development environments across Saudi Arabia and the UAE that use VS Code, consume npm or Python packages, or clone open-source repositories from GitHub are within the attack surface that GlassWorm exploited. The takedown disrupts the current infrastructure, but the technique is replicable and the operators remain active.

Security teams should immediately audit VS Code extensions installed across developer workstations against known-good lists, review recently installed npm and Python packages for anomalous publisher accounts or unusual permission requests, rotate GitHub tokens and npm access tokens for any developer whose workstation may have been compromised, and check for unexpected outbound connections to VPS infrastructure, BitTorrent DHT peers, or unusual Google Calendar API activity.

The MuddyWater Microsoft Teams false flag operation previously documented how threat actors exploit trusted platform communications to deliver payloads. GlassWorm extends that same principle to the development toolchain itself, where trust in the extension marketplace and package registry is the vulnerability being exploited.