Direct naar de inhoud
Software Supply Chain Security

Typosquatting op RubyGems: StubMaker steelt data

Typosquatting op RubyGems

Onderzoekers hebben een nieuwe campagne gesignaleerd die focust op Typosquatting op RubyGems. Daarbij worden misleidende Ruby-pakketten aangeboden die lijken op populaire afhankelijkheden. De werkelijke bedoeling is echter anders: de zogeheten StubMaker verzamelt inlog- en browserdata en richt zich ook op crypto-wallets en Telegram-gegevens.

De pakketten zijn inmiddels van RubyGems gehaald, maar de techniek achter de aanval laat zien hoe kwetsbaar een software supply chain kan zijn—zeker wanneer er sprake is van naamhergebruik, installatie-automatisering en onvoldoende validatie van pakketmetadata.

Wat is StubMaker en waarom is het gevaarlijk?

De malware die achter deze campagne schuilgaat, wordt door onderzoekers gelabeld als StubMaker. Het gaat om een Windows-gebaseerde informatieverzamelaar. Volgens OpenSourceMalware verzamelt de dreiging onder meer:

  • Browsercredentials en gegevens uit Chromium-gebaseerde browsers
  • Cryptocurrency wallets en seed phrases
  • Telegram Desktop data
  • extra informatie zoals extension data, browsegeschiedenis en ook payment card nummers

De kern is dat de aanvaller geen “gewone” Ruby-implementatie levert die je direct in de package-code verwacht. In plaats daarvan wordt tijdens installatie een keten van stappen geactiveerd die uiteindelijk de echte diefstal mogelijk maakt.

Typosquatting op RubyGems: 16 pakketten met verwarrende namen

De campagne bestond uit 16 RubyGems-pakketten. Ze zijn gepubliceerd met namen die sterk lijken op bestaande, gangbare Ruby-dependencies, maar dan met kleine typfouten. Daardoor kunnen ontwikkelaars die “snel” typen, of die niet dubbelchecken welke gem ze installeren, toch de kwaadaardige variant binnenhalen.

De gem-namen die onderdeel waren van de campagne zijn onder andere: ubnuler, ubnlder, ri18nr, reaker, rakier, orakw, joxn, ise18n, ioe18n, ie18u, iai8n, i1l8n, i18om, activesupmport, brumdler en brundlef.

Bij publicatie stonden de pakketten op RubyGems al snel onder druk, waarna ze zijn ingetrokken. Toch geldt: zodra zo’n pakket eenmaal door een build of installproces is gegaan, kan het kwaad al zijn geschied.

Hoe krijgen aanvallers het uitgevoerd? Install-hooks en een “nep build”-fase

Een opvallend element is de manier waarop de aanval wordt geactiveerd. StubMaker maakt gebruik van RubyGems-gedrag rond extconf.rb. Dit bestand kan tijdens installatie automatisch worden uitgevoerd om native extensies te configureren. Dat is op zich legitiem—Ruby gebruikt dit mechanisme vaak voor componenten in C/C++/Rust.

In deze campagne verandert die “normale” hook in een transportmiddel. StubMaker genereert namelijk een Makefile en stub-scripts die doen alsof alles netjes wordt opgebouwd. Daardoor kan de installatie aan de buitenkant “schoon” lijken, terwijl de echte payload niet pas later, maar via de installer-hook wordt opgehaald en gestart.

Concreet wordt een loader van ongeveer 22 MB opgehaald uit een GitHub release. Deze GitHub-bron is inmiddels niet meer toegankelijk. Vervolgens start de loader een Go-gebaseerde stealer (genaamd wincfg) waarin de diefstallogica is verwerkt.

Welke data wordt gestolen uit browsers en crypto-wallets?

De stealer bevat een extra DLL (genaamd abe_payload.dll) die zich richt op Chromium-achtige browsers, waaronder onder meer Google Chrome, Microsoft Edge, Brave en Opera. Ook andere browsers met vergelijkbare mechanismen worden genoemd, zoals Vivaldi, Yandex, Avast/AVG Browser en CCleaner Browser.

De diefstal richt zich op browserinformatie waarbij de aanvaller bescherming rond app-bound encryption omzeilt. Daarbij worden niet alleen accountgegevens of cookies genoemd, maar ook zaken als:

  • Extension data
  • Browsegeschiedenis
  • Payment card nummers

Daarnaast zoekt StubMaker expliciet naar crypto-wallets en seed phrases, en het verzamelt gegevens uit Telegram Desktop. Verder vraagt het via een externe dienst naar het publieke IP-adres van het slachtoffer.

Na het verzamelen wordt de data samengepakt in een wachtwoordbeveiligd ZIP-bestand. Vervolgens wordt die upload gedaan naar een opslagdienst (Gofile), waarna de resulterende downloadlink naar de aanvaller wordt gestuurd via een niet-versleutelde HTTP verbinding.

Waarom kon dit zo lang “werkend” blijven? Hergebruik van pakketnames

Volgens onderzoekers is de campagne niet alleen disruptief omdat het malware bevat, maar ook omdat het profiteert van RubyGems-gedragskeuzes. In ten minste twee gevallen (met de pakketten brumdler en brundlef) is misbruik gemaakt van een situatie waarin een namespace opnieuw kan worden geclaim zodra alle versies van een gem zijn ingetrokken.

De pakketten waren eerder gepubliceerd door een andere gebruiker (met de naam “gemlewqqhu1”) en daarna gereclaimd door twee accounts die in de campagne opdoken (“mod8rz41mje” en “rbq95bwt6q”). Daardoor kon wat eigenlijk “dood” zou moeten zijn, toch weer opnieuw worden ingezet voor aanvallen.

Ook valt op dat de aanvaller voor elke gem een andere Author-naam gebruikte om de pakketten minder aan elkaar te koppelen. Dat zou kunnen afleiden van het centrale eigenaarschap—maar het Author-veld is volgens de betrokken onderzoekers een ongevalideerde plaintext die niet hoeft overeen te komen met de daadwerkelijke eigenaar.

Impact op teams: wat betekent dit voor jouw Ruby supply chain?

Zelfs als een kwaad pakket snel wordt verwijderd, blijft het risico bestaan zolang ontwikkelaars en CI/CD-processen het kunnen binnenhalen. Dit soort campagnes benadrukt dat je niet kunt leunen op alleen “vendor patches” of alleen runtime monitoring.

Voor Ruby-omgevingen zijn dit praktische aandachtspunten:

  • Controleer gem-namen op typefouten in requirements en scripts (zeker bij overgenomen code).
  • Gebruik versie-pinning en volg vaste dependency locks waar dat mogelijk is.
  • Beperk wie publiceert en waar je automatisch updates accepteert binnen je organisatie.
  • Review install-hooks in dependencies en let op files die automatisch worden uitgevoerd.

Als je in je keten regelmatig nieuwe gems toevoegt, loont het om een lichtgewicht controle toe te voegen die verdachte naming of onverwachte install-gedrag direct signaleert.

Meer supply chain signalen: ook npm krijgt typosquatting-varianten

De publicatie van StubMaker valt samen met andere ontdekkingen in het bredere domein van software supply chain aanvallen. Er werden ook npm-campagnes gemeld waarbij typosquatting inspeelde op executables via het bin-veld. In die gevallen worden naam-conflicten anders gespeeld dan bij klassieke pakketnaam squatters, waardoor standaard mitigerende maatregelen niet altijd afdoende zijn.

Daarnaast zijn er signalen rond kwaadaardige forks van populaire npm-modules. Die vertonen uiteenlopende gedragingen die het installatieproces misbruiken om accounts te sturen of advertentie-inhoud in verstuurde media te injecteren.

Het gemeenschappelijke patroon: aanvallers zoeken naar de zwakste schakel in de manier waarop packages worden geïnstalleerd, geconfigureerd en automatisch uitgevoerd.

Gerelateerde aandachtspunten op deze site

Wie dit soort mechanismen al eerder tegenkwam, herkent de overeenkomst met andere supply chain en install-hook gerelateerde risico’s. Lees bijvoorbeeld ook:

Conclusie: Typosquatting op RubyGems vraagt om strengere dependency discipline

Typosquatting op RubyGems met StubMaker laat zien hoe aanvallers misbruik maken van ogenschijnlijk normale package-installatie. De combinatie van misleidende gem-namen, install-hooks en een “nep build”-fase maakt de techniek lastig te herkennen voordat de schade is aangericht.

Hoewel de specifieke pakketten zijn ingetrokken, is dit vooral een waarschuwing voor teams: houd dependency-invoer strak bij, pin versies, controleer installgedrag en zorg dat CI/CD niet klakkeloos nieuwe of verdachte packages binnenhaalt. Zo verklein je de kans dat een typfout of een ogenschijnlijk onschuldige update verandert in datadiefstal.

Bron: https://thehackernews.com/2026/08/16-typosquatted-rubygems-packages-steal.html