Reconstructed Stuxnet source code appears on GitHub as a research artifact

Reconstructed Stuxnet source code appears on GitHub

A GitHub project that surfaced on Hacker News's front page offers a reconstructed source tree for Stuxnet, the worm widely described as the first malware built to physically destroy industrial equipment. According to the repository's README, the code is an education- and research-oriented rebuild assembled from decompiled binaries of the samples discovered in 2010, with the original logic and attack vectors preserved but the codebase reorganized so it can actually be read and studied. The author, publishing under the handle Sadpainy, notes the code works only on Windows XP and Windows 7.

The project is licensed under the GNU GPL v3 and carries heavy disclaimers: the README states it is meant for academic study, malware-analysis training and defensive research, that it is not intended as deployable malware, and that while the original authors of the worm remain anonymous, the reconstruction is the work of independent researchers.

What is in the repository

The code is organized around the modules the security community identified while dissecting the worm over a decade ago. Per the README, these include:

• A loader and dropper (winsta.exe, ~WTR4141.tmp) handling initial infection, privilege escalation and deployment of the remaining components.
• A privilege-escalation module (~WTR4132.tmp) abusing a Win32k.sys vulnerability to reach system-level privileges.
• Two hook libraries that hijack Siemens tooling: s7otbxdx.dll, a stand-in for the legitimate s7otbxsx.dll that intercepts communication between Step 7 and the PLC, and s7aaapix.dll, which hooks the automation API inside the Step 7 engineering environment.
• Kernel-mode rootkit drivers mrxcls.sys, which hides files, processes and registry keys through SSDT hooking, and mrxnet.sys, which filters file-system requests and supports peer-to-peer spread.
• A payload module named s7plcmain containing the logic that manipulates drive frequencies.

The README lists three propagation paths: USB drives via LNK exploits, network shares via the Print Spooler service, and peer-to-peer.

The attack chain it documents

Stuxnet targeted Siemens SIMATIC WinCC and Step 7 software along with S7-300/400 PLCs. The documented execution flow runs through twelve stages: initial infection, dropper and escalation, then an environment check. On machines where the Siemens software is present, the hooks are installed; on non-target machines the worm self-destructs or idles. From there it monitors PLC writes, waits for the OB1 or OB35 blocks to be written, injects its payload and alters frequency output. Only afterward do the rootkit and networking modules come into play, hiding artifacts and enabling further spread.

The reconnaissance step specifically looks for WinCC, Step 7 and the S7-315 and S7-417 controllers. The DLL hook intercepts the s7blk_write call, so when an engineer downloads a project to the PLC, malicious code is appended to the OB1 and OB35 blocks. The PLC then executes the manipulated code, driving connected variable-frequency drives to abnormal speeds, alternating high and low, which produces the mechanical damage to centrifuge rotors that made Stuxnet notorious.

A lab artifact, not a weapon

Build guidance in the README points to Visual Studio 2019/2022 or mingw-w64, the Windows Driver Kit 7600 for the kernel drivers, and Windows XP or 7 targets for driver compatibility. The intended workflow is static analysis and debugging inside an isolated virtual machine with host-only networking and no internet access, using tools such as IDA Pro, Ghidra, x64dbg, Process Monitor, Process Hacker and Wireshark. Suggested applications include studying advanced persistent threat tradecraft, writing YARA and Snort detection signatures for ICS security tooling, and academic work on critical-infrastructure protection.

The acknowledgements credit Symantec's W32.Stuxnet dossier, Kaspersky's and ESET's analyses, and earlier reconstruction work by Amr Thabet and Christian Roggia, positioning the project as a distillation of existing community research rather than new discovery.

Why it matters

Stuxnet is the reference case for malware crossing from software into physical destruction, and readable source lowers the barrier for the people who have to defend against that class of threat. For detection engineers and ICS security teams, a structured codebase is far easier to reason about than decompiled binaries, and it can directly inform signatures and lab exercises. The caveats are real, though: this is a single, self-published reconstruction, nothing in it has been independently audited, and how faithfully it mirrors the original binaries cannot be confirmed from the repository alone. Handling malware source also carries legal exposure that varies by jurisdiction, and the README explicitly puts compliance obligations on the user. As an educational artifact it is genuinely useful, provided it stays inside isolated lab environments.