DragonOK Updates Toolset and Targets Multiple Geographic Regions


Category: Unit 42

Tags: , ,

This post is also available in: 日本語 (Japanese)

The DragonOK group has been actively launching attacks for years. We first discussed them in April 2015 when we witnessed them targeting a number of organizations in Japan. In recent months, Unit 42 has observed a number of attacks that we attribute to this group. Multiple new variants of the previously discussed sysget malware family have been observed in use by DragonOK. Sysget malware was delivered both directly via phishing emails, as well as in Rich Text Format (RTF) documents exploiting the CVE-2015-1641 vulnerability (patched in MS15-033) that in turn leveraged a very unique shellcode. Additionally, we have observed instances of the IsSpace and TidePool malware families being delivered via the same techniques. While Japan is still the most heavily targeted geographic region by this particular actor, we also observed instances where individuals or organizations in Taiwan, Tibet, and Russia also may have been targeted.


We observed two unique techniques of infiltration for this particular campaign:

  1. Phishing emails being sent with malicious executables directly attached
  2. Malicious RTF files which exploit CVE-2015-1641.

The phishing emails had the following characteristics:

Email Subjects

  • Pickup at the Juanda Airport (1-Sep)
  • ポイントプレゼントのお知らせ [Roughly Translated: Point gift announcement]
  • 20周年記念パーティー [Roughly Translated: 20th Anniversary Party]
  • 参加者の10周年記念同窓会一覧 [Roughly Translated: List of participants' 10th anniversary alumni association]
  • 子供の調査連れ [Roughly Translated: Children's investigation]
  • G20 report
  • 記念日の再会 [Roughly Translated: Anniversary reunion]
  • 最新の人事異動通知 [Roughly Translated: Recent personnel change notice]

Attachment Filenames

  • G20 report.exe
  • exe
  • List of Participants.exe
  • Registration form.exe

These emails targeted the following industries in Japan:

  • Manufacturing
  • Higher Education
  • Energy
  • Technology
  • Semiconductor

The malicious RTF files in question leverage a very specific shellcode to drop and execute the malicious payload, as well as a decoy document. Decoy documents are legitimate benign documents that are opened after the malicious payload is delivered, thus ensuring that the victim does not become suspicious because their expected document opened as expected.

Two samples were found to include the decoy document show in Figure 1.

The title of the document roughly translates to “Ministry of Communications & Departments Authorities Empty Sites and Hosted Public Works Source Clearance Photos”. The use of traditional Chinese indicators the target likely residing in either Taiwan, Hong Kong, or Macau. However, based on the Taiwanese subject matter in this document, we can safely come to the conclusion that the intended victim was of Taiwanese origin. These samples delivered an updated version of the IsSpace malware family, which was discussed previously in a watering hole attack targeting an aerospace firm. IsSpace is an evolved variant of the NFlog backdoor, which has been used by DragonOK in the past.


Figure 1 Taiwanese decoy document

Two other samples were identified that used a Tibet-themed decoy document. The document in question (Figure 2) appears to be an internal newsletter from the Central Tibetan Ministry, as suggested by the logo used as well as the content of the document itself.  This document indicates that the malware may have been targeted towards an individual that is interested in Tibetan affairs. These particular samples were unique in that they delivered the TidePool malware family that we reported on in May of 2016. We have not previously observed DragonOK using TidePool in attacks.


Figure 2 Tibetan decoy document containing internal newsletter

We also identified an additional sample using decoy targeting Taiwanese victims (Figure 3), which deployed a newer sysget sample.


Figure 3 Taiwanese-targeted decoy document

Other new samples associated with this group used a Russian language decoy document (Figure 4.) The decoy document in question discusses the GOST block cipher, which was created by the Russian government in the 1970’s. The combination of Russian language and Russian-specific subject matter indicates that the intended victim speaks Russian and may be interested in encryption. Like the previously discussed Tibetan decoy documents, these samples also delivered the TidePool malware family.


Figure 4 Russian decoy document discussing the GOST block cipher

Finally, multiple samples used a traditional Chinese language decoy document that discussed a subsidy welfare adjustment program. The use of traditional Chinese indicators the target likely residing in either Taiwan, Hong Kong, or Macau. Similar to other attacks witnessed, a variant of the sysget malware family is installed by these files.


Figure 5 Decoy document discussing subsidy welfare adjustment program

Malware Deployed

In looking at the various malware samples used in attempted attacks, the following four families were identified:

  • Sysget version 2
  • Sysget version 3
  • TidePool
  • IsSpace

We broke the sysget classification into multiple variants when we found that a number of changes have been made since our April 2015 report. Major distinctions between the versions of sysget include the following:

Sysget version 2

  • Removed support for persistence on Windows XP
  • Reworked the URIs used for network communication
  • Added additional layers of encryption for network communication and stored configuration files
  • Switched from RC4 to AES-128

Sysget version 3

  • Numerous anti-debug and anti-vm procedures added
  • Encrypted URIs in network communication with an initial static key

In addition, we observed a sysget version 4 that was discovered in another sample during our research. This version is not attributed to a specific attack against an organization.

Indicators of compromise related to sysget version 4 and other samples not directly attributed to specific attacks may be found in the Appendix of this blog post.  Additionally, more information about the various sysget variants may also be found in the Appendix.

The TidePool samples encountered are consistent with the samples previously discussed. I encourage readers to view our previous blog post to learn more about the intricacies of this particular malware family.

The IsSpace malware sample, however, looks to have been updated since last we wrote on it. While the available commands from the command and control (C2) server remains the same, the URI structure of the network communication has been modified. Additionally, the installation routine for this malware family has been updated to be far less complex than previous discussed versions, favoring PowerShell to set persistence and forgoing the previously used side-loading technique. A more detailed analysis of the new instances of IsSpace may be found at the end of this blog post in the Appendix.


A number of unique domains were employed by the various Trojans used in these attacks. For the numerous instances of sysget we observed, the following domains were observed for their C2:

  • kr44.78host[.]com
  • gtoimage[.]com
  • gogolekr[.]com

All of the above domains have Chinese WHOIS registrant details. Additionally, the gotoimage[.]com and trend.gogolekr[.]com are both registered to the same registrant and resolve to the same netblock of

The instances of TidePool identified communicated with the following C2 servers:

  • europe.wikaba[.]com
  • russiaboy.ssl443[.]org
  • cool.skywave[.]top

These domains did not have many definitive relations with the sysget C2 servers except for cool.skywave[.]top, which shared a unique registrant email with the sysget C2 server of trend.gogolekr[.]com. Additionally, the geographic region of the resolved IPs was consistent with the previous set, as they all resolved to various regions in southeast Asia. Specifically, the domains resolved to China, Korea, and Taiwan in the past six months.

The IsSpace samples resolved to the following domains:

  • www.dppline[.]org
  • www.matrens[.]top

These domains had no apparent connections to the previously discussed C2 servers, other than the fact that they resolved to Korea and Hong Kong respectively. Additionally, the registrar of ‘Jiangsu Bangning Science and technology Co. Ltd.’ was used for a large number of domains. A full graph of the relations between the various attacks is shown in Figure 6.


Figure 6 Relationships between attacks


The DragonOK group are quite active and continue updating their tools and tactics. Their toolset is being actively developed to make detection and analysis more difficult. Additionally, they appear to be using additional malware toolsets such as TidePool. While Japan is still the most-targeted region by this group, they look to be seeking out victims in other regions as well, such as Taiwan, Tibet, and Russia.

Palo Alto Network customers are protected against this threat in the following ways:

  • Malware families are tagged in AutoFocus via a variety of tags (TidePool, NFlog, Sysget)
  • The following IPS signatures detect malicious network traffic:
    • IPS signature 14365 (IsSpace.Gen Command And Control Traffic)
    • IPS signature 14588 (Suspicious.Gen Command And Control Traffic)
    • IPS signature 13574 (NfLog.Gen Command And Control Traffic)
    • IPS signature 13359 (Nflog.Gen Command And Control Traffic)
  • All samples are appropriately marked malicious in WildFire


CVE-2015-1641 Exploit and Shellcode

This particular group uses a very specific shellcode payload when exploiting CVE-2015-1641. This CVE is memory corruption vulnerability which allows for arbitrary code execution in various versions of Microsoft Office, including 2007, 2010, and 2013.

The shellcode begins by dynamically loading a small number of API functions from kernel32. A number of hashes are included that represent function names, which have a rotate right 7 (ROR7) operation applied against them before being XORed against a key of “\x10\xAD\xBE\xEF”. The ROR7 operation is a very common technique in shellcode to obfuscate what functions are being called. The author added the XOR operation to add another layer of obfuscation.


Figure 7 API function hashes contained in shellcode

After the shellcode loads the necessary API functions, it proceeds to seek out a number of markers that will mark the beginning and ending of both an embedded malicious payload, as well as a decoy document.

The malicious executable is marked with a starting point of 0xBABABABABABA and an end marker of 0xBBBBBBBB. The decoy document is found immediately after the end of the malicious payload, and has an end marker of 0xBCBCBCBC. Both executables are encrypted with a 4-byte XOR key. Should the original data contain 0x00000000, it will not have the XOR applied against it.

The malicious payload is XORed against a key of 0xCAFEBEEF and the decoy document is XORed against 0xBAADF00D. The following script may be applied against the RTF document to extract both the malicious payload and the decoy:

When both files are decrypted, they are written to the following location in the %TEMP% directory:

  • ../..exe
  • ../..doc

Note the initial ‘..’, which represents the parent directory of %TEMP%. This coupled with the unusual names of ..exe and ..doc make this particular shellcode very unique, which is one way we have attributed these samples to the same group. After the samples have been written, they are executed via calls to WinExec.

Sysget v2 Analysis

One of the fundamental changes witnessed in the second iteration of sysget is removing support for Windows XP and lower. Other changes include modifications to the URIs used for network communication.

Like the original version of sysget, sysget v2 still uses a named event of ‘mcsong[]’ to ensure a single instance is running at a time. It proceeds to make attempts at copying itself to the %STARTUP%/notilv.exe path. However, it uses COM objects to perform this action that is not available in Windows XP, which prevents the malware from installing itself to this location. While the remainder of the malware operates as expected, it will not survive a restart of the system.

Sysget proceeds to make an attempt at reading the following configuration file. This filename and path has changed since the original version, and is consistent in the subsequent versions.

  • %APPDATA%/vklCen5.tmp

This configuration file holds both a unique victim identifier, as well as a key that is used to encrypt HTTP traffic. It is encrypted using the AES-128 encryption algorithm, using a static key of ‘734thfg9ih’. Using AES-128 is a change from the previous version, where RC4 was used for all encryption operations. The following Python code may be used to decrypt this file:

When executed against an example configuration file, we see the following output, which includes the two pieces of data noted previously:

The encryption of this configuration file is a new feature that was not present in the original version of sysget.

If this file is not present on the system, the malware will attempt to retrieve the necessary information via a HTTP request. The following request is made to the remote command and control server. Note that the full URI is statically set by the malware sample.

The server responds with the following data, encrypted using the same technique previously described with a static key of ‘aliado75496’. Once decrypted, we see the following example data being sent back to sysget:


The first string is used as a key for all subsequent network communication. The second string is treated as a unique victim identifier. This data is encrypted using the key of ‘734thfg9ih’ and written to the %APPDATA%/vklCen5.tmp file.

After this information has been obtained, the malware proceeds to enter its command and control loop. An HTTP request such as the following is made to the remote server. Note that the ‘mid’ GET variable holds the MD5 hash of the previously obtained victim identifier. The remaining data in the URI is hardcoded.

The response is encrypted using the unique key that was obtained previously. Should the response contain ‘Fatal error’ unencrypted, no further actions are taken by the malware sample. Once decrypted, the response may have one of the following two choices, and their accompanying purpose. Alternatively, if a raw command is provided, the malware will execute it and return the results.

Command Description
goto wrong "[file_path]";\n Read a specific file and return its contents.
goto right "[filename]" "[identifier]" Write a given file. The identifier is used to retrieve the file’s contents in a subsequent HTTP request.

When the ‘goto wrong’ request is made, a HTTP POST request is made to the following URI. In the following URI, the ‘list’ parameter contains the MD5 hash of the victim’s identifier.


The contents of this POST request contains the victim’s identifier, as well as the file’s contents encrypted with the unique key. The first 50 bytes are reserved for the victim identifier, as shown below:

Once decrypted, the data contains both the filename, as well as the contents of that file.

If the ‘goto right’ command is used, the malware will make a subsequent request to the following URI. The ‘cache’ variable holds the unique identifier that was provided in the ‘goto right’ command.


Once the file contents are obtained, they are written to the specified filename in the %STARTUP% folder.

When a raw command is received, the malware will upload the results to the following URI via a POST request:


An overview of the network communications exhibited by sysget version 2 can be seen in the figure below.


Figure 8 Sysget version 2 command and control flow

Sysget v3 Analysis

Some of the biggest changes witnessed in version 3 of sysget includes numerous anti-debug and anti-vm detections added, as well as the encryption of the URIs used for network communication.

When the malware initially executes, it performs the following checks to ensure it is not being debugged and not running in a sandbox or virtualized environment.

Should these checks return false, the malware proceeds to enter its installation routine. The malware originally copies itself to a temp file in the %TEMP% directory with a filename prefix of ‘00’. It proceeds to append 4194304 bytes of randomly chosen data to the end of this file. The increased filesize may have been added by the author in an attempt to thwart sandboxes that impose filesize limits on what is saved and/or processed. Finally, the malware copies the original file from the tmp path to the %STARTUP%/winlogon.exe path using the same technique witnessed in version 2. Sysget then writes a batch script in the %TEMP% folder with the following contents, cleaning up the original files and spawning the newly written winlogon.exe executable:

After installation, sysget will attempt to read the same %APPDATA%/vklCen5.tmp file as witnessed in the previous variant. A number of strings within the malware, including the ‘734thfg9ih’ key used to encrypt this file, have been obfuscated via a single-byte XOR of 0x5F.

Similar to previous versions, should this vklCen5.tmp file not be present on the victim machine, it will make an external HTTP request to retrieve the necessary information. The following request is made by the malware. Readers will notice that the URI has changed from previous versions in a number of ways. This version of sysget looks to always make requests to 1.php, which is hardcoded within the malware itself. Additionally, all HTTP URIs in this version of sysget are encrypted. The initial GET request made to retrieve the victim identifier and unique key is encrypted with a key of ‘Cra%hello-12sW’. The subsequent response containing this information is then decrypted using a key of ‘aliado75496’, which is consistent with previous versions.

When the URI above is base64-decoded and subsequently decrypted, we see the following:


This URI is consistent with the previous sysget variant. It would seem the authors simply have added this layer of encryption to hinder efforts to block the malware via network-based detections.

After this initial request to retrieve the victim identifier and unique key, sysget enters its command and control loop. This process is consistent with the previous version, but simply has the extra layer of encryption used for the URIs.

Sysget v4 Analysis

The fourth variant of sysget is nearly identical to the third variant. However, the main difference lies in the URIs used for network communication. In addition to the expected encryption of the URIs, this variant also mangles the base64 encoding that is performed afterwards. The following Python script may be used to de-obfuscate the base64 URI found in this variant:

Additionally, the C2 URI changes in this variant, from 1.php to 5.php

IsSpace Analysis

When initially run, IsSpace will create a unique event to ensure a single instance of the malware is running at a given time. This event name appears to be unique per the sample, as multiple samples contained unique event names. The following event names have been observed in the samples that were analyzed:

  • e6al69MS5iP
  • v485ILa3q5z

IsSpace proceeds to iterate over the running processes on the system, seeking out the following two process substrings:

  • uiSeAgnt
  • avp.exe

The uiSeAgnt string may be related to Trend Micro’s solutions, while avp.exe most likely is related to Kaspersky’s anti-malware product.

In the event uiSeAgnt is identified, the malware will enter its installation routine if not already running as ‘bfsuc.exe’ and proceeds to exit afterwards. Should avp.exe be identified, the malware enters an infinite sleep loop until a mouse click occurs. After this takes place, the malware proceeds as normal.

The malware then determines if it is running under Windows XP. In the event that it is, it will make a HTTP GET request to www.bing.com, presumably to ensure network connectivity.


Figure 9 IsSpace connecting to www.bing.com

If the malware is not running on Windows XP, it will attempt to obtain and decrypt any basic authentication credentials from Internet Explorer. This information is used in subsequent HTTP requests in the event a 407 (Proxy Authentication Required) or 401 (Unauthorized) response code is received during network communication.

IsSpace will then enter its installation routine, where it will first copy itself to the %LOCALAPPDATA% folder with a name of ‘bfsuc.exe’.  It then sets the proper registry key for persistence by executing the following PowerShell command:

The malware then makes an initial HTTP POST request to the configured C2 server. It will make this request to the ‘/news/Senmsip.asp’ URI. The POST data is XORed against a key of “\x35\x8E\x9D\x7A”, which is consistent with previous versions of IsSpace and NFlog. Decrypted, the POST data reads “01234567890”. The C2 server in turn will respond with the victim’s external IP address.


Figure 10 Initial IsSpace beacon

IsSpace then spawns two threads that will make HTTP requests to the following URIs:

  • /news/Sennw.asp?rsv_info=[MAC_ADDRESS]
  • /news/Sentire.asp?rsv_info=[MAC_ADDRESS]

The ‘Sennw.asp’ POST requests that are made contain collected victim information. They, like other information sent across the network, are encrypted using the previously mentioned 4-byte XOR key. When decrypted, we are provided with information such as the following:

The information, delimited via ‘#%#’, is as follows:

Value Description
60-F8-1D-CC-2F-CF MAC address External IP collected previously Internal IP address
Win7 Windows version
English(US) Language
2016-12-20 16:27:12 Timestamp
Active Malware status. May also be ‘Sleep’
xp20160628 Potential campaign identifier
IsAdmins / False User admin status

The malware is expected to return one of the following two responses to this HTTP request:

  • Active
  • Slient (Note the typo)

In the event the response of Slient is received, the malware will stop sending out HTTP requests to the ‘Sentire.asp’ URI. Conversely, if the malware is set to the ‘Sleep’ status and the ‘Active’ response is received, it will begin the ‘Sentire.asp’ requests once more.

The requests to ‘Sentire.asp’ act as the main C2 loop, requesting commands from the remote server. The commands are consistent with previously observed instances of IsSpace, however, the URIs have been modified.

Command Description Response URI
CMD Executes command Sentrl.asp
Browse List specified directory Senjb.asp
UploadFile Upload file Sensp.asp
DownLoad Download file Senwhr.asp
DelFile Delete file N/A

DragonOK Indicators

Malicious RTF Documents




C2 Domains


C2 Domains


Sysget Version 2


C2 Domains


Sysget Version 3


C2 Domains


Additional Indicators

Sysget Version 2


C2 Domains


Sysget Version 3


C2 Domains


Sysget Version 4


C2 Domains