Table of Contents
TLDR
Symantec’s Threat Hunter Team has confirmed Fast16 malware was built to sabotage nuclear weapon simulations. The framework dates back to roughly 2005, around two years before Stuxnet was active.
It tampered with LS-DYNA and AUTODYN simulations using rule-level precision. The malware only acted when material density passed 30 g/cm³, a value uranium reaches only under implosion compression.
Up to ten distinct hook groups suggest the operators tracked software updates across years. Fast16 spread inside target networks but was deliberately built not to leave them.
The pre-Stuxnet sabotage tool we never saw coming
Fast16 malware sat hidden in plain sight for years. Symantec’s recent analysis builds on SentinelOne’s April 2026 disclosure, and the picture isn’t pretty.
The oldest Fast16 malware components date back to around 2005. That’s roughly two years before Stuxnet famously crippled Iran’s centrifuges. So this thing has been kicking about a long time.
Here’s the thing. Fast16 wasn’t built to steal data or ransom files. This pre-Stuxnet sabotage tool was built to nudge nuclear weapon simulations off course just enough to derail a programme.
What Fast16 malware actually does
Fast16 plants a boot-start filesystem driver onto Windows machines. Once installed, it watches for executable files compiled with the Intel compiler. The driver matches the string ‘Intel’ inside the PE header.
When such a file gets read into memory, the driver patches specific opcode sequences on the fly. The malware doesn’t touch the binary on disk. That’s what makes it so brilliant at staying hidden.
The hook engine carries 101 byte-pattern rules. Each one fires on a precise instruction sequence. Some rules just capture an address; others redirect execution into injected malicious code stashed in an .xdata section.
These aren’t generic patterns. The rules match versions of LS-DYNA and AUTODYN, two simulation packages used for crash testing, material modelling, and explosive detonation work.
How Fast16 targets nuclear weapon simulations
This is where it gets really interesting. Fast16 only tampers with a simulation when very specific physics conditions appear.
The malware checks whether the material density passes 30 g/cm³. That figure isn’t arbitrary. Uranium can only reach such density under the shock compression of an implosion device. Nothing in everyday engineering goes anywhere near that number.
The Equation of State selections it watches for are equally telling. Jones-Wilkins-Lee, Sack Tuesday, and Ignition and Growth of Reaction in High Explosives. These are models for high explosives, the sort wrapped around a uranium core to compress it past supercriticality.
In short, Fast16 was built to sabotage nuclear weapon simulations and very little else.
Three tampering mechanisms inside Fast16
Symantec’s reverse engineers found three distinct attack strategies inside the malware. Each one nudges results subtly enough to fly past a casual reviewer.
Mechanism A: drip-feed corruption
The first hit and the sixteenth hit get skipped entirely. When inputs sit between 30 and 65, outputs get scaled to 10% of their real values.
That reduction sticks for the rest of the run. An engineer staring at the data might just see odd readings, not an obvious failure.
Mechanism B: slow-burn pressure tampering
This one works inside LS-DYNA. It only fires once a simulation attribute hits five times its starting value.
After that, the Cauchy stress tensor outputs get reduced toward 1% of their true values as material density approaches 60 g/cm³. The reduction follows a calculated slope.
Nothing looks like a sudden cliff, just a gentle drift downwards. That’s what makes Mechanism B so nasty.
Mechanism C: AUTODYN-flavoured corruption
Mechanism C targets AUTODYN with EOS values 3, 5, and 11. These map to Ideal Gas, JWL, and Lee-Tarver models respectively.
The string ‘$Loading co’ must sit in memory before tampering kicks in. Output values such as pressure get scaled down at variable rates, with different start and end density slopes.
Different versions of the simulation software triggered different tampering ratios. The attackers were tracking software updates and tweaking their hooks accordingly.
How Fast16 spreads inside the network
The svcmgmt.exe binary runs as a Windows service. It also handles remote installation through command-line flags.
Before doing anything noisy, the malware scans for 18 endpoint security registry keys. If any of them show up, Fast16 simply refuses to propagate further.
For persistence, the framework abuses Image File Execution Options. It writes its own path into the Debugger registry value, so Windows launches Fast16 instead of the intended program. The malware then runs the real app and re-adds the key, so the hijack is silently restored each time.
To spread, it registers a DLL as a Multiple Provider Router notifyee. Whenever any process calls WNetAddConnection, the DLL gets loaded and reports new share connections back via a named pipe.
Fast16 then enumerates domains and shares to find more hosts within 10.x.x.x, 172.16.x.x, and 192.168.x.x ranges. It impersonates the logged-on user’s credentials and copies itself across.
Notice what’s missing? Fast16 won’t leave the target network. It’s deliberately contained, which fits the air-gapped reality of nuclear research environments perfectly.
Expert commentary
William Fieldhouse, Director of Aardwolf Security Ltd, offered his view on the findings:
“Fast16 malware is a textbook lesson in how attackers can wait years inside an environment if defenders aren’t checking the right things. Loaded drivers, unsigned binaries, and odd MPR providers all leave fingerprints, but only if someone’s actually looking. If your security model still ignores boot-start drivers and Image File Execution Options abuse, you’re already behind.”
Why this matters for defenders today
We don’t know whether a modern Fast16 variant is doing the rounds somewhere right now. But the playbook is sound and the techniques still work.
Boot-start drivers, IFEO persistence, and on-the-fly code patching haven’t gone out of fashion. Inventory your drivers. Properly. Anything unsigned or unfamiliar deserves a hard look.
Application control tools should block unapproved executables and DLLs by default, not just log them. Adaptive Protection features inside modern EDR platforms can lock down dual-use tooling that attackers love to misuse.
The bigger lesson? Air-gapped doesn’t mean safe. Fast16 was clearly designed to ride in via USB sticks, contractor laptops, or insider movement.
If you handle sensitive R&D or industrial control kit, threat-modelling against this sort of bespoke sabotage is no longer optional.
If you’d like to test how your estate would hold up against stealthy malware, request a penetration test quote from Aardwolf Security.
Final thoughts on Fast16 malware
Fast16 malware represents a chilling level of domain expertise. The attackers understood Equation of State selections, compiler quirks, calling conventions, and uranium physics.
They built a tool that wouldn’t trip alarms unless it spotted a very specific simulation in progress. That’s a long, long way from spray-and-pray ransomware.
It’s also a reminder that nation-state operators have been doing precision sabotage longer than most of us realised. Stuxnet wasn’t the start. It was just the first time we noticed.
