Emissary Trojan Changelog: Did Operation Lotus Blossom Cause It to Evolve?

In December 2015, Unit 42 published a blog about a cyber espionage attack using the Emissary Trojan as a payload. Emissary is related to the Elise Trojan and the Operation Lotus Blossom attack campaign, which prompted us to start collecting additional samples of Emissary.

The oldest sample we found was created in 2009, indicating this tool has been in use for almost seven years. Of note, this is three years earlier than the oldest Elise sample we have found, suggesting this group has been active longer than previously documented. In addition, Emissary appears to only be used against Taiwanese or Hong Kong based targets, all of the decoys are written in Traditional Chinese, and they use themes related to the government or military.

We also found several different versions of Emissary that had several iterative changes that show how the Trojan evolved over the years. One of the most interesting observations made during this analysis is that the amount of development effort devoted to Emissary significantly increased after we published our Operation Lotus Blossom report in June 2015, resulting in many new versions of the Emissary Trojan. In addition, we observed a TTP shift post publication with regards to their malware delivery; they started using compromised but legitimate domains to serve their malware. Interestingly, the C2 infrastructure is also somewhat different than that used by Elise.


In contrast to Elise, which was used in attacks against multiple Southeast Asian countries in region appropriate languages, all of the Emissary decoys we’ve collected are written in Traditional Chinese, which is used primarily in Taiwan and Hong Kong. The targets we have identified are also limited to those two regions. Despite appearing to target a more limited geographical range, Emissary targeted the government, higher education, and high tech companies with a mix of copy and pasted news articles and documents that do not appear to be available online. Decoys include:

  • An Excel spreadsheet containing legitimate contact information for much of the Taiwanese government that does not appear to be available online.
  • Copy and paste of a news article where the Deputy Commander of the Nanjing Military region, Wang Huanguang, responds negatively to a 2014 magazine article from a respected US Taiwan scholar saying the odds of China and Taiwan reuniting is low and discussing the issues with an attempted military takeover.
  • Copy of a news article from 2010 about the Chinese League of Victims protesting the involuntary removal of Shanghai residents in the lead up to the Shanghai Expo.
  • Copy of the official Taiwan holiday schedule for 2016, which is the 105th anniversary of the current Taiwanese government.

Emissary 1

Figure 1: Partial screenshot of the response from Deputy Commander of the Nanjing Military Region Wang Huangguang.

Evolve to Survive: TTP Shifts and Infrastructure

We’ve expanded our knowledge of Emissary infrastructure significantly since our first Emissary blog and we’ve found almost exclusive use of Dynamic DNS (DDNS) domains with only one purchased from a Chinese reseller. In contrast, the Elise samples used a mix of actor-registered and DDNS, with the actor-registered serving as one of the data points we used to tie all of the activity together. While the use of DDNS can make tying activity together more difficult, and despite the new Emissary variants since our publication, two of the most recent C2s resolved to IPs used by Elise C2s detailed in Operation Lotus Blossom. The Emissary samples typically have three hardcoded C2s that are a mix of IPs and domain names, with one of the domains or IPs not being used by the other three C2s in a likely effort to avoid loss of control. A full IOC list is included at the end of this report.

Also new is the actors’ use of compromised legitimate Taiwanese websites to serve their malware, including the official website of the Democratic Progressive Party. This is particularly interesting as Taiwan just held a closely watched Presidential election on 16 January where DPP candidate Tsai Ing-wen won. This marked the first time a woman was elected President of Taiwan and only the second time a member of the Kuomintang did not hold the office since being ousted from China in 1949 when the Communist Party of China took power. In line with her party’s stance, she is widely seen as a proponent of an independent Taiwan and not in favor of reunification with the People’s Republic of China.

Malware Updates

Our evidence suggests that malware authors created Emissary as early as 2009, which suggests that threat actors have relied on this tool as a payload in cyber-espionage attacks for many years. The Emissary Trojan is a capable tool to gain a foothold on a targeted system. While it lacks more advanced functionality like screen capturing, it is still able to carry out most tasks desired by threat actors: exfiltration of files, ability to download and execute additional payloads, and gain remote shell access. It appears that threat actors have continually used this Trojan, and developed several updated versions of Emissary to remain undetected and fresh over time.

We analyzed all of the known Emissary samples to determine what changes the malware author made between the different versions of the Trojan. During our analysis, we examined when each sample was created based on its compile time and produced a simple timeline, seen in Figure 2, to display the development efforts expended on the Emissary Trojan. It should be noted that we know some Emissary samples have been used multiple times with different configurations, so the timeline only shows when development activity took place on Emissary and should not be misconstrued to when Emissary was used in attacks.

The timeline in Figure 2 shows that the Emissary Trojan was first created (version 1.0) in May 2009 and quickly received an update that resulted in version 1.1 in June 2009. The Trojan did not receive much in the form of updates until September 2011 when the author released version 2.0. Version 2.0 received one update in October 2013 before the malware author released version 3.0 in December 2014. The malware author released version 4.0 in March 2015, but curiously created a version 3.0 sample afterwards on June 26, 2015, which was out-of-sequence from the incrementing versioning. Between August and November 2015 the malware author creates several new versions of Emissary, specifically 5.0, 5.1, 5.3 and 5.4 in a much more rapid succession compared to development process in earlier versions.


Figure 2: Timeline of development efforts spent on Emissary

The out-of-sequence version 3.0 appears to be an early variant of version 5.0 based on significant similarities (discussed in the changelog section) that are not seen in the original version 3.0 and other earlier versions of Emissary. One campaign code associated with of the out-of-sequence version 3.0 sample was “3test”, suggesting the malware author created it for testing purposes. The other campaign code associated with the out-of-sequence sample was “IC00001”, which could denote an attack payload as it appears to be a plausible code to describe a campaign.

While this may be coincidental, the out-of-sequence version 3.0 sample was created ten days after we published the Operation Lotus Blossom paper that exposed the Elise Trojan that is closely related to Emissary. It is possible that the threat actors were prompted to make malware changes in response to our research. Regardless of causation, the rapid development of new versions of Emissary suggests that the malware authors are making frequent modifications to evade detection, which as a corollary suggests the threat actors are actively using the Emissary Trojan as a payload in attacks.

Emissary Changelog

In this section, we discuss the changes observed between each version of Emissary. As this section is focused on changes, the features and functionality are the same between Emissary versions unless otherwise mentioned.

Version 1.0

Date: 5/12/2009

SHA256: a7d07b92e48876e2195e5d8769a47cf0a237e11ac304e41b14fc36042b0d9484 Original Name: WUMsvc.dll

Initial Release

The initial loader Trojan writes Emissary to %SYSTEM%\WSPsvc.dll and installs it as a service, which will run the exported function “ServiceMain” within the Emissary Trojan to carry out its functionality.

Configuration data is stored in the last 1024 bytes of the payload, from which the Trojan will extract an 896 byte structure. The configuration is decrypted with an algorithm that uses the XOR operation on each byte using the value at a different offset within the ciphertext.

The code will create the following registry keys:

Emissary uses the “CheckCode” registry key to store the encrypted configuration for the Trojan, while it stores a GUID that Emissary uses to uniquely identify the compromised host in the “CheckID” key.

The malware performs initial system information gathering and saves data to a file named TMP2548. The initial gathering relies on a combination of the following commands executed by the command prompt:

Emissary parses command and control responses for “instru”, which will precede a GUID value that designates the command the C2 server wishes to execute on the system. The command handler does not use a nested if/else or switch statement like most malware families, instead Emissary creates a structure that contains all of the available command GUIDs that it will iterate through each time the C2 supplies a GUID in order to determine which command the operator wishes to execute. Emissary can include up to 32 different commands within this data structure, but it appears the author has decided to include six commands within the Trojan. The following denotes the command handler structure used by Emissary v1.0:

Table 1 contains the commands available within the Emissary v1.0 command handler.

Command Description
bac84b12-5b0b-491f-a885-8667d156394f Upload file.
3d8313cc-53ca-4751-bbbf-ea5f914f8e65 Download file.
db0e93e7-b46c-4cba-81f1-ec70da57dc19 Update config. C2 specifies files as: p1 = C2 server 1, p2 = C2 server 2, p3 = C2 server 3, p4 = Sleep Interval, p5 = System Identifier (computer name), p6 = GUID for beacon.
2e382e51-3089-4293-8454-5eccb253eb54 Executes a specified command.
a57db08a-bf97-4b43-b27d-157e62e2fd74 Create remote shell.
eab5c1ab-a497-4fc2-bbe0-049be45d6f2d Update Trojan with new executable.

Table 1: Emissary command handler

The Emissary version 1.0 beacon to the C2 server appears as follows:

Date: 5/31/2009

SHA256: e6c4611b1399ada920730686395d6fc1700fc39add3d0d40b4f784ccb6ad0c30, Original Name: WUMsvc.dll

Removed checks for “//” and “/” in the update configuration command when updating the three C2 servers.

Version 1.1

Date: 6/5/2009

SHA256: 931a1284b11a3997c7a99076d582ed3436aa30409dc73bd763436dddd490f9cb

Original Name: WUMsvc.dll

Bug fixes:

  • Added code to make sure the content received from the C2 server matches the “Content-Length” value in the HTTP response.
  • Code added to allow for the download of more than 524,288 bytes.

The Emissary v1.1 C2 beacon appears as follows, which has not changed since version 1.0:

Version 2.0

Date: 9/15/2011

SHA256: 5edf2d0270f8e7eb5be3476802e46c578c4afc4b046411be0806b9acc3bfa099 Original Name: EmissaryDll.dll

Version 2.0 was a significant re-write of the Emissary Trojan.

The configuration data for the Trojan is still saved to the registry, but the registry key has changed to:

The configuration structure also changed in size to 464 bytes. The Emissary configuration is now encrypted using a custom algorithm that uses the “srand” function to seed the “rand” function using a value of 2563. This seed value causes the “rand” function to generate the same values each time, which Emissary will use as a key along with the XOR operation. The configuration now contains the version number of Emissary, instead of the version being hardcoded into the Trojan.

This version of Emissary keeps track of which C2 location within its configuration that it has been communicating with by storing the index of the C2 server (1, 2, or 3) in the following registry key:

This version of Emissary moves away from the command handler using the structure and moves to a nested if/else statement for less complicated command handling; however, the command GUID and commands themselves are unchanged.

The Emissary version 2.0 beacon changed slightly from previous versions, specifically the removal of the User-Agent field and the use of a lowercase “h” in the “Host” field. The following is an example of the version 2.0 beacon, which contains the same GUID and “op” values:

Version 2.0 also introduces a debug message logging system that includes verbose error messages that are accompanied by an error ID number. Error messages are written to the file %TEMP%\em.log. The following is a list of all possible debug messages:

Date: 10/24/2013

SHA256: 9dab2d1b16eb0fb4ec2095d4b4e2a3ad67a707ab4f54f9c26539619691f103f3

Original Name: NetPigeon_DLL.dll

This update to Emissary allowed the Trojan to run as a service. The configuration now contains settings for the Emissary service, which the Trojan will store in and access from the following registry keys:

SOFTWARE\Microsoft\VBA\Serv -> Service Name

SOFTWARE\Microsoft\VBA\VbaList -> Binary Path for the Service

Also, this version of Emissary was created using Microsoft Foundation Classes (MFC) to carry out a majority of its functionality. For instance, instead of manually building an HTTP request as in previous versions, this version uses the MFC functions to create the HTTP request and send it to the C2 server:

  • CInternetSession::CInternetSession
  • CInternetSession::GetHttpConnection
  • CHttpConnection::OpenRequest
  • CHttpFile::AddRequestHeaders
  • CInternetSession::SetCookie
  • CHttpFile::SendRequest

Using these classes creates a significantly different HTTP request sent to the C2 server, but the functionality of obtaining instructions from the C2 is the same. The following is an example of a beacon generated by this sample, which contains the same “op” value and has additional fields within the HTTP header:

The logging functionality within this update no longer includes error ID values, but still contains verbose debug messages that are written to a file named %TEMP%\msmqinst.ax.

Version 3.0

Date: 12/24/2014

SHA256: dcbeca8c92d6d18f2faf385e677913dc8abac3fa3303c1f5cfe166180cffbed3

Original Name: Generic.dll

Bug fixes:

  • Added a function to the configuration update command that checks to see if the C2 provided a new sleep interval at offset 460 and uses the interval stored in the VbaData registry key if its missing. This fixes the bug that would not allow the sleep interval to update correctly.

Version 4.0

Date: 3/26/2015

SHA256: 5171c9a593389011da4d72125e52bf7ef86b2da7fcd6c2a2bc95467afe6a1b58

Original Name: Generic.dll

This version of Emissary includes both the installation and loading functionality along with the Emissary functional code in the same file. The installation and loading portion of the Trojan is called using an exported function named “Setting”, which moves the file to:

The loading portion of this version of Emissary checks the permissions of the current user and either installs Emissary as a service or as a standalone Trojan. To install as a service, the loader will enumerate the services on the system looking for services running under the “netsvcs” group, and it will attempt to hijack the first “netsvcs” service by replacing the “ServiceDLL” parameter to point to the Emissary DLL. For instance, during the analysis period, the installation code changed the following registry key of the AppMgmt:


If the user does not have permissions to add a service, the installation routine attempts to add persistence by creating the following registry key that will run the functional code within Emissary via an exported function named “DllRegister”:

This version of emissary has its configuration appended to the end of the DLL, specifically starting at offset 0xc600. The following code accesses the configuration embedded within the DLL and decrypts it using a single byte XOR algorithm using 65 as the key:

This algorithm differs from the algorithm introduced in Emissary version 2.0 that used the srand and rand functions to generate a key to use in conjunction with the XOR operation. With the configuration embedded within the Emissary DLL, each Emissary version 4.0 sample will have a different hash as the configuration data changes.

The network beacon sent from Emissary version 4.0 is the same as other previous versions starting at version 2.0, as seen in the following:

Version 3.0: Out-of-sequence

Date: 6/25/2015

SHA256: 70bed57bc3484fe5dbcf3c732bd7b11f80a742138f4733bc7e9b6d03e721da4a

Original Name: IISDLL.dll

Major Overhaul

The compilation time of one sample of Emissary version 3.0 on June 25, 2015 appears out of order, as it occurs after the compilation of Emissary version 4.0. The differences between this out of order sample compared to the other known version 3.0 sample, as well as version 4.0 for that matter, include a dramatic change in configuration storage and the handling of commands. Also, the files stored on the system have different names than Emissary versions in the past, which are:

This version of Emissary is designed to be injected into an Internet Explorer process by its associated loader Trojan, which marks the first time Emissary executes through DLL injection.

This version of Emissary also has a different configuration structure than prior versions. The configuration is no longer stored in the registry; rather it is saved to a file named 75BD50EC.DAT. The Emissary DLL will skip to offset 0x488 within this file and read the next 132 bytes, which it will decrypt with a new algorithm as seen in the following:

The configuration structure has also changed as well, with Emissary now using the following structure:

This version of Emissary also introduced a new command handler that uses number-based commands instead of the GUID commands seen in prior versions of Emissary. The functionality of the commands are the same, however, the commands themselves are invoked using a number. Table 2 contains a list of available commands and a brief description of the functionality carried out by the command.

Command Description
102 Upload a file to the C2 server.
103 Executes a specified command.
104 Download file from the C2 server.
105 Update configuration file.
106 Create a remote shell.
107 Updates the Trojan with a new executable.

Table 2: New Emissary command handler

The network beacon sent from this version of Emissary is very similar to the beacon first introduced in Emissary version 2.0; however, the “op” value of “101” is hardcoded for the beacon and replaces the GUID based op designator to match the new command handler. The following is an example of the network beacon generated by this version of Emissary:

Version 5.0

Date: 8/25/2015

SHA256: c145bb2e4ce77c79aa01de2aec4a8b5b0b680e23bceda2c230903b5f0e119634, Original Name: WinDLL.dll

Emissary version 5.0 closely resembles the out-of-order version 3.0 sample, which suggests that the malware author just forgot to change the version number of the out of order sample. While the configuration and Emissary DLL filenames used by the version 5.0 Emissary sample are the same as the out-of-order version 3.0 sample, the log file name differs but only slightly, as seen in the following list of related files:

Version 5.0 uses numbers within its command handler and the same configuration structure as the out-of-order version 3.0. The only major change in 5.0 is the ability to obtain a compromised system’s external IP address by performing an HTTP GET request to “http://showip.net/index.php”. The code will parse the response from this webserver for the following to obtain the system’s IP address:

The SID value sent from the C2 server is encrypted using an algorithm that uses the XOR operation on the data using 0x76 as the key on the first byte and the resulting cleartext byte as the key on the next byte and so on. The network beacon sent from this version of Emissary visually resembles the out-of-order version, with the addition of a field “SHO” that contains the IP address of the compromised host. The following is an example of the Emissary version 5.0 network beacon, which is also the same in versions 5.1, 5.3 and 5.4 as well:

Version 5.1

Date: 9/29/2015

SHA256: 375190cc8e0e75cf771d66347ea2a04b6d1b59bf2f56823eb81270618f133e2d

Original Name: WinDLL.dll

For version 5.1 the malware author took out the exception handling in the Upload File command and obfuscated two strings within the Trojan to avoid detection. The strings exist in the Trojan in encrypted form and are decrypted using an algorithm that uses addition to each byte of ciphertext, using 65 (“A”) as a key. The obfuscated strings, as seen below, involve the filename of the log file and the command prompt executable used to create the remote shell:

Date: 10/14/2015

SHA256: e369417a7623d73346f6dff729e68f7e057f7f6dae7bb03d56a7510cb3bfe538

Original Name: WinDLL.dll

In an attempt to avoid detection based on PE header hashes, version 5.1 was recompiled without making any changes.

Version 5.3

Date: 11/7/2015

SHA256: 29d8dc863427c8e37b75eb738069c2172e79607acc7b65de6f8086ba36abf051

Original Name: WinDLL.dll

Emissary 5.3 moved some code used to create the remote shell out of a sub-function in an attempt to evade signatures used to detect the remote shell creation. For instance, in Emissary 5.1 the command handler would call an initial subfunction that would then call a second subfunction to carry out the activities to create and interact with the remote shell. In 5.3, the command handler calls an initial subfunction that carries out the activities to create and interact with the remote shell.

Version 5.4

Date: 11/23/2015

SHA256: 69b1d5454abe2475257defd9962a24a92411212c4f592de8765369a97f26c037 (Base DLL with junk data removed)

Original Name WinDLL.dll

Version 5.4 of Emissary was the basis for the blog “ELISE: Security Through Obesity” by Michael Yip of PWC. This blog provides a great analysis of this version of Emissary and we highly suggest reading it to become familiar with the Trojan.

There is one difference in the functional code between Emissary versions 5.3 and 5.4, which involves the removal of the command ‘107’ used to update the Trojan. The string ‘107’ still exists within the Trojan, however, the command handler does not check the C2 response for this command and the code used to update the Trojan has been removed.

The major difference between Emissary version 5.4 and all previous versions is how the Trojan is saved and loaded. First, the filenames of the various components of Emissary changed to the following; however, the filename for debug logs has not changed:

In addition to file name changes, the biggest (pardon the pun) change involves the Loader Trojan (Syncmgr.dll) appending junk data to the end of the Emissary DLL file to make incredibly large files. The reason for creating such large files is to trick antivirus applications into not scanning the file, as it could exceed the maximum size of files the antivirus can scan (even VirusTotal has a maximum file size of 128MB). For instance, the following pseudo code contains two loops that will end up appending 524,288,000 bytes to the end of file, resulting in a DLL that exceeds 500MB in size:

With the new filenames, malware persistence is achieved via the following registry key:

Date: 11/24/2015

SHA256: bfceccdd553c7e26006bb044ea6d87e597c7cce08218068e31dc940e9f55b636 (Base DLL with junk data removed)

Original Name: WinDLL.dll

In another attempt to avoid detection based on PE header hashes, the Trojan was recompiled without making any changes.


The actors using Emissary, who were previously reported as behind Operation Lotus Blossom, have been active for at least seven years in Southeast Asia. They are persistent, evolve over time, and have enough resources to have multiple custom RATs that receive regular updates. The targeting is largely military or government, with some cases of higher education and high tech companies. They also have the ability to select and use appropriate decoys in multiple Asian languages that appear legitimate.

The use of Emissary appears to be focused only on Taiwan and Hong Kong, with regular malware updates to avoid detection and to increase the odds of success. Of particular note, there is an interesting coincidence between the timing of the publication of our Operation Lotus Blossom report and a flurry of Emissary updates. The first occurred ten days after publication and was followed by updates over increasingly shorter time frames, starting at roughly every three months and progressing to monthly by the final version discussed here. Until that publication, according to our research Emissary was updated roughly every two years. This indicates the threat actors may take note of threat intelligence reporting and are fully capable of making immediate changes when deemed necessary.

In addition to the malware evolution, the actors also shifted from solely spear-phishing targets with attachments to also compromising legitimate websites to host malware. The consistent updates to the Trojan and the shift in the actor’s TTPs suggests that this threat will continue to use Emissary in future espionage related attacks.

We have updated the Emissary tag for Palo Alto Networks AutoFocus users to track this threat using the indicators discussed in this blog.

Emissary Delivery Documents












Emissary Installers/Loaders




















Emissary DLL Version 1.0 through 5.4

















Emissary C2 URLs


Emissary Campaign Codes


Post Your Comment