Stuxnet

DiscussionHistory

Overview

Stuxnet is the most written-about malware in history and one of the most consistently misdescribed. The standard sentence — that it spun Iranian centrifuges to destruction while replaying recorded normal readings to the operators watching the screens — fuses two different attacks, written for two different controllers, separated by years. Ralph Langner, whose analysis is the closest thing the field has to an authority on what the code was trying to do, calls that fusion "the most common technical misconception about Stuxnet that appears in almost every publication."

What is not in dispute is the category. Stuxnet was built to damage machinery rather than to steal from it, and it worked.

What it actually did

Stuxnet moved through Windows, looked for Siemens Step 7 engineering software, and if it found the right industrial configuration, wrote its own code onto the programmable logic controllers underneath.

The mechanism was a swapped library. Stuxnet replaced s7otbxdx.dll, the file Step 7 uses to talk to a PLC, renaming the original and interposing itself between the two. That let it write rogue logic to the controller and hide that logic from any engineer who later read the controller back — the first PLC rootkit anyone had documented.

It targeted two controller families, and this is where the popular account goes wrong.

The S7-315 attack manipulated rotor speed. It was complete and it ran. Stuxnet identified its target by the Profibus identification numbers of the attached frequency-converter drives: 7050h for drives made by Fararo Paya in Tehran, 9500h for Vacon drives from Finland. It required at least thirty-three of them before doing anything. Against an expected operating range of 807 to 1210 Hz, it drove the frequency to 1410 Hz, then to 2 Hz, then to 1064 Hz, and looped.

Those numbers mean something specific. The Institute for Science and International Security identified 1,064 Hz as the nominal operating frequency of Iran's IR-1 centrifuge and roughly 1,410 Hz as the burst frequency of its aluminium rotor. Langner converted them to rotor speeds: a normal 63,000 rpm driven up by about a third to 84,600 rpm for fifteen minutes, and in a later run brought down to essentially a standstill at 120 rpm. ISIS put roughly fifty minutes at the low setting and about twenty-seven days between sequences.

The S7-417 attack was the other one — an overpressure attack that worked by closing valves. In the sample Symantec analysed it was unfinished and never activated; a missing function meant the data block it needed was never created.

The twenty-one seconds of recorded sensor data, replayed in a loop so the control room saw normal operation, belongs to that second attack. The rotor-speed attack has no such routine, and per Langner could not have run one on the smaller controller for technical reasons. It simply suspended the legitimate control code and re-looped.

So the famous image — engineers watching calm dials while the machines tore themselves apart — describes an attack that, in the recovered sample, never ran.

The rest of the toolkit

Stuxnet used four Windows zero-days, which was extravagant. A shortcut-parsing flaw let it spread from removable drives; a Print Spooler flaw carried it across a local network; and two separate privilege-escalation flaws, one in the kernel's keyboard-layout handling and one in Task Scheduler, were chosen depending on which version of Windows it landed on.

A fifth vulnerability is often folded into the count incorrectly. The Server Service flaw Stuxnet also carried had been patched in October 2008 — it is the same one Conficker used, and it was not a zero-day by the time Stuxnet shipped.

It also carried drivers signed with legitimate code-signing certificates stolen from two Taiwanese hardware companies, Realtek and JMicron, both with offices in the same science park. Symantec observed that obtaining them would likely have required someone physically entering the premises.

It was older than its discovery

The worm became public in 2010, but the campaign was much older.

Symantec's later analysis of an earlier variant, Stuxnet 0.5, found a command-and-control server registered in November 2005 and the malware itself submitted to a public scanning service in November 2007. That version had no Windows exploits at all — it spread only through infected Step 7 project files. It attacked the S7-417 and worked by closing valves rather than by changing speeds. It was built on a different code platform from the later versions, and it was programmed to stop infecting in July 2009.

It also carried Natanz's floor plan in its logic. It parsed labels of the form PV-A21-8-160, requiring the cascade module string to fall between "A21" and "A28" and the centrifuge number to be under 164 — which is the size of an IR-1 cascade.

Symantec added a line worth keeping in view: more versions are known to exist and have never been recovered.

How far it spread, and why that number misleads

By late September 2010 Symantec counted roughly 100,000 infected hosts, across more than 40,000 unique external addresses in more than 155 countries, with about sixty percent of infections in Iran. Five organisations were targeted, all with a presence in Iran, and some 12,000 infections traced back to ten initial ones at those five.

Symantec's own characterisation of everything outside Iran was "collateral damage — unintentional side-effects of the promiscuous initial propagation methodology." The payload only fired against a very particular Profibus configuration with at least thirty-three specific drives attached. A hundred thousand machines were infected; almost none of them were attacked.

The damage figure, and what it rests on

The number everyone repeats is a thousand centrifuges. It is worth being precise about where it comes from, because it is an inference rather than an observation, and the report that produced it was titled as a question.

ISIS reasoned from IAEA cascade counts. An IAEA report of November 2009 showed a peak of 8,692 IR-1 centrifuges installed at the Natanz fuel enrichment plant. A February 2010 report showed centrifuges disconnected in eleven of the eighteen cascades in one module. At 164 centrifuges per cascade, roughly a thousand machines — about six cascades — appeared to have been decommissioned and replaced in late 2009 or early 2010.

Three caveats travel with that figure and are usually dropped.

IR-1 centrifuges fail on their own; ISIS noted that officials close to the IAEA put the failure rate as high as ten percent a year. The claim is that breakage exceeded the baseline, not that all of it was Stuxnet.

Enrichment output went up, not down. ISIS recorded that low-enriched uranium production "increased significantly" between November 2009 and February 2010, and that the gain held afterwards.

And ISIS hedged its own conclusion: although Stuxnet was "a reasonable explanation for the apparent damage," it wrote, "questions remain about this conclusion." On whether an observed efficiency decline was attributable to the worm: "Whether this is due to Stuxnet is unknown."

ISIS also framed success conditionally, and the sentence is usually quoted only as far as its first half: "If Stuxnet's goal was the destruction of all the centrifuges in the FEP, Stuxnet failed. But if its goal was to destroy a more limited number of centrifuges and set back Iran's progress in operating the FEP" — the assessment turns on which goal is assumed, and ISIS did not claim to know.

Langner reached a compatible reading from the code. He noted that no attempt was made to disable the cascade protection system during the rotor-speed attack, which would have been the easier path to catastrophic destruction, and read the intent instead as raising failure rates and leaving operators, in his phrase, chasing a demon in the machine.

Who built it

This is where the difference between acknowledged and reported matters most.

Iran acknowledged damage. President Ahmadinejad said in November 2010 that a cyberattack had been "able to disable on a limited basis" some centrifuges through "software installed in electronic equipment." He attributed it to no one. Ali Akbar Salehi had said days earlier that "Westerners sent a virus to [our] country's nuclear sites."

The United States has never acknowledged it. The contemporaneous US government position is a Congressional Research Service report of December 2010, which stated that the target, "if any, is unknown," listed six countries merely among those with speculated capability or motive, and warned about "the lack of clear attribution."

The attribution that everyone repeats is journalism. In June 2012 David Sanger reported in the New York Times that Stuxnet was part of a programme called Olympic Games, begun under the Bush administration and continued under Obama, developed by the NSA and an Israeli unit. His sourcing is participants speaking anonymously. That is substantial reporting, and it is not an official acknowledgement, and the distinction has been quietly erased in most retellings.

The clues in the code, and why the analysts warned against them

Two strings inside Stuxnet generated most of the folklore.

One driver retained a project path containing the word myrtus. Guavas belong to the myrtle genus; the string could also be read as "MyRTUs," for remote terminal units; and Esther's Hebrew name, Hadassah, means myrtle, the Book of Esther being a story about a foiled plot against Persian Jews. Elsewhere, a registry value of 19790509 caused Stuxnet to exit — a do-not-infect marker — and can be read as 9 May 1979, the date a prominent Iranian Jewish businessman was executed in Tehran.

Symantec found both, and said of the first that it "could have no significant meaning" and of the second that it "may be a random string and represent nothing." It then added a caution that deserves quoting whenever these strings are cited as evidence: "Symantec cautions readers on drawing any attribution conclusions. Attackers would have the natural desire to implicate another party."

The people who found the clues thought they were as consistent with misdirection as with authorship.

The escape

Sanger's account has Stuxnet reaching the wider internet because of a programming error in an update, which spread it to an engineer's computer connected to the centrifuges.

Langner rejects the mechanism outright: "While that is a good story, it cannot be true." An infected controller holds only the payload and no dropper, which makes the described jump from controller back to computer technically impossible. His alternative is more mundane — contractors carrying infected laptops between clients, and trusted network links doing the rest.

This is a live disagreement between anonymous participant sourcing and technical analysis of the artefact, and there is no reason to resolve it in either direction here.

On a related point Langner is unambiguous: once it was loose, "the attackers simply lacked the technical capability to call the attack off," because nothing in the malware could remove code already sitting on infected controllers.

Crossing the air gap

What is documented is that Stuxnet spread to removable drives, that it infected Step 7 project files so it executed when a project was opened, and that Symantec's forensic data shows infections seeded at five organisations — in one case, the same USB key inserted into three different computers.

What is inferred is the rest. ISIS reasoned that because the Natanz control systems are not connected to the internet, the worm must have travelled in on removable media, and that plant personnel could have carried it unknowingly. ISIS marked its own reasoning as speculation: "Perhaps the attackers first targeted the personal computers of Natanz personnel."

What is neither documented nor inferred is the story with a named insider, a planted drive in a car park, or a particular intelligence service physically carrying it through the gate. None of that appears in any of the technical primary sources.

What it was not

A cluster of claims attaches to Stuxnet that the record does not carry.

Duqu, discovered in September 2011 by a Budapest research lab and built on the same platform by what appear to be the same developers, was not a second attack on Iran's centrifuges. It was an information stealer. The US industrial-control advisory on it concluded that neither industrial control systems nor their vendors were targeted, and that Duqu was primarily a remote access trojan.

Stuxnet did not cause Fukushima, the 2003 North American blackout — which predates it — or Deepwater Horizon, and it is not still loose in anyone's grid. The 1.x versions carried a hard infection stop date of June 2012.

And the widely repeated claim that it set Iran's programme back by some number of years does not come from the technical or IAEA record. It comes from official and media assessments, and belongs to whoever made it rather than to the evidence.

Why it mattered

Strip away the misdescription and what remains is still the significant thing: code written with enough knowledge of a specific industrial process to damage it, delivered into a facility with no internet connection, and hidden from the engineers responsible for the machines.

The strategic literature that grew up afterwards treated it as the first demonstration that sabotage at that level could substitute for a military strike. What the technical record adds is a note of restraint the strategic reading tends to lose: the people closest to the code doubted it was ever meant to destroy the plant, and the enrichment figures for the period it ran are not those of a facility being crippled.

Timeline of Events

  1. 2005-01-01
    Development Period Commonly Placed By Analysts

    Public summaries and later reporting place Stuxnet’s development no later than the mid-2000s, with some analyses saying it was in development by at least 2005. :contentReference[oaicite:37]{index=37}

  2. 2006-01-01
    Olympic Games Origin Phase

    Public reporting on Operation Olympic Games places the covert anti-Iran cyber campaign as beginning during the George W. Bush administration around 2006. :contentReference[oaicite:38]{index=38}

  3. 2009-01-01
    Natanz Disruption Window

    Analysts later tied Stuxnet’s probable active sabotage period to the 2009–2010 disruption and replacement cycle of centrifuges at Natanz. :contentReference[oaicite:39]{index=39}

  4. 2010-06-17
    VirusBlokAda Identifies Stuxnet

    The malware is first publicly uncovered by VirusBlokAda in mid-June 2010. :contentReference[oaicite:40]{index=40}

  5. 2010-07-15
    Stuxnet Becomes Widely Known

    Broader public and specialist awareness expands rapidly in July 2010 as reporting and reverse-engineering intensify. :contentReference[oaicite:41]{index=41}

  6. 2010-09-14
    Four Zero-Day Exploits Widely Reported

    Public technical reporting emphasizes that the worm relied on four Windows zero-day vulnerabilities, marking it as unusually sophisticated. :contentReference[oaicite:42]{index=42}

  7. 2010-12-22
    Centrifuge Damage Estimates Publicized

    Public analysis links Stuxnet to the possible loss or replacement of roughly 1,000 centrifuges at Natanz. :contentReference[oaicite:43]{index=43}

  8. 2012-06-01
    U.S.–Israel Attribution Reporting Peaks

    Major press reports publicly tie Stuxnet to a covert U.S.–Israeli operation commonly called Olympic Games. :contentReference[oaicite:44]{index=44}

Categories

Sources & References

  1. Nicolas Falliere, Liam O Murchu and Eric Chien(2011)Symantec Security Response
  2. Geoff McDonald, Liam O Murchu, Stephen Doherty and Eric Chien(2013)Symantec Security Response
  3. Ralph Langner(2013)The Langner Group
  4. David Albright, Paul Brannan and Christina Walrond(2010)Institute for Science and International Security
  5. David Albright, Paul Brannan and Christina Walrond(2011)Institute for Science and International Security
  6. Aleksandr Matrosov, Eugene Rodionov, David Harley and Juraj Malcho(2011)ESET
  7. Alexander Gostev(2012)Securelist, Kaspersky Lab
  8. (2010)Microsoft
  9. Paul K. Kerr, John W. Rollins and Catherine A. Theohary(2010)Congressional Research Service
  10. (2010)Radio Free Europe / Radio Liberty
  11. David E. Sanger(2012)Reproduced in the ICRC Casebook
  12. Boldizsar Bencsath, Gabor Pek, Levente Buttyan and Mark Felegyhazi(2012)CrySyS Lab, Budapest University of Technology and Economics (EuroSec 2012)
  13. (2013)Cybersecurity and Infrastructure Security Agency
  14. James P. Farwell and Rafal Rohozinski(2011)Survival 53:1, 23-40
Field Assessment0 readings

Truth Meter

Unrated
CredibleDisputed
Last updated September 5, 2026. Community-maintained and reviewed under our Editorial Standards.