ITInnovationStation

Most software supply-chain attacks are built for scale. Attackers compromise a widely used library or publish a malicious package hoping to steal credentials, install backdoors or infect as many developers as possible.

A newly disclosed NuGet attack followed a far more surgical model.

On July 21, 2026, JFrog Security Research published its analysis of Newtonsoftt.Json.Net, a typosquatted package designed to resemble the legitimate and extremely popular Newtonsoft.Json library. The malicious package did not behave like ordinary commodity malware. It remained largely harmless on unrelated systems while waiting for the internal code of one specific online betting platform.

When it encountered that environment, it attempted to modify the application’s game results.

This was not simply dependency confusion, credential theft or a generic software backdoor. It was target-specific business-logic sabotage delivered through the software supply chain.

A Single Extra Letter

NuGet is the standard package-management ecosystem used by many .NET developers. A NuGet package can contain compiled libraries, dependencies and metadata that are automatically incorporated into an application during development or deployment.

The legitimate package targeted by the impersonation was:

Newtonsoft.Json

The malicious package was:

Newtonsoftt.Json.Net

The additional t in “Newtonsoftt” and the appended .Net were easy to overlook.

This type of attack is known as typosquatting. An attacker publishes a package whose name closely resembles a trusted dependency, hoping that a developer mistypes the name, selects the wrong search result or accepts a misleading recommendation.

The package metadata reinforced the deception. According to JFrog, it claimed the identity of Json.NET creator James Newton-King, referenced the legitimate project’s website, used familiar descriptions and adopted an 11.0.x versioning pattern that looked plausible at a glance.

The disguise went beyond metadata.

The package included a functional, trojanized fork of the real JSON library. Applications could continue serializing and deserializing data normally. Builds could succeed. Tests might pass. Developers outside the intended target could use the package without seeing an obvious error.

That normal behavior was not incidental. It was part of the concealment.

Malware That Waited for One Application

Many malicious packages execute as soon as they are installed or imported. They may collect environment variables, steal cryptocurrency wallets, download another payload or open a reverse shell.

This package was more selective.

Its malicious logic was triggered through the commonly used JsonConvert.DefaultSettings configuration property. After activation, the package delayed its next stage rather than immediately performing a suspicious action. Different versions used delays ranging from approximately ten minutes to a scheduled period on the following day.

The delay helped the package survive ordinary testing.

A developer might add the dependency, start the application, confirm that JSON processing worked and conclude that nothing was wrong. Automated tests or security sandboxes with short execution windows might also finish before the hidden behavior began.

Even after the delay, the payload still needed to find a highly specific target:

Digitain.FG.SharedCrash.GameLogic.SharedCrashRules.GenerateGameResult

That internal method reportedly belonged to the backend of a “crash”-style betting game operated by Digitain or its BetOnGames platform. If the method was absent, the package had no game logic to patch.

On an ordinary application, the malicious dependency effectively remained dormant.

On the intended betting system, it used the legitimate HarmonyLib runtime-patching framework to alter the game-result method while the application was running. HarmonyLib itself is a dual-use development tool, not inherently malicious. In this case, it was used to change application behavior without replacing the original executable on disk.

Sabotaging Integrity Instead of Stealing Access

The objective was unusually narrow: manipulate the outcome of selected betting rounds.

JFrog found that the package’s generations used date, time and predefined value tables to determine when manipulated rounds should occur. The changes were mixed among normal results and stopped after a limited number of affected rounds.

That design could make the fraud more difficult to notice.

If every game result became abnormal, customers, operators and monitoring systems would quickly detect the problem. Sporadic changes distributed among legitimate rounds could resemble statistical variation, software defects or ordinary player behavior.

Later package versions also sent information about manipulated rounds to an attacker-controlled server. This would allow the operator to know when rigged results occurred, potentially enabling coordinated betting or providing confirmation that the sabotage remained active.

Notably, JFrog reported that the package did not include the usual collection of credential-stealing, persistence or lateral-movement features.

Its apparent purpose was not to take control of the entire server.

Its purpose was to corrupt the integrity of one business process.

That distinction is essential.

Cybersecurity frequently emphasizes confidentiality: protecting passwords, customer records and sensitive documents from theft. It also emphasizes availability: preventing ransomware and denial-of-service attacks from taking systems offline.

This attack primarily targeted integrity.

The application could remain online. Users could continue placing bets. Logs could continue being generated. The service might appear healthy while the calculations at the heart of the business were being covertly altered.

Seven Versions and Three Generations

JFrog identified seven versions published between August and October 2025. The versions represented three generations of development, with changes to obfuscation, manipulation logic and data-exfiltration behavior.

Some builds were heavily obfuscated. Others were easier to analyze. The final version was reportedly published without obfuscation, possibly because of an operational mistake or an accidental clean build.

The timeline requires an important clarification.

The packages were published in 2025, not July 2026. The event was newly disclosed and analyzed on July 21, 2026; it was not necessarily a newly launched attack that month.

JFrog privately notified Digitain on July 7, 2026. The company responded that it had already become aware of and resolved the issue. However, JFrog said it did not know whether the malicious package had successfully executed on production systems or what the complete exposure may have been.

We therefore know that the package was intentionally constructed to target the platform, but public reporting does not establish the full operational outcome.

The Insider-Knowledge Question

The package contained indicators suggesting unusually detailed knowledge of the victim’s software.

JFrog found an internal repository URL referencing Digitain infrastructure and the FG-Crash project. The malware also knew the precise namespace, class and method associated with generating game results.

That level of specificity raises several possibilities.

The creator may have been an insider, a former employee, a contractor, someone with access to leaked source code or an external attacker who had previously compromised the development environment.

The evidence does not publicly establish which explanation is correct.

However, it demonstrates why source-code exposure can create risks beyond intellectual-property theft. Internal class names, service relationships, build processes and method signatures can enable attackers to create malware that activates only inside a particular organization.

Why This Attack Matters

The larger lesson is that malicious dependencies do not need to look malicious everywhere.

Traditional package scanning often searches for universally suspicious behavior: shell execution, credential access, persistence commands, encoded downloads or connections to known malicious infrastructure.

A target-specific package can evade that model.

It can provide its advertised functionality, avoid crashing applications and reserve its malicious activity for one precise runtime condition. Public analysis systems may never contain the victim’s private class names or internal business logic, meaning the hidden payload may never fully activate during automated testing.

The compromise also persists naturally through the software lifecycle. As long as the dependency remains referenced, clean builds and redeployments may reinstall the sabotage.

Defenders must therefore verify not only whether a dependency contains obviously malicious code, but also:

• Whether the package identity and publisher are legitimate
• Whether its name differs subtly from an approved component
• Whether unexpected assemblies are loaded with it
• Whether runtime-patching frameworks are used
• Whether code searches for private organizational namespaces
• Whether application behavior changes after delayed execution
• Whether dependencies are centrally approved and version-locked

NuGet supports centralized package-version management and lock files that record the dependency graph used during restoration. These controls can help teams review and stabilize approved dependencies rather than allowing developers to introduce similarly named packages without scrutiny.

A New Model for Supply-Chain Sabotage

The most disturbing feature of Newtonsoftt.Json.Net was not its complexity.

It was its restraint.

The package did not need to infect thousands of organizations. It needed only one developer, one mistaken dependency and one application containing the method it was built to recognize.

For everyone else, it was a functioning JSON library.

For its intended target, it was a hidden mechanism for manipulating the fundamental outcome of the business.

That is what makes the incident an important evolution in software supply-chain attacks. The compromised component was not merely a vehicle for entering the network. It was built to understand and alter the business itself.

The next malicious dependency may not steal a password or deploy ransomware.

It may quietly change a price, approve a transaction, alter a medical calculation, manipulate an industrial process or determine who wins.