According to researchers from Symantec and Carbon Black (part of Broadcom), the Lua-based malicious framework fast16 was designed to deliberately distort the results of uranium compression simulations — a process that is critically important for nuclear weapons design. If the researchers’ conclusions are correct, this would be one of the earliest known cases of cyber sabotage against industrial processes, predating Stuxnet and reshaping the timeline of nation-state cyberattacks on critical infrastructure.

Technical mechanism of sabotage

According to the Threat Hunter Team report, fast16 selectively intercepts computations inside two engineering applications — LS-DYNA and AUTODYN. Both software packages are widely used to model real-world physical processes, from automotive crash tests to simulations of explosive detonations.

The key feature of the malware is its highly selective activation. Researchers report that fast16 checks the density of the material being modeled and triggers only when it exceeds 30 g/cm³ — a value uranium reaches exclusively under shock compression in an implosion device. As a result, the malware ignores routine engineering calculations and activates only during full-scale detonation simulations.

The fast16 architecture includes 101 interception rules (hook rules), organized into 9–10 groups. Each group targets a specific LS-DYNA or AUTODYN build, which, in the researchers’ assessment, indicates methodical maintenance: the developers tracked updates to the targeted software and adapted the malware to new versions.

The researchers identify three attack strategies implemented via these hooks:

• Distortion is activated only during full-scale transient calculations of explosions and detonations
• The malware automatically spreads to other nodes on the same network, ensuring identical distorted results on any machine running simulations
• Fast16 avoids infecting computers that have certain security tools installed

One notable detail discovered when analyzing the sequence of rule groups: according to the researchers, some groups for older software versions were added after the groups for newer versions. This may indicate that, after encountering anomalies, the simulation software user rolled back to a previous version — which then also became a target.

Context and attribution

Earlier, SentinelOne described fast16 as the first known sabotage framework whose components may have been developed as early as 2005 — two years before the earliest known version of Stuxnet (Stuxnet 0.5). It should be noted that this dating is not confirmed by independent primary sources and is based on the researchers’ analytical conclusions.

Among the circumstantial evidence is a reference to the string “fast16” in a text file published by the hacker group The Shadow Brokers in 2017. This file was part of a collection of tools allegedly used by the Equation Group. However, primary sources for this claim are absent from the available materials, and this connection should therefore be treated with caution.

As reported by journalist Kim Zetter, Symantec CTO Vikram Thakur characterized the level of expertise required to create such malware in 2005 as “astonishing.” The researchers emphasize that developing fast16 required deep knowledge of equations of state, calling conventions generated by specific compilers, and the logic used to classify simulations — knowledge that is rare in any era and was exceptional in 2005.

Impact assessment

Symantec and Carbon Black place fast16 in the same conceptual line as Stuxnet: both pieces of malware were tailored not just to a specific vendor’s product but to a specific physical process modeled or controlled by that product. The difference is that Stuxnet affected physical equipment (uranium enrichment centrifuges in Natanz via Siemens controllers), whereas fast16 distorted computational results, potentially rendering entire research cycles invalid.

The consequences of such sabotage are particularly insidious: unlike destructive attacks, simulation distortion can remain undetected for a long time, undermining trust in research results and leading to erroneous design decisions.

At the same time, based on the available data, it is unknown whether a modern version of fast16 exists.

Recommendations

Although fast16 belongs to a historical arsenal, the principles identified in its operation remain relevant for protecting modern research and engineering environments:

• Computation integrity control: organizations using LS-DYNA, AUTODYN, and similar simulation software should implement mechanisms to verify results — cross-checking on isolated systems with different builds
• Network segmentation: machines used for critical simulations should be isolated from the general network infrastructure, given fast16’s ability to automatically spread across the network
• Monitoring for modifications: integrity control for simulation software executables and monitoring for unauthorized interceptors (hooks) in simulation processes
• Version auditing: documentation and control of all engineering software versions in use, since fast16 demonstrates a pattern of adapting to rollbacks to previous versions

The analysis of fast16 demonstrates that strategic sabotage of computational processes is not a theoretical threat but a documented practice with a 20-year history. Organizations working with critical simulations in the defense, nuclear, and aerospace sectors should revisit their threat models to account for attacks on the integrity of modeling results, not just on data availability or confidentiality.