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.

Are the 2011 and 2013 South Korean Cyber Attacks Related?

In the past four years there have been several major cyber attacks against South Korea. We have identified a particular back door (Backdoor.Prioxer) that surfaced during the 2011 attacks. A modified version of this back door was also discovered during the 2013 attacks. The back door is based on publicly available code, but there are some indications that the same individuals are responsible for the 2011 and 2013 versions, pointing towards a possible connection between the two attacks.

The first documented major attack was in July, 2009. The attacks began on July 4, Independence Day in the United States, and consisted of a distributed denial-of-service (DDoS) attack against various Korean and US government and financial websites. A second wave of attacks occurred on July 7 and a third wave on July 9. The malware used to launch the attacks was Trojan.Dozer, which was spread through e-mail. Trojan.Dozer contained a time bomb in its code, triggered on July 10. This time bomb would overwrite various types of files on the hard drive and then overwrite the first one megabyte of the hard drive, destroying the MBR and partition table. The hard drive was overwritten with the string, “Memory of the Independence Day.”

The second major attack occurred on the March 4, 2011. This attack was again a DDoS and again, against U.S. and South Korean government institutions. The malware used was Trojan.Koredos. This malware also overwrote a specified set of file types and destroyed the MBR.  During investigations into these attacks, a back door Trojan called Backdoor.Prioxer was discovered. The back door was quite sophisticated and infected files in a discreet manner.  You can see our previous blog, which describes this technique in detail.

The third attack occurred on March 20, 2013. This attack does appear to have used only hard drive overwrites, and no DDoS attacks. Trojan.Jokra overwrites the MBR and then the contents of the hard drive, independent of file format. It then looks for any mapped network drives and attempts to overwrite those as well. There appears to be multiple installation vectors, including e-mail and patch management. Patch management is an auto-update system that was compromised to deliver the malware.

Similar to the 2011 Trojan.Koredos investigation, we discovered a new version of Backdoor.Prioxer (labeled Backdoor.Prioxer.B) while examining files from computers compromised with Trojan.Jokra. This new version shares the same the same C&C base protocol, but does not proxy IRC communications as in the older version. When we investigated this file further, in an attempt to determine how it was installed onto victims’ computers, we established a link with Trojan.Jokra.

Making connections
The Trojan.Jokra samples are obfuscated by the Jokra packer. The Jokra packer was also used to obfuscate a downloader (encountered in August of 2012 with an MD5 of 50e03200c3a0becbf33b3788dac8cd46). This downloader was seen to download Backdoor.Prioxer from the following location:[REMOVED]/update_body.jpg

The link between Trojan.Jokra and Backdoor.Prioxer.B is also based on the Jokra packer. An additional malware sample (Trojan.Gen.2), located in the 2013 incident, which is packed with the Jokra packer, contains a build path string. This string describes where the sample was compiled on disk. 

The path is:

Z:\Work\Make Troy\3RAT Project\3RATClient_Load\Release\3RATClient_Load.pdb

A Backdoor.Prioxer.B sample found in the same investigation also contains a build string:

Z:\Work\Make Troy\Concealment Troy\Exe_Concealment_Troy(Winlogon_Shell)\Dll\Concealment_Troy(Dll)\Release\Concealment_Troy.pdb

Clearly, the two separate pieces of malware were compiled from the same build source directory, Z:\work\Make Troy.

Work or fun?
If the Jokra packer is limited to the one group, then the connections between Backdoor.Prioxer.B and Trojan.Jokra are reliable. We believe that this packer is not publicly distributed because the number of detections for it are very low, are limited to Korea, and so far have only covered Jokra, the downloader, and the back door Trojan containing the “Z:” build string. This low prevalence is an indication that the packer is in use by only one group.

The connection between Backdoor.Prioxer.B and the 2011 attacks is not as clear cut. It is certainly suspicious that versions of Backdoor.Prioxer have been present during both attacks, but it could be explained away as the Trojan merely being discovered during the course of an investigation and not actually being related to the attacks. However, we think it is likely that the samples are related, given the Jokra connection.

Finally, the build path itself used in the Backdoor.Prioxer sample is informative. The path is “Z:\work”, and it seems unlikely that an independent hacktivist would use a folder labeled “work” to store their Trojan. For them, the development of a Trojan is not work, it is fun. The type of person who stores their code in a work folder is someone who is doing this professionally. The implication is that someone has been paid or ordered to perform these attacks, either as a contractor or as an employee.


Backdoor.Prioxer!inf: “Accidentally” the Stealthiest File Infector Ever!

Following the Trojan.Koredos incident, we stumbled upon a very interesting back door Trojan—Backdoor.Prioxer. We received this Trojan from a source that was also infected by Trojan.Koredos, and although we cannot prove a direct link between the two, we believe it is likely that both threats derive from the same source.

You can read more details about Trojan.Koredos in our previous blog entry. Briefly, Koredos is a threat that was used in a targeted attack against several Korean websites. The Trojan shows a modular architecture and a level of sophistication that suggests the attack is coming from a well-established malware source.

Why is Prioxer interesting? Well, at first glance it looks like a normal back door Trojan, which, in fact, it is. The installer drops a .dll file that is the botnet component. The bot operates via IRC in order to exchange commands and data with the command-and-control (C&C) server. The threat files are not even encrypted or obfuscated. Furthermore, in order to survive a reboot of the computer, it infects a Windows system .dll file. The .dll file is then loaded whenever Windows starts and the payload of the threat loads the botnet .dll file again. Nothing new there, save one thing of particular note—the infected files are completely invisible!

Very invisible infection—an accident?
Prioxer does not use rootkit functionality, nor does it use any code in kernel mode. How is it possible to achieve such invisibility from a simple application? It succeeds in evading a number of security tools, with the exception of one anti-rootkit tool that is able to extract the infected .dll file by using its own file browser utility.

A closer look at the infector code solves the mystery:

Figure 1: The code determines whether the disk volume is FAT32 or NTFS and runs its own custom file system interpreter.

The main dropper has its own built-in parser for the FAT32 and NTFS file systems. The code opens the C volume in raw mode, performs a manual read of disk sectors, and then manually parses the disk data in order to understand the file system structure and find where in the disk the infection target .dll file is located (and perform a raw write operation to infect it). This whole functionality normally resides in the file system layer in the kernel. An application specifies a file path and the file system driver (NTFS on most Windows computers) locates the file data on the disk. Prioxer is able to do all of this by itself, bypassing the file system layer completely and accessing the disk directly.

By infecting the .dll file in raw mode, the Trojan is able to bypass filters or restrictions on the file itself. This is not really new or ground breaking because threats possessing raw access to hardware resources are quite common.

Nonetheless, there is another interesting thing that comes into play: caching. The NTFS file system driver maintains a cache of the most frequently read files (and a Windows .dll file is likely to belong in this category) in order to speed up performance. Whenever you modify a file that is cached, NTFS should update the memory cache to reflect the file changes. Instead, Prioxer writes to disk, directly bypassing the file system layer completely. In this way, NTFS does not know that a system .dll file present in the cache has been modified and will not update the cached version of the file.

Figure 2: The infected .dll is on the disk, but the NTFS cache is providing the clean .dll instead, rendering the infection invisible.

This leads to an inconsistent situation. The cached .dll file is the clean one, but the infected one is actually on the disk. This means that if you try to access the infected file from any application, or even from Kernelmode drivers, you will access it through the NTFS layer and NTFS will return the data of the clean version of the .dll file. Therefore, the real infected .dll file is on the disk and invisible!

Notice that this behaviour is not a bug, nor is it a flaw in the NTFS design. The cache is simply working the way it is supposed to. The infected file can of course be accessed by any utility that can operate at a lower level than the NTFS file system. Also, the cache is not permanent, so the system may eventually end up refreshing the cached infected file, rendering it back to visible (for example after a memory stress condition, or simply after reboot).

Figure 3: The infection code in the targeted DLL.

Given that Prioxer does not really try to actively hide itself, it is possible that this invisibility feature was not intended by the malware authors. It is just a handy side effect of misusing the system’s functionality. However, this example shows that this technique could be very effective if abused, and it can be run from Usermode without requiring the use of kernel drivers (which rootkits normally need).

The bot
The payload is a simple bot that operates via IRC protocol. The bot can exchange data with the C&C server in the form of chat messages, like any other standard IRC backdoor. I joined the C&C server and got some interesting information:

 PASS [removed]
NICK [nick]
USER nobody unknown unknown :noname
:MyWebServer 375 [nick] :- MyWebServer Message of the Day -
:MyWebServer 372 [nick] :- This is ircd-hybrid MOTD replace it with something better
:MyWebServer 376 [nick] :End of /MOTD command.
:MyWebServer 351 [nick] hybrid-7.2.3(SVN). MyWebServer :egIKMZ6 TS6ow

:MyWebServer 265 [nick] :Current local users: 46  Max: 53
:MyWebServer 266 [nick] :Current global users: 46  Max: 53

:MyWebServer 321 [nick] Channel :Users  Name
:MyWebServer 322 [nick] #mail01 5 :
:MyWebServer 322 [nick] #god8 1 :
:MyWebServer 322 [nick] #god2 8 :
:MyWebServer 322 [nick] #god3 1 :
:MyWebServer 322 [nick] #god1 2 :
:MyWebServer 322 [nick] #god4 1 :
:MyWebServer 322 [nick] #kkk3 4 :
:MyWebServer 322 [nick] #kkk2 19 :
:MyWebServer 322 [nick] #kkk1 8 :
:MyWebServer 323 [nick] :End of /LIST

:MyWebServer 251 [nick] :There are 0 users and 47 invisible on 1 servers
:MyWebServer 254 [nick] 9 :channels formed
:MyWebServer 255 [nick] :I have 47 clients and 0 servers
:MyWebServer 265 [nick] :Current local users: 47  Max: 53
:MyWebServer 266 [nick] :Current global users: 47  Max: 53
:MyWebServer 250 [nick] :Highest connection count: 48 (48 clients) (265 connections recei

STATS :MyWebServer
:MyWebServer 212 [nick] JOIN 313 1589 :0
:MyWebServer 212 [nick] NICK 270 4658 :0
:MyWebServer 212 [nick] PASS 271 3794 :0
:MyWebServer 212 [nick] PRIVMSG 4238 2345746 :0
:MyWebServer 212 [nick] USER 269 8070 :0
:MyWebServer 212 [nick] WHOIS 234 8520 :0 

Figure 4: Some snippets of the data log from the IRC C&C server. The USERS command shows the number of users over a period of time. LIST shows the available channels and how many users are on them. STATS shows how many times commands have been used in the server.

I issued standard IRC commands to obtain lists of statistics and the number of users. From the STATS command we can see some global counters of how many times the commands have been executed (the second number after the command name). We can see that JOIN, NICK, PASS, and USER commands (normally used by bots to authenticate themselves and join a channel) are more-or-less consistent, and are in the order of several thousand. Of course, this is the total number including non-bots, so it is reasonable to estimate that the total size of this botnet could be roughly 100, which makes it relatively small. This doesn’t come as a surprise, since we mentioned a possible link with the Koredos threat. Knowing that it was a targeted attack, it is unlikely to be widespread.

Although we are focusing on its invisibility, the threat does not seem to do this intentionally, as mentioned above, nor does it take any action to actively hide itself. Therefore, the cache trick only works for a limited amount of time. As a defence, a computer can be simply rebooted and then the malicious infection will be visible and detected by security products. If the computer has been running long enough after infection, there are also good chances that the infection will be visible due to a refreshed cache.

It’s a clever, though likely unintentional, ruse. Regardless, customers that update to the latest virus definitions will be protected from this threat.

Trojan.Koredos Comes with an Unwelcomed Surprise

Recent Distributed Denial of Service (DDoS) attacks on a number South Korean websites have been in news for the past week. The threat responsible for carrying out these attacks is Trojan.Koredos.

This attack is reminiscent of another attack, launched on July 4th, 2009 against the U.S. and South Korean governments, as well as financial and media websites. For now, the attack has subsided and the affected sites can be accessed without any issues. However, the computers have not been cleaned for the Trojan.Koredos infection will be greeted with a surprise well after the initial infection, which we will detail in this blog.

Attacks such as this usually involve a command and control (C&C) server that sends commands to the compromised computers, resulting in systematic and coordinated attacks. In this case, the commands do not come from a C&C—they are hidden inside the threat.

There are many components involved in the attack, and that alone indicates some level of sophistication. Of those files, the destructive behavior is carried out by the s[RANDOM LETTERS]svc.dll file. While we have seen several variants of this .dll, the end result is the same—the master boot record (MBR) of the compromised computer is destroyed.

Some variants scan the fixed drives of compromised computers for files with various extensions, which are used by software predominantly used in Korea (i.e. .alz, .gul, and .hwp). This strongly suggests the threat targets computers located in Korea.

Figure 1 –  Heatmap showing Trojan.Koredos infections.

Figure 2 – The threat searching for file extensions.

The threat overwrites the files with all zeros. Additionally, if the file size is larger than or equal to 10,485,760 bytes, the threat simply deletes the files. If a file does not meet the previous condition, the threat creates a .cab file using the original file name, and deletes the original file. In other cases deleted files can be restored using various methods, but since the threat overwrites the files with zeros, the original file cannot be restored.

The threat destroys the MBR of all drives if one of the following conditions is met:

  • The %System%\noise03.dat file is missing. The noise3.dat file is a part of Trojan.Koredos that contains a number 7 within it. This is the number of days the destruction functionality gets triggered. One interesting part is that the number can be overwritten, though the threat can only distinguish up to 10. (Any number over 10 will be interpreted as 7.) This means the maximum life of the compromised computer is 10 days.

    Figure 3 – Creating the noise03.dat file with the date and time of infection and days to attack.

  • A %System%\dnsec.dat file exists, and its first four bytes are all zero. The dnsec.dat file is also a component of W32.Koredos that works with other threat components.

    Figure 4 – Overwriting files with zeros and checking that the file size is greater than 10,485,760 bytes.

  • The current date and time is later than 7 days, or equal to the number in %SYSTEM%\noise03.dat at the time of first infection.
  • The current date and time is equal to or longer than 7 to 10 days after first infection. As explained previously, the number can manually overwritten in the %System%\noise03.dat file, but the operating system will be destroyed.

    Figure 5 – Checking that 7 to 10 days have passed.

In short, the infected computers can live up to 10 days if they are not cleaned. Symantec provides protection against the threat. Please make sure you keep virus definitions up-to-date to keep your valuable data safe from the destructive threat.

Thanks to Masaki Suenaga for his contributions to this blog.