Video Screencast Help

Security Response

Showing posts tagged with W32.Stuxnet
Showing posts in English
Symantec Security Response | 26 Jun 2013 22:33:21 GMT

Yesterday, June 25, the Korean peninsula observed a series of cyberattacks coinciding with the 63rd anniversary of the start of the Korean War. While multiple attacks were conducted by multiple perpetrators, one of the distributed denial-of-service (DDoS) attacks observed yesterday against South Korean government websites can be directly linked to the DarkSeoul gang and Trojan.Castov.

We can now attribute multiple previous high-profile attacks to the DarkSeoul gang over the last 4 years against South Korea, in addition to yesterday’s attack. These attacks include the devastating Jokra attacks in March 2013 that wiped numerous computer hard drives at South Korean banks and television broadcasters, as well as the...

Symantec Security Response | 26 Feb 2013 17:40:00 GMT

In July 2010, Stuxnet, one of the most sophisticated pieces of malware ever written, was discovered in the wild. This complex malware took many months to analyze and the eventual payload significantly raised the bar in terms of cyber threat capability. Stuxnet proved that malicious programs executing in the cyber world could successfully impact critical national infrastructure. The earliest known variant of Stuxnet was version 1.001 created in 2009. That is, until now.

Symantec Security Response has recently analyzed a sample of Stuxnet that predates version 1.001. Analysis of this code reveals the latest discovery to be version 0.5 and that it was in operation between 2007 and 2009 with indications that it, or even earlier variants of it, were in operation as early as 2005.

Key discoveries found while analyzing Stuxnet 0.5:

  • Oldest variant of Stuxnet ever found...
Symantec Security Response | 26 Feb 2013 17:40:00 GMT

When Symantec first disclosed details about how Stuxnet affected the programmable logic controllers (PLCs) used for uranium enrichment in Natanz, Iran, we documented two attack strategies. We also noted that the one targeting 417 PLC devices was disabled. We have now obtained an earlier version of Stuxnet that contains the fully operational 417 PLC device attack code.

After painstaking analysis, we can now confirm that the 417 PLC device attack code modifies the state of the valves used to feed UF6 (uranium hexafluoride gas) into the uranium enrichment centrifuges. The attack essentially closes the valves causing disruption to the flow and possibly destruction of the centrifuges and related systems. In addition, the code will take snapshots of the normal running state of the system, and then replay normal operating values...

Symantec Security Response | 26 Feb 2013 17:40:00 GMT


Stuxnet stores a version number within its code. Analysis of this code reveals the latest discovery to be version 0.5. Based on website domain registration details, Stuxnet 0.5 may have been in operation as early as 2005. The exact date this version began circulating in the wild is unclear. What is known is that the date this early variant stopped compromising computers was July 4, 2009—just 12 days after version 1 was created.

Table 1. Known Stuxnet variants, based on main module PE timestamps

This blog focuses on the Stuxnet timeline, how Stuxnet 0.5 fits into the attack timeline, and its evolution to Stuxnet version 1.


Stuxnet 0.5 is...

Symantec Security Response | 26 Feb 2013 17:40:00 GMT

Similar to Stuxnet 1.x versions, Stuxnet 0.5 has limited command-and-control (C&C) ability. In particular, Stuxnet 0.5 does not provide fine-grained control to its authors. Instead, Stuxnet 0.5 can only download new code and update itself. Stuxnet needs to spread on isolated networks and therefore has been designed to be autonomous, reducing the need to have robust and fine-grained C&C ability. Stuxnet 0.5 also uses a secondary peer-to-peer mechanism in order to propagate code updates to peers on networks inaccessible to the broader Internet.

Stuxnet 0.5 has four C&C servers, all of which are now either unavailable or have since been registered by an unrelated party.

Interestingly, Stuxnet 0.5 is programmed to stop contacting the C&C server after January 11, 2009, even though the threat is programmed to stop spreading several months later after July 4, 2009.

The C&C server domains were created in 2005 and all displayed the same front page...

Symantec Security Response | 22 Nov 2012 10:39:05 GMT

In the last couple of years, we have seen highly sophisticated malware used to sabotage the business activities of chosen targets. We have seen malware such as W32.Stuxnet designed to tamper with industrial automation systems and other destructive examples such as W32.Disstrack and W32.Flamer, which can both wiped out data and files from hard disks. All of these threats can badly disrupt the activities of those affected.

Following along that theme, we recently came across an interesting threat that has another method of causing chaos, this time, by targeting and modifying corporate databases. We detect this threat as...

Symantec Security Response | 01 Jun 2012 11:13:13 GMT

Flamer has the ability to spread from one computer to the next. However, Flamer does not automatically spread, but instead waits for instructions from the attackers. Flamer can spread using the following methods:

Symantec Security Response | 28 May 2012 13:32:58 GMT

Over the past few days, we have been analyzing a potential new threat that has been operating discreetly for at least two years. We were contacted about this threat by Crysys who have released their own analysis. (The threat is referred to by CrySys as 'Skywiper'). There are indications that W32.Flamer is also the same threat as described recently by the Iranian national cert. Our analysis of the retrieved samples reveals complex code that utilizes several components. At first glance, the executable appears to be benign but further inspection reveals cleverly concealed malicious functionality.

The complexity of the code within this threat is at par with that seen in Stuxnet and...

Eric Chien | 21 Oct 2011 23:00:30 GMT

I wrote Symantec's original blog post describing the discovery of Duqu. In that blog I use the term "industrial control system manufacturers" and (after discussions with a variety of parties) we want to change that term to "industrial industry manufacturers" to more accurately define where Duqu has been found. We already made this change to our paper.

Finding the correct term can sometimes be a challenge. When we first wrote about Stuxnet, we originally used the term SCADA (supervisory control and data acquisition) and quickly discovered the proper term was "industrial control systems". In the computer security industry, we actually have specific definitions of viruses, worms, and trojans, while the general public often refer to any malware as just a virus. (In an unrelated...

Symantec Security Response | 21 Oct 2011 16:56:58 GMT

As mentioned in our previous blog, W32.Duqu was first brought to our attention by a research lab who had been investigating a targeted attack on another organization. This research was conducted by the Laboratory of Cryptography and System Security (CrySyS) in the Department of Telecommunications, Budapest University of Technology and Economics. CrySyS identified the infection and observed its similarity to W32.Stuxnet. They stated that no data was leaked as part of this attack.

We are grateful to CrySyS—sharing their findings allowed us to identify further attacks taking place. We have now determined that the originally targeted organization was one of a limited number of targets which include those in the industrial infrastructure industry. CrySyS has issued a statement regarding their analysis here:

The latest...