#glassworm

Remote Access Trojans are the family of malware I see most often in my research. Sure there are infostealers and denial-of-service bots galore out there, but it always seems to come back to the ‘basics’, the one that slips by unseen by user and security software alike, leaving behind backdoors and persistent traffic feeding data to the control-and-command actor. And more and more often, they’re hiding in GitHub repositories.

The first of the two reports on the topic in my news feed today is an overall study of how GitHub and GitLab are being exploited. Cofense took a look at data spanning from 2021 to 2025, and found a significant rise in abuse among open source repositories and/or cloud native services. Fully 45% of attack campaigns happened in 2025 alone, nearly equaling the amount collected in the previous four years. Within those attacks, most of them were targeting GitHub, with just 5% aimed at GitLab (which tracks for me as a researcher; I hardly ever hear about GitLab campaigns). 58% delivered credential phishing, while 42% contain malware. Sometimes those overlap and do both. The malware seen is almost invariably some form of RAT.

The second comes from Aikido, and is a more specific breakdown of an ongoing campaign using GlassWorm. I’ve covered the Shai-Halud offshoot before (here and here), and it is still using the same tactic now, where it infects OpenVSX extensions to propagate itself. The current iteration of the malware is impersonating WakaTime, the popular developer time-tracking tool, and ships a Zig-compiled native binary alongside its JavaScript code, inserting a persistent dropper (one of its hallmarks) into the extension. From there, it infects every Integrated Development Environment (IDE), the software that works to provide users with consistent experiences as they use disparate tools. This campaign is affecting both Windows and macOS.

So why the uptick, and why RAT’s? The answer to both has to do with business done at machine speed, exploited trust, and the way RAT’s work in the first place. Code repositories store all the related files and documents involved in developing new software, and Git is a version control system (VCS), meaning that developers who need a specific branch of code can find it easily and make changes to it without losing any of the work done by others. It’s a way to share files by making each one instanced to the user (this being a code mechanic in gaming that allows multiple assets to be available in the same place regardless of how many people are utilizing them). In short, it makes a fully malleable copy or version. Inserting a Trojan into the files is not hard, given that most repositories are open source, or otherwise have low authorization requirements in order for them to be available to so many. And all it takes is one compromised file or line of code buried beneath layers of legitimate programming to infect whole development trees. Social engineering – abusing the users’ trust in the sites – does the rest.

Trojans, by nature of their intrinsic obfuscation within legitimate programs, can be difficult to remediate. Upon download they often rename themselves as something else, delete the data from the download folder so the user can’t find it, or are so embedded within whatever they rode in on that one cannot simply uninstall to take care of the problem. During my training, I had at least two assignments that involved locating the presence of a RAT, hunting through individual logs to find those run-rename-delete commands. It’s time consuming. It is generally easier to just release a new, clean version of compromised software than try to root out the initial infection. Reports such as Cofense and Aikido’s are most often warnings to be aware of infected packages and programs, usually with version numbers – both compromised and clean – so that users can check if they’re running an affected one. And it’s my job as your friendly neighborhood WISP to ensure that they don’t get buried under other news.

Dormant VSX extensions were activated to deliver trojanised VSIX files from GitHub, bypassing registry takedowns and executing AES-256 payloads in memory with Solana blockchain C2.

Source: Socket

Do you know what kind of bug this is? Probably around 1cm long, I live in Canada, Alberta (like middle of of the province)

it's hard to tell from this picture (small bugs are REALLY hard to photograph with a phone!), but it looks like a glassworm midge to me! i.e., a midge in the genus Chaoborus.

Malware buried in npm dependencies of two popular packages exploits the Solana blockchain for in-memory payload delivery, affecting 134,000 developers without leaving traces in parent packages.

Source: Endor Labs

A stealthy malware wave is quietly hijacking VS Code extensions and GitHub repositories, spreading via invisible code and blockchain commands while targeting real organisations across several continents.

Source: Koi Security

The landscape of cybercrime has shifted in the last year or so. While traditional attacks are still very much a part of that landscape, with phishing, remote command execution, denial-of-service and prompt injection campaigns all being prominent and often, the real juggernaut these days is supply chain attacks. And Glassworm has been at the forefront, adapting and evolving to avoid effective disruption while continuing to spread throughout developer environments.

I first reported on it back in December, where I talked about how it’s similar to Shai-Hulud in behavior, being self-propagating through compromised credentials and its agentic nature, meaning it requires no oversight or user intervention to execute. At that time, Glassworm was abusing visual script extensions as part of its tactics for compromising developer trees, and had first been reported by The Hacker News in October, after Koi Security discovered it on the heels of a Shai-Hulud campaign targeting npm.

Part of Glassworm’s resilience is in the pattern of its architecture. It has adopted new programming languages since its inception, from JavaScript to Rust to Zig. It’s expanded across package ecosystems such as VSCode, npm, PyPI, and GitHub. And it’s built redundant infrastructure designed to survive takedown attempts like infected Solana blockchain dead drops,.peer-to-peer networking for configuration data via BitTorrent Distributed Hash Tables, Google Calendar event titles as dead-drop locations for Base64-encoded C2 paths, as well as direct server connections in more ‘traditional’ command-and-control hosted by commercial providers.

The attack cycle of this particular infection relies on multiple stages of compromise; it’s part of the persistence mechanism. An initial installation of a package with malicious but inactive code written into it, followed by delayed payloads injected into dependency trees to bypass detection and activate the ‘sleeper cell’ malware. Which then leads to data harvesting, credential theft and a Node.js remote access tool dubbed GlasswormRAT that cascades throughout a developer supply chain both laterally and downstream. And this is a cross-platform assault, affecting Windows, macOS and Linux. In order to actually disrupt this massive and pervasive malware, a more coordinated and simultaneous attempt to take down all of the C2 options must be enacted.

And that’s what CrowdStrike has done. Yesterday, in collaboration with Google and the Shadowserver Foundation, the security company’s Counter Adversary Operations team hit all four C2 channels simultaneously, cutting off the threat actors from infected machines. This move does not remove the malware from these compromised devices, but it does prevent new payloads from being delivered.

I don’t think this is the end for Glassworm; I’ve watched too many disrupted campaigns make a resurgence shortly thereafter. However, possibly infected machines can be currently checked with a key network indicator. CrowdStrike has created a benign (read: controlled by them) beacon redirect. The article contains the IP address of that redirect if you want to check your networks for its presence, which in turn marks a compromised package. Remediation of this type of attack is nearly impossible with the supply chain so reliant upon many of the dependency trees that are infected. One cannot just delete them without their entire development ecosystem collapsing. Detection after the fact does nothing for the damage control other than awareness. Prevention is also difficult considering how many are open source and therefore have little in the way of security built in.

What we really need is a change at the heart of software development. Will that happen? Eh, I’m not holding my breath. In the meantime, at least we have defenders like CrowdStrike.

I’ve talked about GlassWorm before. The Shai-Hulud offshoot has been in constant evolution since at least October of 2025, with iterations affecting numerous open source extensions and developer registries across a wide array of endpoints. Today, it appears not once but twice on my cyber news feed with a pair of unrelated waves of attacks.

The first, as reported by Endor Labs, covers a campaign using a multi-stage approach of infection, obfuscation and deployment in an npm package that ultimately ends with the maintainer of the package being completely locked out of their account and unable to take the compromised version down. The campaign began with a pre-install hook in two known packages – npm install react-native-international-phone-number and npm install react-native-country-select – using a Solana blockchain command-and-control client as a dead drop, rather than being hardcoded into the URL’s which could be blocklisted. The hook is coded to in-memory execution, meaning it’s living off the land; it isn’t saved to the disk. It achieves persistence through a json command. This first wave was counteracted by the maintainer, with a new clean version published shortly after the attack.

The second wave was something of a placeholder, intended to pre-stage a dependency on the previous, infected version of the packages, but containing no further payload. With nothing to be flagged by security software, this second stage gets scanned and determined to be benign, and thus remains available for download and use. This is a deferred armament technique, plant the dependency chain while it's clean, let scanners clear it, then arm it later when nobody's watching. The attacker waited nearly a full day before releasing the armed version, enough time for the packages to be distributed without issue.

The final wave deployed the armed version of the packages, with them pinned as ‘latest’ for automatic updating in downloaded copies. No suspicious signals were flagged, because the malware itself is embedded in the dependency chain, not the final iteration. And then the attacker changed the npm account email, effectively locking the owner out of recovery. Endor Labs states that versions (those above 0.12.0 for phone-number, 0.4.0 for country-select) containing the ~/init.json command confirms the presence of the executed malware.

The second report of GlassWorm comes from Socket, regarding the ongoing campaign to spread the malware through OpenVSX extensions. They’d first reported on the campaign a week ago, finding 72 extensions carrying the malware at that time. Over the weekend, at least 20 more were detected, with a further number including ‘sleeper’ extensions that hadn’t yet delivered their payload. Using the same tactic as the case of npm, extensions were published with no malware in them, although they were often typosquats. And then an update introduced the malicious version.

This iteration of the malware uses GitHub’s own infrastructure for living off the land. Eclipse Foundation – Open VSX’s parent company – has been flagging and removing the extensions as they’re found before they can be activated by users. Socket’s article has a list of possibly compromised extensions, both active and sleeper, with the versions that are affected and those that are likely clean. Most of them are running an import command, and several accounts are suspected to be hosts or publishers of the campaign with high confidence.

GlassWorm campaigns have been a fairly common headline in my news feed for months, but this is the first time two separate attacks were reported on the same day. Given the use of Solana blockchain for command-and-control, one can presume that cryptocurrency theft is among the goals by the attacker. As always, I’ll be keeping my eye on things and any further developments.