10:45 AM
Connect Directly

Stuxnet's Earlier Version Much More Powerful And Dangerous, New Analysis Finds

ICS/SCADA expert Ralph Langner analyzes how Stuxnet shifted from super-stealthy to simpler, and dispels common misconceptions about the infamous Stuxnet attack on Iran's nuclear facility -- including the belief that only a nation-state could pull off a similar attack in the future

The later-discovered earlier iteration of Stuxnet was a far more aggressive, stealthy, and sophisticated attack that could have ultimately caused catastrophic physical damage in Iran's Natanz facility. So says the expert who deciphered how Stuxnet targeted the Siemens PLCs, after recently reverse-engineering the code and further studying the attacks.

Ralph Langner, head of The Langner Group and a renowned ICS/SCADA expert, today published an analysis of Stuxnet that shines new light on the game-changing cyberweapon. Langner concludes, among other things, that the attackers moved from a more destructive and stealthy payload to a weaker and more easily detected one, and conventional wisdom that it would take a nation-state to use Stuxnet as a blueprint for attacks against U.S. and its allies' critical infrastructure is incorrect.

One big takeaway from Langner's new analysis is how the Stuxnet attackers so dramatically shifted gears from a dangerous, aggressive, and hidden attack strategy that wasn't discovered for at least five years to a louder, more noticeable, and detectable one that burnt multiple zero-day vulnerabilities and used stolen digital certificates. "What you see today in that analysis is that the first attack was more complex, stealthy, and more aggressive than the second. That is counterintuitive," Langer told Dark Reading. "So why did the attackers go from the ultimate in stealth and aggression to something that's much more simple and comes with a much higher risk of detection?"

The first attack was never meant to be detected, nor was it until Symantec found its malware clue tucked among Stuxnet samples. It was a component that didn't fit with the malware, according to Liam O Murchu, manager of North American operations for Symantec Security Technology & Response. In February Murchu detailed Symantec's discovery of what it nicknamed "Stuxnet 0.5," which dates back to 2005, five years before the later and better-known version of the malware was discovered in 2010.

[Symantec finds 'missing link' in infamous Stuxnet malware that sabotages another piece of equipment in Iranian nuclear facility. See Stuxnet, The Prequel: Earlier Version Of Cyberweapon Discovered.]

Langner says he's still baffled by why the Stuxnet attackers left behind the dormant payload, which overpressured the centrifuge rotors in the Natanz plant. The malware, like its better-known successor, was written to inflict damage on the centrifuge rotors. The main difference between the two attacks is in just how they did so: The early attack overpressured the centrifuges, which could have led to a more catastrophic physical attack. It infected the Siemens S7-417 controllers that control the valve and pressure sensors of the so-called Cascade Protection System -- groups of gas centrifuges for uranium enrichment. The second version of the Stuxnet malware attack sped up the spinning of the centrifuges at various intervals to eventually disable them, targeting the Siemens S7-315 controller.

"If the idea was catastrophic destruction, one would simply have to sit and wait. But causing a solidification of process gas would have resulted in simultaneous destruction of hundreds of centrifuges per infected controller," he wrote in his new Stuxnet paper. "While at first glance this may sound like a goal worthwhile achieving, it would also have blown cover since its cause would have been detected fairly easily by Iranian engineers in post mortem analysis. The implementation of the attack with its extremely close monitoring of pressures and centrifuge status suggests that the attackers instead took great care to avoid catastrophic damage. The intent of the overpressure attack was more likely to increase rotor stress, thereby causing rotors to break early – but not necessarily during the attack run."

Langner told Dark Reading that the early version of Stuxnet would not have been detected had the attackers taken more pains to cover their tracks. "It was only detected given the knowledge of the later version [of Stuxnet]," he says. If they had removed that payload, then it would likely never have been discovered at all, and we would not have learned of the first more deadly attack, he says.

"But with the full story, we have a better idea of how bad things can get: Malware flies under the radar of all antivirus and intrusion detection systems, and you have no chance to discover it just by looking at it. And it attacks the most sensitive components in any big industrial facility -- the protection and safety systems. That's a nightmare for engineers," he says. "That's one thing you put trust in, those systems that are designed and installed to [alert you] that if something goes wrong for whatever reason, still, disaster won't hit you."

Langner says the earlier Stuxnet payload is a wake-up call that attackers can and will go after ICS/SCADA equipment, and can cause major physical damage.

So why the change-up to a less powerful payload for Stuxnet? "The only explanation is a change in policy, strategy. And most likely, a change in stakeholders," Langner says of the attackers.

The attackers behind Stuxnet reportedly were U.S. intelligence and military officials, including the National Security Agency, according to published reports quoting unnamed Obama administration officials.

The earlier version of Stuxnet was less about information security capabilities. "It didn't require and use stolen digital certificates. There must be a reason for that. The one thing I believe that is pretty much obvious is for the second and later version, we see stuff you know is something the NSA has," Langner says.

Despite a common conclusion that Stuxnet could not be repurposed for other attacks on ICS/SCADA systems, Langner contends that Stuxnet, indeed, could be used in copycat attacks. For one, Stuxnet relied heavily on the weakest link in the facility -- its contractors, he says.

Langner argues that simultaneous attacks against multiple facilities with similar equipment could occur. That "scalability" of an attack would supersede the need for a nation-state or other sophisticated attacker, and could indeed cause power failure, for example. "These [attack] tactics can be copied -- it's doesn't require nation-state capabilities," Langner says.

Targeting a facility's contractors, for instance, as a way to secretly install the malware is a tactic any savvy attacker could employ. And code can be repurposed, Langner notes in his paper: "One of the toughest challenges is the fact that exploit code can be packaged into software tools. The genius mastermind is needed only for identifying vulnerabilities and designing exploits ... At some level of software maturity, such exploit components can be made available in user-friendly point-and-click software applications, just like it is now for boilerplate malware development. The skill set for those who assemble and deploy a specific sample of cyber-physical attack code will then drop dramatically."

Meanwhile, Langner says his new Stuxnet analysis is his last. "I don't plan to publish anything further. It sucked up too many of my resources. There was no external budget for this; I did it all on my own," he says.

Langner's full and detailed report, "To Kill A Centrifuge," which includes analysis of photos from inside the Natanz plant floor, is available here (PDF) for download.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message. Kelly Jackson Higgins is Executive Editor at She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
New Mexico Man Sentenced on DDoS, Gun Charges
Dark Reading Staff 5/18/2018
Cracking 2FA: How It's Done and How to Stay Safe
Kelly Sheridan, Staff Editor, Dark Reading,  5/17/2018
What Israel's Elite Defense Force Unit 8200 Can Teach Security about Diversity
Lital Asher-Dotan, Senior Director, Security Research and Content, Cybereason,  5/21/2018
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Shhh!  They're watching... And you have a laptop?  
Current Issue
Flash Poll
[Strategic Security Report] Navigating the Threat Intelligence Maze
[Strategic Security Report] Navigating the Threat Intelligence Maze
Most enterprises are using threat intel services, but many are still figuring out how to use the data they're collecting. In this Dark Reading survey we give you a look at what they're doing today - and where they hope to go.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2018-05-24
Some Huawei smart phones with the versions before Berlin-L21HNC185B381; the versions before Prague-AL00AC00B223; the versions before Prague-AL00BC00B223; the versions before Prague-AL00CC00B223; the versions before Prague-L31C432B208; the versions before Prague-TL00AC01B223; the versions before Prag...
PUBLISHED: 2018-05-24
Huawei DP300 V500R002C00; RP200 V600R006C00; TE30 V100R001C10; V500R002C00; V600R006C00; TE40 V500R002C00; V600R006C00; TE50 V500R002C00; V600R006C00; TE60 V100R001C10; V500R002C00; V600R006C00 have a numeric errors vulnerability. An unauthenticated, remote attacker may send specially crafted SCCP m...
PUBLISHED: 2018-05-24
NetApp OnCommand Unified Manager for Windows versions 7.2 through 7.3 are susceptible to a vulnerability which could lead to a privilege escalation attack.
PUBLISHED: 2018-05-24
NetApp OnCommand Unified Manager for Linux versions 7.2 through 7.3 ship with the Java Management Extension Remote Method Invocation (JMX RMI) service bound to the network, and are susceptible to unauthenticated remote code execution.
PUBLISHED: 2018-05-24
Huawei 1288H V5 and 288H V5 with software of V100R005C00 have a JSON injection vulnerability. An authenticated, remote attacker can launch a JSON injection to modify the password of administrator. Due to insufficient verification of the input, this could be exploited to obtain the management privile...