Stuxnet Reconstruction (Defender's View)
Stuxnet worked because the operator view and the controller were both made to lie: the HMI replayed a steady 1064 Hz while the centrifuge drives ran up into the ~1410 Hz resonance band, and a PLC rootkit showed STEP 7 the original, clean code. This lab walks the real, published chain on Siemens S7-300/400 PLCs and WinCC/STEP 7 — from the USB/LNK entry to the s7otbxdx.dll hijack to the record-and-replay deception — and asks, at each stage, which detection or defense would have caught it. It is strictly a defender's reconstruction from public post-incident reporting: no exploit code, no payloads, no attack instructions.
The real job. More noise, a tighter clock.
Stage 1 / 12
An engineer plugs in a USB stick
The enrichment cell is air-gapped — no internet, no business LAN. A contractor’s USB drive is inserted into a programming laptop to move a project file. Nothing visible happens.
Published fact: Stuxnet’s initial access was removable media. It abused the Windows .LNK shortcut flaw (CVE-2010-2568) so merely viewing the drive in Explorer executed it — no double-click, no network.
Which control catches or stops this stage?
Pick the detection/defense control for this stage.
Reconstruction
Walk the real, published Stuxnet chain across 12 stages. For each, name the defensive control that would have detected or stopped it. Pull the independent tap when you suspect the HMI is being replayed a normal value — the Stuxnet move.
So far: 0 / 12 stages locked in.
Safe & educational
This is a defender-lens reconstruction from public post-incident reporting (Symantec, Langner, ESET, CISA ICS-CERT). It contains no exploit code and no payloads — only how each stage worked and how you detect or stop it.
The recurring lesson: when the HMI and the PLC can both be made to lie, truth has to come from outside both.
Live arena
4 activeadversary staging…
What this lab is
- A free, browser-based reconstruction of the real Stuxnet attack chain against Siemens S7-300/400 PLCs and WinCC/STEP 7 — told entirely from the defender’s side.
- Walk 12 published stages: the USB/LNK entry (CVE-2010-2568), stolen-certificate signed drivers, the s7otbxdx.dll hijack on the engineering workstation, hidden S7 logic injection, VFD over-speed to ~1410 Hz, and the 21-second record-and-replay that kept the HMI showing normal.
- A live centrifuge-cascade and HMI-mimic diagram shows the core deception: the operator screen reads a steady 1064 Hz while an independent tap reveals the rotors in the resonance band.
- Each stage asks which detection or defense control would have caught it — removable-media control, code-signing trust, engineering-workstation hardening, PLC integrity monitoring, offline baselining, or out-of-band process sensing. Scored and graded S–D.
- Strictly educational and defender-focused: mechanism, detection and mitigation at the level of public post-incident reporting. No exploit code, no payloads, no attack instructions.
How the Stuxnet chain actually worked
Stuxnet is the most-studied industrial cyber-physical attack in history, and almost everything about it is public. It crossed an air gap on a USB stick, abusing the Windows .LNK shortcut flaw (CVE-2010-2568) so simply viewing the drive ran the code. It spread across Windows using the print-spooler flaw (CVE-2010-2729), the RPC flaw (MS08-067) and WinCC's hardcoded database account, and loaded kernel rootkit drivers signed with stolen Realtek and JMicron certificates so Windows trusted them.
On the engineering workstation it replaced s7otbxdx.dll, the STEP 7 to PLC communication library, to sit in the middle of every program download and upload. It then armed only on a very specific target — particular S7-315 and S7-417 CPUs driving CP 342-5 Profibus with a defined set of Vacon/Fararo Paya variable-frequency drives — and injected rogue logic blocks into the CPU. A PLC-resident rootkit then returned the original code on read-back, so the program looked untouched in STEP 7.
The sabotage itself was patient and physical: the drives were pushed out of their normal band and back over intervals spaced weeks apart, while about 21 seconds of recorded normal values were replayed to the monitoring and safety logic. Centrifuges failed at an unusual rate for months and it looked like ordinary reliability trouble, because no logged value ever showed the over-speed. The enduring defensive lesson is simple and hard: a controller that can lie about its own contents, and an HMI that can be fed a replay, cannot be trusted to report their own integrity — that has to be established from outside them.
Frequently asked questions
What is the Stuxnet Reconstruction lab?
A free, in-browser exercise that walks the real, published Stuxnet attack chain one stage at a time from a defender’s point of view. For each stage — USB/LNK initial access, signed-driver spread, the STEP 7 comms-DLL hijack, PLC logic injection, variable-frequency-drive over-speed, and the record-and-replay HMI deception — you choose the detection or mitigation that would have caught or stopped it. A centrifuge-cascade and HMI diagram visualises the deception as you go. It runs entirely in your browser; nothing is uploaded.
Is this a real attack tool or does it contain exploit code?
No. It contains no exploit code, no payloads and no attack instructions. Every round is described at the level of public post-incident reporting — Symantec’s W32.Stuxnet Dossier, Ralph Langner’s analysis, ESET, and CISA ICS-CERT advisories — which means the mechanism, how you detect it, and how you mitigate it, but never an operational how-to. The processes and values are a teaching simulation, not a live control system.
What was the actual Stuxnet deception?
Stuxnet injected hidden logic into specific Siemens S7-315/S7-417 CPUs and drove the centrifuge variable-frequency drives well above their ~1064 Hz normal band (to roughly 1410 Hz) and later far below, in bursts spaced weeks apart. While it did this it replayed about 21 seconds of previously-recorded normal sensor values to the monitoring and safety logic, and a PLC-resident rootkit returned the original, clean code to STEP 7 on read-back. So both the HMI and the controller lied: the operators saw a healthy process the entire time.
What is the defensive lesson?
When the HMI view and the PLC can both be made to lie, truth has to come from outside both. Defence in depth stops the early hops — removable-media control and patching break the entry and spread, engineering-workstation hardening and toolchain integrity protect the programming path, and offline logic baselining catches controller tampering. But the one control that still works after the HMI and PLC are compromised is independent, out-of-band sensing of the real physical process with instruments the controller cannot feed.