Researchers Found a Cyber Weapon Hidden for 20 Years—It Sabotaged Engineering Software Five Years Before Stuxnet

The Weapon That Came Before Stuxnet

Stuxnet, discovered in 2010, is widely considered the first cyber weapon designed to cause physical damage. It famously destroyed centrifuges in Iran's Natanz uranium enrichment facility by manipulating their spin rates. For 15 years, Stuxnet defined the starting point of state sponsored cyber sabotage.

That timeline is now wrong. On April 25, 2026, SentinelOne's research lab published an analysis of a previously undocumented malware framework codenamed fast16. The core binary was compiled on August 30, 2005, five years before Stuxnet was discovered. It did not destroy hardware. It did something more subtle: it corrupted the results of precision engineering calculations, producing wrong answers that looked correct.

How SentinelOne Found It

Researchers were analyzing how advanced threat actors use embedded scripting engines in malware when they identified a suspicious binary called svcmgmt.exe. Inside it was a Lua 5.0 virtual machine with encrypted bytecode and a PDB debug path that referenced fast16.pdb. The name matched an entry in the ShadowBrokers leak: a 2017 dump of NSA offensive tools that included a file called drv_list.txt containing deconfliction signatures used by operators to mark implants as friendly.

Next to the fast16 entry, the guidance read: "Nothing to see here — carry on." The instruction told NSA operators encountering the driver on a target machine to leave it alone. It was already theirs.

What fast16 Did

The framework consisted of three components: a carrier binary (svcmgmt.exe), a kernel driver (fast16.sys compiled July 2005), and a reporting module (svcmgmt.dll compiled June 2005). The kernel driver was the weapon.

Fast16.sys installed itself as a boot start filesystem driver, inserting above every active filesystem on the machine: NTFS, FAT, and network shares. It monitored every file access and matched them against two criteria: the filename had to end in .EXE, and the binary had to contain an ASCII string beginning with "Intel" after the final PE section header. This combination identified software compiled with the Intel C/C++ compiler, which was the standard toolchain for high precision scientific and engineering applications.

When the driver found a matching executable, it applied 101 pattern matching rules to patch the code in memory. The patches injected floating point instructions that corrupted precision arithmetic and scaling values in internal calculation arrays. The result: the software would run normally, produce output that looked plausible, but the numbers would be wrong. In an engineering simulation testing how materials behave under extreme stress, or modeling the physics of a nuclear weapon, wrong calculations produce wrong designs.

The Target Software

SentinelOne matched the patching rules against software available in the mid 2000s and identified three targets:

• LS-DYNA 970: An engineering simulation suite used to analyze material behavior under extreme conditions, including crash testing, explosions, and metal forming. It is used across automotive, aerospace, and defense industries. Public reporting has cited LS-DYNA in connection with suspected Iranian computer modeling for nuclear weapons development.
• PKPM: A Chinese structural engineering CAD suite used for building design. Its core engine handles structural analysis for high rise buildings, including beams, columns, walls, and frames.
• MOHID: A hydrodynamic modeling system developed by the Instituto Superior Tecnico in Lisbon, used for marine and coastal modeling including water quality simulation and oil spill prediction.

The combination of self propagation and calculation corruption meant the framework could spread across an entire facility and ensure that every workstation running the targeted software produced the same inaccurate results. Researchers at the facility would see consistent output across machines, making the corruption nearly impossible to detect.

A Self Propagating Worm

Fast16 was not a single implant dropped on one machine. It included a worm component that SentinelOne calls a "wormlet." The propagation mechanism copied the payload to network shares using default and weak administrative passwords, installed itself as a Windows service called SvcMgmt, and optionally deployed the kernel driver. It then repeated the process across every reachable server, with configurable delays between attempts.

Before installation, the malware checked the Windows registry for security products including Symantec, Kaspersky, McAfee, TrendMicro, F-Secure, and Zone Labs. If any were detected, installation was aborted to avoid discovery. The carrier binary was uploaded to VirusTotal nearly a decade before SentinelOne's disclosure and received only one detection with limited confidence.

Who Built It

SentinelOne stops short of formal attribution but presents compelling circumstantial evidence. The fast16 name appears in the ShadowBrokers' leak of NSA tools. The binaries contain archaic source control markers from SCCS and RCS, version control systems from the 1970s and 1980s used primarily in Unix environments associated with government and military development. Finding these artifacts in mid 2000s Windows code suggests the authors were long term engineers from high security environments, consistent with a sustained, well resourced development program.

The targeting profile also aligns. LS-DYNA's connection to Iranian nuclear research, combined with the framework's design for sabotaging precision calculations rather than stealing data, mirrors the logic behind Stuxnet: degrade a program's output without the operators realizing anything is wrong.

Why This Changes the Timeline

Before fast16, the history of state sponsored cyber sabotage began with Stuxnet in 2010. The discovery pushes that timeline back to at least 2005, and the development artifacts suggest the program was already mature by then. SentinelOne's analysis notes that the Lua implementation in fast16 predates the Flame malware samples by three years, making it the earliest known sophisticated embedded scripting engine in Windows malware.

The framework also demonstrates a different philosophy of sabotage. Stuxnet caused visible physical destruction: centrifuges tearing themselves apart. Fast16 was designed to be invisible. Wrong calculations would produce flawed designs, failed experiments, or unsafe structures, and the source of the error would be nearly impossible to trace. In some ways, that makes it more dangerous.

As SentinelOne writes, the discovery "forces a re-evaluation" of when clandestine cyber sabotage operations began and how long they may have operated undetected. If fast16 sat undiscovered for 20 years, the question is how many similar tools remain hidden.

What This Means for Privacy and Security

Fast16 is a reminder that the most sophisticated surveillance and sabotage tools are designed to be invisible. The same principle applies at every level of the technology stack, from kernel drivers that intercept filesystem calls to tracking pixels that fire silently when you open an email. The common thread is that the most effective monitoring operates where you cannot see it, does not announce itself, and produces no visible change in behavior.

Fast16 corrupted engineering calculations. Email tracking pixels corrupt your expectation of privacy. Both rely on the same design principle: intercept a routine operation, extract or modify data, and leave no trace that anything happened. The scale is different. The architecture is the same.