Four Years of DarkSeoul Cyberattacks Against South Korea Continue on Anniversary of Korean War

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 attacks on South Korean financial companies in May 2013.

Conducting DDoS attacks and hard disk wiping on key historical dates is not new for the DarkSeoul gang. They previously conducted DDoS and wiping attacks on the United States Independence Day as well.


Figure 1. Four years of DarkSeoul activity

The DarkSeoul gang’s attacks tend to follow similar methods of operation. Trademarks of their attacks include:

  • Multi-staged, coordinated attacks against high-profile targets in South Korea
  • Destructive payloads, such as hard disk wiping and DDoS attacks configured to trigger on historically significant dates
  • Overwriting disk sectors with politically-themed strings
  • Use of legitimate third-party patching mechanisms in order to spread across corporate networks
  • Specific encryption and obfuscation methods
  • Use of specific third-party webmailer servers to store files
  • Use of similar command-and-control structures

The attacks conducted by the DarkSeoul gang have required intelligence and coordination, and in some cases have demonstrated technical sophistication. While nation-state attribution is difficult, South Korean media reports have pointed to an investigation which concluded the attackers were working on behalf of North Korea. Symantec expects the DarkSeoul attacks to continue and, regardless of whether the gang is working on behalf of North Korea or not, the attacks are both politically motivated and have the necessary financial support to continue acts of cybersabotage on organizations in South Korea. Cybersabotage attacks on a national scale have been rare—Stuxnet and Shamoon (W32.Disttrack) are the other two main examples. However, the DarkSeoul gang is almost unique in its ability to carry out such high-profile and damaging attacks over several years.


Figure 2. Castov DDoS attack


The Castov DDoS attack occurs in the following manner:

  1. Compromised website leads to the download of SimDisk.exe (Trojan.Castov), a Trojanized version of a legitimate application.
  2. SimDisk.exe drops two files onto the compromised system: SimDisk.exe (Clean), the legitimate non-Trojanized version, and SimDiskup.exe (Downloader.Castov).
  3. Downloader.Castov connects to a second compromised server to download the C.jpg file (Downloader.Castov), an executable file which appears to be an image.
  4. Threat uses the Tor network to download Sermgr.exe (Trojan.Castov).
  5. Castov drops the Ole[VARIABLE].dll file (Trojan.Castov) in the Windows system folder.
  6. Castov downloads the CT.jpg file from a Web server hosting a ICEWARP webmail, that has been compromised as a result of publicly known vulnerabilities in ICEWARP. The CT.jpg file contains a timestamp used by Castov to synchronize attacks.
  7. Once this time is reached, Castov drops Wuauieop.exe (Trojan.Castdos).
  8. Castdos begins to overload the DNS server with DNS requests, effectively performing a DDoS attack affecting multiple websites.

Stuxnet 0.5: How It Evolved


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 the oldest known Stuxnet variant analyzed to date. This variant stopped compromising computers on July 4, 2009 and stopped communicating with its command-and-control (C&C) servers on January 11 of the same year. The compile timestamps found within most of the code appear unreliable and generally are in the range of 2001.

The main differences between Stuxnet 0.5 and later versions are as follows:

  1. Later versions significantly increased their spreading capability and use of vulnerabilities
  2. Replacement of Flamer platform code with Tilded platform code
  3. Later versions adopted an alternative attack strategy from uranium enrichment valve disruption to centrifuge speed modification

1. Significantly increased spreading capability and use of vulnerabilities

Stuxnet significantly increased its spreading capabilities and aggressiveness by introducing multiple vulnerabilities. The only method of replication identified in Stuxnet 0.5 was through the infection of Siemens Step 7 project files. Stuxnet 0.5 does not exploit any Microsoft vulnerabilities to move from one computer to the next unlike version 1.x.

Tables 2 and 3 show the differences in exploited vulnerabilities and spreading mechanisms.

Table 2. Evolution of the Stuxnet exploits

Table 3. Evolution of the Stuxnet replication mechanisms

2. Migration from Flamer toward Tilded

Until now Stuxnet was believed to be a project developed by people with access to Flamer components and not necessarily the whole Flamer platform source code. The discovery of Stuxnet 0.5 shows that Stuxnet’s developers had access to the complete Flamer platform source code.

Stuxnet 0.5 is partly based on the Flamer platform whereas 1.x versions were based primarily on the Tilded platform. Over time, the developers appear to have migrated more towards the Tilded platform. The developers actually re-implemented Flamer platform components using the Tilded platform in later versions.

Both the Flamer and Tilded platform code bases are different enough to suggest different developers were involved.

3. Adopting an alternative attack strategy

Stuxnet version 1 contained code that targeted Siemens 315 PLCs, which controlled the speed of spinning centrifuges, and also an incomplete code sequence that targeted Siemens 417 PLCs with unknown consequences at that time.

We have discovered a full working version of the attack on Siemens 417 PLCs in version 0.5, the purpose of which is to modify the valve operation during uranium enrichment.

Stuxnet 0.5 only contains the 417 attack code and does not contain the 315 attack code.

Detailed information on the 417 attack code can be found in the blog Stuxnet 0.5: Disrupting Uranium Processing at Natanz.


The discovery of Stuxnet 0.5 further clarifies the evolution of Stuxnet. To put this evolution in context, we have mapped key dates of Stuxnet development against low-enriched uranium (LEU) production levels at Natanz. Interesting events are dips in feed or production amounts and lower levels of production given the same or greater feed amounts (gaps between the two lines).

Figure 1. LEU production (Source: ISIS)

The existence of unrecovered versions of Stuxnet, both before version 0.5 and especially between versions 0.5 and 1.001, are likely. Partial components of Stuxnet discovered in 2010 still remain unmatched to known versions of Stuxnet. A summary list of the key differences between known versions is shown in Table 4.

Table 4. Stuxnet comparison between versions

More information on key aspects of Stuxnet 0.5 can be found in the following blogs, video, and technical white paper:

For further details on Stuxnet 0.5 you can download a copy of our white paper.

Stuxnet 0.5: The Missing Link

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
  • Built using the Flamer platform
  • Spreads by infecting Step 7 projects including on USB keys
  • Stops spreading on July 4, 2009 
  • Does not contain any Microsoft exploits
  • Has a full working payload against Siemens 417 PLCs that was incomplete in Stuxnet 1.x versions

As with version 1.x, Stuxnet 0.5 is a complicated and sophisticated piece of malware requiring a similar level of skill and effort to produce.

Despite the age of the threat and kill date, Symantec sensors have still detected a small number of dormant infections (Stuxnet 0.5 files found within Step 7 project files) worldwide over the past year.

Figure 1. Dormant infections detected in the past year

The following video explains how Stuxnet 0.5 attempts to sabotage the Natanz uranium enrichment facility.

Default Chromeless Player


More information on key aspects of Stuxnet 0.5 can be found in the following blogs and technical whitepaper:

For further details on Stuxnet 0.5 you can download a copy of our whitepaper.


Symantec would like to thank the Institute for Science and International Security (ISIS) for their continued assistance in understanding centrifugal uranium enrichment systems.

Stuxnet 0.5: Disrupting Uranium Processing at Natanz

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 during an attack so that the operators are unaware that the system is not operating normally. It will also prevent modification to the valve states in case the operator tries to change any settings during the course of an attack cycle.

Figure 1. Summary of the Stuxnet 0.5 attack strategy

Given Stuxnet 0.5 is an earlier version of Stuxnet, the 417 attack strategy was the original strategy, and likely abandoned in favor of modifying the centrifuge speeds instead—a technique used in Stuxnet 1.x versions.

Stuxnet 1.x contained missing pieces of code, which are present in Stuxnet 0.5. These pieces of code perform the necessary fingerprinting of the target system before deploying the 417 attack strategy and build a critical PLC data block (DB8061). Therefore, we can now fully describe the intended 417 attack strategy.

Fingerprinting target system configuration

This version of Stuxnet extensively fingerprints the target system to determine whether it is in the right location before it will activate the payload. To make this determination, Stuxnet checks if the infected system is running Step 7 software and parses the symbol table of the target system. The symbol table holds identification labels for each physical device in the target system. For example, each valve, pump, and sensor will have a unique identifier. The symbol labels loosely follow the ANSI/ISA-5.1 Instrumentation Symbols and Identification standard, which is used in piping and instrumentation diagrams (P&ID).

Figure 2. An example of a P&ID diagram from a uranium enrichment facility in Iran (Source: PressTV)

The following table summarizes what devices and labels Stuxnet looks for within the symbol table.

Table 1. Device types and labels targeted by Stuxnet

The labels for each of these devices follow the following specific format:

For example, for a valve in module A21, in cascade eight, associated with centrifuge 160, the label would be PV-A21-8-160.

The logic used to parse these strings yields additional interesting clues. For example, the cascade module must be between A21 and A28; this matches the known configuration of cascade modules at Natanz, Iran. Stuxnet expects a maximum of 18 cascades per module, 164 centrifuges grouped into 15 stages per cascade, which again matches the published configuration at Natanz, Iran.

Furthermore, the number of centrifuges is expected to be distributed within stages, as shown in the following table.

Table 2. Configuration of process stages and centrifuges

Within each stage, centrifuges can be further grouped into sub-clusters of four.

During fingerprinting, Stuxnet keeps a counter for each device that matches the expected configuration. Once the counter surpasses a particular threshold, Stuxnet considers the system that is being fingerprinted to match the target system configuration and will inject the attack PLC code. Stuxnet also determines which six cascades out of the possible 18 are the highest value targets and saves this information along with device addresses and configuration information into data block DB8061.

Attack process

Similar to version 1.x of Stuxnet, the 417 PLC device attack code consists of a state machine with eight possible states. The states conduct an attack by closing valves within six of the possible 18 cascades.

Figure 3. 417 PLC device attack code state flow diagram

  • State 0 – Wait: Perform system identification and wait for the enrichment process to reach steady-state before attacking (approximately 30 days).
  • State 1 – Record: Take peripheral snapshots and build fake input blocks for replaying later.
  • State 2 – Attack centrifuge valves: Begin replaying fake input signals. Close valves on most centrifuges with the exception of the initial feed stage valves.
  • State 3 – Secondary pressure reading: Open valves in the final stage of a single cascade to obtain a low pressure reading.
  • State 4 – Wait for pressure change: Wait for desired pressure change or time limit. This can take up to two hours.
  • State 5 – Attack auxiliary valves: Open all auxiliary valves except valves believed to be near the first feed stage (stage 10). Waits for three minutes in this state.
  • State 6 – Wait for attack completion: Waits for six minutes whilst preventing any state changes.
  • State 7 – Finish: Reset and return to state zero.

By closing almost all valves except the initial feed stage valves, UF6 will continue to flow into the system. This act alone may cause damage to the centrifuges themselves. However, the attack expects the pressure to reach five times the normal operating pressure. At this pressure, significant damage to the uranium enrichment system could occur and the UF6 gas could even revert to a solid.

Whether the attack succeeded in this manner or not remains unclear. Even if the attack did succeed, the attackers decided to switch to a different strategy, of attacking the speed of the centrifuges themselves instead, in Stuxnet 1.x versions.

Symantec would like to thank the Institute for Science and International Security (ISIS) for their continued assistance in understanding centrifugal uranium enrichment systems.

More information on key aspects of Stuxnet 0.5 can be found in the following blogs, video, and technical white paper:

For further details on Stuxnet 0.5 you can download a copy of our white paper.