Malicious NuGet Packages Hide Time-Delayed Sabotage Code

Researchers at Socket have identified a sophisticated supply-chain attack campaign in which nine malicious NuGet packages embed time-delayed, probabilistic sabotage routines into otherwise legitimate .NET libraries. 

The packages, downloaded 9,488 times before disclosure, use hidden triggers to kill host processes and, in one case, corrupt industrial control system write operations. 

From Library to Liability

The malicious packages were published under the alias shanhai666 between 2023 and 2024.

Each malicious package delivers genuine, working functionality to establish trust and evade cursory review, while burying ~20 lines of malicious code. 

The actor weaponizes C# extension methods (e.g., .Exec() for database commands and .BeginTran() for S7 PLC clients) so that every database query or PLC operation implicitly executes the injected logic. 

After hardcoded (or encrypted) trigger dates, the payload computes a random number and calls Process.GetCurrentProcess().Kill(), abruptly terminating the application. 

Trigger dates are staggered — some packages activate in 2027 or 2028 — extending the actor’s window to harvest victims before detection.

Sharp7Extend, the campaign’s most dangerous package, combines two sabotage modes.

• An immediate probabilistic process-kill on every PLC operation (active until June 6, 2028) 
• A deferred write-failure mechanism that silently returns failed results for up to 80% of write attempts after a 30–90 minute grace period. 

The latter behavior corrupts PLC writes without obvious error messages, risking actuator non-response, failed safety engagements, and undetected production drift — effects that mimic intermittent hardware problems rather than a deliberate attack.

Why Detection is Difficult

Several factors make these packages difficult to detect: 

• The bulk of the code is legitimate and useful, which passes functional testing and code review.
• Typosquatting (Sharp7 → Sharp7Extend) increases accidental installs in OT environments.
• Bundled legitimate libraries remove obvious red flags during integration testing.
• Randomized, probabilistic activation disguises systematic interference as random failures.
• Long delays between install and activation break forensic timelines by the time impacts are observed. 

The attacker intentionally varied author metadata and forged signature artifacts to frustrate automated heuristics.

Building Supply Chain Resilience

Defending against the NuGet campaign requires immediate action and long-term supply chain resilience.

• Audit dependencies now: Inventory .NET packages and remove or replace any of the nine identified packages immediately.
• Enforce dependency hygiene: Require verified publisher metadata, deny typosquatted names, and restrict package sources to approved registries.
• Scan at build and pre-merge: Integrate SBOM checks and static analysis in CI/CD pipelines to flag time-based logic, unusual extension methods, or obfuscated trigger code.
• Monitor for probabilistic/time-based logic: Alert on date checks, randomized control flows, or unusual use of Process.Kill() and extension methods in dependencies.
• Validate ICS integrity: For industrial environments, implement write-verification for PLC commands, baseline PLC success rates, and monitor for sudden drops in write confirmation.
• Harden supply-chain policies: Enforce least privilege for package installation, require code reviews for third-party libraries, and apply strict change control for OT components.

By integrating these practices, organizations can strengthen their software supply chain and reduce exposure to hidden malicious logic.

This campaign demonstrates how supply-chain attacks can weaponize trusted code and time delays to achieve destructive effects while evading detection.