A chilling discovery has been made in the .NET development world. Security experts have uncovered nine malicious packages on the NuGet repository, a central hub for developer tools. These packages, downloaded nearly 9,500 times, are not just simple malware; they are sophisticated “logic bombs” designed to secretly sabotage databases and even disrupt critical industrial control systems. The code is programmed to wait years before unleashing its destructive payload, creating a nightmare scenario for any company that installed them.

The “Sleeper” Malware and Its Creator

According to Socket, the software supply chain security firm that flagged the threat, the packages were uploaded during 2023 and 2024. They all came from a single user account named “shanhai666.” This attacker, whose username might hint at a Chinese origin, published 12 packages in total. While three were harmless, the other nine were carefully crafted traps.

These nine packages were downloaded a combined 9,488 times by unsuspecting developers before they were finally removed from the NuGet platform. The malicious code inside them is programmed to “wake up” on specific dates, namely in August 2027 and November 2028, to begin their destructive tasks.

A Two-Pronged Attack on Industry

Security researcher Kush Pandya highlighted one package as being the most immediately dangerous: Sharp7Extend. This tool was designed to appeal to developers working with industrial Programmable Logic Controllers (PLCs), the small computers that run factory floors and manufacturing plants. It specifically targets users of a legitimate library for Siemens S7 PLCs, a common brand in industrial settings.

Pandya explained that this package has two separate ways to cause chaos. First, it immediately starts causing trouble. Right after installation, the malware has a 20% chance of suddenly terminating the entire application. This would look like a random, unexplainable crash. This termination feature is set to run until June 6, 2028.

The second, more sinister function kicks in after a random delay of 30 to 90 minutes. After this “grace period,” the malware silently starts to sabotage write operations to the PLC. This means that 80% of the time, when an operator tries to send a command to the machinery (like “stop,” “start,” or “change pressure”), the command simply fails without any error message. This could lead to catastrophic failures, broken equipment, or serious safety risks in a manufacturing environment, all while the system appears to be working normally.

How the Attack Hides in Plain Sight

This attack was so effective because the malicious packages were not just useless malware; they actually worked as promised. Socket’s report noted that all nine packages provided the functionality they advertised. This tactic builds trust, convincing developers that the tools are safe and useful. They would then add them to their projects, completely unaware of the ticking time bomb hidden inside.

The attacker cleverly used a feature of the C# programming language called “extension methods.” This feature, normally used to add new functions to existing code, was used as a weapon. The attacker used it to secretly inject their own malicious code. Every time the developer’s application tried to perform a normal database query or a PLC operation, the attacker’s hidden code would run first. This hidden code would check the current date, comparing it to the hardcoded trigger dates.

The Impossible Investigation

While Sharp7Extend began its sabotage immediately, the other packages were programmed for the long game. Packages targeting SQL Server, PostgreSQL, and SQLite databases—like MCDbRepository, SqlUnicornCoreTest, and SqlUnicornCore—are set to activate on August 8, 2027, and November 29, 2028. The full list of malicious packages includes MyDbRepository, MCDbRepository, Sharp7Extend, SqlDbRepository, SqlRepository, SqlUnicornCoreTest, SqlUnicornCore, SqlUnicorn.Core, and SqlLiteRepository.

Socket noted that this combination of techniques makes this attack particularly brilliant and devastating. The 20% chance of a crash makes the problem look like a random bug or a hardware glitch, not a systematic attack.

The true genius of the attack is its delayed activation. By the time the database-corrupting malware triggers in 2027 or 2028, the developer who originally installed the package in 2024 will likely have moved to a different project or even a different company. When the systems finally start failing, it will be almost impossible for the new security team to conduct an investigation. They won’t be able to trace the failure back to its root cause, identify who installed the compromised package, or establish a clear timeline of the attack. The attacker, “shanhai666,” will have effectively erased their own paper trail, leaving behind only chaos and corrupted systems.