Clear evidence that Stuxnet targeted Natanz nuclear centrifuges

The latest evidence revealed by two independent groups of researchers studying the code in the Stuxnet malware — the world’s first identified cyber weapon — indicates the Iran’s uranium enrichment facility at Natanz was almost certainly the target for attack. Not only was it aimed at programmable logic controllers that regulate motor speeds in a limited number of applications, mainly in uranium enrichment. Stuxnet would also alter operating speeds in such a way that centrifuges would unpredictably malfunction — the intent clearly being that the sabotage would be both effective yet also go unrecognized as sabotage.

Christian Science Monitor reports:

Once Stuxnet has locked its sights on the target, it alternately brings the centrifuge process to either a grinding slowdown or an explosive surge – by sabotaging the centrifuge refining process. It tells the commandeered PLC to force the frequency converter drive to do something it’s not ever supposed to do: Switch back and forth from high speed to low speed at intervals punctuated by long period of normal operation. It also occasionally pushes the centrifuge to far exceed its maximum speed.

“Stuxnet changes the output frequencies and thus the speed of the motors for short intervals over periods of months,” Symantec researcher Eric Chien reported Nov. 12 on his blog. “Interfering with the speed of the motors sabotages the normal operation of the industrial control process.”

Normal operating frequency of the special drive is supposed to be between 807 and 1210 Hz – the higher the hertz, the higher the speed. One hertz means that a cycle is repeated once per second.

Stuxnet “sabotages the system by slowing down or speeding up the motor to different rates at different times,” including sending it up to 1410 Hz, well beyond its intended maximum speed. Such wide swings would probably destroy the centrifuge – or at least wreck its ability to produce refined uranium fuel, others researchers say.

“One reasonable goal for the attack could be to destroy the centrifuge rotor by vibration, which causes the centrifuge to explode” as well as simply degrading the output subtly over time, Ralph Langner, the German researcher who first revealed Stuxnet’s function as a weapon in mid-September, wrote on his blog last week.

All of the circumstantial evidence points in the same direction: Natanz.

The Natanz nuclear centrifuge fuel-refining plant may have been hit first by Stuxnet in mid-2009, said Frank Rieger, a German researcher with Berlin encryption firm GSMK. The International Atomic Energy Agency found a sudden drop in the number of working centrifuges at the Natanz site, he noted in an interview in September.

“It seems like the parts of Stuxnet dealing with PLCs have been designed to work on multiple nodes at once – which makes it fit well with a centrifuge plant like Natanz,” Mr. Rieger says. By contrast, Bushehr is a big central facility with many disparate PLCs performing many different functions. Stuxnet seems focused on replicating its intrusion across a lot of identical units in a single plant, he said.

That and Symantec’s new findings also dovetail nicely with Mr. Langner’s detailed findings in his ongoing dissection of Stuxnet. Parts of the code show Stuxnet causing problems for short periods, then resuming undisturbed operation, Symantec’s findings show. As a result, Langner writes, “the victim, having no clue of being under a cyber attack, will replace broken centrifuges by new ones – until ending in frustration. It’s like a Chinese water torture.”

Print Friendly, PDF & Email

8 thoughts on “Clear evidence that Stuxnet targeted Natanz nuclear centrifuges

  1. Norman

    Interesting detective work. I will be waiting to hear/read from wence the malware came. I believe that it is being reverse engineered, but whether or not we will be informed, remains to be seen.

  2. Ben D

    Paul, I have no intention of going over this story again, but this latest claim is just so technically unreasonably far fetched that I’ll just say your credibility is permanently damaged so far as I’m concerned that I intend to unsubscribe from War in Context. I have better things to do then read B/S dis-info stuff.

  3. Paul Woodward

    Ben – maybe you should submit your technical analysis of the Stuxnet code to Symantec and Langner and show them the error of their ways. Unless of course Stuxnet itself is a piece of this “B/S dis-info stuff”. Anyhow, I’m glad to hear you have better things to do. Enjoy.

  4. David

    I continue to be underwhelmed by the alleged “proof” (speculation, really) that the ability to screw with a particular brand of industrial controller means that it (1) targeted Iran specifically (since the attacks occurred in lots of countries and particularly the “I” countries); (2) that the virus attacked Natanz specifically (since overrunning the watchdog timer and creating any number of kinds of industrial disasters would be accomplished by the QB35 tinkering); and (3) that a specific country was responsible.

    There is simply not enough information to draw any of these conclusions at this time.

  5. Paul Woodward

    The analysis of Stuxnet is not as wildly speculative as some commenters seem to believe. Leaving aside conspiracy theorists who might believe that the existence of Stuxnet is a fabrication, the analysis rests on concrete evidence: the Stuxnet code. Early in this process and basing this speculation primarily on the circumstantial evidence of the frequency with which Stuxnet had appeared in Iran, Ralph Langner suggested that the Bushehr nuclear reactor was the target of the malware. That speculation was supported by photographic evidence that Siemens software was in use at the plant, Russian contractors using USB thumb drives would have been a likely source of infection, and that the plant had identifiable security vulnerabilities. Still, that was an aggregation of circumstantial evidence — not proof.

    The next logical step in the analysis was to pin down exactly how the code functions. This is where we now move closer to proving something. Symantec and Langner have independently arrived at the same conclusion — that the malware was designed to target nuclear centrifuges. The evidence? That it targets specific drives which operate at unusually high speeds — drives whose export is controlled because one of their main uses is for uranium enrichment.

    At this point we can say that the weight of the evidence does not simply point to Iran but to Natanz (and/or other unknown enrichment facilities). As to who was behind the attack, that remains a matter of speculation but the prime suspect must still be Israel.

    I welcome skeptics who can present more persuasive theories about what Stuxnet was designed to do. Jeffrey Carr, for instance, suggested that it might have been responsible for the failure of India’s INSAT-4B satellite. Even though the satellite contained the type of PLCs that Stuxnet targets, I can’t imagine that they would be controlling motors running at the now-known target speeds. Keep in mind that the new evidence provides very detailed information about how Stuxnet works. As Danger Room reports:

    Once Stuxnet determines it has infected the targeted system or systems, it begins intercepting commands to the frequency drives, altering their operation.

    “Stuxnet changes the output frequency for short periods of time to 1410Hz and then to 2Hz and then to 1064Hz,” writes Symantec’s Eric Chien on the company’s blog. “Modification of the output frequency essentially sabotages the automation system from operating properly. Other parameter changes may also cause unexpected effects.”

    “That’s another indicator that the amount of applications where this would be applicable are very limited,” O Murchu says. “You would need a process running continuously for more than a month for this code to be able to get the desired effect. Using nuclear enrichment as an example, the centrifuges need to spin at a precise speed for long periods of time in order to extract the pure uranium. If those centrifuges stop to spin at that high speed, then it can disrupt the process of isolating the heavier isotopes in those centrifuges … and the final grade of uranium you would get out would be a lower quality.”

    O Murchu said that there is a long wait time between different stages of malicious processes initiated by the code — in some cases more than three weeks — indicating that the attackers were interested in sticking around undetected on the target system, rather than blowing something up in a manner that would attract notice.

    “It wanted to lie there and wait and continuously change how a process worked over a long period of time to change the end results,” O Murchu said.

    Stuxnet was designed to hide itself from detection so that even if administrators at a targeted facility noticed that something in the facility’s process had changed, they wouldn’t be able to see Stuxnet on their system intercepting and altering commands. Or at least they wouldn’t have seen this, if information about Stuxnet hadn’t been released last July.

    Again, note that the new evidence has compelled Langner to modify his interpretation of Stuxnet — it most likely was not targeting Bushehr and it was not designed to dramatically cause the failure of an operation but rather to discreetly corrupt it in such a way that failure would not be attributed to sabotage.

  6. charlie

    Nbc news has reported that without a doubt… George Bush did it, along with the right wind conspiricy.
    Carl Rove was waiting in the get-away car outside in the parking lot.

    Glen Beck entertained the guards while George did his dirty work right under their noses.

Comments are closed.