Pre-Stuxnet Sabotage Malware ‘Fast16’ Linked to US-Iran Cyber Tensions

What happened

SentinelOne has uncovered Fast16, a Lua-based sabotage malware developed and deployed years before Stuxnet that was designed to tamper with high-precision calculation software used in civil engineering, physics, and physical process simulations. The malware was used in an attack in 2005 and was referenced in the ShadowBrokers’ 2016 leak of NSA offensive tools. SentinelOne’s analysis indicates Fast16 may have been developed by the United States.

The core component is svcmgmt.exe, a service binary containing an embedded Lua 5.0 virtual machine and three payloads: Lua code handling configuration, propagation, and coordination; an auxiliary DLL; and a kernel driver named fast16.sys. The kernel driver loads alongside disk device drivers, inserts itself above filesystems, and attaches to every filesystem device to intercept I/O requests. It focuses specifically on executables compiled with the Intel C/C++ compiler, modifying their PE headers to inject additional sections that enable targeted code patching.

The sabotage mechanism introduces small but systematic errors into precision calculations rather than destroying data or causing obvious failures, designed to degrade scientific research programs over time or contribute to physical damage without immediate detection. A wormable component allowed Fast16 to spread across networked systems using default or weak file share passwords on Windows 2000 and XP, and a separate verification mechanism would confirm tampered calculations on a different machine to prevent the sabotage from being discovered. SentinelOne identified three engineering and simulation suites potentially targeted: LS-DYNA 970, PKPM, and the MOHID hydrodynamic modeling platform. LS-DYNA has documented use in Iran’s nuclear weapons development program, the same program later targeted by Stuxnet.

The malware’s compartmentalized design separated a stable execution wrapper from encrypted task-specific payloads, creating a reusable framework adaptable to different target environments while leaving the outer binary largely unchanged across campaigns.

Who is affected

Fast16’s confirmed targets were engineering and scientific simulation environments, specifically those running high-precision calculation software relevant to physical process modeling. The historical targets appear to have been Iranian nuclear and scientific programs. The broader relevance today is for organizations running legacy simulation and engineering software in critical infrastructure, defense, and research environments.

Why CISOs should care

Fast16 demonstrates that state-grade cyber-sabotage capabilities designed to produce strategic physical-world effects were fully operational by the mid-2000s, predating Stuxnet by years. The sabotage model it established, introducing small systematic calculation errors rather than obvious failures, is particularly difficult to detect because the software continues to run normally. Results simply become wrong over time.

For security leaders responsible for operational technology, scientific computing, or engineering simulation environments, the Fast16 discovery is a reminder that the most dangerous attacks on these systems may not look like attacks at all. Output integrity verification is not a standard control in most OT and scientific computing environments, and that gap has existed for at least two decades.

3 practical actions

1. Implement integrity verification for outputs from high-precision simulation and engineering software: Fast16’s sabotage was designed to produce plausible but incorrect results. Cross-validation of critical calculation outputs against independent systems or known baselines is the primary detection mechanism for this class of attack.
2. Audit legacy engineering and simulation software deployments for unauthorized modifications: Fast16 modified PE headers of targeted executables to inject patching code. Review integrity of executables in engineering and scientific computing environments, particularly those running Intel C/C++ compiled binaries, and establish baseline hashes for critical software.
3. Treat scientific and engineering computing environments as OT security priorities: Precision calculation software used in physical process simulation carries the same risk profile as industrial control systems when targeted by state-sponsored actors. Apply OT security principles including network segmentation, access control, and anomaly detection to these environments regardless of whether they sit on traditional IT infrastructure.

Also in the news today:

• • Trigona Ransomware Attacks Use Custom Exfiltration Tool to Steal Data
  • Over 10,000 Zimbra Servers Vulnerable to Ongoing XSS Attacks
  • Firestarter Malware Survives Cisco Firewall Updates and Security Patches
  • ADT Confirms Data Breach After ShinyHunters Leak Threat
  • Threat Actor Uses Microsoft Teams to Deploy New Snow Malware Suite
  • Pentagon Grapples With Securing AI as It Moves Toward Autonomous Warfare
  • NASA Employees Duped in Chinese Phishing Scheme Targeting Defense Software