What Happened
Since October 2025, the Glassworm botnet has been targeting developers through software supply-chain attacks. Unlike traditional botnets that rely on centralized command-and-control (C2) servers, Glassworm embedded its C2 infrastructure across four distinct channels: Solana blockchain transactions, the BitTorrent DHT network, and two other communication pathways.
In a coordinated takedown, CrowdStrike, Google, and The Shadowserver Foundation disrupted all four channels simultaneously. This operation required parallel action across fundamentally different infrastructure types—an effort most organizations aren't equipped to execute alone.
Timeline
October 2025: Glassworm campaigns begin targeting developer environments.
[Date unknown]: Security researchers identify the botnet's use of blockchain and DHT networks for C2 communication.
[Date unknown]: Coordinated takedown executed across all four C2 channels simultaneously.
The timeline details are limited, but the key point is clear: this botnet operated for months using infrastructure that traditional disruption methods couldn't touch.
Which Controls Failed or Were Missing
The Glassworm case exposes gaps in three areas:
Network monitoring blind spots: Your intrusion detection systems may scan for suspicious DNS queries, HTTP callbacks, and known malicious IPs, but they likely don't flag blockchain transactions or DHT lookups as C2 traffic. If your network monitoring tools treat cryptocurrency wallet activity and peer-to-peer file sharing as normal traffic, you're missing an entire attack surface.
Supply chain verification: The botnet targeted developers, likely compromising development dependencies, build tools, or CI/CD pipelines. If you're not scanning your build environment for unexpected network connections—including blockchain nodes and DHT peers—you won't catch these infections until they've already exfiltrated credentials or injected backdoors.
Incident response coordination: When your C2 infrastructure spans four distinct technologies, you can't just call your ISP and get a domain seized. The successful takedown required coordination between a threat intelligence firm, a major cloud provider, and a nonprofit security foundation. Most organizations lack the relationships and processes to orchestrate that kind of multi-party response.
What the Standards Require
The NIST CSF v2.0 calls for continuous monitoring of network communications (DE.CM-1) and analysis of detected events (DE.AE-2). But the framework doesn't specify what "network communications" means in a world where C2 traffic masquerades as blockchain transactions. You need to expand your definition beyond traditional protocols.
ISO 27001 requires security monitoring (Control 8.16) and management of technical vulnerabilities (Control 8.8). The standard expects you to identify and respond to security events across all information systems—which includes developer workstations executing blockchain queries you didn't know were happening.
NIST 800-53 Rev 5 is more specific: SI-4 (Information System Monitoring) requires you to monitor "unusual or unauthorized activities." The control enhancement SI-4(18) explicitly calls out analyzing network traffic for indicators of compromise. If your traffic analysis doesn't include blockchain transactions and DHT lookups, you're not meeting the spirit of the requirement.
PCI DSS v4.0.1 Requirement 10.4.1 mandates detecting and reporting failures of critical security control systems. If your monitoring tools can't see C2 traffic because it's encoded in blockchain transactions, your security controls have failed—you just don't know it yet.
The standards all point to the same gap: you need visibility into all network communications, not just the ones your tools were designed to catch in 2015.
Lessons and Action Items for Your Team
Map your actual network traffic, not your expected traffic. Run a two-week capture on your developer network segment. Look for connections to blockchain nodes, DHT networks, IPFS gateways, and other decentralized protocols. If you find them, determine whether they're legitimate (a developer testing a Web3 application) or suspicious (malware using the blockchain as a dead drop). Document the legitimate use cases to establish a baseline for normal activity.
Update your security monitoring rules. Add detection logic for:
- Outbound connections to known blockchain RPC endpoints
- DHT network participation from non-standard processes
- Unusual cryptocurrency wallet activity from developer machines
- Peer-to-peer protocol usage outside approved applications
Don't just block these protocols—that's impractical if your organization builds blockchain applications or uses BitTorrent legitimately. Instead, create alerts when unexpected processes initiate these connections.
Harden your build environment. Glassworm targeted developers because compromising the build pipeline gives attackers access to everything downstream. Isolate your CI/CD workers in a network segment with strict egress filtering. If a build job needs to pull dependencies, it should only connect to your internal artifact repository—not arbitrary internet hosts, and definitely not blockchain nodes.
Build incident response relationships now. The Glassworm takedown worked because three organizations coordinated simultaneous action across four infrastructure types. You can't build those relationships during an active incident. Identify which cloud providers, ISPs, and security vendors you'd need to coordinate with for a complex takedown. Establish contacts before you need them.
Test your detection against unconventional C2. Run a purple team exercise where your red team uses a blockchain or DHT network as a C2 channel. Can your blue team detect it? If not, you've found a gap worth fixing before an actual adversary exploits it.
The Glassworm case proves that traditional C2 infrastructure is outdated for sophisticated adversaries. They're moving to decentralized technologies that your existing tools weren't built to monitor. The question isn't whether you'll face this type of threat. The question is whether you'll detect it when you do.
