Philip Hung Cao

Stay Hungry. Stay Foolish.

Unit 42 Identifies New DragonOK Backdoor Malware Deployed Against Japanese Targets

15 min read



Palo Alto Networks Unit 42 used the AutoFocus threat intelligence service to identify a series of phishing attacks against Japanese organizations. Using AutoFocus to quickly search and correlate artifacts across the collective set of WildFire and other Palo Alto Networks threat intelligence, we were able to associate the attacks with the group publicly known as “DragonOK.” [1] These attacks took place between January and March of 2015.

DragonOK has previously targeted Japanese high-tech and manufacturing firms, but we’ve identified a new backdoor malware, named “FormerFirstRAT,” deployed by these attackers. See the “Malware Details” section for analysis of the three RATs and two additional backdoors deployed in this persistent attack campaign.

Campaign Details

This campaign involved five separate phishing attacks, each carrying a different variant of Sysget malware, also known as HelloBridge. The malware was included as an attachment intended to trick the user into opening the malware. This included altering the icon of the executable to appear as other file types (Figure 1) as well as decoy documents to trick users into thinking they had opened a legitimate file.

figure 1 - dragon

Figure 1. Icons used by malicious Sysget attachments.

All of the Sysget files used in this campaign communicate with a single command and control (C2) server, hosted at biosnews[.]info. Sysget communicates with this server using the HTTP protocol; see the Malware Details section for specifics of the command and control traffic. All five phishing campaigns targeted a Japanese manufacturing firm over the course of two months, but the final campaign also targeted a separate Japanese high-tech organization. (Figure 2)

figure 2 - dragon

Figure 2. Five Sysget samples used to target two Japanese organizations.

Four of the five Sysget variants included a form of decoy document to trick users into believing they had opened a legitimate file rather than malware. Two of the executables used decoy documents that included information about obituaries. Figure 3 shows a GIF file containing an obituary notice for a woman, while Figure 4 shows a Microsoft Word document containing the obituary of a man.

figure 3 - dragon

Figure 3. Japanese decoy document containing an obituary notice for a woman.

figure 4 - dragon

Figure 4. Japanese decoy document containing an obituary notice for a woman.

The Sysget sample with a PDF icon created a second executable, named Adobe.exe, which simply displayed the following warning.

figure 5 - dragon

Figure 5. Error message generated by Adobe.exe

The final Sysget sample used a Microsoft Excel icon and opened an Excel document that contained cells filled with “XXXXXX.” (Figure 6)

figure 6 - dragon

Figure 6. Excel spreadsheet with Xs in multiple rows and columns.

These Sysget variants appear to be a first stage payload in these attacks. During analysis of this threat, we identified five additional backdoor tools hosted on biosnews[.]info which may be downloaded by the Sysget variants once the attackers have established a foothold.

Three of the backdoors, NFlog, PoisonIvy, and NewCT have previously been publicly associated with DragonOK. Additionally, the actors have now added the popular PlugX backdoor to their toolkit. An additional backdoor appears to be a new, custom-built tool, which we have not previously associated with DragonOK or any other attack group.  We’ve named this tool “FormerFirstRAT” as it appears to be the names used by the developers to refer to their creations. Figure 7 shows the relationship between these backdoors and their respective command and control servers.

figure 7 - dragon

Figure 7. Relationship between five additional backdoors used by DragonOK and their C2 servers in this campaign.

The following section details the functionality of the malware deployed in this campaign.

Malware Details


In this campaign, Sysget samples were attached to e-mails and used various icons to trick users into infecting their systems. The majority of these samples are self-extracting executables that contain both a malicious downloader, along with a legitimate file. When the self-extracting executable is launched, the downloader and legitimate file are typically dropped in one of the following directories and then executed:

  • %WINDIR%\Temp

When the malicious downloader is executed, it begins by creating the ‘mcsong[]’ event in order to ensure one instance is running. It then spawns a new instance of ‘C:\\windows\\system32\\cmd.exe’ with a window name of ‘Chrome-Update’. It attempts to obtain a handle to this window using the FindWindowW API call and then proceeds to send the following command to this executable. This allows the malware to indirectly execute a command within the cmd.exe process.

This registry key will ensure an executable that it later downloads is configured to persist across reboots. It then sends the ‘exit’ command to this executable, which will kill this particular process.

The malware then attempts to read the following file. This file is used to store a key that is later used to decrypt data received during network communications.

  • %temp%\ibmCon6.tmp

If the file does not exist, it will make the following GET request:

The filename and name parameters are statically set in the above request. The server responds with data similar to the following:

The first two pieces of data (’17’ and ‘gh204503254′) are then written to the ibmCon6.tmp file referenced earlier.

The malware will copy itself to the %TEMP% directory with the executable name of ‘notilv.exe’. Due to the previously written registry key, this file will execute when the machine is restarted and the current user logs in.

The malware then makes the following request:

The filename and uid parameters are statically set in the above request. The response data is decrypted using the RC4 cryptographic stream cipher. The ‘gh204503254′ data that was previously downloaded is used as the key. The following Python code can be used for decryption, using the ‘gh204503254′ key:

At this stage, the remote server can send a number of different responses. The following example response will instruct the malware to download a remote executable file:

‘filename.exe’ is the path where the downloaded file will be stored, and ‘01234567890123456789012345678901’ is the value supplied in the subsequent HTTP request. When this command is received, the following example request is made:

At this point, the remote server will respond with an unencrypted file that the malware saves to the system.

The remote server can also send the following example response. This response will instruct the malware to upload the specified file:

An example upload request can be seen below:

The remote server can also send the following example response. This response will instruct the malware to execute the given command:

The results of this -execution are stored in a temporary text file in the %TEMP% directory. These results are encrypted using the same technique mentioned previously. An example upload of these results can be seen below:


PlugX is a backdoor that is often used by actors in targeted attacks. This version of PlugX attempts to disguise itself as a Symantec product. The following icon is present in this sample:

figure 8 - dragon

Figure 8. PlugX file uses Symantec logo icon. 

Upon execution, the malware will install itself as a service with the following parameters:

Service Name RasTls
Service Display Name RasTls
Service Description Symantec 802.1x Supplicant

It may also set the following registry key for persistence:

PlugX is a well-studied malware family with a long history of use in targeted attacks. More information on its history is available at the following links.


This remote administration tool (RAT) is referred to as “FormerFirstRAT” by its authors. FormerFirstRAT communicates using unencrypted HTTP over port 443; the use of mismatching ports and communication protocols is not uncommon in targeted attack campaigns. In addition, port / protocol mis-match traffic can be an indicator of bad activity.

When the malware starts, it writes the following registry key to ensure persistence:

The malware then proceeds to send an HTTP POST request with information about the victim system. The following information is collected:

  • Victim IP address
  • Username
  • Administrative privileges
  • RAT status (active/sleep)
  • RAT version (in this case, 0.8)
  • Microsoft Windows version
  • UserID (Volume Serial followed by an underscore and a series of ‘1’s)
  • Language

The following settings are used for command and control:

The malware encrypts network communication using the AES128 encryption cipher. It uses the MD5 of ‘tucwatkins’ in order to generate the key. All data is sent via HTTP POST requests. While not a distinct TTP, the author of this malware may be a soap-opera fan. The following code demonstrates how you can decrypt the malware communications using Python:

The malware then enters a loop where it will send out periodic requests to the remote server. The remote server has the ability to respond and provide instructions to the RAT. We have identified the following functionalities:

  • Modify sleep timer between requests
  • Execute a command and return the command output
  • Browse the file system
  • Download files
  • Delete files
  • Exfiltrate victim information

An example HTTP POST request can be seen below.


When loaded inside of a running process, NFlog begins by spawning a new thread. This new thread is responsible for all malicious activities produced by this DLL. Initially, the malware will set the following registry key:

Where [current_executable_filename] is the path to the current running executable, which is acquired via a call to GetModuleFileNameA. This registry key ensures that the malware will persist across reboots when the current user logs in.

Multiple string obfuscation routines are included in this malware sample. Strings contained in the binary are decrypted via a simple binary XOR against a single byte key of 0x25.

The malware proceeds to create a named event object of ‘GoogleZCM’ and uses this event in order to ensure only one instance of this malware is running at a given time.

The malware proceeds to make an attempt at binding to the local host on port 1139.

The malware attempts to ensure Internet connectivity by making a request to An example request is shown below.

The malware looks for a response ‘Server’ header to contain the string ‘IIS’.

This malware proceeds to check for connectivity to the remote host by making a POST request to the ‘/news/STTip.asp’ URI to the new.hotpmsn[.]com domain. An example is shown below.

The malware then sends out victim information via a POST request to the ‘/news/SNews.asp’ URI. This request also contains a GET parameter of ‘HostID’, which contains the victim’s MAC address. An example request can be seen below.

The included binary data is XORed against a 4-byte key of “\x35\x8E\x9D\x7A”. Once decrypted, we see the following data:

This data contains the following information, separated by the ‘#%#’ delimiter:

  • Victim MAC Address (Host ID)
  • Command (if available)
  • Victim IP address
  • Username
  • Windows OS version
  • Windows language
  • Current time
  • Status

The server’s response to this request allows this malware to accept a number of commands. The commands and their associated response URIs can be seen below. Please note that all commands must be encrypted using the 4-byte XOR key previously identified.

Command Description URI
CMD Executes provided command /news/STravel.asp
Browse Directory listing of provided directory /news/SJobs.asp
UploadFile Upload specified file /news/SSports.asp
DownLoad Download specified file /news/SWeather.asp
DelFile Delete specified file N/A


This malware was identified as the popular PoisonIvy remote access trojan (RAT). The following debug strings were discovered to be embedded within the one of the decrypted dropped files.

  • d:\MyProject\Street2008\PotPlayer\Release_Mini_Unicode\PotPlayerMini.pdb

PoisonIvy begins by creating three files in the following locations.

  • %APPDATA%\\svchosts.exe
  • %APPDATA%\\PotPlayer.dll
  • %APPDATA%\\demo.dat

Next, the malware executes the svchosts.exe executable via a call to WinExec. The svchosts.exe malware begins by decrypting the PotPlayer.dll library prior to loading it within it’s own process. It proceeds to load the following exported functions from PotPlayer.dll.

  • PreprocessCmdLineExW
  • UninitPotPlayer
  • CreatePotPlayerExW
  • DestroyPotPlayer
  • RunPotPlayer
  • SetPotPlayRegKeyW

The loading of PotPlayer.dll triggers the DLL’s DllEntryPoint function, which contains the core of the malicious functionality. When PotPlayer.dll is initially loaded, the malware will load and execute a stub of shellcode. This shellcode spawns a new instance of the current executable in a suspended state. It then decrypts the ‘demo.dat’ file using the following algorithm:

This decrypted code is then injected to the suspended process prior to that process being resumed.  This newly created svchost.exe process begins by dynamically loading a number of libraries and functions. The malware consists primarily of shellcode. It then proceeds to create the following mutex:

Next it attempts to delete the original executable. It then sets the following registry key. If running as an administrator, HKLM is used. Otherwise it is set in the context of HKCU.

The malware then begins preparing for network communication. It attempts to identify any proxies that may be present. It collects the victim’s MAC address and hostname and concatenates them into a single string.

PoisonIvy is configured to communicate with the bbs.reweblink[.]com domain. The following example request demonstrates a HTTP request being made:

The following configuration details were extracted from this malware:

RAT Identifier 12008
Proxy Count 0
Communications Key DF#[email protected]!
Auto-remove Dropper True
C&C bbs.reweblink[.]com:80


NewCT 64-bit DLL backdoor that makes periodic requests to its command and control server. This family makes a request to in order to verify Internet connectivity. This same technique was witnessed in the previously discussed NFlog malware sample.

When Internet connectivity is confirmed, the malware will send a POST request similar to the following:

The following decoded data is contained within the above POST request, including a specific campaign identifier.

Key 0x30303137
Victim ID 60F81DCC2FCF_WIN-71FN1PE1AT8
Campaign APR1_2.3
URI index.asp


The DragonOK actors appear to have evolved their TTPs, using two new families of malware, one of which appears to be custom-built. However, they have continued using the same email addresses to register domains intended for C2 and / or malware hosting, as well as re-using some of these domains over a period of years.  This means even with new malware they are still fairly easy to track and the new malware itself was not particularly advanced in relation to what the group has used in the past.

While DragonOK actors may not be the most technically advanced, they have demonstrated a high level of persistence in going after their targets time and again over a relatively short period of time.  Many so-called “APT” groups are more persistent than advanced, and DragonOK falls into that category.  Unfortunately, these tools combined with spear-phishing attacks are often successful for malicious actors with enough time. All of the malware samples described in this blog were identified properly by WildFire as malware.

We encourage customers to confirm these indicator sets are in their current security solutions, add them when appropriate, and proactively search their networks for an existing compromise. The ideal security solution employs a platform-based approach that provides protection at each stage of the attack kill-chain, automatically adding new protections as unknown threats are detected.

[1] Operation Quantum Entanglement – Thoufique Haq, Ned Moran, Sai Vashisht, and Mike Scott –

Sample Summary

Filename ].exe
First Seen 19 Jan 2015
SHA256 227de988efdcf886bc0be7dc3df9f51a727664593de47352df31757853e42968
C2 biosnews[.]info
PDB string D:\Work\1021WinInetGEnc1\Release\WinInetG.pdb
Filename A.exe
First Seen 27 Jan 2015
SHA256 35784ec1968d322092cb6826f7795f65eeb0b8365ac8c7d8756851c92acf31ae
C2 biosnews[.]info
PDB string D:\Work\1021WinInetGEnc1\Release\WinInetG.pdb
First Seen 10 Mar 2015
SHA256 0b97ced3fabb14dbffa641d9bd1cc9dd8c97eab9cb6160d43202ee078e017989
C2 biosnews[.]info
PDB string D:\Work\1021WinInetGEnc1\Release\WinInetG.pdb
Filename address.exe
First Seen 16 Mar 2015
SHA256 287e29ca7b2177fdaa561a96284726ada636dbbdaadfdbeadf88164e625ed88e
C2 biosnews[.]info
PDB string D:\Work\1021WinInetGEnc1\Release\WinInetG.pdb
Filename schost.exe
First Seen 16 Mar 2015
SHA256 70ac649d31db748c4396a9a3f7a9c619c8d09e6400492ab3447520fb726083c4
Filename shost.exe
First Seen 17 Mar 2015
SHA256 6e95215a52e1cbf4a58cb24c91750151170ea3d59fa9dbfe566e33a2ffc04f4c
Filename RpcRtRemote.dll
First Seen 16 Mar 2015
SHA256 e68b70eaaf45fa43e726a29ce956f0e6ea26ece51165a1989e22597aebba244f
Filename chrome_frame_helper.dll
First Seen 17 Mar 2015
SHA256 64cbcb1f5b8a9d98b3543e3bf342e8c799e0f74f582a5eb0dc383abac7692f63
Filename shost.exe
First Seen 17 Mar 2015
SHA256 6e95215a52e1cbf4a58cb24c91750151170ea3d59fa9dbfe566e33a2ffc04f4c

[Palo Alto Networks Blog]

Leave a Reply

Copyright © 2006-2022 Philip Hung Cao. All rights reserved