Trojanized Newtonsoft.Json Fork Hides Game-Rigging Code in a Working Library

# The NuGet Heist: How a Fake JSON Library Was Rigging Online Betting Games

Someone who calls themselves "theperfectheist2025" just revealed what may be the most precisely targeted supply chain attack ever documented — and their goal wasn't your password or your AWS keys. They wanted to fix the outcome of a crash game.

Researchers at JFrog published findings this week on a NuGet package called Newtonsoftt.Json.Net — one extra t in Newtonsoft, the kind of typo a developer's fingers produce on a bad afternoon. The package is a fully functional fork of the real Newtonsoft.Json library, one of the most downloaded packages in the entire .NET ecosystem. Install it by mistake and your JSON serialization works perfectly. Unless you happen to be running Digitain's FG-Crash betting backend. Then you just got robbed.

## A Scalpel, Not a Sledgehammer

Seven versions of the package appeared on NuGet between August and October 2025. All seven contain the same trojanized fork. All seven leaked an internal Digitain repository URL in their metadata. The attacker isn't hiding that they had access to Digitain's source code — that leak is just there, baked into every artifact, presumably because they were working against the actual FG-Crash codebase and forgot to sanitize their package configuration before publishing.

The malicious code waits for JsonConvert.DefaultSettings to be assigned — a standard initialization step in many .NET applications — then introduces a randomized delay before activating. No hurry. No noise. It specifically patches a method that only exists in Digitain's crash-game backend, meaning any other developer who accidentally installs the package gets exactly what they expected: a working JSON library, nothing more.

"Non-targeted consumers may see only a working JSON library and no rigging behavior," JFrog researcher Guy Korolevski noted, "which is exactly what makes this typosquat attack so effective."

There's no credential theft. No persistence mechanism. No lateral movement. The payload does exactly one thing: rig game round results and exfiltrate them to a hard-coded C2 address (185.126.237[.]64:5341) disguised as telemetry, using an HTTP header keyed to theperfectheist2025. The attacker named the operation in the artifact itself.

## Three Generations of Refinement

What JFrog documented isn't a single attack — it's an iterative development cycle. Three distinct generations are visible across the seven published versions:

Generation 1 established that rigging was possible. Local-only manipulation, no data leaving the system. A proof of concept against Digitain's actual codebase.

Generation 2 added exfiltration but leaned on ConfuserEx obfuscation and reflection to hide the mechanics from static analysis. The attacker was learning.

Generation 3 cleaned up the rigging logic, stabilized the exfiltration path, and then — in version 11.0.11 — accidentally shipped an unobfuscated build. JFrog describes this as "consistent with an accidental clean build being published," which is a diplomatic way of saying the attacker fumbled the release process at the end.

That fumble is revealing. This isn't a sophisticated criminal syndicate with a release pipeline. It's one person (or a small group), iterating in private against source code they already had, publishing incrementally, and making human mistakes. The theperfectheist2025 handle is starting to look more aspirational than descriptive.

## What the Leaked Repository URL Actually Means

The internal Digitain repository URL embedded in all seven package versions deserves more attention than it's getting. This isn't circumstantial. The attacker had Digitain's FG-Crash source code. They knew exactly which method to patch because they were compiling against Digitain's actual codebase.

That means one of a few things is true: someone inside Digitain built this, someone outside Digitain compromised Digitain's source code repository first (making this an attack following a prior breach), or Digitain's source code was exposed through some other vector — leaked credentials, an exposed repo, a contractor's laptop.

Digitain confirmed awareness of the issue and says it has taken remediation steps. The company hasn't disclosed whether any games were actually compromised or whether any payouts were affected. "The full extent of the exposure remains unknown" is doing a lot of heavy lifting in JFrog's writeup.

For a betting platform, that ambiguity is material. FG-Crash is a game where players bet on a multiplier that could crash at any moment. If the attacker could influence when the crash happens, they could place bets through separate accounts with foreknowledge of the outcome. The package exfiltrating "rigged round results" to an attacker-controlled server is the tell — that data was being used to inform wagers somewhere.

## For Developers Still Running It

The package has been unlisted on NuGet — it won't surface in search results — but the artifacts remain downloadable. If Newtonsoftt.Json.Net appears in any of your dependency trees, assume compromise of any system where it ran alongside Digitain's backend. For everyone else:

---

## HackWire Analysis

This attack should reframe how the security community thinks about supply chain threats.

The dominant mental model for NuGet, npm, and PyPI typosquats is mass credential harvesting — spray a believable package name, collect whatever environment variables and SSH keys flow through CI pipelines, monetize at scale. The Newtonsoftt.Json.Net campaign breaks that pattern entirely. It's not a net; it's a sniper shot.

What makes this structurally different isn't just the targeting — it's the prior access implied by the targeting. You can't write a patch that activates only on a specific private method without having read the source that defines that method. The supply chain compromise follows an earlier compromise that JFrog's report doesn't fully address. The NuGet package was the delivery vehicle for fraud, not the entry point into Digitain.

This matters because defenders are optimized for the wrong threat model. Software composition analysis tools flag known-malicious packages and packages with suspicious behaviors like shell execution or network calls at install time. A package that sits dormant, behaves correctly for everyone except one organization, and activates only after a specific property setter fires — that's a much harder detection problem. Your SCA scanner almost certainly would have passed this clean.

The gambling and gaming sector should be treating this as a category-defining incident. You are a financial target. Your backend libraries are an attack surface. And if your source code has ever been accessible to more than a handful of people, you don't actually know what the attacker knows about your stack.

The broader pattern worth watching: as high-value vertical targets (sports betting, DeFi protocols, trading platforms) increasingly run on commodity open-source infrastructure, expect more surgical supply chain campaigns designed for financial fraud rather than bulk data theft. The economics are compelling — rig enough crash game rounds and the return on a few months of C# work gets interesting fast.

The "perfect heist" it wasn't. But the concept is sound enough that someone less careless will try it again.

— HackWire Editorial

---

## Related Coverage