Eine funktionierende Bibliothek mit gefälschter Identität
Wer das Paket versehentlich durch einen Tippfehler installierte, erhielt eine echte, funktionierende JSON-Bibliothek. Alles arbeitete normal, Anwendungen liefen weiter, Tests wurden bestanden, sodass niemand Anlass hatte, nach einem Problem zu suchen. Im Verborgenen brachte das Paket jedoch einen trojanisierten Fork von Newtonsoft.Json mit, dazu eine versteckte Payload und eine Bibliothek zum Patchen zur Laufzeit. Da NuGet alle mitgelieferten Komponenten automatisch einbindet, lud ein Entwickler, der nur eine JSON-Bibliothek hinzufügen wollte, unbemerkt alle drei in seine Anwendung. Die Metadaten waren eine sorgfältige Nachahmung: Sie nannten den ursprünglichen Autor der echten Bibliothek, die offizielle Projektwebsite, die übliche Open-Source-Lizenz und ein unauffälliges Versionsschema. Doch dieselben Metadaten verrieten das Ziel: Jede Version enthielt eine interne Server-URL, die auf ein Projekt für ein Wettspiel vom Typ ‚Crash’ bei Digitain, einer Online-Wettplattform, verwies.
Der technische Hintergrund: ein verzögerter, gut versteckter Auslöser
Das schädliche Verhalten war an einen gängigen Schritt beim Anwendungsstart geknüpft. Sobald die Anwendung ihre Standard-JSON-Einstellungen konfigurierte, ersetzte der Trojaner heimlich die Konfiguration des Entwicklers durch seine eigene, sodass alles weiterhin funktionierte und nichts kaputt wirkte. Zugleich brachte er seine eigentliche Payload über einen Timer verzögert in Stellung: In früheren Versionen zündete sie erst am nächsten Nachmittag, in späteren nach rund zehn Minuten. Wurde die Payload aktiv, hatte die Anwendung den Start längst hinter sich, die Logs sahen sauber aus und niemand beobachtete den Prozess mehr. Zudem wurde die Payload nur auf Systemen ausgelöst, die eine bestimmte interne Methode aus dem Spiel-Backend der Wettplattform bereitstellten; für alle anderen blieb das Paket schlicht eine funktionierende JSON-Bibliothek.
Sobald sie aktiv war, kaperte die Payload mit einer bekannten Technik zum Patchen zur Laufzeit genau jene Methode, die die Spielergebnisse erzeugte, und ersetzte den Crash-Koeffizienten, also den entscheidenden Multiplikator des Spiels, durch Werte, die der Angreifer zuvor in Tabellen festgelegt hatte. Entscheidend dabei: Die manipulierten Runden waren nach einem nur dem Angreifer bekannten Muster unter die regulären gemischt, sodass der Betrug in der Gesamtstatistik nicht auffiel. Eine bestimmte Tagesstunde behandelte das Schema sogar gesondert. So erhielt der Angreifer ein eigenes Playbook, das das Muster unvorhersehbar und schwer erkennbar hielt.
Sieben Versionen über drei Generationen
JFrog analysierte alle sieben Versionen und stellte fest, dass es sich um Builds desselben trojanisierten Forks handelte, mit identischem Auslöser und Ziel; verändert hatten sich nur die Raffinesse der Tarnung und die Angriffstechnik. Die früheste Generation war ein lokaler Proof of Concept ohne Netzwerkfunktion und gab die manipulierten Werte über die Konsole aus, was nur einem Insider nützte, der den Patch auf einem Entwicklungsrechner testete. Die zweite ergänzte eine Exfiltration, verbarg sie aber hinter Reflection und starker Verschleierung, um die Serverdetails des Angreifers aus dem sichtbaren Code herauszuhalten. Die dritte straffte die Manipulation und stabilisierte die Exfiltration. Die letzte Version wurde völlig unverschleiert ausgeliefert, passend zu einem versehentlich veröffentlichten sauberen Build, was den Forschern schließlich erlaubte, die komplette Angreifer-Infrastruktur zu rekonstruieren. Diese Exfiltration war ihrerseits als gewöhnliches Logging getarnt: Jedes manipulierte Ergebnis ging an den Server des Angreifers, und zwar über denselben Endpunkt, dasselbe Header-Format und dasselbe Event-Schema wie bei einem verbreiteten Logging-Dienst. So wirkte der Datenverkehr wie routinemäßige Telemetrie statt wie Schadsoftware und verschaffte dem Angreifer sowohl einen externen Nachweis des Betrugs als auch einen verdeckten Kanal, um zu prüfen, ob der Trojaner noch lief.
Wer ist betroffen
Das primäre Opfer ist Digitain, Betreiber des angegriffenen „Crash"-Wettspiels. Der Angreifer, möglicherweise ein Insider oder jemand mit Zugriff auf das interne Quellcode-Repository, erlangte teilweise Kontrolle über die Spielergebnisse. Die Auswirkungen verteilen sich auf drei Bereiche:
- Finanzieller Betrug: Manipulierte Spielrunden, die den Ausgang zugunsten bestimmter Spieler oder des Betreibers steuern.
- Datenexfiltration: Jedes manipulierte Ergebnis floss an einen externen Server und lieferte dem Angreifer eine heimliche Mitschrift des Betrugs.
- Dauerhafte Verankerung in der Software-Lieferkette: Das Paket gab sich als zentrale JSON-Bibliothek aus und überdauerte Rebuilds, bis die Abhängigkeit korrigiert wurde.
Die Payload stahl keine Zugangsdaten, nistete sich nicht dauerhaft ein und breitete sich nicht im Netzwerk aus. Ihr einziges Ziel war es, die Spielergebnisse zu manipulieren, und für alle anderen Entwickler blieb sie unsichtbar, was den Angriff so wirkungsvoll machte.
Maßnahmen zur Behebung
JFrog empfiehlt betroffenen Organisationen:
„Newtonsoftt.Json.Net" entfernen, durch das offizielle Newtonsoft.Json 13.0.3 oder neuer ersetzen und aus einem sauberen Restore neu bauen.
Zwischengespeicherte Kopien aus dem globalen NuGet-Cache und allen internen Feed-Mirrors löschen.
Ausgehende Verbindungen zum Server des Angreifers blockieren und Netzwerk-Logs auf frühere Kontakte prüfen.
Newtonsoft.Json über Lock-Dateien oder zentrales Versionsmanagement auf eine geprüfte Version festlegen und private Feeds per Allow-List absichern.
Was der Fall lehrt
Der Angriff zeigt, wie viel Schaden ein einziger Tippfehler anrichten kann, wenn der Angreifer sein Ziel gut kennt. Der doppelte Buchstabe ist der einzige sichtbare Unterschied zur echten Bibliothek, und die Payload wird nur auf Systemen aktiv, die eine bestimmte interne Methode bereitstellen, und das erst mit einer Verzögerung, die lange nach dem Start greift. Die Entwicklung über drei Generationen offenbart einen versierten Angreifer, der seine Verschleierung stetig verfeinerte. Die größere Lehre: Ein Paket muss kein breit angelegtes schädliches Verhalten zeigen, um gefährlich zu sein. Eine Abhängigkeit kann für nahezu alle harmlos sein und dennoch in genau der Umgebung, für die sie gebaut wurde, verheerend wirken.
