The fast16 Mystery
and the MARINTEK False Positive
A 2005 state-grade sabotage framework predates Stuxnet by five years — and its YARA signatures are now flagging legitimate Norwegian marine engineering software. Researcher Snorre Fagerland explains why.
01 / Background: What Is fast16?
In April 2026, SentinelLABS researchers Vitaly Kamluk and Juan Andrés Guerrero-Saade published a landmark analysis of a previously undocumented cyber sabotage framework they named fast16. Dating to 2005, it predates Stuxnet by at least five years and stands as the earliest known example of state-grade software designed to silently corrupt physical-world calculations.
The name fast16 appears in the Shadow Brokers' 2017 leak of NSA's "Territorial Dispute" deconfliction signatures, with an unusual operator note: "fast16 *** Nothing to see here – carry on ***"
The framework consists of two core components. svcmgmt.exe is a Lua-powered wormable carrier, compiled August 2005, that spreads itself across network shares and installs the payload. fast16.sys is a kernel-mode filesystem driver that intercepts executable reads and patches code in memory in real time — corrupting high-precision floating-point calculations without ever touching the file on disk.
drv_list.txt with a fast16 entry and the "Nothing to see here" deconfliction note.02 / How the Sabotage Works
The genius — and the danger — of fast16 is that it never modifies a file on disk. The kernel driver inserts itself above every active filesystem device (NTFS, FAT, network shares) and intercepts read operations. When a qualifying executable is loaded into memory, the driver applies a rule-driven patch engine containing 101 patterns before the code ever reaches the CPU.
Target Selection: Intel Compiler Fingerprinting
A file qualifies for patching only if two conditions are met: the filename ends in .EXE, and immediately after the last PE section header there is a printable ASCII string beginning with Intel. This is a compiler metadata artifact left by the Intel C/C++ compiler — the same toolchain used by LS-DYNA, PKPM, and MOHID. It is a remarkably precise targeting mechanism for 2005.
The Floating-Point Corruption Block
Most of the 101 patch rules deal with code flow manipulation — standard injection technique. But one injected block stands apart: a large sequence of x87 FPU instructions that scales values in internal numeric arrays. Without knowing the exact target binary, the precise effect cannot be determined. But the intent is unambiguous: to produce subtly wrong numerical results in physical-world simulations.
Because the wormable carrier deploys the same driver to every reachable network host, an independent verification run on another machine on the same network would produce the same corrupted output — eliminating the most obvious cross-check.
03 / The Three Confirmed Target Candidates
SentinelLABS ran the patching engine's byte patterns as YARA rules against large, era-appropriate software corpora. Only a handful of files matched two or more patterns — and they clustered into three distinct suites:
| Software | Domain | Significance | Status |
|---|---|---|---|
| LS-DYNA 970 | Structural / crash simulation | Cited in IAEA reporting on Iran's AMAD nuclear weapons program — used to model explosive lens implosion dynamics | High Confidence |
| PKPM Suite | Chinese civil engineering CAD | Dominant structural design platform across China; SATWE engine handles full tridimensional analysis | High Confidence |
| MOHID | Marine hydrodynamics | Portuguese open-source water modeling; used for coastal, oil spill, and sediment transport simulations | Needs More Research |
The combination of LS-DYNA and PKPM as targets carries significant geopolitical weight. LS-DYNA's documented role in Iran's suspected nuclear warhead design work — specifically for simulating the precisely shaped conventional explosive lenses required for an implosion-type device — places fast16 squarely in the domain of counter-proliferation operations.
04 / Enter Snorre Fagerland: A Possible Fourth Hit
Norwegian malware analyst and reverse engineer Snorre Fagerland — known for deep work on ICS/SCADA threats and targeted attack research — posted a notable observation on LinkedIn following the SentinelLABS publication. He had run the clean_fast16_patchtarget YARA rule against a DLL from the files of MARINTEK A/S, the Norwegian Marine Technology Research Institute (now part of SINTEF Ocean, Trondheim).
Description MARINTEK Report Generator DLL
Product Dynamic Link Library for Analysis of Performance Tests
Copyright © MARINTEK A/S
Version 2, 0, 21, 0
SHA-256 abb70fd400f4ab9fe27e8a1b3aa937db8fb88aea59c9ebc8ce645cd59f0cc2f2
The YARA rule fired. Two patterns matched inside the function _TIMESERIES_ANALYSIS_JNI_mp_TIMESERIES_ANALYSIS. One of those matching patterns is rule $el36:
$el36 = { 75 18 8D 35 ?? ?? ?? ?? 56 8D 3D }
This is the exact byte sequence visible in Fagerland's IDA Pro screenshot, highlighted in orange — a push [ebp+OMEGA] / lea esi, WMAX_RSP sequence in the middle of a dense signal processing argument-setup block.
"I have no idea whether this is a real hit or a false positive. The byte strings that are used by Fast16 to decide whether the file is of interest are... not hugely accurate. As an old signature pro I think FPs are possible."
— Snorre Fagerland, LinkedIn05 / False Positive Analysis
Why the Match Is Structurally Weak
The clean_fast16_patchtarget YARA rule requires any 2 of ~45 patterns to fire — a deliberately low threshold chosen to maximize research coverage rather than detection precision. Rule $el36, the matching pattern in question, is only 10 bytes long with wildcard bytes at positions 4–7. In 32-bit x86 calling convention code, the sequence lea reg, [var] / push reg repeating across multiple arguments is extremely common in any compiled C code that passes multiple pointer arguments to a function.
What the IDA Screenshot Shows
The surrounding context in Fagerland's IDA view is unambiguous scientific computing: operands named WMAX_RSP, WMIN_RSP, OMEGA, TZERO, RESPONSE, DT, NBR_SAMPLES, NSTEPS, NWSP, N_FFT_SEQ — textbook time-series spectral analysis parameters. The function calls _TS_ANALYSIS_mp_TS_SPEC and is followed by fdiv, fld, fstp, fcomp floating-point instructions. This is consistent with marine vessel performance analysis: computing response amplitude operators, frequency-domain spectra, and fatigue loads from sea trial data.
The Intel Compiler Criterion Likely Fails
The actual fast16 kernel driver only patches executables compiled with the Intel C/C++ compiler, checked by reading compiler metadata embedded after the last PE section header. MTRepGenDLL.dll would need to carry that Intel compiler signature to be targeted at runtime. This is a separate and harder condition than the YARA byte match — it acts as a natural pre-filter the driver applies before any pattern matching begins.
| Criterion | MARINTEK DLL | Verdict |
|---|---|---|
| YARA pattern match (2+ rules) | Yes — $el36 + one other |
Inconclusive |
| Intel compiler metadata after last PE section | Unknown / likely absent | Probably FP |
| Matching pattern length & specificity | 10 bytes with wildcards — very short | Probably FP |
| Code context (surrounding disassembly) | Pure DSP / signal processing math | Probably FP |
| Geopolitical/sector fit | Norwegian marine research — no proliferation nexus | Probably FP |
| Import table anomalies | Not reported; none visible | Probably FP |
This is almost certainly a false positive. The YARA rule was designed for broad community research hunting, not operational detection. The MARINTEK DLL matches on short, common x86 patterns that appear naturally in any 32-bit scientific computing DLL from the 2000s era.
06 / Why the Norwegian Context Matters
Snorre Fagerland's nationality is not incidental here. MARINTEK A/S is a well-known Norwegian institution — its Trondheim-based marine technology labs have been central to North Sea offshore engineering and ship performance research for decades. A Norwegian analyst immediately recognizes this as a domestic research organization with no plausible connection to the geopolitical targets fast16 appears to have been aimed at.
This local knowledge is precisely what gives Fagerland's observation weight. A non-Norwegian analyst scanning the same YARA hit might have flagged it as suspicious without the institutional context to dismiss it confidently. His post is a responsible, community-minded act of signature quality control — the kind of signal the research community needs to tune detection rules before they cause incident responders to chase phantoms.
Any organization in offshore engineering, naval architecture, or coastal simulation that uses similar 32-bit scientific DLLs compiled in the 2000–2015 era may see false positives from the clean_fast16_patchtarget rule. This is especially relevant in OT/ICS environments where alert fatigue or incorrect attribution could have real operational consequences.
07 / Recommendations for Defenders
If you are running the SentinelLABS fast16 YARA rules in your environment, consider the following before acting on a hit from clean_fast16_patchtarget:
Step 1 — Check the Intel Compiler Marker
Parse the PE file. After the last section header (IMAGE_SECTION_HEADER array), check for a printable ASCII string beginning with Intel. If absent, the file would not have been targeted by the actual fast16 driver at runtime — strong evidence of a false positive.
Step 2 — Examine the Import Table
Legitimate scientific DLLs import math, memory, and OS APIs. Suspicious imports for a calculation DLL include network functions (WSAConnect, InternetOpen), process injection APIs (VirtualAllocEx, WriteProcessMemory), or crypto primitives outside expected contexts.
Step 3 — Disassemble the Matching Region
Open the file in IDA Pro or Ghidra. Navigate to the matching byte pattern. If the surrounding code is dense floating-point math with named scientific operands — spectral analysis, fluid dynamics, structural loads — that is a false positive signature, not malware.
Step 4 — Check Section Entropy
Packed or encrypted sections have high entropy (>7.0). A legitimate engineering DLL should have normal section entropy. High entropy in a code section warrants deeper investigation regardless of the YARA result.
Step 5 — Apply Geopolitical Context
fast16's confirmed and suspected targets are all directly relevant to nuclear weapons development or Chinese civil infrastructure. A Norwegian marine performance DLL, a Dutch offshore simulation suite, or an academic fluid dynamics package have no plausible place in that target set.
08 / Conclusion
fast16 is a genuinely remarkable piece of history — a 2005 state-grade sabotage framework whose kernel-level floating-point corruption predates every well-known ICS attack. Its discovery forces a re-evaluation of when sophisticated cyber sabotage became operational, and its appearance in the Shadow Brokers leak raises questions about provenance and use that the research community is still working through.
Snorre Fagerland's observation about MARINTEK's MTRepGenDLL.dll is a necessary counterweight to that excitement. Good threat intelligence is not just about finding new malware — it is about ensuring the signatures and rules that follow do not create noise that degrades incident response. The clean_fast16_patchtarget rule, by design, casts a wide net. Analysts acting on its results need to apply the full chain of analysis before drawing conclusions.
In this case, the weight of evidence is clear: the MARINTEK hit is a false positive, produced by short, common x86 patterns in legitimate engineering code. The real targets of fast16 remain those identified by SentinelLABS — and understanding exactly what was being sabotaged, and where, is the research question that still deserves the community's attention.
Kamluk, V. & Guerrero-Saade, J.A. (2026). fast16 | Mystery Shadow Brokers Reference Reveals High-Precision Software Sabotage 5 Years Before Stuxnet. SentinelLABS. April 23, 2026.
No comments:
Post a Comment