Gefälschtes NuGet-Paket manipuliert Wettplattform

Sicherheitsforscher von JFrog haben einen ungewöhnlich präzisen Supply-Chain-Angriff aufgedeckt , der offenbar speziell zur Manipulation eines Online-Wettspiels entwickelt wurde. Der Fall zeigt, wie Angreifer legitime Open-Source-Komponenten, Typosquatting und internes Wissen kombinieren können, um unbemerkt geschäftskritische Anwendungen zu verändern.

Das JFrog Security Research Team hat auf der Paketplattform NuGet eine gefälschte Variante der weit verbreiteten JSON-Bibliothek Newtonsoft.Json entdeckt. Das Paket mit dem Namen „Newtonsoftt.Json.Net“ unterschied sich vom Original lediglich durch ein zusätzliches „t“ und den Namenszusatz „.Net“.

Hinter dieser unscheinbaren Abweichung verbarg sich jedoch kein gewöhnlicher Info-Stealer und keine breit angelegte Malware-Kampagne. Das Paket war offenbar als gezieltes Betrugswerkzeug gegen eine einzige Online-Wettplattform konzipiert. Auf allen anderen Systemen verhielt es sich wie eine normale, funktionierende Softwarebibliothek.

Typosquatting mit nahezu perfekter Tarnung

Das manipulierte Paket war von August bis Oktober 2025 über die NuGet-Suche auffindbar. Anschließend entfernte der Autor es offenbar aus den Suchergebnissen. Die eigentlichen Paketdateien blieben jedoch weiterhin abrufbar.

Wer „Newtonsoftt.Json.Net“ versehentlich installierte, erhielt zunächst eine funktionsfähige JSON-Bibliothek. Anwendungen ließen sich ausführen, Tests wurden bestanden und typische Funktionen arbeiteten wie erwartet. Für Entwickler gab es daher kaum einen erkennbaren Anlass, die installierte Abhängigkeit genauer zu untersuchen.

Im Hintergrund enthielt das Paket allerdings einen trojanisierten Fork von Newtonsoft.Json, eine versteckte Schadkomponente und eine zusätzliche Bibliothek zur Manipulation von Methoden während der Laufzeit. Da NuGet alle enthaltenen Komponenten automatisch in die Anwendung integrierte, wurden diese Bestandteile unbemerkt mitgeladen.

Auch die Paketmetadaten waren professionell nachgebildet. Sie verwiesen auf den ursprünglichen Autor, die offizielle Projektwebsite, die bekannte Open-Source-Lizenz und ein plausibles Versionsschema.

Ein Detail verriet jedoch den eigentlichen Zweck: Jede Version enthielt eine interne Serveradresse, die auf ein Projekt für ein sogenanntes Crash-Wettspiel beim Online-Gaming-Anbieter Digitain verwies.

Schadcode startet erst nach einer Verzögerung

Die Schadfunktion war an einen typischen Initialisierungsschritt beim Start einer Anwendung gekoppelt. Sobald die Software ihre standardmäßigen JSON-Einstellungen konfigurierte, ersetzte das Paket diese Konfiguration unbemerkt durch eigene Vorgaben.

Für die Anwendung änderte sich äußerlich zunächst nichts. Sie funktionierte weiter, erzeugte keine offensichtlichen Fehler und hinterließ beim Start unauffällige Protokolleinträge.

Die eigentliche Payload wurde zudem erst zeitversetzt aktiviert. Bei früheren Versionen erfolgte die Ausführung teilweise erst am folgenden Nachmittag. Spätere Versionen warteten rund zehn Minuten.

Diese Verzögerung reduzierte die Wahrscheinlichkeit einer Entdeckung erheblich. Zu diesem Zeitpunkt war der Anwendungsstart längst abgeschlossen, die ersten Prüfungen waren beendet und Administratoren beobachteten den Prozess in der Regel nicht mehr aktiv.

Hinzu kam eine weitere Einschränkung: Die Payload wurde ausschließlich auf Systemen aktiviert, die eine bestimmte interne Methode aus dem Backend des anvisierten Wettspiels bereitstellten. Auf allen anderen Systemen blieb das Paket eine scheinbar legitime JSON-Bibliothek.

Manipulation des entscheidenden Spielmultiplikators

Nach ihrer Aktivierung nutzte die Schadkomponente eine bekannte Technik zum Patchen von Softwaremethoden während der Laufzeit. Dabei übernahm sie genau jene Funktion, die die Ergebnisse des Crash-Wettspiels berechnete.

Bei dieser Spielform steigt ein Multiplikator kontinuierlich an, bis die virtuelle Runde unerwartet „crasht“. Spieler müssen ihren Einsatz rechtzeitig auszahlen lassen. Der sogenannte Crash-Koeffizient entscheidet somit unmittelbar über Gewinne und Verluste.

Das gefälschte Paket ersetzte diesen Wert in ausgewählten Runden durch zuvor festgelegte Zahlen. Die manipulierten Ergebnisse wurden nach einem Muster unter reguläre Spielrunden gemischt, das ausschließlich dem Angreifer bekannt war.

Dadurch blieben die statistischen Gesamtergebnisse weitgehend unauffällig. Für eine bestimmte Tagesstunde kam sogar ein gesondertes Schema zum Einsatz. Der Angreifer verfügte damit offenbar über ein eigenes Playbook, mit dem sich manipulierte Runden gezielt vorhersagen oder ausnutzen ließen.

Sieben Versionen und drei Entwicklungsstufen

JFrog untersuchte insgesamt sieben Versionen des Pakets. Nach Einschätzung der Forscher handelte es sich bei allen Varianten um Builds desselben manipulierten Newtonsoft.Json-Forks.

Das Ziel, der Auslösemechanismus und die grundlegende Funktionsweise blieben gleich. Verändert wurden vor allem die Tarnung, die Exfiltration und die technische Umsetzung des Angriffs.

Die erste Generation war offenbar als lokaler Proof of Concept konzipiert. Sie verfügte über keine Netzwerkfunktionen und gab manipulierte Werte lediglich über die Konsole aus. Eine solche Variante wäre vor allem für einen Insider oder einen Angreifer mit Zugriff auf eine Entwicklungsumgebung nützlich gewesen.

Die zweite Generation ergänzte eine Funktion zur Datenexfiltration. Die Kommunikation wurde durch Reflection und starke Codeverschleierung verborgen, sodass Serveradressen und technische Details im Quellcode kaum sichtbar waren.

In der dritten Generation vereinfachte der Entwickler die Manipulationslogik und stabilisierte die Übertragung der Daten. Die letzte analysierte Version wurde überraschenderweise weitgehend unverschleiert veröffentlicht. Vermutlich handelte es sich um einen versehentlich hochgeladenen Build.

Gerade dieser Fehler ermöglichte es den Forschern, die vollständige Infrastruktur des Angreifers zu rekonstruieren.

Datenverkehr als gewöhnliches Logging getarnt

Jedes manipulierte Spielergebnis wurde an einen externen Server übertragen. Die Kommunikation war jedoch so gestaltet, dass sie wie normale Anwendungstelemetrie wirkte.

Die Schadkomponente nutzte denselben Endpunktaufbau, vergleichbare HTTP-Header und ein ähnliches Ereignisschema wie ein verbreiteter Logging-Dienst. Für Netzwerküberwachungssysteme konnte der ausgehende Datenverkehr daher wie routinemäßiges Monitoring erscheinen.

Der Angreifer erhielt dadurch zwei Vorteile: Er konnte die manipulierten Ergebnisse extern dokumentieren und gleichzeitig überprüfen, ob das kompromittierte Paket weiterhin aktiv war.

Wer von dem Angriff betroffen ist

Als primäres Ziel identifizierte JFrog den Online-Gaming- und Wettplattformanbieter Digitain. Der Täter verfügte offenbar über detaillierte Kenntnisse der internen Softwarearchitektur und der für die Spielergebnisse verantwortlichen Backend-Methode.

Dies deutet darauf hin, dass ein Insider oder eine Person mit Zugriff auf interne Quellcode-Repositories beteiligt gewesen sein könnte. Ein eindeutiger Nachweis zur Identität oder Position des Angreifers liegt jedoch nicht vor.

Die möglichen Folgen betreffen drei zentrale Bereiche:

• Manipulation von Spielergebnissen: Ausgewählte Spielrunden konnten so verändert werden, dass bestimmte Spieler oder andere Beteiligte einen vorhersehbaren Vorteil erhielten.
• Verdeckte Datenübertragung: Jedes manipulierte Ergebnis wurde an einen externen Server übertragen und dort vermutlich als Nachweis oder Kontrollinformation gespeichert.
• Persistenz über die Software-Lieferkette: Da sich das Paket als zentrale JSON-Bibliothek ausgab, konnte es auch neue Builds und Deployments überstehen, solange die gefälschte Abhängigkeit nicht entfernt wurde.

Bemerkenswert ist, was die Schadkomponente nicht tat. Sie stahl keine Zugangsdaten, versuchte nicht, sich im Netzwerk auszubreiten, und installierte keine klassische dauerhafte Hintertür.

Ihr einziges Ziel bestand offenbar darin, eine bestimmte Spiellogik zu manipulieren. Diese extreme Spezialisierung machte den Angriff besonders schwer erkennbar.

JFrog empfiehlt vollständige Bereinigung

Organisationen, die „Newtonsoftt.Json.Net“ eingesetzt haben könnten, sollten das Paket unverzüglich entfernen. JFrog empfiehlt, es durch die offizielle Version von Newtonsoft.Json 13.0.3 oder neuer zu ersetzen und die betroffenen Anwendungen anschließend aus einer sauberen Umgebung neu zu erstellen.

Darüber hinaus sollten zwischengespeicherte Paketkopien aus dem globalen NuGet-Cache sowie aus internen Paket-Mirrors gelöscht werden. Andernfalls besteht die Gefahr, dass die manipulierte Abhängigkeit bei späteren Builds erneut eingebunden wird.

Ausgehende Verbindungen zur Infrastruktur des Angreifers sollten blockiert und vorhandene Netzwerkprotokolle auf frühere Kommunikation überprüft werden.

Um ähnliche Angriffe zu verhindern, sollten Unternehmen Softwareabhängigkeiten über Lock-Dateien oder zentrales Versionsmanagement auf geprüfte Versionen festlegen. Private Paketquellen sollten zudem mit Allow-Lists abgesichert werden.

Supply-Chain-Angriffe werden immer zielgerichteter

Der Vorfall zeigt, dass ein einziger zusätzlicher Buchstabe im Namen einer Abhängigkeit ausreichen kann, um Schadcode in eine geschäftskritische Anwendung einzuschleusen.

Besonders gefährlich war nicht nur die professionelle Nachahmung der Originalbibliothek. Entscheidend war vielmehr, dass die Schadfunktion ausschließlich in einer klar definierten Zielumgebung aktiviert wurde und erst lange nach dem Start der Anwendung reagierte.

Der Fall verdeutlicht damit eine neue Qualität von Supply-Chain-Angriffen. Ein Softwarepaket muss nicht auf Tausenden Systemen schädliches Verhalten zeigen, um eine erhebliche Bedrohung darzustellen.

Es kann für nahezu alle Nutzer vollkommen legitim erscheinen – und dennoch genau in der Umgebung, für die es entwickelt wurde, verheerenden Schaden anrichten.