« October 2015 | Main | December 2015 »

3 posts from November 2015

Nov 19, 2015

Decrypting Strings in Emdivi

Hello, this is You ‘Tsuru’ Nakatsuru at Analysis Center.

As introduced in the previous blog post, my colleagues presented on the attacks arising in Japan at CODE BLUE 2015, entitled “Revealing the Attack Operations Targeting Japan”.

In this entry, I will introduce the details of an IDAPython script “emdivi_string_decryptor.py”, which JPCERT/CC developed to analyse Emdivi, a remote control malware. The script was also introduced in our presentation at CODE BLUE 2015. Please utilize the script along with the codes, etc., that are already published on JPCERT/CC’s GitHub account.

JPCERTCC/aa-tools · GitHub


Encrypted Strings within Emdivi

Emdivi encrypts strings such as URLs that they connect to and stores them in itself. Depending on the sample, encrypted strings are Base64-encoded and stored as in Figure 1, or in other cases, just saved in an encrypted binary format.

Figure 1: Encrypted strings encoded with Base64

In the incident analysis phase, these encrypted strings need to be decrypted in order to identify information such as URLs that the malware connects to, etc. For this purpose, JPCERT/CC developed emdivi_string_decryptor.py.

Analysis on Emdivi’s Decryption Process

Emdivi runs the following process in order to decrypt the strings in itself.

Upon its startup, it calculates the key for decryption, based on the following string information:

  • The sample’s version strings

e.g. t17.08.26..3340.4444

  • Random long strings in the sample

e.g. jp5cQEhSR7xMEdv1JOjh5eKGsMxSCAE5M57CijC8VgN1KMbBvP9 (Omitted hereafter)

It then combines these strings with Base64 encode, MD5 hash value calculation and others to calculate the decryption key as in Figure 2. Depending on Emdivi’s version, it sometimes combines addition and other arithmetic process for this calculation.

Figure 2: Calculated decryption key

Using the decryption key calculated here, Emdivi performs decryption just before it uses the strings. Processes related to the encryption are implemented as classes. Figure 3 shows information of those classes.

Figure 3: Encryption related classes defined within Emdivi

Many samples of Emdivi use XxTEA as in Figure 3, but we have confirmed that some versions use AES. Also, there are some versions that switch the encryption and decryption process, and we have seen that some use XxTEA encryption process for decryption.

After analysing various samples of Emdivi, we were able to summarise the method for the decryption key calculation and the decryption process as in Chart 1 below. For details of the decryption key generation process, please refer to the source codes of emdivi_string_decryptor.py.

Table 1: Decryption process for each Emdivi version
t17t19 and t20 mid versionst20 early and late versions
Decryption process XxTEA Decryption XxTEA Encryption AES Encryption
Method to calculate decryption key MD5(









Before Using emdivi_string_decryptor.py

Since emdivi_string_decryptor.py is an IDAPython script, it requires disassembler IDA for execution. Also, the version string used when calculating the decryption key is required for string decryption.

Before actually using the tool, you have to obtain the version string from the memory or communication data.

If you are obtaining the string from the memory, execute Emdivi in an analysis environment and then search for the string in the memory by using debugger, etc. You do not have to worry about virtual environment detection, since the version string is generated before the detection process.

If you are obtaining the version string from the communication data, you would need to decode that data. For decoding, you can use emdivi_postdata_decoder.py which is also made public together with emdivi_string_decryptor.py. Here below is what you will see when executing by giving the data you want to decode to emdivi_postdata_decoder.py’s argument.

> python emdivi_postdata_decoder.py
[*] 3 field(s) found in postdata
"r13ftV"        ->      "win7_32JP_SP1-IE11*968"
"yhmsuRvo"      ->      "1"
"date"  ->      "9v3r: t17.08.26..3340.4444     |       NT: 6.1.7601    [ja-JP]
|       MEM: 2048M      |       GMT(9)"

Please note that the version string included in the communication data may be different from the string required for the decryption. Therefore, we recommend obtaining the string from the memory.

Executing emdivi_string_decryptor.py

If you have obtained the version string, you are all set. Load the target Emdivi into IDA, and execute emdivi_string_decryptor.py. Then, it will process as follows:

  1. Input version string
  2. Calculate decryption key
  3. Search for encrypted string
  4. Decrypt string
  5. Output results and insert comments in the corresponding section

Upon execution of emdivi_string_decryptor.py, the following dialog box appears to input the version string.

Figure 4: Dialog box to input version string

After you input the version string, the tool will display the decrypted string in the console, and it will be inserted as a comment to where the encrypted string is stored. This is shown in Figure 5.

Figure 5: Screenshot after executing emdivi_string_decryptor.py

Now you can obtain various information including URLs that the malware connects to. Based on these and other related pieces of information, JPCERT/CC coordinates and handles incidents caused by attack operations involving Emdivi.

In Summary

We hope that the scripts that we made public will contribute in dealing with the attacks relating to Emdivi, and in improving malware analysis techniques.

A blog entry by Kaspersky (see Reference) has revealed that a few versions of Emdivi use the infected users’ SID. Unfortunately, the current version of emdivi_string_decryptor.py is not yet adapted to input SID. Furthermore, it is possible that new versions of Emdivi with other encryption methods may emerge in the future. We welcome any pull requests on GitHub.

Thanks for reading.

-You Nakatsuru


New activity of The Blue Termite APT - Securelist


Nov 09, 2015

A Volatility Plugin Created for Detecting Malware Used in Targeted Attacks

Hello again – this is Shusei Tomonaga from Analysis Center.

This blog entry is to introduce “apt17scan.py” created by JPCERT/CC to detect certain malware used in targeted attacks, and to extract its configuration information. It is a plugin for the Volatility Framework (hereinafter “Volatility”), a memory forensics tool. My colleague Yuu Nakamura and I had the honour to introduce this at CODE BLUE 2015, an international conference for information security specialists, held in Tokyo on 28-29 October 2015.

The plugin is available for download on GitHub:

JPCERTCC/aa-tools · GitHub


Characteristics of the Adversary Group Targeting Japan

JPCERT/CC has confirmed that the following types of malware are being used by a certain attacker group targeting Japanese organisations:

  • Agtid
  • Hikit
  • McRAT
  • Preshin
  • BlackCoffee
  • Derusbi

The attacker group using these types of malware is referred to as “APT17” (by FireEye) [1] or “Aurora Panda” (by CrowdStrike) etc., and a number of security vendors have been investigating them.

One of the characteristics of this adversary group is that it sometimes uses malware which only exists in the memory (not saved as file). As such, you might not be able to detect the malware just by examining the hard disk when investigating the incident. Even if you could, its configuration information may be altered by the attacker’s command.

Therefore, there is a need to examine the dumped memory image in an offline environment, in order to detect the malware which only exists in the memory, and to extract the configuration information of the malware which is running.

How To Use This Plugin

apt17scan.py has the following commands:

  • apt17scan: Detect Agtid, Hikit, McRAT, Preshin, BlackCoffee and Derusbi in memory dump
  • derusbiconfig: Detect Derusbi in memory dump and extract its configuration information
  • hikitconfig: Detect Hikit in memory dump and extract its configuration information
  • agtidconfig: Detect Agtid in memory dump and extract its configuration information

Upon its execution, save apt17scan.py in the “contrib/plugins/malware” folder in Volatility, and execute as follows:

$python vol.py [apt17scan|derusbiconfig|hikitconfig|agtidconfig] –f <memory.image>

Figure 1 below shows a sample result of executing apt17scan. It displays process names (Name), Process IDs (PID) and malware (Malware Name) that were detected.

Figure 1: A result of executing apt17scan

Figure 2 below shows a sample result of executing derusbiconfig. In many cases, Derusbi contains proxy information of internal networks. Also, the IDs contain strings that identify target organisations.

Figure 2: A result of executing derusbiconfig

Similarly, hikitconfig and agtidconfig can display malware configuration information as well.

Way Forward

JPCERT/CC has confirmed that the adversary group uses not only the aforementioned 6 types of malware, but also other kinds of malware including PlugX. We will keep updating the plugin so that it can detect other malware as well.

We would highly appreciate your comments and feedback on the tool. Please contact aa-info@jpcert.or.jp.

Thank you.

- Shusei Tomonaga


[1] FireEye - APT17: Hiding in Plain Sight - FireEye and Microsoft Expose Obfuscation Tactic



SHA-256 Hash Value of the samples

  • Agtid: b33ffbec01b43301edd9db42a59dcd33dd45f638733e2f92f0cb5bfe86714734
  • Hikit: 8da8dce703bc66d6ce57046151403f0972216b6b9d7b0127e8f1d5c788fea1ba
  • McRAT: cc985872fe35fbb70b99c4adc5e51b52bc8358df08b4193e7b30251f967604f4
  • Preshin: feafe1e3c9d93667e11712793f6c95fe953a1058519cfefb81f95ea2626af267
  • BlackCoffee: 20cd49fd0f244944a8f5ba1d7656af3026e67d170133c1b3546c8b2de38d4f27
  • Derusbi: 6d02c109b76267101c0d48c89b762d15b85c0eda4bbcd9f27bd76a905db202cd

Nov 06, 2015

Emdivi and the Rise of Targeted Attacks in Japan

You may well have heard of the May cyber attack in Japan against the Japan Pension Service – a high-profile case seen in the first half of this year, where 1.25 million cases of personal data was exposed. According to the Japan Pension Service, the data leaked included names and ID numbers, and for some cases, dates of birth and home addresses.

The official reports(1) say that the massive leak was caused by attackers hacking Japan Pension Service staff computers through a malicious email attachment, which was disguised as a legitimate document, but in fact was a malware. According to other various sources, the malware used is said to be “Emdivi.” This classic ploy, or targeted attack, has been around for years – however, Japan is recently experiencing a rise in this attack.

According to the National Police Agency, the number of targeted email attacks they have recognized count up to 492 cases in 2013, 1,723 in 2014 and 1,472 in the first half of 2015 alone.

Figure 1: Number of Targeted Attacks Recognized by the National Police Agency [Click to enlarge image]

Source: Cyberspace Threat Landscape in the first half of 2015 https://www.npa.go.jp/kanbou/cybersecurity/H27_kami_jousei.pdf (Japanese only)

Note: The title/figure have been translated by JPCERT/CC


Emdivi is notoriously used in these targeted attacks, and what is distinct is that it specifically focuses on Japanese targets. The Japan Pension Service indeed drew nationwide attention, but Emdivi has victimized several other government and private organizations. This attack campaign, specifically targeting Japan, is also known as “CloudyOmega” named by Symantec, or “Blue Termite” by Kaspersky.

Following this trend, JPCERT/CC newly added a “targeted attack” category in its Incident Handling Report (April – June 2015), to count the number of targeted attack incidents reported to JPCERT/CC.

Figure 2: Category of Incidents Reported to JPCERT/CC (April – June 2015) [Click to enlarge image]



Although targeted attack accounts for a mere 1.4%, the significance and impact of the attack has forced to take as much as half the resource of our Incident Response Group, according to the Group’s Manager. During the quarter, JPCERT/CC notified 66 organizations on the possibility of being victimized by targeted attacks, of which 44 were related to Emdivi. Based on the reports received, JPCERT/CC investigated the malware and attack infrastructures (C&C servers, etc.), and also developed a tool for visualizing the relation of Indicators of Compromise (IOCs) for further analysis. The visualization is shown in Figure 3.

Figure 3: Visualization of the Relation of IOCs [Click to enlarge image]



This tool aims to sort out various information relating to targeted attacks, and to give an overall picture of what is going on. While various campaigns and attack groups have been observed by security related organizations, the same campaign may have different names (as mentioned above), or different campaigns may have similar attack methods. This could cause confusion when you want to find out where a certain piece of indicator information was observed. This tool was developed to resolve this confusion. By registering the IOCs of respective attack campaigns and incidents, and also the relation of the IOCs, it is designed to visualize the big picture of the attack.

Based on these analyses, JPCERT/CC engages in sharing information with organizations that may potentially become the next target, as well as notifying organizations that are presumed to be victimized already. As Emdivi is also known for cleverly hiding itself, there is a high possibility that still several organizations are unaware of the situation, even if they are already infected. JPCERT/CC will continue to make every effort to address such situations in cooperation with other relevant parties.

In the next blog posts, our Analysis Center will introduce technical knowledge on JPCERT/CC’s tools, developed to detect malware in targeted attacks as well as to analyze Emdivi. See you again there!

- Keishi Kubo and Shiori Kubo


(1) Official Reports:

Note: The titles of the reports have been translated by JPCERT/CC