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
Crowdsourced vs. Traditional Pen Testing
Alex Haynes, Chief Information Security Officer, CDL,  3/19/2019
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Reading Schneier's Friday Squid Blog again?
Current Issue
5 Emerging Cyber Threats to Watch for in 2019
Online attackers are constantly developing new, innovative ways to break into the enterprise. This Dark Reading Tech Digest gives an in-depth look at five emerging attack trends and exploits your security team should look out for, along with helpful recommendations on how you can prevent your organization from falling victim.
Flash Poll
The State of Cyber Security Incident Response
The State of Cyber Security Incident Response
Organizations are responding to new threats with new processes for detecting and mitigating them. Here's a look at how the discipline of incident response is evolving.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2019-03-18
An unquoted search path vulnerability was identified in Lenovo Dynamic Power Reduction Utility prior to version that could allow a malicious user with local access to execute code with administrative privileges.
PUBLISHED: 2019-03-18
Five9 Agent Desktop Plus 10.0.70 has Incorrect Access Control (issue 2 of 2).
PUBLISHED: 2019-03-17
Phamm (aka PHP LDAP Virtual Hosting Manager) 0.6.8 allows XSS via the login page (the /public/main.php action parameter).
PUBLISHED: 2019-03-15
CircuitWerkes Sicon-8, a hardware device used for managing electrical devices, ships with a web-based front-end controller and implements an authentication mechanism in JavaScript that is run in the context of a user's web browser.
PUBLISHED: 2019-03-15
An Integer overflow vulnerability exists in the batchTransfer function of a smart contract implementation for CryptoBotsBattle (CBTB), an Ethereum token. This vulnerability could be used by an attacker to create an arbitrary amount of tokens for any user.