StubMaker RubyGems Campaign Delivers a Windows Infostealer | OpenSourceMalware

On August 15, 2026, we discovered newly-published RubyGems packages that installs a multi-stage Windows infostealer malware. This new malware harvests browser credentials, cryptocurrency wallets, seed phrases, and Telegram data. All of the malicious Rubygems packages appear to be typosquats of popular Ruby dependencies, but rather than the clever SEO-fueled typosquats we've seen from other threat actors (e.g. events-channel imitating the popular Node.js events module), they're all clumsy typos.<br>But don't let that fool you into not taking them seriously. The threat actor still managed hundreds of downloads before the packages were taken down.<br>The malicious packages include an extconf.rb hook that downloads exactly one file: a 22 MB Rust loader from a GitHub release. Everything after that is decrypted in memory. The loader carries an 11 MB Go infostealer inside its own data section and never fetches it from a URL. The stealer, in turn, carries its own embedded DLL for extracting the ABE key that modern Chromium versions use to lock down saved passwords and cookies, so a browser protection meant to survive exactly this kind of theft doesn't hold. No second-stage download, no C2 for the payload itself, nothing for network defenders to catch after the first request.<br>We’re naming this campaign StubMaker (click here to see all the threat reports) , after the artifact that makes it work: make_stub and make_stub.bat, the fake compiler stand-ins the installer writes to disk. RubyGems expects extconf.rb to configure and build a native C extension. StubMaker doesn’t build anything — it generates a Makefile with empty all, install, and clean targets, plus Unix and Windows stub scripts that do nothing but return success, so the extension phase reports a clean build while the real work (the platform beacon, the Windows loader fetch and execution) happens in the installer hook itself. The name points at that specific move: manufacturing a fake build toolchain to make a malicious install look like a routine one, rather than just describing another typosquatted RubyGems package.<br>That matters for detection. If you're waiting to see a second payload download before you treat this as a full compromise, you're already too late. Everything that follows the first GitHub request runs entirely off what was already delivered.<br>Threat Type: Supply-chain downloader and Windows infostealer

Affected Ecosystem: RubyGems

Impact: Theft of credentials, authenticated browser sessions, payment-card data, cryptocurrency wallets and seed phrases, Telegram data, and host information

Key Finding: The downloaded loader and browser-injection DLL are encrypted inside earlier stages rather than retrieved from additional payload URLs

Exfiltration: Stolen data is uploaded to Gofile; the resulting download link is sent to dresslee.com over unencrypted HTTP

These packages represent a layered supply-chain attack built to frustrate superficial analysis. The Ruby layer provides installation-time execution and platform filtering, the Rust loader conceals the primary stealer as encrypted data, and the Go payload keeps a browser-injection DLL embedded for defeating modern Chromium protections.<br>From Two Packages to Seventeen<br>We first identified this campaign from two typosquatted packages, brumdler and brundlef, published under the RubyGems account gemlewqqhu1 (“Taylor Moore”). Both names imitate the legitimate package bundler, the dependency manager present on nearly every Ruby install, making a mistyped gem install bundler an easy way to land on either one.<br>That wasn’t the end of it. Within a day, a second account, mod8rz41mje (“Riley Miller”), surfaced and pushed 15 more gems — including a new version of brumdler.<br>How interesting, we thought, that a totally different publisher was able to push new code to brumdler. It turns out this matches a known, maintainer-acknowledged RubyGems.org behavior: once all versions of a gem are yanked, its namespace opens up for any account to claim with a new push — the original owner has no special reclaim right, and there’s no documented reservation period standing in the way (rubygems/rubygems.org#1226, discussion #2787). That would explain how mod8rz41mje ended up owning the exact package name that was already taken down. Rather than register a new typosquat, the actor could simply wait for brumdler to free up and reclaim it. The version history for the current brumdler is consistent with this — two versions with unusual, high build numbers (1.0.44290 and 1.0.86147) were pushed and yanked on August 15, before a 1.0.0 release landed and stayed live on August 16.<br>We see a similar shape with brundlef. RubyGems.org currently shows it as unhosted (“this gem is not currently hosted on RubyGems.org”), with ownership listed under a third account, rbq95bwt6q (“Alex Davis”), rather than the original gemlewqqhu1.<br>Whatever the exact mechanism, the...