The Sophons Are Real
How a 21-Year-Old Worm Quietly Rewrote the History of Cyber Warfare — and Mirrored the Plot of 3 Body Problem
If you've read Liu Cixin's Remembrance of Earth's Past trilogy, or watched Netflix's 3 Body Problem, you remember the gut-punch moment: Earth's particle accelerators stop producing reliable data. Every collision experiment yields nonsense. Physicists across the planet quietly start losing their minds — one of them, Vera Ye, walks into her own neutrino detector tank to die. The villain isn't a bomb or a virus. It's an alien intelligence that has decided the simplest way to cripple humanity is to break our trust in our own math.
Last week, SentinelOne announced they had found something that does almost exactly that. It was built by humans. It has been hiding in plain sight on VirusTotal for nearly a decade. And it appears to have been operational in 2005 — five years before Stuxnet, the worm everyone called the dawn of the cyberweapon era.
It's called fast16. And it is the closest thing to a real-world Sophon we have ever seen.
The Find
SentinelOne researchers Vitaly Kamluk and Juan Andrés Guerrero-Saade went looking for something specific. They wanted to know whether the famous nation-state malware families that used embedded Lua virtual machines — Flame, Animal Farm, Project Sauron — had ancestors nobody had ever bothered to identify. They were essentially digging for the missing link.
They found it inside an unassuming Windows binary called svcmgmt.exe, uploaded to VirusTotal on October 8, 2016, by someone unknown. On the surface, it looked like a generic console-mode service wrapper. Boring. Forgettable. The kind of file an antivirus engine glances at, shrugs, and moves on.
The compilation timestamp on the binary read August 30, 2005. Stuxnet's command-and-control infrastructure was set up in November of that same year. Whoever built fast16 was operating on the same timeline as the team that would eventually take out Iran's centrifuges — except they were doing something much stranger and, in some ways, much more disturbing.
What It Actually Does
Stuxnet was loud, in a sense. Its job was to spin centrifuges past their mechanical limits while feeding fake telemetry to the people watching the dials. Eventually, equipment broke. People noticed.
Fast16 is the opposite. It does not destroy anything. Nothing crashes. Nothing burns. Software runs normally, error logs stay clean, and the engineers using the system have no reason to suspect a thing.
It just makes the answers wrong.
The framework has three layers:
- A carrier (svcmgmt.exe) that contains an embedded Lua 5.0 virtual machine and several encrypted payloads. This is the brain. It handles configuration, propagation, and coordination.
- A set of wormlets — small Lua-based modules that allow the framework to spread laterally across a network using weak file shares and default credentials common on Windows 2000 and XP systems.
- And the dangerous part: a kernel driver called fast16.sys. This driver intercepts I/O operations and patches executables in memory using 101 pattern-matching rules to corrupt floating-point calculations.
That last sentence deserves a slow re-read. The driver doesn't tamper with the engineering software on disk. It doesn't modify configuration files. It sits at the kernel level and watches for specific binaries being loaded into memory — and as those binaries are streamed off the disk into RAM, it surgically rewrites their floating-point arithmetic routines. Your software is signed. Your inputs are correct. Your hash is valid. The math is sabotaged in the microsecond between the disk and the CPU.
Among the 101 patches, most are mundane substitutions of standard x86 instructions. But one is special — a block of injected FPU code that scales values inside three internal arrays as they pass through a calculation. Wrong by a little. Wrong by a lot. Wrong in a way that depends on the numbers themselves. Researchers haven't yet identified exactly which arrays they are or what they represent in the original software, but the intent is unambiguous: produce plausible wrong answers.
The Targets
SentinelOne couldn't get the malware to execute its full payload because fast16 only runs on Windows XP, single-core, and they have not been able to perfectly replicate the original target environment. (It refuses to run on anything newer than XP, and Intel didn't ship multi-core consumer chips until 2006 — another fingerprint of how old this thing actually is.)
By pattern-matching the 101 patches against era-appropriate software, they identified the most likely targets:
- LS-DYNA 970 — one of the most widely-used multi-physics simulation suites on the planet. It models crashes, impacts, explosions, structural failure — including defense applications. A 2024 report from the Institute for Science and International Security examined 157 academic publications and concluded Iran likely used LS-DYNA in its nuclear weapons development work.
- PKPM — a Chinese structural engineering and seismic analysis platform used to design buildings, bridges, and other infrastructure.
- MOHID — a hydrodynamic modeling tool used for coastal, environmental, and industrial process simulation.
Stop and think about what an attacker who silently corrupts those calculations could accomplish. A nuclear weapons program that spends years iterating on flawed implosion physics. A bridge whose stress simulations underestimate critical loads by half a percent. A flood model that puts the safe zone in the wrong place. The damage doesn't have to be dramatic — it just has to be systematic and trusted.
The Cruelty of the Network Worm
Now here is where the design crosses from sophisticated into something close to artistic, in the way that the best dark fiction is artistic. Because anyone who has worked in engineering or research knows the standard gut-check for a result that seems off: run it on another machine.
Fast16's authors anticipated that.
The wormable carrier ensures that once the malware lands on one workstation in a facility, it spreads to every other workstation that shares the same network and security posture. Every machine ends up with the same kernel driver. Every machine produces the same wrong answer.
A senior engineer running a sanity check on a peer's workstation gets agreement. The supervisor running it on his own laptop in the next office gets agreement. The cluster running an overnight verification job gets agreement. Everyone agrees. The math is consensus reality. The math is also wrong.
The only way to catch it is to run the calculation on a system physically and logically isolated from the affected network. And almost nobody does that, because almost nobody has a reason to suspect their FPU is lying to them.
Where 3 Body Problem Comes In
The Trisolarans, in Liu Cixin's novels, can't beat humanity in a fair fight across the timescale of their fleet's voyage. Humans evolve too fast. Our scientific understanding of physics will eventually outpace theirs. So they cheat.
They unfold a single proton into a planet-sized two-dimensional sheet, etch a quantum supercomputer onto it, fold it back into a proton, and shoot it across the galaxy at near-light-speed. They call it a Sophon. When it arrives in our solar system, it interferes with every particle accelerator on Earth, forcing collision experiments to produce false and chaotic results.
The genius of the Sophon is that it doesn't destroy science. It corrupts it. The accelerators still run. The detectors still detect. Papers still get written. But the foundation underneath the whole edifice has been quietly poisoned, and after a few years of inexplicable, contradictory data, the brightest minds on Earth begin to suspect the universe itself is broken. Some of them stop working. Some of them kill themselves. Some convert to the alien cause. Real scientific progress halts.
Fast16 is the same idea executed against a smaller surface. Replace the particle accelerator with the engineering workstation. Replace the alien proton with a kernel driver. Replace the unfolded quantum computer with 101 pattern-matching patches against floating-point routines. Replace the Trisolarans with — well, that's a question worth pausing on.
The intent is identical: let the target keep working, but make their work quietly invalid.
This is what makes fast16 categorically different from every other piece of state-grade malware we've publicly seen. It isn't espionage. It isn't theft. It isn't destruction. It is an attack on the trust relationship between a researcher and their tools. And once you've lost that trust at scale, you don't get it back without a multi-year audit and probably a rebuild.
Who Built It
SentinelOne is, professionally and appropriately, refusing to make a hard attribution. But the breadcrumbs are telling.
The string "fast16" appeared in a deconfliction document inside the 2016 ShadowBrokers leak of NSA offensive cyber tools. Deconfliction lists are how intelligence agencies tell their own people don't trip over this op, it's ours. The reference doesn't prove NSA built fast16, but it strongly suggests US intelligence either built it, knew about it, or had access to it.
Several researchers analyzing the timeline have arrived at similar conclusions independently. The same era. The same target ecosystem. The same probable adversary (Iran's nuclear program). It would be a remarkable coincidence if fast16 wasn't a precursor to, or sister project of, what eventually became Stuxnet.
What's Sitting Next To It
Here is the part that should keep you up tonight, regardless of whether you ever touch engineering software.
Fast16 was uploaded to VirusTotal in 2016. It sat there, available to every threat researcher and antivirus vendor on Earth, for nearly ten years. Almost no engine flagged it. Almost no analyst opened it up. It took two specific researchers asking a specific question — what came before Flame? — to drag it into the light.
VirusTotal currently holds billions of files. The vast majority have been processed by automated systems that excel at finding malware that looks like other known malware. Fast16 didn't look like anything. It looked, on first glance, like boring system code.
If something this elegant, this strategically dangerous, and this clearly state-built spent twenty-one years undetected, the obvious next question is: what else is sitting in the same archive right now, waiting for a researcher to ask the right question?
Because the threat model implied by fast16 is one most defensive security postures simply do not address. Endpoint detection looks for behavior. Antivirus looks for signatures. Code-signing looks for tampering on disk. None of those help when the math is being rewritten at the kernel level on a trusted, signed binary at execution time, by something that has been quietly running in your environment since Bush's second term.
What Anyone Reading This Should Actually Do
If you run high-precision simulation software for anything that matters — defense, civil infrastructure, pharmaceutical modeling, aerospace, nuclear, anything where a 0.5% error compounds — there is one defensive practice that fast16's design tells you is non-negotiable:
Verify critical calculations on a system that does not share a network or build chain with your production environment.
Different OS if possible. Different vendor's compiler if possible. Different physical building if you're paranoid, and after reading this, paranoia seems reasonable. Because the entire premise of fast16 is that on-network verification is worthless when the network itself is compromised.
For everyone else, this story is a useful update to your mental model of what cyber operations actually are. Most of us still think of "hacking" as theft, espionage, or visible destruction. Fast16 represents a third category that's been operational, in the wild, for two decades — an attack that targets the integrity of physical-world reasoning itself.
That's not a security problem. That's an epistemology problem.
A Final Thought
Liu Cixin published The Three-Body Problem in 2008. Fast16 was compiled in 2005.
The fictional Sophons sabotage particle accelerators by tampering with subatomic events. Real-world fast16 sabotages engineering simulations by tampering with floating-point math. The mechanism is wildly different. The strategic intent is the same: silently corrupt the inputs that humans use to understand the physical world, so that everything we build on top of them is quietly, structurally wrong.
Liu Cixin imagined what a sufficiently advanced enemy might do to a civilization that trusted its own science. Someone working a desk job in 2005, in a building most of us will never know about, was already doing it.
The Sophons are real. They've been real for twenty-one years. We just hadn't found them yet.
— CAPRI Labs Research Division, May 2, 2026