A Researcher Just Put a Full Stuxnet Rebuild on GitHub

A GitHub user going by Sadpainy spent the past few weeks piecing Stuxnet back together and published the result as a public repository this week. Tom's Hardware and the Adafruit blog both picked it up within hours of each other on September 8, and by the time GenZ Tech checked the repo the next morning it already carried 53 commits and a research-only license. Stuxnet is the malware that physically wrecked centrifuges at Iran's Natanz enrichment plant around 2009 and 2010, widely regarded as the first piece of software known to cause physical destruction through a purely digital attack.

The repo, hosted at github.com/Sadpainy/Stuxnet, doesn't just describe the malware. It rebuilds working pieces of it:

RelatedShieldBreak Zero-Day Bypasses Microsoft's Defender Patch

• A loader and dropper (winsta.exe) that handled the initial infection and privilege escalation on a Windows host.
• Rootkit drivers (mrxcls.sys, mrxnet.sys) that hid Stuxnet's files, processes, and registry entries from the operating system.
• A hook library (s7otbxdx.dll) that sat between Siemens' Step 7 engineering software and the PLCs it talks to, intercepting and altering that traffic.
• A payload module (s7plcmain) containing the actual frequency-tampering logic that spun centrifuge motors out of their safe range.
• A second hook library (s7aaapix.dll) for further Step 7 API interception.

The README is explicit about intent: it calls the project "strictly educational and research-oriented," lists malware-analysis training and defensive ICS research as the stated purposes, and states plainly that it "is not intended to be used for any malicious purposes." The code carries a GPL-family open-source license.

What did the original Stuxnet actually do?

Stuxnet is generally believed to have been built to sabotage Iran's uranium enrichment program without anyone noticing for as long as possible. It spread initially through infected USB drives, since Natanz's centrifuge control network was air-gapped from the internet, then moved laterally across Windows machines using a chain of previously unknown vulnerabilities that Microsoft had never seen before. Once it reached a machine running Siemens' Step 7 software, it hooked into the communication path between that software and the Siemens S7-300 programmable logic controllers actually running the centrifuges.

From there its behavior was almost surgical. It periodically pushed the centrifuge rotors to spin faster or slower than their design tolerance, straining and eventually damaging the physical hardware, while simultaneously feeding the control room's monitoring systems a stream of falsified readings that looked completely normal. Engineers at Natanz reportedly spent months troubleshooting equipment failures they had no reason to trace back to sabotage, because every instrument they checked told them everything was fine. Independent analysis at the time estimated it destroyed or degraded somewhere around a thousand centrifuges before it was discovered in June 2010 by the Belarusian security firm VirusBlokAda.

Is this actually new, or has Stuxnet's code been floating around for years?

It's not the first time pieces of Stuxnet have shown up on GitHub. Symantec published an exhaustive technical dossier on the malware back in 2010 and 2011, and researchers including Christian Roggia and Amr Thabet later put out their own decompiled binaries and rootkit analyses, some of which have sat in public repos for close to a decade. What's different about Sadpainy's repo is scope: rather than static analysis notes or a single extracted component, it's organized as a fuller working reconstruction spanning the loader, the rootkit drivers, both hook libraries, and the PLC payload logic together, built from that same decade of accumulated public research rather than from a leak of Stuxnet's actual original source.

1. 2010-06VirusBlokAda discovers Stuxnet in the wild the first confirmation a cyberweapon had physically damaged industrial hardware
2. 2010-2011Symantec publishes its W32.Stuxnet dossier the technical baseline nearly every later analysis, including this repo, builds on
3. 2010sIndependent researchers post partial decompiles and rootkit breakdowns to GitHub static analysis and extracted binaries, not a unified rebuild
4. 2026-09-08Sadpainy publishes a fuller reconstruction on GitHub loader, rootkit, both hooks and the PLC payload assembled together; picked up by Tom's Hardware and Adafruit

Could someone actually run this against a real target today?

Not without a lot of extra work. The vulnerabilities Stuxnet originally exploited to spread and escalate privileges on Windows were zero-days in 2009 and 2010; Microsoft patched all of them years ago, and any reasonably maintained Windows machine has had those fixes for over a decade. The rootkit drivers also relied on stolen, legitimate code-signing certificates from Realtek and JMicron to install without tripping Windows' driver-signing checks, and both certificates were revoked once the original campaign was discovered. Reusing this reconstruction against a patched, modern environment would mean swapping in new exploits, new signing methods, and likely reworking the PLC-side logic for whatever hardware and firmware version an attacker actually faced, none of which the repo provides.

RelatedWindows LegacyHive Zero-Day Gets a Fix, Just Not From Microsoft

What it does hand anyone who clones it is the part that's harder to find written down anywhere else: a working example of how the rootkit, the engineering-software hook, and the PLC payload fit together as a system. That's genuinely valuable to someone studying industrial control system security defensively. It's also, less comfortably, a usable blueprint for the mechanics of that kind of attack for anyone willing to put in the work Stuxnet's original authors already did once.

Our take

The most useful reaction to this isn't alarm about Stuxnet 2.0 showing up next week. The specific exploits are dead, the certificates are revoked, and nobody is pointing this straight at a live target without redoing a meaningful chunk of the original work. The more honest reaction is that industrial control system security has run on scattered, hard-to-access technical writeups for fifteen years, and a clean, runnable reconstruction lowers the cost of actually studying how one of the most consequential cyberweapons ever deployed was built, for defenders and attackers alike, in roughly equal measure. That trade-off isn't new to security research. It's just rarely this concrete about which historical weapon it's making easier to understand.

Original analysis by GenZTech, based on the published GitHub repository and contemporaneous reporting. See the repository.