Glassworm Takedown: When C2 Hides in Solana, BitTorrent, and Google Calendar

At 14:00 UTC on 2026-05-26, CrowdStrike, Google, and the Shadowserver Foundation coordinated a takedown of Glassworm — a self-spreading supply-chain botnet that had been quietly distributing trojanized VS Code extensions, npm packages, and force-pushed GitHub commits for over a year. The novelty isn't the malware. The novelty is where the malware looked for its instructions. Glassworm's operators ran command-and-control over four parallel channels: memo fields in Solana blockchain transactions, the BitTorrent peer-to-peer distributed hash table, event titles on Google Calendar, and a small fleet of commercial VPS. To every signature-based NDR, NGFW, and outbound-reputation tool on the market, the first three channels look like a developer who uses crypto, torrents, and Google Workspace. Which is to say: most developers.

What was actually taken down

The takedown action was a joint disruption of all four C2 channels simultaneously, not the underlying malware. CrowdStrike's blog frames the operation as cutting Glassworm's "resilient command-and-control infrastructure" — Google revoked the Calendar event accounts being used as dead drops, Shadowserver sinkholed the VPS layer and the BitTorrent DHT keys, and CrowdStrike's counter-adversary team handled the Solana side via on-chain attribution and wallet flagging. BleepingComputer reports the campaign was responsible for the distribution of at least 73 sleeper extensions on the OpenVSX marketplace and "more than 400 software artifacts" across GitHub and npm in aggregate. CrowdStrike independently cites more than 300 GitHub repositories with malicious force-pushes from credentials harvested by prior infections.

The malware itself is not gone. Already-infected developer machines remain implanted; they have simply lost the ability to receive new tasking — until the operators rebuild the C2 layer, which they will, because supply-chain botnets are economically rational and have a track record of coming back online weeks after every takedown going back to Storm Worm in 2008.

The four C2 channels — and why each one was invisible

Glassworm's C2 design is the part defenders should sit with. Each channel was chosen because it sits inside a flow that enterprise egress filtering is paid to let through.

Solana memo fields. Solana transactions carry an optional memo field — a few hundred bytes of free text intended for legitimate use cases like attaching a customer ID to a payment. Glassworm encoded its C2 server addresses in those memos. The cost to publish a memo is a fraction of a cent. From the wire, an infected host querying Solana RPC endpoints (api.mainnet-beta.solana.com and similar) looks identical to a developer running a personal wallet against the public network. There is no domain to block without breaking the public blockchain.

BitTorrent DHT. The BitTorrent peer-to-peer distributed hash table is a globally-shared key-value store designed to be censorship-resistant. Glassworm queried the DHT for configuration data stored against hardcoded public keys controlled by the operators. The traffic pattern is UDP datagrams to thousands of peers across residential and hosting providers — visually identical to a torrent client. Most enterprises do not block BitTorrent at the gateway anymore because Linux ISO distributions and game patches legitimately use it.

Google Calendar event titles. This is the most elegant of the four. Glassworm operators created Google Calendar events whose titles contained Base64-encoded C2 path fragments. Infected hosts polled the legitimate Google Calendar API for events on attacker-controlled calendars. From the perimeter, this is calendar.google.com traffic from an authenticated Google Workspace session. No outbound-reputation product on the market scores google.com as malicious. The defender is asked to choose between blocking Calendar entirely or accepting that any string in any event title is a potential dead drop.

Commercial VPS. The fourth channel is the boring one — traditional C2 hosted on rented VPS. It exists as the fallback when the other three are noisier than usual. Even this layer was rotated frequently enough that domain-reputation feeds did not catch it in time.

The defensive significance is that the first three are categorically different from the VPS layer. They are not C2 infrastructure that defenders failed to detect; they are C2 infrastructure designed to be statistically indistinguishable from legitimate traffic. Blocking the protocol breaks legitimate use. Blocking the destination breaks legitimate use. The signal — if there is one — is in the behaviour of the calls, not the calls themselves.

How developer machines got there in the first place

Glassworm's entry was the OpenVSX marketplace and a smaller number of trojanized npm and (per CrowdStrike) PyPI packages. According to BleepingComputer's reporting, 73 sleeper extensions on OpenVSX carried Glassworm payloads. OpenVSX is the open-source registry that VSCode-derivative editors (VSCodium, Theia, Gitpod, Eclipse Che) pull extensions from. It does not have the same review pipeline as the official Microsoft marketplace. A vsx install is a package.json install — the extension runs JavaScript in the editor's context, with the same filesystem permissions as the developer.

Once installed, Glassworm harvested credentials from the developer machine — git credential managers, browser cookies, IDE-cached PATs, npm tokens — and used those credentials to force-push malicious commits to repositories the victim had write access to. That is how the campaign reached 300+ GitHub repositories without the operators ever needing to compromise GitHub itself. It is also why CrowdStrike's report flags Glassworm's behaviour as self-spreading: the second-stage propagation is not on the operators' infrastructure at all.

CrowdStrike notes locale and timezone checks in the implant that silently exit on machines configured for CIS countries — the long-standing tell of Russian-speaking operators, though no public attribution to a named adversary has been made.

Why your current stack didn't see it

The post-mortem question is the only one that matters. Defenders who already had a SOC, a SIEM, a modern EDR, an NDR appliance, and an NGFW saw exactly nothing of Glassworm for over a year. The reason is not laziness. It is the design of the detection stack.

"We see the egress to calendar.google.com. We see the egress to api.mainnet-beta.solana.com. We see the BitTorrent peers. None of those are on a blocklist, none of them have a low reputation score, and we have legitimate users hitting them every day. What were we supposed to alert on?"

That is a paraphrase of every NDR analyst who reviewed the Glassworm IOC list this week. They are right. Signature- and reputation-based detection cannot solve this category, because the signature is legitimate traffic.

The detectable signal exists, but it lives in places signature engines do not look:

• Beacon timing. Glassworm's poll cadence against the Calendar API and the Solana RPC is regular in a way human developer use is not. Once you have a baseline of what a real Workspace user looks like, the bot beat is visible.
• Endpoint context. A developer laptop that suddenly starts querying Solana RPC having never done so before is a behavioural anomaly even if Solana is on no blocklist. The signal is in the change, not the destination.
• Volume asymmetry on shared infrastructure. Hosts that pull config from BitTorrent DHT every few minutes for weeks, with no corresponding torrent download payload, are running a control plane — not a torrent client.
• Process-network correlation. A VSCode extension process making outbound calls to a Google API is normal. The same extension process making outbound calls to a Solana RPC endpoint is not.

All four of these signals are statistical, not signature-based. They are exactly what a deep-learning network model trained on baseline traffic flags as a deviation — and exactly what the perimeter products on the receipt side of the procurement cycle do not generate.

The detection problem this leaves behind

Glassworm is a milestone in a pattern that has been building for three years. The 2023 npm typo-squatting waves were detectable at the registry. The 2024 signed-but-malicious supply-chain problem was detectable at the attestation layer. Glassworm's C2-in-legitimate-channels approach is detectable only on the wire, in real time, against a behavioural model — because by the time the package is installed and the implant is running, attestation, reputation, and signature have all already passed their checks legitimately.

The takedown will buy defenders weeks. The 73 OpenVSX extensions are removed. The Calendar accounts are revoked. The Solana wallets are flagged. None of this prevents the next iteration, which will use a different blockchain, a different Calendar-equivalent, and a different peer-to-peer overlay. The C2-hidden-in-legitimate-traffic design is now part of the threat-actor toolbox, and the perimeter products that missed it the first time will miss the next one too — because the missing detection isn't a vendor failure, it's a category failure.

Where Zero Hunt fits in the post-Glassworm world

This scenario is exactly what the Zero Hunt platform's AI Traffic Analysis pillar was engineered for. The appliance runs a proprietary deep-learning model with four parallel inference heads — suspicious traffic, malware classification, attack-type identification, application fingerprinting — trained on billions of PCAP sequences and inferring locally on the appliance GPU at 2.7+ Gbit/s. It does not call a reputation feed. It does not need a destination to be on a blocklist. It looks at the shape of the traffic: timing, volume asymmetry, process-flow correlation, deviation from the host's own baseline.

A VSCode extension on a developer laptop beaconing every 90 seconds to a Solana RPC endpoint where the same machine had no prior crypto activity is a deviation. A residential laptop publishing BitTorrent DHT queries with no torrent payload is a deviation. An authenticated Google Workspace session whose Calendar API call pattern doesn't look like a human checking their schedule is a deviation. None of these are reputation calls. All of them happen on the wire, locally, in real time — which is the only place the Glassworm-class problem is detectable at all.

The complementary generative pentest pillar closes the loop on the perimeter side: continuous validation that the developer-laptop attack path the Glassworm campaign actually used — IDE plugin install → credential harvest → outbound to non-corporate API — is one of the chains the 10-agent swarm regenerates per environment, backtested via AI Gym before it ever runs against a real network. And on the compliance side, every traffic-side detection and every continuous-validation finding is mapped against NIS2, DORA, and ISO 27001 controls with ECDSA-signed evidence, so the supply-chain-detection capability translates directly into auditor-ready proof.

If you want to see what Glassworm-class detection actually looks like against your own perimeter and developer traffic, open a conversation. The takedown was the easy half. The detection is the half that's still on the defender.