Source: TechCrunch Security — https://techcrunch.com/2026/05/27/crowdstrike-and-google-take-down-botnet-used-by-hackers-to-target-software-developers-in-supply-chain-attacks/
The useful lesson is not the takedown. It is the target.#
CrowdStrike, working with Google and Shadowserver, says it disrupted Glassworm, a botnet used to push malware and steal passwords from open-source software developers. The operation reportedly cut off four command-and-control channels and stopped the operators from delivering more malware through infected machines.
That is the visible win. The more important point is where the campaign was aimed.
Glassworm was not only going after finished software products or exposed company servers. According to CrowdStrike, the group targeted developers and the open-source supply chain around them. That changes the risk model. A compromised developer account or workstation can become a route into code repositories, package updates, extensions, and downstream organizations that never interacted with the attacker directly.
CrowdStrike put the stakes plainly: attackers are no longer just targeting products, they are targeting the people who build them. That is not a slogan. It describes why developer identity, local machines, CI/CD secrets, package publishing rights, and marketplace accounts now sit inside the real perimeter.
What Glassworm allegedly used#
TechCrunch reports that Glassworm operators used several routes to push malicious code and steal credentials from developers.
The reported methods included malicious extensions on a developer marketplace, malvertising through sponsored search results, and the reuse of credentials stolen in earlier compromises. Those stolen credentials allowed the attackers to hijack developer accounts and plant malware in code.
CrowdStrike said the campaign “poisoned” more than 300 GitHub repositories. The source material does not give a full victim list, a precise infection count, or a complete map of downstream impact. That matters. More than 300 repositories is serious, but it does not automatically mean every dependent organization was compromised. Repository poisoning can range from attempted placement to actual execution by victims, and those details decide the blast radius.
Still, the pattern is clear enough to act on. The attackers worked around trust. They did not need to break every company directly if they could compromise the developer accounts, extensions, or code paths those companies already trusted.
The C2 design is the sharp technical detail#
CrowdStrike said it took down four command-and-control channels used by the Glassworm operators. According to the report, those channels relied on Solana blockchain infrastructure, the BitTorrent peer-to-peer network, Google Calendar, and virtual private servers.
That mix is worth noticing.
Using a normal VPS for C2 is familiar. Using public or semi-public infrastructure such as blockchain data, peer-to-peer networks, or calendar services is harder to reason about from a defender’s view. These channels can blur the line between malicious traffic and ordinary platform use. They also give attackers fallback paths when one part of the infrastructure is blocked.
The takedown reportedly cut the operators’ access to infected computers and stopped further malware delivery. That is a meaningful disruption, but it should not be read as proof that every infected system is clean or every stolen credential is invalid. C2 disruption can break active control. It does not automatically reverse repository changes, rotate leaked tokens, remove persistence, or repair trust in compromised accounts.
TechCrunch also notes that it is not clear what legal or technical authority CrowdStrike and others used for the takedown. That is not a minor footnote. Botnet disruptions often sit at the intersection of platform enforcement, sinkholing, abuse response, court orders, infrastructure provider action, and private-sector coordination. Without details, readers should avoid assuming either a specific legal mechanism or a full technical eradication.
Why developers are now high-value infrastructure#
Open-source developers are often treated as individual contributors. In modern software supply chains, many of them function more like critical infrastructure maintainers.
A single developer workstation may hold package registry tokens, GitHub sessions, SSH keys, cloud credentials, signing material, browser cookies, and access to release workflows. A single account may have rights across multiple repositories. A single malicious update can reach far beyond the original maintainer’s organization.
That is why campaigns like Glassworm are effective. They exploit trust at the point where code is created, reviewed, packaged, and shipped.
The reported tactics also show that “supply-chain attack” is no longer one technique. It can start with a malicious extension. It can start with a search ad that pushes a fake download. It can start with a password stolen in a previous breach and reused against a developer account. The supply-chain part begins later, when that initial foothold becomes access to code or release paths.
This is the same broader pressure visible in other recent developer-focused incidents. TechCrunch cites a separate campaign called “Mini Shai-Hulud,” where open-source projects were compromised and pushed malicious updates, and another March incident involving the hijacking of Axios, a widely used open-source software development tool, allegedly by a suspected North Korean hacker. The details differ. The direction is the same: developer trust is being treated as a distribution channel.
What teams should check now#
The right response is not panic-scanning every dependency in isolation. Start with the places where developer compromise becomes release compromise.
Teams should review recent repository changes, especially unexpected commits, new maintainers, altered build scripts, dependency changes, package publishing configuration, and workflow files. GitHub Actions and similar CI systems deserve special attention because they often bridge code changes to secrets, artifacts, package registries, and cloud environments.
Developer credentials should be treated as potentially exposed if they were used on machines that installed untrusted extensions, clicked sponsored software download links, or reused passwords across services. Rotate high-value tokens first: package registry credentials, GitHub tokens, cloud keys, signing keys, deploy keys, and CI/CD secrets. Remove stale tokens rather than only rotating the obvious ones.
Organizations should also audit marketplace extensions used by developers. Extensions run close to the work. Some can read files, interact with code, or observe credentials and sessions. That makes them attractive targets. Treat developer extensions more like privileged software than cosmetic tooling.
Search ads need a specific control, too. If developers install tools by searching product names and clicking the first sponsored result, attackers have a cheap entry point. Internal documentation should link to approved download locations directly. For security-sensitive tools, prefer verified publisher pages, package manager sources with clear provenance, or signed releases where available.
What not to overclaim#
The public reporting supports a clear claim: CrowdStrike, Google, and Shadowserver disrupted infrastructure used by Glassworm, a botnet aimed at open-source developers and supply-chain compromise.
It does not support a clean claim that the threat is gone.
The report does not establish that every infected host was remediated, every stolen credential was rotated, or every poisoned repository was restored. It also does not clarify the legal or procedural mechanism behind the takedown. Those gaps do not make the reporting weak; they define what can and cannot be concluded from it.
For defenders, the practical conclusion is narrower and stronger: developer environments are part of the production attack surface. If an attacker can steal a maintainer’s credentials, hijack a release path, or plant code through a trusted account, the boundary between endpoint security and supply-chain security disappears.