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
Register for Dark Reading Newsletters
White Papers
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2015-04-24
Multiple cross-site request forgery (CSRF) vulnerabilities in Zen Cart 1.3.9h allow remote attackers to hijack the authentication of administrators for requests that (1) delete a product via a delete_product_confirm action to product.php or (2) disable a product via a setflag action to

Published: 2015-04-24
Multiple cross-site request forgery (CSRF) vulnerabilities in TinyWebGallery (TWG) before 1.8.8 allow remote attackers to hijack the authentication of administrators for requests that (1) add a user via an adduser action to admin/index.php or (2) conduct static PHP code injection attacks in .htusers...

Published: 2015-04-24
Multiple cross-site scripting (XSS) vulnerabilities in TinyWebGallery (TWG) before 1.8.8 allow remote attackers to inject arbitrary web script or HTML via the (1) selitems[] parameter in a copy, (2) chmod, or (3) arch action to admin/index.php or (4) searchitem parameter in a search action to admin/...

Published: 2015-04-24
Multiple stack-based buffer overflows in HttpUtils.dll in TVMOBiLi before allow remote attackers to cause a denial of service (tvMobiliService service crash) via a long string in a (1) GET or (2) HEAD request to TCP port 30888.

Published: 2015-04-24
Red Hat JBoss Operations Network 3.3.1 does not properly restrict access to certain APIs, which allows remote attackers to execute arbitrary Java methos via the (1) ServerInvokerServlet or (2) SchedulerService or (3) cause a denial of service (disk consumption) via the ContentManager.

Dark Reading Radio
Archived Dark Reading Radio
Join security and risk expert John Pironti and Dark Reading Editor-in-Chief Tim Wilson for a live online discussion of the sea-changing shift in security strategy and the many ways it is affecting IT and business.