Eine neue Kampagne zur Typosquatting RubyGems beschäftigt derzeit die Sicherheitscommunity. Dabei wurden mehrere Ruby-Pakete so benannt, dass sie dem Anschein nach bekannte Abhängigkeiten imitieren. Ziel: Nutzer sollen die Gems versehentlich installieren – und dabei einem Windows-basierten Information Stealer den Weg auf ihre Systeme öffnen.
Die Aktivität wurde am 15. August 2026 von OpenSourceMalware entdeckt. Verfolgt wird der Angriff unter dem Namen StubMaker. Laut den Forschern wurden die betroffenen Pakete inzwischen wieder aus RubyGems entfernt, dennoch lohnt sich ein genauer Blick auf die Mechanik, weil sie typische Schwächen in der Lieferkette ausnutzt.
Was steckt hinter StubMaker?
StubMaker ist als Information Stealer ausgelegt. Er sammelt unter anderem Browser-Credentials, Daten aus kryptowährungsbezogenen Wallets sowie Seed Phrases. Zusätzlich werden Telegram-Daten ausgelesen. Das Schadprogramm zielt damit klar auf Informationen, die für Identitätsdiebstahl, Kontokompromittierung und finanziellen Schaden besonders wertvoll sind.
Die Sicherheitsforscher berichten außerdem, dass die bösartigen Gems zwar wie Typosquats wirken, jedoch nicht besonders raffiniert getarnt sind. Statt subtilen Varianten seien es eher „klobige“ Tippfehler, die trotzdem erfolgreich sein können, wenn in Projekt-Setups oder bei der Installation gerade keine strikten Prüfungen erfolgen.
Die betroffenen RubyGems-Pakete
Im Rahmen der Kampagne wurden insgesamt 16 Gems veröffentlicht. Zu den aufgeführten Paketnamen gehören unter anderem:
- ubnuler, ubnlder
- ri18nr, reaker, rakier
- orakw, joxn, ise18n, ioe18n
- ie18u, iai8n, i1l8n, i18om
- activesupmport
- brumdler, brundlef
Zum Zeitpunkt der Berichterstattung waren diese Pakete bereits von RubyGems entfernt („yanked“). Trotzdem sind solche Vorfälle ein Hinweis darauf, wie schnell bösartige Pakete vor der Sperrung in reale Umgebungen gelangen können – etwa durch bereits gestartete Installationen oder durch lokale Caches.
Wie funktioniert die Typosquatting RubyGems-Kampagne?
Der Kern der Angriffslogik liegt in Ruby-Installationshooks. Konkret nutzen die StubMaker-Gems einen extconf.rb-Hook, um bei der Installation Code ausführen zu lassen. Dieses Verhalten knüpft an eine typische Ruby-Praxis an: Beim Installieren eines Gems kann extconf.rb automatisch gestartet werden, um native Erweiterungen zu konfigurieren.
Diese Dateien findet man üblicherweise in der ext/-Struktur eines Ruby-Pakets. In „normalen“ Fällen werden dabei Erweiterungen für C, C++ oder Rust vorbereitet und während der Installation kompiliert.
Bei StubMaker wird dieses Szenario jedoch als Transportweg verwendet. Der Ruby-Hook dient dazu, einen 22 MB großen Loader aus einer GitHub-Veröffentlichung abzurufen. Anschließend startet ein weiterer Payload-Stage ein in den Loader eingebettetes Schadprogramm auf Go-Basis, das als wincfg beschrieben wird.
Von Rust zu Go: Laden, starten, stehlen
Der Ablauf ist damit mehrstufig: Zuerst lädt der Installer den Rust-basierten Loader herunter, dann übernimmt der Go-basierte Stealer. Ergänzend wird im Verlauf ein DLL-Payload genannt (abe_payload.dll), die schließlich die eigentlichen Daten aus Browsern extrahiert.
Im Fokus stehen Chromium-basierte Browser und zugehörige Programme, darunter unter anderem Google Chrome, Microsoft Edge, Brave, Opera, Vivaldi sowie weitere aufgeführte Anwendungen wie Yandex, Avast, AVG und sogar CCleaner Browser.
Laut den Forschern umgeht StubMaker dabei ABE-Schutzmechanismen (App-Bound Encryption), die von Google eingeführt wurden. Dadurch wird es möglich, Credentials auszulesen, obwohl Browserdaten normalerweise stärker geschützt sind.
Welche Daten werden gesammelt?
Neben Browser-Credentials sammelt StubMaker weitere sensible Informationen:
- Erweiterungsdaten und Browser-Historie
- Zahlungskartennummern
- Suche nach Krypto-Wallets und Seed Phrases
- Telegram Desktop-Daten
- Systeminformationen für ein besseres Profiling
Außerdem wird eine externe Anfrage an api.ipify.org gestellt, um die öffentliche IP-Adresse des Opfers zu ermitteln. Solche Metadaten helfen Angreifern, Zielumgebungen besser einzuordnen und Kampagnen zu steuern.
Fake-Build statt „böses Kompilieren“
Ein besonders bemerkenswerter Punkt ist die Tarnung im Installationsprozess. McCarty beschreibt, dass StubMaker keinen echten Build erzeugt. Stattdessen generiert das Paket eine Makefile mit leeren bzw. wirkungslosen Targets wie „all“, „install“ und „clean“. Zusätzlich werden Stub-Skripte für Unix und Windows bereitgestellt, die lediglich Erfolg melden.
Damit erscheint die Erweiterungsphase beim Installieren „sauber“. Die eigentliche Arbeit verlagert sich jedoch in den Installer-Hook selbst: Plattform-Beacons, das Laden des Windows-Loaders und die Ausführung passieren also genau dort, wo der Benutzer die Installation auslöst.
Der Name StubMaker soll dabei genau diese Strategie widerspiegeln: Es wird eine falsche Build-Toolchain hergestellt, um eine bösartige Installation wie eine Routine-Installation wirken zu lassen.
Wie der Angriff selbst nach „Yank“ weiterging
In mindestens zwei Fällen – brumdler und brundlef – fanden die Forscher eine besonders problematische Nutzung eines RubyGems-Verhaltens. Wenn alle Versionen eines Gems yanked wurden, kann unter bestimmten Bedingungen ein Namespace für Dritte wieder verfügbar werden, sodass er erneut beansprucht werden kann.
Ursprünglich wurden die betreffenden Pakete von einem Account veröffentlicht, der als gemlewqqhu1 (aka Taylor Moore) genannt wird. Anschließend wurden sie von den späteren Angreifer-Konten erneut „beansprucht“ – nämlich durch die Accounts mod8rz41mje (Riley Miller) und rbq95bwt6q (Alex Davis).
Die Folge: Obwohl die Kampagne früh gestoppt wurde, konnte sie laut OpenSourceMalware zeitweise effektiver wirken, weil „was hätte tot sein sollen“ wieder aktiviert wurde – und damit weitere Nutzer kompromittiert werden konnten.
Unvalidierter Author-Name als zusätzliche Tarnung
Ein weiterer Hebel ist das Ausstellen der Gems mit unterschiedlichen „Author“-Angaben. Laut den Forschern wählte der Angreifer pro Paket einen anderen Author-Namen, um eine Zugehörigkeit zu verschleiern, obwohl der Owner-Account gleich blieb.
Der Grund: Das Feld „Author“ ist eine unvalidierte Klartext-Information. Es muss nicht mit dem tatsächlichen Owner übereinstimmen. Dadurch kann die Täuschung in RubyGems stärker aussehen, als sie tatsächlich ist.
Weitere Supply-Chain-Kampagnen im npm-Umfeld
Die Enthüllung fällt in eine breitere Welle von Supply-Chain-Angriffen. Parallel wird über zwei weitere npm-Kampagnen berichtet, die in der gleichen Sicherheitsmeldung erwähnt werden:
- Typosquats über das „bin“-Feld: 21 Pakete zielten auf CLI-Binärnamen ab, die aus Google-Scopes resultieren. Dadurch entstanden ungescoped Namen, die Dritte registrieren können. Übliche Gegenmaßnahmen greifen hier teilweise nicht, weil die Lücke nicht durch Scope-Publishing oder Lockfile-Pinning vollständig geschlossen wird.
- Maliziöse Baileys-Forks: Mehrere Abzweigungen des WhatsApp-Ökosystems wurden für verdeckte Manipulationen missbraucht, etwa indem das Bot-Konto Kanälen folgt, die vom Autor kontrolliert werden, und Werbe-URLs in Medien injiziert.
Auch diese Hinweise unterstreichen: Die Angriffsfläche in Paketmanager-Ökosystemen wächst nicht nur über Tippfehler, sondern auch über Details im Packaging- und Hook-Verhalten.
Was Anwender jetzt tun sollten
Auch wenn die StubMaker-Gems entfernt wurden, bleibt das Risiko praktisch: Sobald ein bösartiges Paket installiert wurde oder in einer Umgebung bereits referenziert ist, kann der Schaden entstehen.
Setzen Sie deshalb auf grundlegende Schutzmaßnahmen, die nicht nur „heute“, sondern dauerhaft helfen:
- Abhängigkeiten prüfen: Achten Sie auf unerwartete Paketnamen und Versionen, vor allem bei Tippfehlern.
- Quellen absichern: Nutzen Sie nachvollziehbare Lockfiles und kontrollieren Sie Builds in CI/CD.
- Systeme überwachen: Prüfen Sie verdächtige Installationsaktivitäten und ungewöhnliche Netzwerkzugriffe.
- Defensive Hygiene: Halten Sie Build-Hosts und Entwicklerumgebungen möglichst isoliert und begrenzen Sie Rechte.
So reduzieren Sie die Chancen, dass Typosquatting RubyGems-Angriffe überhaupt erfolgreich werden – selbst wenn bösartige Pakete kurzfristig verfügbar sind.
Fazit: Ruby-Installationshooks bleiben ein attraktives Ziel
Die StubMaker-Kampagne zeigt eindrücklich, wie Angreifer die Installationsmechanik von Ruby-Paketen ausnutzen. Durch Hooks wie extconf.rb kann Code zur falschen Zeit und am richtigen Ort gestartet werden, während die Build-Phase nach außen „unauffällig“ wirkt. In Kombination mit Wiederverfügbarkeiten durch Yank-Verhalten und unvalidierten Metafeldern entsteht ein Angriffsszenario, das schwerer zu stoppen ist als nur „Pakete entfernen“.
Für Teams, die RubyGems nutzen, ist das eine klare Erinnerung: Transparenz, Verifikation und kontrollierte Abhängigkeitsprozesse sind entscheidend, damit aus einem Tippfehler nicht ein echter Sicherheitsvorfall wird.
Quelle: https://thehackernews.com/2026/08/16-typosquatted-rubygems-packages-steal.html
