CrowdStrike, Google and Shadowserver Dismantle Glassworm Botnet Targeting Developers
Glassworm was not just another botnet waiting on infected machines. It was built to sit inside the software supply chain.
CrowdStrike says it has dismantled the developer-targeting Glassworm botnet in a coordinated operation with Google and the Shadowserver Foundation. The takedown, executed on May 26, 2026 at 14:00 UTC, severed all four of the botnet’s command-and-control channels at the same time, cutting operators off from infected developer systems and blocking the delivery of new payloads.
The bigger warning is sharper than the takedown itself: attackers are no longer only trying to compromise finished software. They are going after the people, tools, tokens, extensions, repositories, and package workflows used to build it.
What Happened
CrowdStrike’s Counter Adversary Operations team said it led a coordinated disruption of Glassworm, a global botnet that had been active since at least early 2025 and focused on developers across the open-source ecosystem.
The operation involved CrowdStrike, Google, and the Shadowserver Foundation. According to CrowdStrike, the partners simultaneously disrupted four separate command-and-control channels used by the malware: Solana blockchain infrastructure, BitTorrent Distributed Hash Table, Google Calendar event titles, and traditional VPS-hosted servers.
That simultaneous timing mattered. Glassworm was designed for resilience. If defenders removed only one command channel, the operators could fall back to the others and continue issuing instructions to compromised machines. By cutting all four at once, the takedown left infected systems unable to receive new commands or additional malicious payloads.
The botnet targeted developers through trojanized coding extensions, malicious open-source packages, and poisoned repositories. Its operators used stolen credentials from earlier infections to compromise additional projects, force-push malicious code, and expand the infection chain through trusted developer workflows.
Why Glassworm Stands Out
Glassworm’s value was not just in the number of infected machines. Its real power came from who it infected.
Developer systems often hold GitHub tokens, npm credentials, SSH keys, cloud access tokens, CI/CD secrets, package registry access, source code, and privileged access to internal engineering environments. A compromised developer workstation can become a bridge into repositories, build systems, cloud accounts, and downstream customers.
CrowdStrike said Glassworm spread through multiple developer-facing routes, including trojanized VS Code extensions, npm and Python packages, and poisoned GitHub repositories. Reporting on the campaign indicates that more than 300 GitHub repositories were affected after attackers reused harvested credentials to inject malicious code into default branches.
The malware performed credential theft and deployed a remote access tool known as GlasswormRAT across Windows, macOS, and Linux systems. That cross-platform reach is important because modern development teams rarely operate in a single operating system environment.
A Botnet Built for Takedown Resistance
Glassworm’s command-and-control design was unusually stubborn.
Instead of depending on one server or one domain, the botnet used four independent control paths. Solana blockchain data helped distribute command information. BitTorrent DHT provided another decentralized channel. Google Calendar event titles were used as a dead-drop mechanism. Traditional VPS servers gave the operators a more conventional fallback.
That design made the botnet harder to neutralize through ordinary domain seizures, hosting takedowns, or IP blocking. Public and decentralized services are difficult to remove cleanly without collateral damage, and attackers know that defenders often have limited ability to block them outright in enterprise environments.
This is why CrowdStrike’s operation is notable. The disruption did not rely on knocking over a single server. It required coordinated action across multiple abuse channels so the botnet could not simply fail over and keep operating.
The Developer Targeting Playbook
Glassworm followed a pattern defenders are seeing more often: compromise the developer, then compromise the trust chain.
A malicious extension or package does not need to exploit a browser zero-day or break into a corporate VPN. It only needs to be installed during normal work. Once running on a developer machine, it can look for local secrets, authentication tokens, package manager credentials, SSH keys, repository access, browser-stored credentials, and cloud tooling configuration files.
From there, the attacker can move outward. Stolen GitHub credentials can be used to poison repositories. Stolen npm or Python package credentials can push malicious updates. Stolen cloud tokens can expose infrastructure. Stolen CI/CD secrets can turn build pipelines into distribution systems.
That is the operational danger of Glassworm. It did not merely infect developers as individual victims. It attempted to convert them into distribution nodes for wider software supply-chain compromise.
Why Defenders Should Care
Security teams should treat this takedown as a disruption, not a cleanup guarantee.
Systems previously infected by Glassworm may no longer receive new instructions through the disrupted C2 channels, but stolen credentials remain dangerous until rotated. A botnet takedown can cut operator access. It does not automatically revoke GitHub tokens, npm tokens, SSH keys, cloud credentials, or secrets already collected before the disruption.
Organizations should identify developer endpoints that installed suspicious VS Code or OpenVSX extensions, pulled recently identified malicious npm or Python packages, or interacted with repositories later found to be poisoned. Any credentials stored on those systems should be treated as exposed unless there is clear evidence to the contrary.
Detection should focus on developer-specific signals: unusual package installation scripts, unexpected postinstall execution, suspicious extension behavior, outbound connections from developer tools, repository changes outside normal workflows, force-pushed commits to default branches, new or unfamiliar CI/CD secrets, and API token use from unexpected locations.
What Security Teams Should Do Now
Start with credential hygiene. Rotate GitHub tokens, npm tokens, PyPI credentials, SSH keys, cloud access keys, and CI/CD secrets from developer systems that may have been exposed. Where possible, replace long-lived static tokens with short-lived credentials and enforce least-privilege scopes.
Review installed developer extensions and remove anything untrusted, abandoned, recently renamed, or sourced from unofficial publishers. Extension marketplaces and package registries should be treated as part of the attack surface, not as neutral software shelves.
Audit repositories for suspicious recent commits, force pushes, unexplained changes to default branches, modified build scripts, new postinstall hooks, obfuscated code, and unexpected dependency additions. Commit signing, protected branches, mandatory reviews, and CI policy checks can reduce the blast radius when a developer account is stolen.
For SOC teams, the key is to monitor the tools developers actually use. Git clients, package managers, IDEs, extension hosts, terminal shells, CI agents, and cloud CLIs are all high-value telemetry sources. Malware operating through developer workflows can look ordinary unless the organization understands what normal developer behavior looks like.
The Bigger Picture
Glassworm fits into a broader shift in software supply-chain attacks. Instead of attacking only production systems, adversaries are moving upstream into the development process, where one compromised account or package can reach many downstream environments.
Open-source ecosystems are especially attractive because they depend on trust, reuse, speed, and automation. Developers routinely install packages, update extensions, clone repositories, run build scripts, and authenticate to multiple services in a single working day. Glassworm abused that rhythm.
The takedown removes an active control layer, but it also exposes a structural weakness: developer machines are often treated like ordinary endpoints even though they carry keys to the software factory.
NeuraCyb's Assessment
The Glassworm takedown is a meaningful win, but the lesson is not that the botnet is gone. The lesson is that developer environments have become prime infrastructure for attackers.
Defenders should assume that compromised development tooling can become a supply-chain incident quickly. Protecting code now means protecting the identities, endpoints, extensions, package credentials, and build systems behind it. Glassworm was disrupted because its control channels were cut together. The next one will be harder to stop if organizations still treat developer workstations as just another laptop.
References
CrowdStrike: Disrupting Glassworm — Inside CrowdStrike’s Takedown of a Developer-Targeting Botnet
SecurityWeek: GlassWorm Botnet Disrupted
Cybersecurity Dive: Coordinated operation takes down Glassworm botnet
