CrowdStrike, working with Google and the Shadowserver Foundation, has announced a coordinated disruption of the command-and-control infrastructure used by GlassWorm, a persistent software supply chain campaign targeting developers through malicious packages and code editor extensions.
The operation simultaneously neutralized all known GlassWorm command-and-control channels, preventing infected machines from receiving new instructions or additional payloads.
The disruption is significant because GlassWorm was not a basic malware campaign. It was a resilient, multi-layered operation designed to compromise developer environments, steal credentials, poison repositories, and use infected machines as covert infrastructure for further attacks.
Developers Remain High-Value Targets
Since at least early 2025, GlassWorm operators have focused heavily on software developers.
That targeting is strategic.
Developer machines often contain access to:
- source code repositories
- npm and Python package registries
- VS Code and Open VSX publishing tokens
- GitHub credentials
- cloud platforms
- CI/CD pipelines
- cryptocurrency wallets
- SSH keys
- internal systems and build environments
A single compromised developer workstation can have a much larger impact than a typical infected endpoint. Attackers may be able to publish malicious packages, compromise repositories, access cloud infrastructure, or inject backdoors into tools used by thousands of downstream users.
That is why software supply chain attacks continue to grow. Compromising the people and systems that produce software can create a massive downstream reach.
How GlassWorm Spread
GlassWorm used a multi-pronged approach to reach developers.
The campaign relied on trojanized VS Code extensions published on both the Microsoft VS Code Marketplace and Open VSX. This allowed the attackers to target not only users of Visual Studio Code, but also users of VS Code-based editors and forks such as:
- Cursor
- Positron
- Windsurf
- VSCodium
The campaign also introduced malicious code through compromised npm and Python packages.
This combination gave GlassWorm several distribution paths across the developer ecosystem. Instead of relying on one marketplace or one package repository, the operators targeted multiple trusted developer channels at once.
What the Malware Did
GlassWorm delivered a data-theft framework focused on developer credentials and system compromise.
Its capabilities included:
- credential harvesting
- cryptocurrency wallet theft
- system profiling
- browser data theft
- arbitrary code execution
- screenshot capture
- keystroke collection
- clipboard monitoring
- remote access
- proxying traffic through infected machines
Later versions deployed a WebSocket-based JavaScript RAT known as GlassWormRAT. This remote access tool could steal browser data, run arbitrary code, and install a malicious Google Chrome extension to collect sensitive information from the infected system.
Once active, GlassWorm searched for developer credentials such as GitHub, npm, OpenVSX tokens, and cryptocurrency wallet data.
Those stolen credentials could then be used to compromise additional repositories, publish poisoned packages, or spread the campaign further.
Turning Developer Machines Into Infrastructure
One of the most concerning parts of GlassWorm was its ability to turn infected developer systems into covert infrastructure.
According to analysis from security researchers, compromised hosts could be used as:
- SOCKS proxies
- hidden VNC servers
- remote execution nodes
- WebRTC-based access points
- Node.js execution environments
This gave attackers anonymized access into corporate and personal networks.
In other words, infected systems were not only victims. They became operational assets that could support further compromise, network pivoting, and concealment of attacker activity.
That makes GlassWorm more dangerous than a simple credential stealer.
More Than 300 GitHub Repositories Poisoned
Using stolen developer credentials, GlassWorm activity reportedly poisoned more than 300 GitHub repositories.
This is a key supply chain risk.
If attackers gain access to a developer’s GitHub account or package publishing tokens, they may be able to modify trusted code, publish malicious releases, or introduce subtle backdoors that downstream users later install.
The impact can spread far beyond the original victim. A compromised developer account can become the starting point for attacks against many organizations that depend on that developer’s code, packages, or extensions.
Four Command-and-Control Channels
GlassWorm stood out because of its unusually resilient command-and-control design.
Rather than depending on a single server or domain, the malware used four different C2 resolution channels:
- Solana blockchain
The operators stored C2 server addresses inside memo fields of blockchain transactions, using the blockchain as a dead drop resolver. - BitTorrent DHT
The malware queried the BitTorrent Distributed Hash Table peer-to-peer network to retrieve configuration data. - Google Calendar
GlassWorm used Google Calendar event titles as a way to fetch C2 server addresses. - Commercial VPS infrastructure
The malware could also connect directly to C2 servers hosted on commercial virtual private server providers.
This design made the operation harder to disrupt. If defenders blocked one channel, infected machines could potentially retrieve instructions through another.
The coordinated takedown was therefore important because all four channels were disrupted at the same time.
Why the Takedown Matters
Command-and-control infrastructure is how malware operators manage infected machines.
By disrupting GlassWorm’s C2 channels, CrowdStrike, Google, and Shadowserver prevented compromised systems from receiving new commands, configurations, or payloads.
This does not automatically clean infected systems, but it weakens the attackers’ ability to control them.
The coordinated nature of the disruption matters because GlassWorm was built for resilience. A partial takedown may have allowed the operators to shift to backup channels. Simultaneously neutralizing all known C2 paths reduces that chance.
Attribution and Operator Profile
CrowdStrike described the GlassWorm operators as well-resourced and persistent.
The activity has been attributed to likely Russia-based cybercriminals, based on indicators such as:
- malware execution stopping on systems located in Commonwealth of Independent States countries
- Russian-language comments in malware components
- operational behavior consistent with financially motivated cybercrime
The campaign appears primarily criminal rather than purely espionage-focused, but its impact on the software supply chain makes it a serious threat to organizations of all sizes.
Why Software Supply Chain Attacks Are So Dangerous
GlassWorm demonstrates why the software supply chain is one of the most important attack surfaces in modern cybersecurity.
Organizations depend on software tools, libraries, extensions, packages, updates, build systems, and developer environments. Attackers understand that compromising these dependencies can provide enormous reach.
The barrier to poisoning a package or extension can be relatively low, especially when maintainers are compromised or publishing tokens are stolen. But the blast radius can be massive.
One malicious package, extension, or repository update can affect:
- developers
- CI/CD systems
- build pipelines
- production applications
- cloud environments
- downstream customers
- open-source ecosystems
Every organization that consumes software inherits some risk from the organizations and individuals that produce it.
Defensive Lessons for Developers
Developers should treat extensions and packages as part of their security perimeter.
Recommended actions include:
- install extensions only from trusted publishers
- review extension permissions and behavior
- remove unused VS Code extensions
- avoid installing newly published or low-reputation packages without review
- monitor GitHub, npm, Python, and OpenVSX tokens
- rotate tokens if compromise is suspected
- use scoped and short-lived tokens where possible
- avoid storing long-lived secrets on developer workstations
- use password managers with strong protection
- review browser extensions for suspicious behavior
- monitor for unexpected remote access tools or proxy processes
Developer machines should be treated as high-value systems, not ordinary endpoints.
Defensive Lessons for Organizations
Security teams should expand supply chain monitoring beyond production systems.
Important controls include:
- endpoint detection on developer workstations
- monitoring for suspicious VS Code extension activity
- package dependency scanning
- GitHub repository monitoring
- alerting on unexpected package publishing
- secret scanning across repositories and build logs
- CI/CD permission hardening
- least-privilege access for developer tokens
- automated revocation of exposed credentials
- approval workflows for publishing packages and extensions
- auditing OpenVSX, npm, PyPI, and GitHub access
- monitoring outbound connections to unusual infrastructure
Organizations should also create an incident response plan specifically for developer credential compromise.
That plan should include repository review, package review, token rotation, extension audit, and downstream notification procedures.
What to Check After GlassWorm
Developers and organizations that may have been exposed should review:
- installed VS Code and Open VSX extensions
- Cursor, Windsurf, Positron, and VSCodium extension lists
- npm and Python packages recently installed
- GitHub access logs
- npm, PyPI, and OpenVSX publishing activity
- new or modified repositories
- unexpected commits or releases
- exposed developer tokens
- unusual browser extension installations
- suspicious local proxy or VNC processes
- unexpected Node.js processes
- unknown WebRTC or WebSocket traffic
If suspicious activity is found, credentials should be rotated immediately.
Final Thoughts
The GlassWorm disruption is an important win for defenders, but it also shows how far software supply chain attacks have evolved.
The campaign targeted developers through trusted tools and package ecosystems, stole credentials, poisoned repositories, deployed remote access capabilities, and used resilient command-and-control channels involving blockchain, peer-to-peer networks, Google Calendar, and VPS infrastructure.
This was not a simple malware campaign. It was a persistent operation designed to survive disruption and maintain access to developer ecosystems.
The key lesson is clear: developer environments are now critical infrastructure.
Protecting software supply chains requires securing not only production systems, but also the workstations, extensions, packages, tokens, repositories, and pipelines used to build the software that everyone else depends on.
