10:46 PM
Connect Directly

Stuxnet, The Prequel: Earlier Version Of Cyberweapon Discovered

Symantec finds 'missing link' in infamous Stuxnet malware that sabotages another piece of equipment in Iranian nuclear facility--attackers became more aggressive as campaign ensued

SAN FRANCISCO -- RSA CONFERENCE 2013 – Researchers at Symantec have identified an earlier version of the Stuxnet malware that shows that the cyberattacks on Iran's Natanz nuclear plant date back as early as 2005 and targeted another piece of uranium-enrichment equipment.

RSA Conference 2013
Click here for more articles.

Symantec found what it calls Stuxnet version 0.5 of the sophisticated cyberweapon among the samples it had collected from the version of the malware that was first discovered in the wild back in July 2010 and was created in 2009. The newly detected version of Stuxnet was in action mainly between 2007 and 2009, according to Symantec.. The cyberweapon malware was reportedly launched by the U.S. and Israel against Iran's nuclear facility to derail the possible development of nuclear weapons.

"This [version 0.5] was not new in the wild. We looked back through our Stuxnet samples and found a component that didn't fit," says Liam O Murchu, manager of North American operations for Symantec Security Technology & Response. After studying the malware more closely, Symantec found it was indeed an older version of Stuxnet, and the security firm has detected a small number of machines around the world infected with the older Stuxnet—albeit dormant infections.

There may even other Stuxnet versions that predate 0.5, because there are signs of activity back in 2005 as well, when the attackers registered domain names for the attacks, O Murchu says. "This may not be first" Stuxnet iteration, he says. "There's a chance there could be an older version than this."

The new timeline and malware version reveal how the attackers became increasingly aggressive in their attacks with the later versions of the malware, O Murchu says. "As you go up through Version 1, you see more zero-day exploits being added," he says. Another puzzle it solves: Stuxnet was definitely based on the Flame/Flamer/TildeD, malware platform as many researchers had theorized, and the writers of those malware families are either one in the same or work closely together, he says.

Flame is a cyberespionage platform used for gathering intelligence. Kaspersky Lab n June of last year found what was the first true link between the two targeted malware families -- shared source code, indicating that the efforts were intertwined.

"With 0.5, we see Flamer code .. so we know when they created the original Stuxnet, they used Flamer. It was probably one team using the same source code, then Stuxnet was developed and that went in one direction, and Flamer in another," O Murchu says.

[Experiment shows how the infamous cyberespionage families can be repurposed -- with exceptions -- in other attacks. See A Flame, Duqu Test-Drive.]

Unlike Stuxnet 1.10, which disrupted and is believed to have damaged the plant's centrifuges used to enrich uranium by attacking the Siemens PLC equipment that ran them, Stuxnet 0.5 went after the Siemens 417 PLCs that operate the valves that feed uranium hexaflouride gas into the uranium enrichment centrifuges. The attack closes the valves, one of which releases depleted uranium, and the other, enriched uranium, which would seriously damage the equipment and sabotage the uranium enrichment process. "In one of the attack scenarios with this code, it turns off the vales at both ends, so no gases are leaving," O Murchu says. The pressure buildup could turn the gas to a solid and ultimately damage the equipment as well, he says.

That solves the PLC 417 mystery in Stuxnet 1.10, which included a nonworking version of a payload attacking those PLCs. That nonfunctional element in the Stuxnet 1.01 had baffled researchers who studied the malware. "For me, it was interesting that Siemens PLC 417 was targeted [in 0.5], as everybody said this was broken in the 'new' Stuxnet," says Boldizsar Bencsath, a member of the CrySys Lab that was instrumental in studying Duqu, a related malware family to Stuxnet.

"It's also strange that it was built on Flame, but basically not that surprising. We already expected that Flame is rather old, and that parts of the code were used in different projects and that these campaigns -- Duqu, Flame, Stuxnet, Gauss, SPE etc. – are related in some way," Bencsath says. "For each goal, they probably used a different tool, but the whole campaign is still the same."

It appears the attackers knew the system and actual code that was deployed in the Iranian facility, he says. "They had surely important information about the system, but the careful design of the attack makes it possible to interact with a not exactly known system-- a system that is slightly different from the original target goal, or a system for what the attacker does not have all details," he says.

Symantec says the 0.5 version of Stuxnet was set to stop spreading on Independence Day--July 4-- of 2009, the same year version 1.10 was written. It spreads via now-patched Siemens Simatic Step 7 programming software used in PLC environments. The malware takes great pains to hide an attack: it takes snapshots of a normal system state and replays those views to fool plant operators into thinking the system is working normally. It also prevents any valve adjustments by the operator during an attack.

"Whether Stuxnet 0.5 was successful is unclear, but later versions of Stuxnet were developed using a different development framework, became more aggressive, and employed a different attack strategy that changed the speeds of the centrifuges instead suggesting Stuxnet 0.5 did not completely fulfill the attacker’s goals," according to a white paper released today by Symantec.

Still, some SCADA security experts working on security for critical infrastructure systems say Stuxnet is interesting, but not their top priority today. More common malware is a bigger concern since Stuxnet is so targeted. "Stuxnet is not relevant. It's not what keeps us up at night," says Jose Fernandez, assistant professor of computer and software engineering at Ecole Polytechnique in Montreal, which conducts SCADA and smart grid security research.

The full Symantec white paper on the newly identified version of Stuxnet 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
User Rank: Apprentice
2/27/2013 | 7:37:19 PM
re: Stuxnet, The Prequel: Earlier Version Of Cyberweapon Discovered
Excellent history of Stuxnet by Kathy Jackson Higgins and good work by Symantec to unravel the trail. It's important to add to the timeframe around Stuxnet, since it appears to illustrate our own participation in cyberwarfare. Symantec's Liam O Murchu says, "This (2005 version of Stuxnet) may not be the first." Fascinating that we may have been targeting the Iranian nuclear site since at least 2005. Highly preferable to employing explosives in a direct act of war, but still a cyberwarfare initiative. Charlie Babcock, InformationWeek- -
Devastating Cyberattack on Email Provider Destroys 18 Years of Data
Jai Vijayan, Freelance writer,  2/12/2019
Up to 100,000 Reported Affected in Landmark White Data Breach
Kelly Sheridan, Staff Editor, Dark Reading,  2/12/2019
Register for Dark Reading Newsletters
White Papers
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
How Enterprises Are Attacking the Cybersecurity Problem
How Enterprises Are Attacking the Cybersecurity Problem
Data breach fears and the need to comply with regulations such as GDPR are two major drivers increased spending on security products and technologies. But other factors are contributing to the trend as well. Find out more about how enterprises are attacking the cybersecurity problem by reading our report today.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2019-02-15
An issue was discovered in SoX 14.4.2. lsx_make_lpf in effect_i_dsp.c has an integer overflow on the result of multiplication fed into malloc. When the buffer is allocated, it is smaller than expected, leading to a heap-based buffer overflow.
PUBLISHED: 2019-02-15
An issue was discovered in SoX 14.4.2. In xmalloc.h, there is an integer overflow on the result of multiplication fed into the lsx_valloc macro that wraps malloc. When the buffer is allocated, it is smaller than expected, leading to a heap-based buffer overflow in channels_start in remix.c.
PUBLISHED: 2019-02-15
An issue was discovered in SoX 14.4.2. One of the arguments to bitrv2 in fft4g.c is not guarded, such that it can lead to write access outside of the statically declared array, aka a stack-based buffer overflow.
PUBLISHED: 2019-02-15
An issue was discovered in SoX 14.4.2. lsx_make_lpf in effect_i_dsp.c allows a NULL pointer dereference.
PUBLISHED: 2019-02-15
Vulnerability in FileUtils v0.7, Ruby Gem Fileutils <= v0.7 Command Injection vulnerability in user supplied url variable that is passed to the shell.