GlassWorm Takedown: CrowdStrike, Google, and Shadowserver Hit All Four C2 Channels at Once

The GlassWorm takedown is not a story about killing a botnet — it is a working template for how to disrupt a campaign built on public infrastructure no enterprise can outright block, and the operative word is simultaneity.

AUSTIN, TEXAS — On May 26-27, 2026, CrowdStrike's Counter Adversary Operations team, working in coordination with Google and the Shadowserver Foundation, executed a simultaneous takedown of all four command-and-control channels used by GlassWorm — the self-spreading software-supply-chain campaign that has targeted software developers since at least early 2025 through compromised open-source packages, malicious VS Code extensions, and poisoned GitHub repositories.

The defining feature of GlassWorm was a deliberately resilient C2 architecture: a Solana blockchain channel that carried C2 server addresses in transaction memo fields, a BitTorrent Distributed Hash Table channel that stored configuration data against hardcoded public keys, a Google Calendar channel that hid Base64-encoded C2 paths inside event titles, and a fourth channel that fell back on direct server connections. CrowdStrike said the four channels had to be hit at the same time to prevent the operators from rebuilding access through one while another was being seized.

What Happened

The takedown was announced across May 26-27, 2026 by CrowdStrike, with Google and the Shadowserver Foundation acknowledged as coordinating parties. CrowdStrike's Counter Adversary Operations team led the operation, and its central operational claim is the part that matters: all four of GlassWorm's command-and-control channels were neutralized at the same time. With the simultaneous strike complete, infected developer machines can no longer reach the campaign's operators through any of the four paths the malware was built to use — they cannot receive new instructions, cannot fetch new payloads, and cannot be redirected to a fresh channel.

GlassWorm itself was not a novel discovery this week. The campaign has been tracked since at least early 2025, and was first reported as a self-spreading VS Code extension worm in late 2025. It targets software developers systematically — through compromised open-source packages, malicious VS Code extensions, and poisoned GitHub repositories — and its self-spreading behavior is what carried it to a footprint large enough to require a coordinated multi-vendor takedown. CrowdStrike has not publicly attributed GlassWorm's operators to any named state or criminal group, characterizing them only as a developer-targeting threat actor.

The C2 Architecture That Made GlassWorm Hard to Kill

GlassWorm's resilience came from a deliberate engineering choice: its four command-and-control channels were built on public infrastructure that defenders cannot reasonably block. The first channel used the Solana blockchain, with C2 server addresses encoded in the memo fields of ordinary Solana transactions — a path that hides command data inside a public ledger that any infected machine can read. The second used the BitTorrent Distributed Hash Table, querying the DHT for configuration data stored against hardcoded public keys; the DHT is the same peer-to-peer lookup network that ordinary BitTorrent clients depend on, and an enterprise that blocks it wholesale also breaks legitimate file-sharing traffic. The third used Google Calendar, treating event titles as dead-drop locations that carried Base64-encoded C2 paths — a channel that rides on a service no enterprise can outright deny. The fourth fell back on direct server connections, the only piece of the architecture that resembles a conventional C2. Three of the four channels are services no organization can outright deny without significant collateral damage; that is what made the campaign hard to kill.

Why Simultaneity Was the Operational Key

CrowdStrike was explicit about the operational reason all four channels had to fall together: a one-at-a-time approach would have let the operators rebuild access through whichever channels remained. Take down Solana first and the operators move their primary signaling to Google Calendar or the BitTorrent DHT while they spin up a new wallet; take down Google Calendar first and they fall back to direct server connections while they rotate. The architecture was designed to be redundant, and a redundant architecture is broken by simultaneous strikes, not sequential ones. The coordination problem that solves — getting a private vendor, a hyperscale cloud and email provider, and a non-profit threat-intelligence organization to act in concert at the same instant against the same target — is the part of the operation that is genuinely difficult, and arguably the most replicable lesson for the rest of the industry.

A Multi-Vendor Coordinated Takedown — and the Cluster It Sits In

The GlassWorm takedown is the most operationally sophisticated developer-supply-chain takedown of 2026 to date, but it lands inside a broader enforcement cadence that The CyberSignal has been tracking. The same six-week stretch produced Operation Endgame 2.0, in which Europol took down 300 servers and named 20 operators of the ransomware supply chain, Europol's first VPN takedown aimed at cybercrime anonymity infrastructure, the Netherlands seizure of roughly 800 Stark Industries bulletproof-hosting servers, and the Canadian arrest of the alleged KimWolf DDoS-for-hire botmaster. The developer-supply-chain target surface that GlassWorm exploits is the same one the published TrapDoor campaign weaponized across npm, PyPI, and Crates by poisoning AI coding assistants, that TeamPCP exploited via a poisoned VS Code extension to exfiltrate 3,800 internal GitHub repositories, and that the Megalodon campaign hit at scale by backdooring 5,561 GitHub repositories through CI/CD workflows. Read together, the takedown and the cluster of campaigns it disrupts are two halves of the same story.

Scope and Impact

The reach of the takedown is bounded by what it is. The strike neutralizes all four C2 channels and severs the operators' ability to push new instructions or payloads to infected developer machines — that is the post-takedown state CrowdStrike has confirmed. What the takedown does not do is reverse anything GlassWorm did before May 26-27. Any credentials harvested from an infected machine, any GitHub or npm token exposed during a compromise, any package or repository tampered with during the campaign's lifetime — none of that is undone by cutting the C2. For organizations whose developer endpoints showed historical GlassWorm activity, the right framing is credential-compromise event, not closed incident.

Several specifics remain unconfirmed and should not be inferred. The identity and origin of GlassWorm's operators have not been publicly disclosed, and CrowdStrike has not attributed them to any named state or criminal group. The total number of compromised developer machines worldwide has not been published. Whether infected machines were used for credential theft alone, or also for downstream supply-chain insertion into open-source packages, extensions, or repositories, is not publicly stated. Which packages, extensions, or repositories were ultimately poisoned — the downstream blast radius — is not enumerated in the public reporting. Whether the takedown disrupted any active in-progress supply-chain attack, whether the operators retain any unrevealed C2 capability that was not part of the four-channel architecture, and whether any specific arrests or legal actions have followed are likewise not stated. This account does not imply otherwise.

Distinguishing GlassWorm from a similarly named actor is worth doing explicitly. GlassWorm is a developer-targeting self-spreading supply-chain campaign documented by CrowdStrike. Webworm is a published China-aligned APT cluster covered separately in industry reporting and on this site; the two should not be conflated. GlassWorm's operators have not been publicly tied to Webworm or to any other named group.

Response and Attribution

For DevSecOps and developer-fleet teams, the immediate action is an audit of developer endpoints for GlassWorm indicators of compromise. CrowdStrike has published indicators with its takedown writeup, and the durable detection signatures are behavioral: outbound connections from developer machines to Solana RPC endpoints, BitTorrent DHT traffic originating from processes that are not torrent clients, and anomalous programmatic access to Google Calendar APIs from developer endpoints. Inventory installed VS Code extensions and review repository-clone activity for the last twelve months. Restrict VS Code extension installation to an organizational allowlist — the same control that would have blunted the TeamPCP VS Code extension breach applies directly here. If any developer machine shows historical GlassWorm activity, treat it as a credential-compromise event: rotate GitHub tokens, npm tokens, cloud credentials, and SSH keys, and apply the staged-publishing and 2FA-gated release-approval controls that npm has been moving the ecosystem toward.

For SOC and threat-hunting teams, the durable lesson is the decentralized-C2 detection signature. Hunt for non-business processes communicating with public blockchain RPCs, the BitTorrent DHT, or programmatically with Google Calendar APIs from endpoints that have no business reason to use them. Treat the takedown of a resilient botnet as a temporary disruption window, not a final state — operators of resilient campaigns historically reconstitute, and the right posture is to use the window to harden detections rather than to assume the threat is closed.

For CISOs and policy-side stakeholders, GlassWorm is the operational template the industry will follow for resilient blockchain and decentralized C2: vendor-coordinated, multi-channel, simultaneous-strike. Blocking malicious infrastructure no longer works against actors who route through services an enterprise cannot block. Behavioral detection of unusual processes using normal services is now the durable defensive posture. The CrowdStrike, Google, and Shadowserver model — a private-sector-led, multi-vendor coordinated takedown — is a useful reference point in policy engagement on public-private cyber-defense partnerships, and the Solana abuse angle is an emerging policy point in its own right: cryptocurrency networks are now operationally used as C2 substrate, not just as a payment rail. On attribution, the honest position is that there is none beyond a developer-targeting threat actor.

The CyberSignal Analysis

Signal 01 — The C2 Was Built on Services Defenders Cannot Block

Most coverage of the GlassWorm takedown will lead with the names of the participants — CrowdStrike, Google, Shadowserver — and the fact that all four channels fell at once. The detail underneath that headline is the architectural one. GlassWorm's operators built their command-and-control on the Solana blockchain, the BitTorrent Distributed Hash Table, and Google Calendar. None of those is a fly-by-night service that a corporate firewall can quietly block. A blockchain is a public ledger any machine can read; the BitTorrent DHT is the same peer-to-peer lookup network ordinary clients use; Google Calendar is core productivity infrastructure. An attacker who routes through services no enterprise can deny has effectively turned the open internet's most legitimate plumbing into a C2 backbone. The defensive implication is not that those services should be blocked but that behavioral detection — non-business processes talking to consumer services in non-consumer ways — is now the durable signature for this class of campaign.

Signal 02 — Simultaneity Is the Replicable Lesson

It is worth being precise about what was novel here. The takedown is not the first multi-vendor effort against a developer-targeting threat actor; it is the first to dismantle a four-channel resilient C2 architecture in a single operational beat. The operational claim CrowdStrike made — that hitting one channel at a time would have let the operators rebuild through the others — is the lesson that generalizes. Resilient architectures fall to simultaneous strikes, not sequential ones, and the coordination problem the GlassWorm operation solved is the model the rest of the industry will be measured against. Standing up a coalition that can act in unison against a single target at a single moment is harder than any single technical disruption, and it is the part of the GlassWorm playbook that scales.

Signal 03 — The Window Closes, the Surface Does Not

The developer toolchain is the soft path into nearly everything downstream of it, and GlassWorm exists because that surface is large, valuable, and under-defended. The takedown closes a window — operators cannot reach infected machines through the four channels they built — but it does not change the underlying target surface. The same developer endpoints, the same VS Code extensions, the same package registries, the same GitHub repositories that GlassWorm exploited are still there, and the same attractor that drew GlassWorm's operators to them will draw the next campaign. Treat the post-takedown period as the moment to do the work the campaign exposed: extension allowlisting, token rotation, repository-clone auditing, and behavioral detection for processes that have no business reason to be talking to public blockchains or peer-to-peer lookup networks. The era in which a takedown ended a story is over; the era in which it opens a remediation window is the one defenders now have to plan around.

Sources