Source: BleepingComputer — https://www.bleepingcomputer.com/news/security/glassworm-botnet-disrupted-after-resilient-c2-infrastructure-takedown/
Glassworm was disrupted because all four control paths were hit at once#
Researchers say the Glassworm botnet has been disrupted after a coordinated takedown cut off four command-and-control channels at the same time. That detail matters. This was not a simple server seizure or a domain suspension.
According to BleepingComputer, CrowdStrike, Google, and The Shadowserver Foundation carried out the operation against infrastructure used by Glassworm operators to control infected developer systems. The botnet had been built to survive partial disruption by spreading its control logic across Solana blockchain transactions, the BitTorrent DHT network, a public calendar service, and conventional VPS-hosted servers.
CrowdStrike’s assessment, as cited in the report, is direct: infected machines can no longer receive new instructions or payloads after the coordinated action. Compromised hosts are now beaconing to 164.92.88[.]210, an IP address operated by CrowdStrike. Organizations are advised to look for that network indicator and remediate affected systems.
This is a disruption, not a reason to assume every prior compromise has been cleaned up. Machines that were already infected still need investigation. Stolen credentials, planted tokens, malicious packages, and persistence artifacts do not disappear because the active C2 path is cut.
The target was the developer supply chain#
Glassworm campaigns have been active since October 2025, according to the report. The early campaigns targeted developers through malicious OpenVSX and Microsoft Visual Studio Code extensions. Those extensions were used to steal cryptocurrency wallets and developer credentials.
The campaign later expanded into GitHub repositories and npm packages. One March campaign reportedly affected more than 400 software artifacts. A more recent wave involved dozens of dormant extensions on OpenVSX, with malicious components designed to activate after an update.
That pattern is the important operational lesson. Glassworm did not need to exploit a classic perimeter flaw first. It went after the working environment of developers: extensions, repositories, packages, and credentials. Those are trusted surfaces inside modern software production.
A malicious developer extension can sit close to secrets, build scripts, source code, package publishing flows, and local wallets. A compromised repository or npm package can carry the attack downstream into other projects. This is why developer-targeted malware has a different blast radius from ordinary endpoint malware. It can turn one infected workstation or maintainer account into a distribution problem.
The C2 design was built for resilience, not elegance#
The botnet’s command-and-control architecture is the notable part of the report. Glassworm used four channels:
- Solana blockchain transactions, with C2 server addresses encoded in memo fields.
- BitTorrent Distributed Hash Table queries, using hardcoded public keys to retrieve configuration data.
- Google Calendar event titles as dead-drop locations for Base64-encoded C2 paths.
- Direct connections to traditional C2 infrastructure hosted on commercial VPS providers.
This mix is deliberately awkward to remove. Blockchain memo fields are public and hard to erase by ordinary takedown methods. BitTorrent DHT has no central provider to contact. A public calendar service can look like normal web traffic until the pattern is understood. VPS servers are the familiar part, but by themselves they are not the whole system.
The design gave Glassworm fallback paths. If defenders removed only the VPS servers, infected hosts could still resolve new instructions through other layers. If one dead drop stopped working, another could keep the operation alive. The public services acted as resolution layers in front of the real payload infrastructure.
That is why the coordinated timing mattered. A piecemeal takedown would have signaled the operators and left enough of the system intact to re-route. The operation had to hit the blockchain-based path, peer-to-peer path, calendar-based path, and direct infrastructure together.
What defenders should check now#
The immediate network indicator from the report is 164.92.88[.]210. CrowdStrike says compromised machines are beaconing to that IP after the disruption. Security teams should search logs for connections to it, especially from developer workstations, CI hosts, build systems, and machines used to maintain packages or browser/editor extensions.
The network hit should be treated as a starting point, not proof of full scope. If a host touched Glassworm infrastructure, responders should assume developer credentials and local secrets may have been exposed until evidence says otherwise.
Practical checks include:
- Review outbound connections to 164.92.88[.]210.
- Inspect developer machines for suspicious VS Code or OpenVSX extensions.
- Audit recently installed or updated extensions, especially those added since October 2025.
- Review npm package publishing activity for affected maintainers.
- Rotate credentials, tokens, and wallet material present on suspected hosts.
- Check GitHub repository access logs and recent commits for unexpected changes.
- Use the YARA rules published by the researchers to validate suspected infections.
Teams should also look at process history and persistence, where available. The public reporting confirms the C2 disruption and the beaconing indicator. It does not prove that every infected endpoint has been reduced to a harmless state.
What not to overclaim#
The report supports a clear conclusion: Glassworm’s active control infrastructure was disrupted by coordinated action across four channels. It does not establish that the operators have been identified, arrested, or permanently removed from the field. It also does not mean every malicious extension, compromised repository, stolen credential, or downstream package risk has already been resolved.
The stronger claim is architectural. Glassworm shows how supply-chain malware can use public infrastructure as part of its control plane. The attacker does not need a sophisticated zero-day to create a difficult takedown problem. They can combine trusted developer surfaces with decentralized or widely used public services, then force defenders to coordinate across providers and protocols.
That changes the defensive burden. Blocking a domain is not enough. Removing one package is not enough. Cleaning one repository is not enough. For developer-focused malware, the response has to cover identity, endpoints, package registries, source control, build systems, and outbound network behavior.
Glassworm’s disruption is good news. The useful lesson is sharper: the malware survived as long as it did because its operators understood where modern software trust is concentrated — and how hard it is to revoke that trust once it has been spread across tools developers use every day.