What Was Stuxnet? The Worm That Reached Into a Nuclear Plant and Broke the Machinery

August 28, 2026

In June 2010, a small antivirus company in Minsk got a support ticket about some computers in Iran that kept rebooting. Not dramatically. Just… rebooting. Blue screen, restart, repeat.

VirusBlokAda had maybe a dozen employees. They were not expecting to find the most sophisticated piece of malware ever written. But they pulled the thread anyway, and what came out the other end was roughly 15,000 lines of code that had been quietly destroying Iran's nuclear enrichment program for over a year.

The best part is how they found it. Stuxnet had been running loose in the wild for months and nobody noticed, because it was extremely good at hiding. What gave it away was a bug. One of its own components crashed the machines it was infecting. The most advanced cyberweapon in history was discovered because it had a memory leak.

What was Stuxnet?

Stuxnet was a computer worm discovered in June 2010 that targeted Siemens SIMATIC Step 7 industrial control software in order to sabotage uranium enrichment centrifuges at the Natanz Fuel Enrichment Plant in Iran. It is widely regarded as the first piece of malware to cause physical destruction of industrial equipment.

The name came from strings inside the code itself — fragments of .stub and mrxnet.sys, mashed together by whoever had to file the sample.

Attribution has never been officially acknowledged by any government. It has been widely reported as a joint US-Israeli operation codenamed Olympic Games, most prominently by David Sanger in 2012. Treat that as reporting, not confirmation.

How did Stuxnet cross an air gap?

Natanz was not on the internet. That was the entire point.

So Stuxnet spread on USB drives, and it did it without anyone clicking anything. It used CVE-2010-2568 (patched as MS10-046), a flaw in how Windows Shell parsed .LNK shortcut files. Windows would render the shortcut's icon just by displaying the folder. Rendering the icon executed the payload. You plugged in the drive, opened Explorer to see what was on it, and you were done.

If you have ever explained to a client why autorun policies matter and gotten a blank stare, this is the story to tell.

The four zero-days

Zero-days are expensive. Burning one on an operation means giving it up forever the moment it's discovered. Stuxnet burned four at once, which tells you more about who built it than any code analysis could.

CVE-2010-2568 (MS10-046) — Windows Shell .LNK parsing. Initial execution via USB.
CVE-2010-2729 (MS10-061) — Print Spooler service impersonation. Network propagation.
CVE-2010-2743 (MS10-073) — Win32k.sys keyboard layout flaw. Local privilege escalation.
CVE-2010-3888 (MS10-092) — Task Scheduler. Local privilege escalation.

It also used CVE-2008-4250 (MS08-067) for lateral movement — the same Server service vulnerability Conficker had made famous two years earlier. Already patched, still working, because it always is.

The stolen certificates

Stuxnet's kernel-mode rootkit drivers were signed with legitimate code-signing certificates stolen from Realtek Semiconductor, and later from JMicron Technology. Windows loaded them without complaint, because as far as Windows was concerned they were fine.

Both companies had offices in Hsinchu Science Park in Taiwan. Whoever took those keys may have simply walked in and taken them.

What it actually did to the centrifuges

This is the part that separates Stuxnet from every other piece of malware.

Once inside, it looked for a very specific environment: Siemens S7-315 and S7-417 PLCs driving frequency converters made by Vacon in Finland or Fararo Paya in Iran, operating between 807 Hz and 1210 Hz. That frequency band is not a general-purpose industrial range. It is the operating range of gas centrifuges for uranium enrichment. If Stuxnet didn't find that exact configuration, it did nothing at all and moved on.

When it did find it, it lied to the people watching. It replaced a Siemens communications library called s7otbxdx.dll with its own copy, intercepting sixteen of that library's hundred and nine exported functions — so every question the monitoring software asked the controller was answered by the malware instead.

There were two separate sabotage routines, and they are almost always reported as one. Ralph Langner's analysis untangled them.

The earlier overpressure attack went after the cascade protection system, manipulating valves to over-pressurise the centrifuges. This is the one with the famous replay trick: it recorded 21 seconds of normal sensor readings and played that loop back to the monitoring stations while the attack ran. A replay attack against the operators themselves.

The later rotor speed attack did something cruder and more physical. IR-1 centrifuges are designed to spin at around 63,000 rpm. Stuxnet drove them up to 84,600 rpm for fifteen minutes, and in a separate sequence dropped them to 120 rpm before bringing them back — a roughly fifty-minute cycle. Aluminium rotors do not tolerate that. They wobble, they crack, they fail.

Either way the operators saw nothing useful. They spent months assuming they had bad parts and bad suppliers.

How much damage did it do?

Less certainly than you will read.

The Institute for Science and International Security estimated that about 1,000 IR-1 centrifuges — over ten percent of those installed — were decommissioned and replaced at Natanz in late 2009 or early 2010. That figure is where every "Stuxnet destroyed a thousand centrifuges" headline comes from.

ISIS itself was more careful than its readers. Its report says that while Stuxnet is "a reasonable explanation for the apparent damage," "questions remain about this conclusion," and concludes that if the goal was to destroy the whole plant, Stuxnet failed; if the goal was limited damage that was hard to detect, it "may have succeeded, at least temporarily."

So: roughly a thousand centrifuges were replaced, and Stuxnet is the most plausible reason. That is a weaker claim than the one usually made, and it is the accurate one.

Why did Stuxnet get caught?

It escaped.

A worm designed to move across air gaps via removable media will, eventually, move across the wrong air gap. Some contractor took a laptop home. Stuxnet ended up on roughly 100,000 hosts worldwide, around 60% of them in Iran, sitting inert on machines that had no centrifuges to attack because the targeting logic was that specific.

It even had an expiry date hardcoded: 24 June 2012, after which it would stop spreading entirely. Someone thought carefully about cleanup. They just underestimated how far it would get first.

And sitting inside the infected controller code was a marker value: 0xDEADF007.

Why it still matters

Every ICS/SCADA security program that exists today exists partly because of this worm. Before Stuxnet, "air-gapped therefore safe" was a sentence people said in meetings without embarrassment. After Stuxnet, it became a punchline.

It also proved something that had only ever been theoretical: code can break things. Not data, not availability, not reputation. Physical objects, made of metal, spinning in a building in the desert.

Fifteen years on, it is still the reference point. Every time someone writes about a cyber-physical attack, they benchmark against Natanz.

EXHIBIT 0001 — STUXNET

We put it on a shirt. The first entry in the archive, because it had to be.

Most people who see it will read a word they half-recognize from a documentary. A smaller number will clock the details and know exactly what they're looking at.

That's the whole idea.

View the Stuxnet shirt — EXHIBIT 0001

Back to blog

Item added to your cart