30 g/cm³ — that is the density threshold the fast16 malware checked for before it began corrupting simulation results, a sign the code was tuned to act only when a simulation reached densities attainable under the shock compression of an implosion device.
Symantec and Carbon Black: malware aimed at explosive simulations in LS-DYNA and AUTODYN
Broadcom-owned Symantec and Carbon Black's Threat Hunter Team concluded that the Lua-based fast16 malware was engineered specifically to tamper with simulations of high-explosive detonations inside two engineering products: LS-DYNA and AUTODYN. "Fast16's hook engine is selectively interested in high-explosive simulations inside LS-DYNA and AUTODYN," the Threat Hunter Team said. According to the researchers, the tampering only activates during full-scale transient blast and detonation runs, and it checks for the density of the material being simulated — acting only when that value passes 30 g/cm³.
Technical profile: 101 rules, 9–10 hook groups, and targeted activation
At its core, fast16 implements a set of 101 hook rules that corrupt mathematical calculations performed by the targeted simulation software. Symantec and Carbon Black mapped those rules into roughly 9–10 hook groups, each aimed at different builds of LS-DYNA or AUTODYN. The grouping suggests the malware's authors tracked software updates and added support for additional versions over time. "If hook rule groups were added sequentially as needed, we see a hook group added for a previous version of the software after a newer version," the researchers observed, noting a pattern consistent with an operator who adapted when users reverted to earlier versions to investigate anomalies.
Propagation, evasion, and the simulations it sought to subvert
Fast16 was crafted to spread automatically to other endpoints on the same network so that any machine used to run the targeted simulations would produce the same tampered outputs. The malware also included logic to avoid infecting systems that had certain security products installed. Symantec and Carbon Black detailed three attack strategies implemented by hooks inside the simulation programs; the tampering only triggers during specific classes of simulation runs, emphasizing that the framework was not a broad-purpose sabotage tool but one tailored to a physical process simulated by particular vendor products.
Origins, discovery, and links to earlier tooling
SentinelOne's earlier analysis described fast16 as a sabotage framework whose components may have developed as early as 2005, predating the earliest known version of Stuxnet (aka Stuxnet 0.5) by two years. Evidence included a reference to the string "fast16" in a text file leaked by the anonymous hacking group The Shadow Brokers in 2017; that file was part of a tranche of tools allegedly used by the Equation Group, a state-sponsored threat actor with suspected ties to the U.S. National Security Agency (NSA). Symantec and Carbon Black's new analysis confirms the software targets and the deliberate design to interfere with uranium-compression simulations central to nuclear weapon design.
Domain expertise required and analysts' reaction
Symantec and Carbon Black highlighted the unusual level of domain knowledge required to build fast16. The researchers wrote that understanding "which EOS [Equation of State] forms matter, which calling conventions are produced by which compilers, and which classes of simulation will or will not trip the gate" would have been rare in 2005. Speaking to cybersecurity journalist Kim Zetter, Vikram Thakur, technical director for Symantec, said the level of expertise and understanding required to design such malware in 2005 is "mind-blowing." The teams concluded that "the framework belongs to the same conceptual lineage as Stuxnet, in which malware was tailored not just to a vendor's product but to a specific physical process being simulated or controlled by that product."
What this means for nuclear researchers, security teams, and policymakers
- Nuclear researchers and simulation operators: verification of simulation integrity becomes critical — the finding that fast16 actively targeted high-explosive implosion runs and checked for precise density thresholds means that tampering can be highly selective and stealthy.
- Enterprise security and incident responders: the malware's network-spread behavior and its checks to avoid machines with certain security products underscore the need for endpoint diversity, rigorous monitoring of simulation workflows, and cross-checks between independent systems.
- Policymakers and defense planners: the existence of a pre-Stuxnet sabotage tool dated to roughly 2005 raises questions about the historical scope and intent of nation-state cyber-sabotage operations against simulation tooling that supports weapons research.
Fast16's confirmation by Symantec and Carbon Black reframes a piece of cyber history: a Lua-based sabotage framework, tuned to a 30 g/cm³ trigger and structured across more than a hundred hook rules, points to methodical, process-aware tampering years before Stuxnet made sabotage visible. The analytic trail — from a leaked Equation Group file to SentinelOne's initial report and now Symantec's detailed mapping to LS-DYNA and AUTODYN — leaves a clear technical record, but also a pointed, unresolved question: if such domain-specific sabotage was possible two decades ago, how many other tools of similar subtlety remain unidentified?
