ForumsResourcesFast16 and the Early Days of OT Sabotage: A Lua-Based Blast from the Past

Fast16 and the Early Days of OT Sabotage: A Lua-Based Blast from the Past

AppSec_Jordan 4/26/2026 USER

Just caught the SentinelOne report on 'fast16', and it’s a fascinating deep dive into the history of cyber warfare. We often cite Stuxnet (2010) as the benchmark for ICS sabotage, but this Lua-based framework dates back to 2005. It shows that threat actors were actively developing precision-tampering tools years before we realized it.

The malware targeted high-precision calculation software, likely intended to introduce subtle errors in engineering data—perfect for sabotaging centrifuge operations without triggering immediate alarms. Because it relies on Lua, a scripting language often embedded in legitimate engineering tools, it provides a high degree of stealth and portability.

While we don't have specific CVEs for this 20-year-old framework, the detection methodology is relevant for modern OT environments. If you are managing legacy systems, you might want to audit for unexpected script execution in application directories.

Here is a quick PowerShell snippet to hunt for suspicious Lua files in engineering application folders that have been recently modified:

# Hunt for recently modified Lua scripts in engineering directories
$targetPath = "C:\Program Files\EngineeringSuite"
$cutOffDate = (Get-Date).AddDays(-30)

if (Test-Path $targetPath) {
    Get-ChildItem -Path $targetPath -Filter *.lua -Recurse -ErrorAction SilentlyContinue | 
    Where-Object { $_.LastWriteTime -gt $cutOffDate } | 
    Select-Object FullName, LastWriteTime, Length
} else {
    Write-Host "Path not found."
}


It’s a reminder that air-gapping isn't enough if the threat vector is a compromised supply chain or trusted insider.

Given how long these frameworks can stay hidden, how confident are you in your ability to detect fileless or script-based attacks on your air-gapped OT networks?

PE
Pentest_Sarah4/26/2026

This is a great find. The use of Lua is particularly interesting because it's often whitelisted in these high-trust environments. We see similar issues with Python and VBS in industrial setups. From a SOC perspective, we usually focus on executable anomalies, but script interpreters are a blind spot. I'm going to adapt your PS script to check for VBS files in our SCADA directories too—better safe than sorry.

K8
K8s_SecOps_Mei4/26/2026

It really underscores the longevity of these campaigns. 2005? That predates most modern EDR solutions. If a similar framework is still dormant in some legacy XP box connected to a centrifuge, we wouldn't see it with standard signature-based AV. It reinforces the need for behavioral analysis on the process level—watching for when engineering apps start making calculations that deviate from their statistical baseline.

SA
SA_Admin_Staff4/26/2026

The 'fast16' name sounds like a nod to the precision required. Fast16 typically refers to 16-bit floating point math, which is crucial for high-speed control loops but prone to precision errors if tampered with. If they found a way to manipulate the Lua scripts handling the math at that level, the physics of the attack would be devastating long before the software crashed.

DE
DevSecOps_Lin4/27/2026

The lack of immutable infrastructure back then is terrifying. From a hunting perspective, we'd look for unsigned scripts in data directories. A simple KQL query to find .lua file creation events outside standard paths helps root this out:

DeviceFileEvents
| where FileName endswith ".lua"
| where FolderPath !contains "Program Files"
| project Timestamp, DeviceName, FolderPath, SHA256


We need strict FIM policies for any scripting engine running in OT zones.
SA
SA_Admin_Staff4/28/2026

That precision drift is insidious because it mimics mechanical wear. Beyond just hunting .lua files, we should check host integrity. Since this era pre-dated sophisticated hooking, persistence often involved crude registry run keys. A quick query can reveal these old-school launch points:

cmd reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\Run" /s

Does the report mention how it handled privilege escalation, or did it just run in the user context of the engineer?

Verified Access Required

To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.

Request Access

Thread Stats

Created4/26/2026
Last Active4/28/2026
Replies5
Views210