A developer-targeting botnet with one of the most resilient command-and-control architectures seen in recent memory has been dismantled. The Glassworm botnet, active since early 2025, was shut down on May 26, 2026 when CrowdStrike, Google, and the Shadowserver Foundation simultaneously cut off all four of its command-and-control channels in a precision operation. For organizations that build or consume software, the Glassworm botnet takedown carries a warning that extends far beyond the operation itself.
Why Developers Were the Target
Glassworm’s operators made a deliberate choice: go after the people who build software, not just the people who use it. Developers have access to source code repositories, cloud platforms, CI/CD pipelines, and package registries. Compromising a single developer’s machine can cascade through an entire software supply chain, potentially affecting thousands of organizations downstream.
The campaign started in October 2025 with malicious extensions published to the OpenVSX marketplace, the open-source alternative to Microsoft’s VS Code extension store. These trojanized extensions disguised themselves as popular tools like time trackers and code formatters. They targeted not just VS Code but also editors like Cursor, Windsurf, and VSCodium. Victims installed them without any reason to suspect anything was wrong.
Later waves expanded the scope considerably. Attackers injected malicious code into npm and Python packages via postinstall hooks and setup scripts, meaning the code ran silently during routine dependency installation. More than 300 GitHub repositories were also poisoned. Glassworm operators used stolen developer credentials from earlier infections to force-push malicious code directly into default branches, giving it immediate reach to anyone pulling from those repositories.
The malware deployed across Windows, macOS, and Linux. At the center of it was GlasswormRAT, a full-featured remote access tool built in Node.js. It harvested credentials for npm, GitHub, and Git, while also turning infected machines into proxy nodes under the operators’ control.
A C2 Architecture Built to Survive
What made the Glassworm botnet particularly difficult to disrupt was the way its operators engineered the command-and-control infrastructure. They did not rely on a single server or even a single method. Instead, they built four distinct C2 channels, each designed to resist conventional takedown efforts.
Solana Blockchain
The first channel used the Solana blockchain. Operators encoded C2 server addresses in the memo fields of blockchain transactions. Because blockchain entries are immutable and publicly accessible, this channel could not be taken offline through conventional means. There is no central authority to contact, no domain to seize, and no server to shut down.
BitTorrent DHT
The second channel leveraged the BitTorrent Distributed Hash Table network. GlasswormRAT queried this peer-to-peer network for configuration data stored against hardcoded public keys. The BitTorrent DHT is a global, decentralized network with no single point of failure. Disrupting it requires a fundamentally different approach than simply taking a server offline.
Google Calendar as a Dead-Drop
The third channel was more creative. Glassworm operators used Google Calendar event titles as dead-drop locations, embedding Base64-encoded C2 paths in what appeared to be ordinary calendar entries. Legitimate services like Google Calendar are rarely blocked on corporate networks, making this an effective way to hide malicious traffic in plain sight.
Direct VPS Connections
The fourth channel was a more traditional setup: direct connections to servers hosted on commercial VPS providers. These handled final payload delivery once the other channels had resolved the correct destination.
Together, this architecture formed multiple layers of indirection. Taking down one channel would have left the others functional, allowing the operators to quickly rebuild. The only viable option was a simultaneous strike across all four.
How the Takedown Worked
CrowdStrike coordinated the operation with Google and the Shadowserver Foundation. Precision and timing were everything. At 14:00 UTC on May 26, 2026, the joint team struck all four C2 channels at once. The operators lost access to their infected machines instantly and lost the ability to deliver new payloads.
As a result of the operation, infected machines now beacon to a CrowdStrike-controlled IP address: 164.92.88[.]210. Any organization that sees connections to this address in their network logs should treat it as a confirmed Glassworm infection and begin remediation immediately.
CrowdStrike has also published YARA detection rules to help security teams identify infected hosts. These rules look for characteristic strings inside the GlasswormRAT script and its obfuscated Python installer variant.
What This Means for Software Supply Chain Security
The Glassworm botnet is not an isolated threat, and the tactics it used are not unique to this campaign. It reflects a broader and deliberate shift in how sophisticated attackers approach their targets. Historically, most malware campaigns focused on end users or corporate networks. Glassworm targeted the people building the software those networks run on.
This approach offers attackers enormous leverage. A single compromised developer account, one poisoned npm package, or one malicious VS Code extension can reach thousands of organizations before anyone realizes something is wrong. The barrier to entry for attackers is low. The blast radius is enormous.
There are dozens of active package ecosystems, including npm, PyPI, OpenVSX, and GitHub, each hosting millions of packages with limited built-in security controls. Attackers can publish malicious code and reach a wide victim pool within minutes. Glassworm’s operators exploited this across multiple ecosystems for over a year, continuously evolving their tactics and infrastructure.
The operators themselves are likely Russia-based. The malware checks the victim’s locale, language, and timezone at runtime. If the machine appears to be in a CIS country, the malware exits quietly, a well-known pattern among cybercriminals operating from the region who avoid attracting attention at home. Russian-language comments also appear throughout the source code.
Final Thoughts
The Glassworm botnet takedown is a meaningful win, but it also makes the stakes of software supply chain security impossible to ignore. Developers are now a primary attack surface. Their tools, their package dependencies, and their code repositories are all active targets.
Detection alone is not a viable defense here. Malicious packages install in seconds during routine dependency updates. By the time a detection fires, the harm may already be done. The Glassworm operation shows what is possible when threat intelligence, platform cooperation, and precise timing come together. But it also shows how much infrastructure a determined threat actor can build and sustain over more than a year.
For organizations that write, ship, or consume software, the lesson is direct: the security of your supply chain is only as strong as the least-protected developer in it.
