CrowdStrike, Google, and Shadowserver Pulled the Plug on Glassworm at 14:00 UTC on May 26—a Russia Linked Developer Targeting Botnet That Hid Its Command and Control Channels Inside Solana Transaction Memo Fields, Google Calendar Event Titles, BitTorrent DHT Records, and VPS Backups, Poisoned More Than 300 GitHub Repositories, and Trojanized VSCode Extensions on OpenVSX for Over Two Years

For more than two years, an unnamed Russia speaking crew ran a developer focused botnet called Glassworm. It compromised more than 300 GitHub repositories by force pushing malicious code into default branches with stolen developer credentials. It published trojanized extensions on the OpenVSX marketplace that VSCode and Cursor users installed without realizing. And it hid the addresses of its command and control servers in places no defender could plausibly block: Solana transaction memo fields, Google Calendar event titles, and BitTorrent DHT records. On May 26, 2026, at exactly 14:00 UTC, CrowdStrike's Counter Adversary Operations team and Google severed all four channels at once.

Key Takeaways

• The Glassworm takedown happened at 14:00 UTC on May 26, 2026, coordinated by CrowdStrike, Google, and the Shadowserver Foundation, severing four independent command and control channels simultaneously.
• Glassworm encoded C2 server addresses in Solana blockchain transaction memo fields, base64 encoded paths inside Google Calendar event titles, BitTorrent DHT records keyed by hardcoded public keys, and a backup pool of traditional VPS infrastructure.
• The campaign targeted software developers specifically, poisoning more than 300 GitHub repositories using stolen credentials and publishing trojanized VSCode extensions on the OpenVSX marketplace.
• The payload, GlasswormRAT, was a full featured Node.js remote access tool with information theft, credential harvesting, and arbitrary command execution that ran across Windows, macOS, and Linux.
• The malware checked the victim's locale and exited silently on machines in CIS countries, which—along with Russian language code comments—is what attributes the operation to Russia speaking operators.

What Made Glassworm's Infrastructure Resilient?

Most botnet operators use one command and control channel. A few use two: a primary domain and a fallback. Glassworm used four, and the four were chosen specifically so that no single defender's takedown could kill the botnet.

According to CrowdStrike's takedown writeup, the four channels were:

• Solana blockchain. Every infected client queried a hardcoded Solana wallet for its recent transactions. The memo field of those transactions encoded the IP address or hostname of the current C2 server. Because the Solana blockchain is permissionless, no single party can stop the operators from posting new transactions.
• Google Calendar. Glasswork looked up event titles in a specific public calendar feed and base64 decoded the titles to retrieve a C2 path. A defender who blocked the calendar URL would also block legitimate Google Calendar access for every employee.
• BitTorrent DHT. Each client published and read records on the BitTorrent Distributed Hash Table, keyed by hardcoded public keys the operators controlled. DHT is global, decentralized, and built to route around blocked nodes.
• Direct VPS. A small pool of VPS hosted servers acted as the cheap, fast fallback when the other three channels were not needed.

Taking any single channel down would not have helped. The botnet was built to roll over to the next channel within minutes. The only way to win was to kill all four at the same instant.

How Did the Coordinated Takedown Work?

CrowdStrike spent months mapping Glassworm's infrastructure quietly before the takedown. Google, Shadowserver, and CrowdStrike's Counter Adversary Operations team then planned a synchronized strike. At 14:00 UTC on May 26:

• Google suspended the abuse account hosting the malicious Calendar feed.
• CrowdStrike registered the Solana wallets the malware was watching and posted a sinkhole memo redirecting beacons.
• Shadowserver poisoned the BitTorrent DHT records under the operators' public keys with sinkhole data.
• The remaining VPS infrastructure was suspended through hosting provider abuse channels.

Every Glassworm infected machine is now beaconing to a benign CrowdStrike controlled IP address: 164.92.88.210. CrowdStrike has asked defenders to search their logs for traffic to that address as a clean way to identify compromised hosts inside their own environments.

How Did Developers Get Infected?

Three vectors, all aimed at the same population:

• Trojanized OpenVSX extensions. OpenVSX is the open marketplace that VSCode forks like VSCodium and Cursor pull extensions from. Glassworm published extensions that performed their advertised function correctly while also dropping the loader on first install.
• Poisoned GitHub repositories. Using stolen developer credentials—often obtained from previous infostealer campaigns—the operators force pushed malicious commits into the default branches of more than 300 repositories. Anyone who pulled the next release ran the loader.
• Malicious npm and Python packages. Where a repository had a publish workflow tied to a credential the operators had stolen, Glassworm pushed poisoned package versions directly to npm and PyPI.

This is the same supply chain pattern we covered in the Nx Console VSCode credential stealer incident and the TanStack OIDC cache poisoning compromise. Glassworm just operated it at industrial scale, with infrastructure designed to survive a takedown.

What Is GlasswormRAT and What Does It Steal?

GlasswormRAT is a Node.js remote access tool—Glassworm runs anywhere Node.js runs, which is precisely why it threatened Windows, macOS, and Linux machines equally. CrowdStrike's analysis describes three functional pillars:

• Information theft. Browser cookies, session tokens, configuration files, SSH keys, AWS credentials, GitHub tokens.
• Credential harvesting. Specifically targeting developer tooling—the keychain entries for source control, package registries, and cloud providers.
• Full RAT capabilities. Arbitrary command execution, file upload and download, shell sessions, and the ability to download additional payloads.

The credentials Glassworm stole were not the end goal—they were the seed for the next wave of supply chain compromise. Every harvested GitHub token was a way to push malicious code into another set of repositories. Every harvested npm token was a way to publish another set of poisoned packages. Glassworm self propagated by stealing the keys to the next victim's codebase.

What Should Developers Do Right Now?

Three concrete actions:

1. Check your traffic for 164.92.88.210. Any beacon to that address from your workstation, CI runner, or build server indicates a Glassworm infection prior to the takedown.
2. Audit OpenVSX extensions installed since 2024. If you use VSCode, Cursor, or any VSCode fork that uses OpenVSX, review your extension list and remove any unfamiliar entries. Pay special attention to extensions with low install counts that you installed recently.
3. Rotate every credential that has been on a developer machine. GitHub personal access tokens, npm tokens, AWS keys, SSH keys, and browser session cookies. If your machine touched Glassworm, your credentials are presumed exfiltrated.

What This Means for Everyone Else

Developers are a leverage point: compromise one, and the malicious code that developer ships reaches every customer. Glassworm spent two years targeting the people who write the apps everyone else uses. The most useful protection an individual user can apply is a defense in depth that does not assume the inbox is safe—because the same operators who stole GitHub tokens are spending those credentials to send convincing phishing from real developer accounts.

Gblock blocks the tracking pixels that confirm phishing emails reached their target, which makes it harder for groups like Glassworm's operators to monetize stolen credentials by tuning follow on attacks. The botnet is down. The credentials it stole are still in circulation.