Fast16: Cyber Sabotage Before Stuxnet

Last Updated on April 27, 2026 by Arnav Sharma

Most people in cybersecurity treat Stuxnet as the starting gun for state-sponsored cyber sabotage. The moment nation-states went from stealing secrets to breaking physical things. That origin story just got rewritten.

Researchers at SentinelOne have uncovered a framework called Fast16, a Lua-based sabotage tool compiled in mid-2005. That puts it a full five years ahead of Stuxnet’s public discovery and several months before even the earliest known Stuxnet 0.5 development began. If the findings hold up, Fast16 represents the oldest known example of precision cyber sabotage targeting real-world engineering systems.

---

How It Was Found

SentinelOne researchers Vitaly Kamluk and Juan Andrés Guerrero-Saade presented their findings at Black Hat Asia this week. The investigation started with a straightforward question: did older nation-state tools that embedded Lua virtual machines (think Flame, Animal Farm, Project Sauron) have predecessors that nobody noticed?

That question led Kamluk to a binary called svcmgmt.exe, uploaded to VirusTotal back in 2016. The compilation timestamp? August 30, 2005. Inside it sat an embedded Lua 5.0 VM, encrypted bytecode, and a PDB debug path referencing fast16.sys.

Here’s where it gets interesting. The name “fast16” also appears in the ShadowBrokers leak of NSA offensive tools. Specifically, it shows up in a file called drv_list.txt, which was essentially a deconfliction checklist. Operators would use it to figure out which drivers on a target system were “friendly” and should be left alone. The entry for fast16 read: “Nothing to see here – carry on.”

---

What Fast16 Actually Does

The framework operates across three layers, and understanding each one matters.

The Carrier (svcmgmt.exe)

This is the entry point. It is a modular service binary that changes what it does based on command-line arguments. Pass -p and it propagates. Pass -i and it installs itself, then runs the embedded Lua code. Pass -r and it just executes the Lua payload without installing. It carries three things inside: encrypted Lua bytecode, a notification DLL, and the fast16.sys kernel driver.

The Wormlet

The propagation module spreads through Windows 2000 and XP networks by targeting file shares with default or weak passwords. But it is cautious. It checks for security products from Kaspersky, Symantec, McAfee, F-Secure, Trend Micro, and others before attempting to move. If it detects any of them, it backs off. This is not brute force. It is careful, selective lateral movement.

The Kernel Driver (fast16.sys)

This is the real payload, and it is genuinely unsettling. The driver sits at the filesystem level and intercepts I/O operations. When executables compiled with the Intel C/C++ compiler are read from disk, the driver patches them on the fly using 101 pattern-matching rules. Those patches inject modified floating-point routines that subtly corrupt mathematical calculations.

Read that again. It does not steal files. It does not encrypt anything. It does not phone home with credentials. It quietly makes math wrong.

---

Why Corrupted Math Is Terrifying

Imagine you are an engineer running a structural simulation for a bridge. Your software tells you the stress tolerances are within safe margins. You sign off on the design. Construction begins. But the numbers your simulation returned were slightly off because something tampered with the calculation at the kernel level. You would never know. Your software ran correctly. Your inputs were correct. The math itself was sabotaged before the application even saw it.

Three high-precision engineering suites were identified as potential targets of Fast16:

• LS-DYNA 970 handles multi-physics simulations for crash testing, explosion modelling, and structural failure analysis. The ISIS institute has documented Iran’s use of LS-DYNA in nuclear weapons development research.
• PKPM is widely used in structural engineering for building design and analysis.
• MOHID handles hydrodynamic and water quality modelling.

The connection to LS-DYNA and its documented use in Iranian nuclear research ties Fast16 directly to the broader narrative around Stuxnet and the campaign against Iran’s weapons programme.

---

A Timeline That Rewrites History

Here is why the dates matter so much:

• July 2005: fast16.sys compiled
• August 2005: svcmgmt.exe compiled
• November 2005: Earliest evidence of Stuxnet 0.5 development begins
• November 2007: Stuxnet 0.5 deployed against Natanz
• June 2010: Stuxnet 1.0 discovered publicly
• 2012: Flame discovered (also Lua-based, but years after Fast16)
• 2016-2017: ShadowBrokers leak references fast16

There is a hardware detail that further corroborates the timeline. The malware only runs on single-core processors. Intel shipped its first multi-core consumer chips in 2006. Fast16 was built for the hardware of its era, not retrofitted to look old.

---

Stuxnet Broke Things. Fast16 Broke Trust.

Stuxnet gets all the headlines because it caused visible, kinetic damage to centrifuges at Natanz. Spinning them too fast, slowing them down, physically destroying hardware. It was dramatic and undeniable once discovered.

Fast16 took a completely different approach. Instead of destroying equipment, it corrupted the intellectual output of engineering processes. The simulations would still run. The software would still produce results. Those results would just be wrong in ways that are incredibly difficult to detect.

From a security architecture perspective, that is arguably the more dangerous model. You can rebuild a centrifuge. But if you cannot trust the output of your computational tools, you cannot trust any decision built on top of them. That uncertainty compounds across every downstream process.

---

What This Means for Modern Security

Fast16 is a relic. It runs on Windows XP and single-core CPUs. Nobody is deploying it today. But the attack pattern it introduced has serious implications that remain relevant.

• Integrity verification matters more than you think. If a kernel driver can silently modify application behaviour at the filesystem level, then the question becomes: how do you verify that your computational results are actually correct? Code signing, secure boot chains, and runtime integrity monitoring exist to address exactly this category of threat. Most organisations still treat them as nice-to-haves rather than critical controls.
• Supply chain trust extends to computation. We spend a lot of time thinking about software supply chain security in terms of dependencies, packages, and build pipelines. Fast16 reminds us that the attack surface includes the computational environment itself. If an adversary can sit between your application and the data it reads, they control the outcome.
• The Lua lineage is real. Fast16 in 2005, Flame in 2012, Animal Farm, Project Sauron. There is a clear architectural thread of embedded Lua VMs running through nation-state tooling across multiple campaigns and likely multiple threat actors. That design pattern persisted for nearly a decade.

---

The Bigger Picture

The cybersecurity industry has treated Stuxnet as Year Zero for cyber-physical sabotage for over fifteen years. Fast16 pushes that timeline back to 2005 and introduces a sabotage model that is, in some ways, more sophisticated than what Stuxnet eventually became. Breaking things is loud. Making someone’s math wrong is quiet, persistent, and deeply corrosive to trust.

State-grade cyber sabotage did not start with Stuxnet. It was already operational before most of us had even heard the term “advanced persistent threat.”