Skip to content
feed: live
>_ 0dayNews
supply chain
Analysis

A NuGet Typosquat That Rigged Games Instead of Wallets

A trojanized fork of Newtonsoft.Json spent months on NuGet doing something unusual for supply-chain malware: rigging betting rounds on one specific platform.

A NuGet Typosquat That Rigged Games Instead of Wallets
Image: 0dayNews / 0dayNews Editorial · All rights reserved
kilobaud Dave "Kilobaud" Ferris · Published · 3 min read

The pattern is familiar enough that most of the news value here is what didn’t happen.

A trojanized fork of Newtonsoft.Json, the .NET library that lives inside a large fraction of production C# code, sat on NuGet from August through October under the name Newtonsoftt.Json.Net — one extra “t,” a tell as old as squatted domains. JFrog’s Guy Korolevski documented seven versions of the package, roughly 1,200 downloads, published between August 13 and October 10, 2025 across three iterative generations before the owner (MagicalPuff96) unlisted it.

That much is the standard supply-chain writeup we’ve been running for a decade now. What makes this one worth the callout is what the payload does. It isn’t a credential stealer. It doesn’t rifle through browser profiles, drop a wallet grabber, or beacon home with environment variables. It checks whether the host is running Digitain’s FG-Crash betting backend, and if it is, rigs the round outcomes and exfiltrates the manipulated results to a single controller at 185.126.237[.]64:5341. On any other host, it stays silent. The trigger is wired through the JsonConvert.DefaultSettings setter, with randomized delays before the malicious path runs — again, per JFrog’s writeup, which I’d point readers to for the full analysis rather than restating any of the mechanics here.

Analysis

That’s a very different economic bet from the usual npm/PyPI/NuGet trojan. The generic infostealer plays the volume game: infect broadly, cash out on whatever falls out. This one reads closer to a targeted commercial fraud tool that happens to be distributed like a supply-chain attack. The attacker didn’t need twelve million downloads. They needed the handful that would reach operators or affiliates of one specific betting platform, and the near-zero payload activity on every other install was a feature — it kept the package boring enough not to trip anyone’s telemetry for the better part of two months.

The registry-level lesson isn’t new. NuGet, npm, and PyPI all still allow lookalike names that a tired reviewer pastes into a .csproj without a second glance, and none of them treat the confusable-character surface as a first-class problem. Newtonsoftt.Json.Net didn’t need to be sophisticated. It needed to be one keystroke removed from a package almost every .NET shop imports, published by an account nobody looked twice at, and left alone long enough for a specific class of victim to find it organically. That worked. The gatekeepers haven’t closed that gap and don’t appear to be in a hurry to.

What’s new-ish is the shape of the attacker. The last few years of supply-chain reporting have flattened almost every campaign into the same silhouette: dropper, infostealer, RAT, cash out. This one reads more like someone with domain knowledge of a specific betting stack looked at the .NET dependency graph, noticed that a widely used client library sat inside that stack, and picked the delivery method with the lowest per-victim cost. The trust model at the registry level was never really designed to catch that, either — but it’s a useful reminder that the reason to catch it isn’t only “someone wants your AWS keys.” Sometimes someone just wants to move the odds on a specific product you happen to run.

What to do

Nothing about the mitigation is exotic. Audit .csproj files for Newtonsoftt.Json.Net (double-t) or any near-neighbor of Newtonsoft.Json; the legitimate package is Newtonsoft.Json on NuGet, maintained by James Newton-King. JFrog’s indicator — the exfiltration endpoint 185.126.237[.]64:5341 — is worth a firewall log grep. If you operate anything downstream of Digitain FG-Crash, this is a call to your fraud team, not just your SOC.

The larger habit — pinning explicit package versions, enforcing an allowlist of upstream package identities, and running a private mirror rather than pulling straight from a public registry — is the answer the industry has been giving for years and mostly not implementing. It’ll still be the answer next time. The delivery method won’t be the interesting part; the payload’s target will be.

Found this useful? Share it.