Nobody talks about why supply-chain attackers started hiding command servers inside Google Calendar events and Solana memo fields — and the Glassworm takedown finally explains it

Glassworm was, until last week, one of the more technically interesting pieces of malware circulating through the open source ecosystem. It propagated through compromised npm and OpenVSX packages, the kind of dependencies that developers install without a second thought, and used infected developer machines to steal credentials, hijack cryptocurrency transactions, and quietly recruit those machines into a wider botnet.

What made it notable was not the payload but the plumbing. Glassworm pulled its command-and-control instructions from Solana blockchain memo fields, Google Calendar event descriptions, and a peer-to-peer fallback network, rotating between them as needed. Last week, a coordinated takedown by security researchers and platform operators dismantled the operator infrastructure, and in doing so finally provided a public explanation for a technique that has been quietly spreading across supply-chain malware families for the past eighteen months.

The structural problem this exposes is that the open source ecosystem operates on trust signals that were not designed for adversarial conditions. npm, PyPI, OpenVSX, and GitHub host millions of packages with limited built-in security controls. Malicious code can be published and pulled into production builds within minutes.

developer workstation code
Photo by hitesh choudhary on Pexels

Why developers became the target

Adversaries are no longer just targeting products, they’re targeting the developers who build them. A single compromised workstation provides access to source code repositories, CI/CD pipelines, cloud platforms, and package registries, the connective tissue of modern software. The blast radius from one developer can reach thousands of downstream organisations before any detection mechanism flags the dependency update. Glassworm’s operators understood this, which is why the malware prioritised exfiltrating npm publishing tokens and OpenVSX credentials from infected machines. Each compromised maintainer became a new distribution channel.

An infrastructure built to survive takedowns

This is where the Solana memos and Google Calendar events come in, and why these techniques have spread so quickly. Traditional command-and-control infrastructure relies on attacker-controlled domains or IP addresses, both of which can be seized, sinkholed, or null-routed once identified.

A Solana memo field, by contrast, is a write-once entry on a public blockchain that cannot be deleted by anyone, including the network operators. A Google Calendar event description sits inside infrastructure that defenders cannot unilaterally take down without disrupting a service used by billions of legitimate users. By encoding the address of the actual payload server inside these neutral, high-availability layers, attackers create a resolution chain where the discoverable parts are unkillable and the killable parts are not easily discoverable.

The Glassworm takedown worked precisely because investigators were able to map all three layers, the Solana addresses, the Calendar accounts, and the P2P fallback, and coordinate simultaneous action across each. Hitting only one would have left the others to reconstitute the network within hours. The use of legitimate consumer services — blockchain ledgers, public calendars, peer-to-peer networks — as resolution layers is the operationally interesting detail. Each layer borrows the legitimacy and uptime of infrastructure that defenders cannot unilaterally disable.

A pattern, not an incident

Glassworm is not the first malware family to use this architecture and will not be the last. The software supply chain has become a contested layer of infrastructure. Endpoint security vendors, platform operators, and law enforcement are increasingly conducting takedowns that sit in legally ambiguous territory. Coordinated actions against accounts on consumer platforms, blockchain transaction tracing, and cross-jurisdictional infrastructure seizures all sit in that grey zone. Consider where the defensive perimeter actually sits for a team running a routine build. The package registry is upstream of them, the maintainer’s laptop is upstream of that, the consumer services carrying the command instructions are upstream of everyone, and the takedown authority is distributed across companies and jurisdictions that have never had to coordinate before. It is no longer clear which of those layers anyone is responsible for defending, or whether the question even has a coherent answer yet.

 

Facebook
X
LinkedIn
Email

Recent Articles