How cybersecurity firms took down Glassworm botnet in one shot

Pierluigi Paganini
May 27, 2026

Glassworm infected developers through poisoned tools and packages until a coordinated takedown killed all four of its C2 channels at once.

On May 26, 2026, at 14:00 UTC, CrowdStrike Counter Adversary Operations team, working with Google and the Shadowserver Foundation, killed all four command-and-control channels of the Glassworm botnet at the same time. The timing was the whole point.

Glassworm has been targeting software developers since at least early 2025. That’s a deliberate choice. Developers have access to source code, cloud credentials, CI/CD pipelines, and package registries. Compromise one developer’s machine and you potentially own everything downstream that developer has ever touched.

The GlassWorm campaign, active since 2025, has evolved from malicious npm packages to large-scale supply chain attacks across GitHub, npm, and VS Code, even deploying RATs via fake browser extensions.

In its latest iteration, threat actors used a malicious OpenVSX extension impersonating WakaTime, bundling a Zig-compiled binary. Instead of acting as the payload, the binary serves as a stealthy dropper that infects multiple IDEs on a system, showing the group’s continuous adapt

The operators ran three parallel infection campaigns. Trojanized VS Code extensions published to the OpenVSX marketplace posed as legitimate tools like time trackers and code formatters, targeting not just VS Code but also Cursor, Windsurf, VSCodium, and others. Malicious npm and Python packages executed harmful code silently during routine dependency installation. And more than 300 GitHub repositories were poisoned using developer credentials stolen from earlier Glassworm infections, with malicious code force-pushed into default branches. Not bad for a group that apparently had nothing better to do for over a year.

The C2 infrastructure was built to survive exactly the kind of operation that just took it down. The operators encoded server addresses into the memo fields of Solana blockchain transactions. Those fields can’t be modified or deleted — that’s the point of a blockchain. BitTorrent’s distributed hash table stored configuration data against hardcoded public keys, with no single server to seize. Google Calendar event titles held Base64-encoded C2 paths. Traditional VPS servers handled actual payload delivery.

“The combination of blockchain, peer-to-peer, and legitimate web services as resolution layers was designed to be resilient against takedowns — a dynamic front protecting the actual C2 servers behind multiple layers of indirection.” reads the report published by CrowdStrike.

The simultaneous strike against all the C2 channels was the only viable option, which required CrowdStrike, Google, and Shadowserver to coordinate precisely on timing and execute together. They did.

The malware itself, called GlasswormRAT, is a full-featured Node.js remote access tool. It steals credentials for npm, GitHub, and Git. It drains funds from cryptocurrency wallet extensions. It deploys SOCKS proxy servers and hidden VNC servers for persistent remote access. It also hides its code using Unicode variation selectors, rendering malicious characters invisible in standard code editors. Cute.

The researchers attribute the malware to Russian threat actors. The malicious code checks the victim machine’s locale, language settings, and timezone at startup and exits quietly if it detects a CIS country, a well-known evasion tactic among Russian-speaking threat actors who avoid causing problems on their home turf. The presence of Russian-language comments in the source code is another piece of evidence that supports the attribution. No single indicator is conclusive, but taken together the pattern is consistent.

“The operators behind Glassworm are well-resourced and persistent. Over the course of more than a year, they continuously evolved: adopting new programming languages (from JavaScript to Rust to Zig), expanding across package ecosystems (VSCode, npm, PyPI, GitHub), and building redundant infrastructure designed to survive takedown attempts.” continues the report. “Left unchecked, their access to developer credentials and systems posed ongoing risk of high-impact supply-chain compromises affecting organizations far beyond the initially infected developers.”

The access these operators had to developer credentials didn’t just threaten the infected machines. Every organization that consumes software built by a compromised developer was also exposed. Supply chain attacks work that way: the target isn’t the end user, it’s whoever built what the end user trusts.

CrowdStrike has now redirected all infected machines to beacon to a benign IP address they control: 164.92.88[.]210. Any organization that sees connections to that address in its network logs has a Glassworm infection that requires remediation. The experts published YARA rules for confirming infections.

“Adversaries are turning an organization’s dependencies on tools, updates, and libraries into weaponized delivery mechanisms and force multipliers. The barrier to poisoning a package or extension is low; the potential blast radius is enormous.” concludes the report. “As long as developer environments, build pipelines, and code repositories remain under-protected, every organization that consumes software inherits the risk of everyone who produces it. Glassworm demonstrates that attackers know this and are investing in resilient infrastructure to maintain persistent access to developer ecosystems.”

The takedown buys time. It doesn’t fix the underlying exposure. Package ecosystems have millions of libraries and limited built-in security controls. Malicious code can reach thousands of developers within minutes of publication. Detection after the fact is barely useful when the harm propagates this fast.

What this operation does demonstrate is that even infrastructure built for resilience has dependencies that can be targeted. The blockchain entries can’t be deleted, but the servers those entries point to can be taken down. The coordination required to do this at scale, across organizations, without tipping off the operators, is genuinely difficult. It worked here. The question is whether the security community can do it consistently enough to make this class of threat economically unviable for the people running it.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon