28 posts categorized "#Trends in Japan" Feed

May 25, 2016

Decoding Obfuscated Strings in Adwind

From the latter half of 2015 to 2016, there have been an increasing number of cyber attacks worldwide using Adwind, a Remote Access Tool [1]. JPCERT/CC also received incident reports about emails with this malware in its attachment.

Adwind is malware written in Java language, and it operates in Windows and other OS as well. It has a variety of functions: to download and execute arbitrary files, send infected machine information to C&C servers and extend functions using plug-ins.

One of the characteristics of Adwind is its frequent updates. In an extreme case, an update was released merely in a two-week interval. When investigating Adwind-related incidents, it is important to correctly examine the functions of the Adwind version in use.

The challenge is, however, the strings stored within Adwind, which count up to about 500, are artfully obfuscated, and they need to be decoded in order to analyse the malware’s function. JPCERT/CC created a tool “adwind_string_decoder.py”, which efficiently decodes such obfuscated strings. This blog article describes how this tool works.

Although Adwind has multiple generations [1], this blog article and the tool created will examine the new Adwind versions which have been used in recent attacks since the latter half of 2015.

Obfuscated strings

Most of the strings that Adwind has are obfuscated as in Figure 1. The number of such strings differs depending on the Adwind’s version, but there are about 500. These strings look totally different in each Adwind version.

Figure 1: Decompiled codes containing obfuscated strings
Figure 2: Decompiled codes in another Adwind version

Figure 1 and Figure 2 describe codes which correspond to the same process. Both figures have line feeds inserted and are indented so that the decompiled codes can be read easier. Figure 2 is the Adwind version which was seen in mid-August 2015 and Figure 1 in late November 2015. As previously mentioned, Adwind gets updated frequently, and furthermore, the codes are obfuscated using different keys for each version.

The red-marked sections in Figure 1 and 2 indicate part of the process for collecting information to be sent to C&C servers, and contain a process for obtaining infected usernames. However, when calling the process for collecting information, the object (which is the username) is specified in the obfuscated strings. This makes it impossible to tell from the codes that the malware intends to collect infected usernames, unless they are decoded. Furthermore, it is difficult to decode the strings since the keys used for obfuscation are scattered and different for each Adwind version (as described later).

In incident analysis, damage caused by the infection and the next attack sequence can sometimes be predicted by specifying the information sent to C&C servers. From the analysis perspectives, it is important to closely examine what kind of information the malware is targeting. For this purpose, static code analysis has to be effectively conducted, and about 500 obfuscated strings for various Adwind versions need to be quickly decoded.

Analysing the string-decoding process

Generally in stream cipher, in order to encrypt data m (with a random length), usually a pseudo-random number sequence k (with the same length as m) is created using its encryption key, and an encrypted string is generated by m XOR k. By combining the XOR for m XOR k and the pseudo-random number sequence k (which is described as (m XOR k) XOR k) using XOR operation, the string is decrypted to derive the plaintext m.

Obfuscation in Adwind is conducted in a method which is similar to the abovementioned stream cypher. However, Adwind creates k in a different method, not from an encryption key. In this article, k for Adwind is referred to as an “obfuscating key”.

Codes in Adwind contain some functions which take an obfuscated string as an argument, and returns its decoded string. These functions are referred to as Fi hereafter. One thing to note here is that Fi returns different results even for the same input, if the caller method is different. This means that, in order to do static analysis and obtain the obfuscating key corresponding to a certain string, it is necessary to understand which Fi processes the strings, as well as in which method the string exists to call for Fi. The following describes what kind of obfuscating key Fi generates to process decoding.

Fi takes its caller’s method name and class name as the basis, and generates an obfuscating key by giving them a transform process derived from the following factors. This process is repeated until it gains a certain length required for a key.

Factor 1: Which comes first when concatenating the method name and class name

Factor 2: The value used in the operation for transforming the basis string to a completely different string

All Fi consist mostly of the same codes, however, only those corresponding to the above factors have different codes in each Fi. Furthermore, Factor 2 does not exist in the code as an immediate constant, and is derived through obfuscated codes including bit-operations.

Adwind contains at least 5 varieties of Fi and about 60 methods including obfuscated strings, which means that it has a combination of about 100 obfuscating keys. Although Fi consists of relatively simple codes, this number makes it fairly difficult to remove obfuscation.

Additionally, the two factors mentioned above vary in each Adwind version. Therefore, even if we create a decoding tool for a certain version of Adwind, it cannot be applied to other versions.

On the other hand, Fi has the following characteristics in common:

- Has one argument of a string object

- Is a static function that returns a decoded string as a string object

- Contains a certain API call to obtain the caller’s information

- Has limited varieties of instructions within the function

Based on the features, JPCERT/CC created a tool to automatically decode obfuscated strings using a method which does not rely on the Adwind version as much as possible.


This tool is available on GitHub. Feel free to download for your use.

JPCERTCC/aa-tools - adwind_string_decoder.py


In order to use adwind_string_decoder.py, a disassembler, javap, is required which is included in JDK (Java Development Kit). Users are required to set a path to javap, or configure so that the environment variable JAVA_HOME is pointed to the JDK folder.

adwind_string_decoder.py basically processes in the following sequence:

  1. Open the selected jar file and call a disassembler
  2. Scan all the disassembled codes, and extract functions which seem to be decoding functions from the arguments and types
  3. Judge if it really is a decoding process from the kinds of instructions and sequences that appear in the function
  4. If it is a decoding process, derive Factor 1 and 2 to generate obfuscating keys
  5. Scan all the codes again and extract parts which call for the decoding process
  6. Derive each method name and class name, and use them as the basis for obfuscating keys
  7. Generate obfuscating keys and decode the strings

Before using adwind_string_decoder.py – Unpacking Adwind

Typically, Adwind is packed, and its main jar file is hidden in the artifact’s jar file. Since adwind_string_decoder.py does not have the function to unpack Adwind, users are required to run Adwind in an analysis environment beforehand, and extract the jar image that appears in its memory. The jar image tends to disappear easily from the memory, however, it could be easier to extract it if you set a breakpoint in the API which reads the jar file, by using a Java debugger (e.g. jdb).

Executing adwind_string_decoder.py

To decode obfuscated strings, select the unpacked jar file and output file, and execute as follows:

python adwind_string_decoder.py sample.jar output.jasm

Then it outputs disassembled codes which contain decoded strings as comments, as in Figure 3.

Figure 3: Disassembled codes with some decoded strings inserted

Also, if you execute without any output files, the output of the disassembled codes will be omitted, and you can output decoded strings only to the standard output, as in Figure 4.

python adwind_string_decoder.py sample.jar
Figure 4: Output of decoded strings only

It is also possible to scan the java codes (outputs of the decompiler), and replace the function call and argument with the decoded string. This option only supports codes in Fully Qualified Name (FQN) format. For example, you can obtain the output in Figure 6 from codes as in Figure 5. Since adwind_string_decoder.py does not have a decompiling function, you need to output a file with the decompiler and store it in a folder beforehand. After selecting that folder and a new folder for outputting the decoded file, execute as follows:

python adwind_string_decoder.py sample.jar source_folder output_folder
Figure 5: Decompiled codes before decoding
Figure 6: Decompiled codes after decoding

Using these decoded strings, it is easy to understand what kind of information the malware intends to collect and send to C&C servers. It is also possible to find out which OS can be infected by the malware, and how the Adwind functions may differ in each OS.


Since early February 2016, attacks using these new Adwind versions have been less and less seen. This may be good news, however, it seems that there are still new samples found at the end of February 2016. We hope that the tool we introduced here would be of your help in case if you see any new versions of Adwind.

- Kenichi Imamatsu

(Translated by Yukako Uchida)


[1] Adwind: FAQ - Securelist



SHA-256 Hash value of the sample

  • 033db051fc98b61dab4a290a5d802abe72930338c4a0dd4705c74eacd84578d3
  • f8f99b405c932adb0f8eb147233bfef1cf3547988be4d27efd1d6b05a8817d46


Apr 08, 2016

PHP Files in CMS, Targeted for Alteration

JPCERT/CC has been continuously observing cases where websites in Japan created with Content Management Systems (hereafter “CMS”) are defaced in a similar way, and the same kind of cases are also observed overseas [1], [2]. In these cases, part of the PHP files composing the CMS are altered, and this results in defacement of the website contents [3].

Based on the analysis of several cases, this entry today describes the alteration of such files composing CMS.

Altered Files

JPCERT/CC confirmed that the targeted CMS contained partially altered PHP files as components. The CMS names and altered PHP files in each are listed in Table 1.

Table 1: CMS names and altered PHP files
CMS NameAltered PHP Files
WordPress /wp-includes/nav-menu.php
Joomla! /includes/defines.php
Drupal /includes/bootstrap.inc
MODX /manager/includes/protect.inc.php

Our study revealed that malicious codes were dynamically inserted into the response from the website for each access by the visitor, which was a result of the PHP file alteration.

How Altered PHP Files Insert Malicious Codes

Altered PHP files included malicious PHP codes in between “//istart” and “//iend” as in Figure 1 (we noted that malicious codes are obfuscated in some cases).

These malicious PHP codes have a function to insert codes obtained from outside. They receive malicious codes from a specific URL and insert them in a certain place.

Figure 1: Malicious PHP codes in between “//istart” and “//iend”

Malicious Codes to be Inserted

When a visitor accesses such websites, the malicious PHP codes in the altered PHP files obtain malicious codes composed of “div” tag and JavaScript, and insert them in the response to the website visitor. The places to insert the codes differ in each CMS: right after the “body” tag in WordPress, and at the beginning of the HTML in Joomla!, Drupal and MODX.

Figure 2: Example of malicious codes to be inserted

Malicious codes include obfuscated JavaScript, and if this is executed on the visitor’s browser, they generate tags such as iframe, etc., which redirect the visitor to the attacker’s site. Also, if the visitor’s web browser or its plug-in, etc., has certain vulnerability, their PC may be exposed to the risk of being infected with malware such as ransomware.


In such cases where malicious codes are dynamically inserted, it may be difficult for website administrators to realise that their websites are providing malicious contents. We recommend the administrators to confirm that there are no malicious PHP codes (as in Figure 1) in the PHP files described in Table 1 and others in their websites. We have not yet confirmed how these PHP files are altered, but vulnerabilities in the CMS or the plug-ins used by CMS may be leveraged for the alteration. We also recommend updating the CMS and plug-ins to the latest version.

Other than the instances introduced here, JPCERT/CC has been seeing cases where Japanese websites are defaced, and then leveraged as an entrance to the attacker’s website. We hope that each website administrator takes actions as updating the software and properly managing passwords, and be mindful that their website would not be abused for such attacks.

- Ayaka Funakoshi

(Translated by Yukako Uchida)


[1] Sucuri Inc
WordPress Malware Causes Psuedo-Darkleech Infection

DarkLeech: Finally Under Control?

JPCERT/CC Incident Handling Report (October 1 – December 31 2015) (English)

Feb 19, 2016

Banking Trojan “Citadel” Returns

Hello again, this is You ‘Tsuru’ Nakatsuru from Analysis Center. It has been just about two years since I delivered a talk “Fight Against Citadel in Japan” at CODE BLUE 2013 (an international security conference in Tokyo) about the situation on banking trojans observed in Japan at that time and detailed analysis results on Citadel (See my blog entry here). For the presentation material and audio archive, please see Reference [1].

Since then, various kinds of efforts have been implemented against this malware. Citadel was less and less seen among incident reports to JPCERT/CC, and there had been no reports about it since the first half of 2014. However, in late November 2015, we observed an attempt to infect a host with an upgraded Citadel via Drive-by-Download attack.

In this blog article, I will discuss how this upgraded Citadel (here after tentatively named as “Citadel 101” since the version was set as had changed from Citadel version (hereafter “Citadel”) which I presented at CODE BLUE. I will also introduce a decryption tool for Citadel 101 created by JPCERT/CC.

Message Impersonating Brian Krebs Removed

It is widely known that Citadel has a function which is not related to its intended behaviour: When executing with argument “-z”, the following message is displayed.

Figure 1: Dialog box displayed when executing with argument "-z"

This is a message impersonating Brian Krebs, a well-known security researcher of Krebs on Security. He himself actually has written an article about this (See Reference [2]). In Citadel 101, this function has been removed.

Change in Structure

There have been some slight changes in structures used within Citadel. For instance, in BinStrage (used as data format for configuration files), the size of random data at the beginning of the header had been changed from 20 bytes to 32 bytes as in Figure 2.

Figure 2: Random data (in red boxes) at the beginning of BinStrage – in Citadel (upper) and Citadel 101 (lower)

XOR Operation Added to Encryption Process

As I introduced at CODE BLUE, Citadel encrypts files, registries and communication data, as indicated in Table 1.

Table 1: Objects that Citadel encrypts and its methods
Encryption objectData formatEncryption method
Communication data Report Encrypted BinStrage RC4+
Dynamic Config Encrypted BinStrage AES+
Additional modules Executable files RC4+ * 2
Files Report files StrageArray AES+ using Installed Data
Module backup StrageArray AES+ using Installed Data
Registry Dynamic Config backup Encrypted BinStrage AES+ using Installed Data

Citadel 101 encrypts the same objects and uses the same encryption methods as Citadel, however, XOR operation has been added at the beginning of the encryption process and the end of the decryption process. Data retrieved through the same decryption method as Citadel includes XOR key (key2) and encoded data (data), which are used in the XOR decoding process (shown in Figure 3).

Figure 3: XOR decoding process added to Citadel 101

The default value of key1, which is one of the XOR keys used here, is hardcoded in Citadel itself. In the incident handling process, this value has to be newly retrieved in order to decrypt data encrypted by Citadel.

Updated Citadel Decryptor Published

Citadel Decryptor is a tool to decrypt data encrypted by Citadel, which I created and presented at CODE BLUE. This time, I expanded its feature so that it can decrypt data encrypted by Citadel 101 as well, and published it on GitHub.



Major changes are as follows:

  • Added the process to obtain encryption keys, etc., hardcoded in Citadel 101 itself
  • Added XOR decoding process at the end of decryption process

⇒In case it fails to obtain the XOR key, it judges that the version is Citadel and does not perform XOR decoding

  • Made changes to correspond to different structures between Citadel 101 and Citadel

There is no change in its usage. Here below is an example of using the tool to decrypt the configuration file which Citadel 101 receives from a C&C server.

> citadel_decryptor.py -v -d root.xml citadel_main.bin
[*] start to decrypt root.xml
[*] get base config & several params
[*] found base config at RVA:0x000047f0, RA:0x000047f0
[*] found login key: D8F3A28A92E53179A3EC2100B314A5CB
[*] use RC4 key at (base config + 0x000001fd)
[*] found following xor key for AES plus:
[40, 40, 84, 92, 146, 121, 93, 197, 4, 73, 90, 178, 167, 220, 62, 44]
[*] found RC4 salt: 0x5198A7FE
[*] found xor key using after Visual Decrypt: 0x5198A7FE
[*] try to unpack
[*] decrypt data using following key:
[58, 225, (snip.) 50, 247, 122, 107, 114, 177, 190, 29, 60, 230, 186, 94]
[*] try to AES+ decryption
[*] use following AES key:
[181, 55, (snip.) , 252, 170, 168, 99, 231, 208, 131, 229, 244, 121]
[*] parse decrypted data... OK
[*] decompress decrypted data
[*] wrote decrypted data to root_decrypted.bin

Way Forward

Since JPCERT/CC has only seen a small number of Citadel 101 cases so far, there has not yet been enough testing on the Citadel Decryptor. There may be some other changes that are not fully covered in this update. I would like to make improvements based on your feedbacks, including Citadel samples which cannot be decrypted with the Citadel Decryptor. Your pull request is also highly appreciated!

Thank you for reading!

- You Nakatsuru


[1] ARCHIVE || Lecture of past || CODE BLUE 2013


[2] Krebs, KrebsOnSecurity, As Malware Memes — Krebs on Security


Appendix: SHA-256 hash value


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

    Jul 23, 2015

    PoisonIvy adapts to communicate through Authentication Proxies

    Hi, it’s Shusei Tomonaga again from the Analysis Center.

    PoisonIvy, a Remote Access Tool/Trojan (RAT) often used in targeted attacks, had been widely seen until around 2013.  Since then, the number of cases using PoisonIvy in such attacks decreased, and there was no special variant with expanded features seen in the wild.  However, recently, we have observed cases where PoisonIvy with expanded features in its communication function were used for attacks.

    In this blog post, I will discuss PoisonIvy’s expanded features.

    PoisonIvy’s Traditional Communication Function

    Traditionally, PoisonIvy had used a proprietary protocol to communicate with C&C servers.  Within organizations using proxies, PoisonIvy attempted to send data to C&C servers via proxies by using CONNECT method or SOCKS (version 4).  This was achieved by pre-setting the proxy server information in PoisonIvy itself, or by enabling the configuration to obtain the proxy information from Internet Explorer.  Figure 1 shows an example of PoisonIvy’s communication using CONNECT method.

    Figure 1: PoisonIvy's Communication using CONNECT Method

    In the past, PoisonIvy was not able to communicate with external C&C servers when authentication was necessary for a proxy connection.

    Transition to HTTP Communication

    Recently, we found that PoisonIvy’s settings changed from its traditional proprietary protocol to HTTP for connecting to C&C servers.  This means that, as shown in Figure 2, the new variant now sends POST requests that include the data to send to C&C servers in the body field.

    Figure 2: PoisonIvy's Communication (the Cookie tag "id=" is followed by a string with MAC address and host name)

    Our analysis revealed that this new PoisonIvy variant has significant changes in its communication function compared to the traditional one (as shown in Figure 3).  The code used for its traditional proprietary communication was replaced with code for HTTP communication.

    Figure 3: Change in PoisonIvy's Communication Code (Left: Traditional PoisonIvy / Right: PoisonIvy with expanded features)

    Adaptability to Authentication Proxies

    Furthermore, this PoisonIvy variant has adapted to communicate through authentication proxies.  When it attempts to connect to C&C servers via proxies, and an error is returned from the authentication proxy (HTTP status code 407), it sniffs the communication in promiscuous mode.  If this communication includes the string “Proxy-Authentication: Basic”, it writes this string to the following registry entry.


    Figure 4 shows an example of sniffed information that we actually observed in the registry.

    Figure 4: Registry Entry with Basic Authentication Information Written Over

    Later when connecting to C&C servers via proxies, PoisonIvy adds the string written in the registry entry to the HTTP header, and attempts to pass through the authentication proxy (as shown in Figure 5).   Note that PoisonIvy requires administrative privileges for the proxy authentication communications.  This is because, without administrative privileges, it cannot create the above registry entry, thus it fails to communicate the authentication information.

    Figure 5: PoisonIvy's Communication with Authentication Information

    In Summary

    Attacks using PoisonIvy has hit a lull lately, but with the new variant introduced here, we never know it may be used actively again, so caution needs to be taken.

    Furthermore, PoisonIvy is not the only case - there are many different types of malware that have adapted to communicate through authentication proxies.  PlugX, covered in an earlier blog entry , is no exception, and we believe that still more types of malware will adapt to communicate through authentication proxies in the future.

    Thank you for reading and see you again soon.

    - Shusei Tomonaga


    SHA-256 hash value of the PoisonIvy variant


    Jun 30, 2015

    APWG eCrime 2015 and Phishing Trends in Japan

    Hola!  This is Shoko from Incident Response Team.  Last month I attended the APWG eCrime 2015, held from May 26-29 in Barcelona – the cosmopolitan capital of Spain’s Catalonia region, defined by quirky art and architecture, imaginative cuisine and siesta.

    Today, I’d like to share an overview of the APWG eCrime 2015 and my presentation there on “Phishing Trends in Japan.”

    About APWG and APWG eCrime 2015

    You may well know that APWG, founded in 2003 as the Anti-Phishing Working Group, is the global coalition of industry, government and law-enforcement sectors, focused on unifying the global response to cybercrime.  APWG provides a forum to discuss phishing and cybercrime issues, to consider potential technology solutions, and more, with over 2,000 institutions participating worldwide.

    The APWG eCrime (Symposium on Electronic Crime Research) 2015 is one of APWG’s rotation of global meetings, held in Europe this time, bringing together a variety of participants from the law enforcement, financial institutions, security vendors, CSIRTs and more.

    At the event, I joined a panel session focusing on cybercrime trends from APWG members around the globe, namely from MyCERT, CERT.br and CNNIC, and presented on Japanese phishing trends in 2014.

    Phishing Trends in Japan

    The following graph shows the number of phishing incidents reported to JPCERT/CC since 2012.

    Figure 1: Trend of phishing sites observed at JPCERT/CC

    The red block shows the number of overseas brand phishing sites (phishing sites spoofing overseas brand websites), and the blue block shows the number of Japanese brand phishing sites (phishing sites spoofing Japanese brand websites).

    The number of overseas brand phishing sites has always been observed at a certain level, but what is interesting is that the number of Japanese brand phishing sites showed a sharp spike at the end of 2013, and then dropped significantly in August 2014.  There could be several reasons for this, but one noteworthy event is that in November 2014, the Japanese police arrested cyber criminals who had illegally set up malicious infrastructures for phishing purposes.  We assume that the timing of their investigation (prior to the arrest), had some relation to the sudden drop of phishing incidents reported to JPCERT/CC.  At that time, we also worked closely with relevant ISPs to investigate the case, and provided information to relevant parties from a technical standpoint.  This case was also covered in the National Police Agency’s presentation during APWG eCrime 2015. 

    The following graphs show the top categories for overseas and Japanese brand phishing sites.

    Figure 2: Industry breakdown of overseas brand phishing
    Figure 3: Industry breakdown of Japanese brand phishing

    The top category for both is Financial, but interestingly, Gaming comes second for Japanese brand phishing sites.  This could be one unique observation in Japan, as one of the famous gaming superpowers.

    In Summary

    The APWG eCrime 2015 was a significant place to strengthen collaboration among persons/organizations pursing the same goal, and to have productive and lively conversations.  Throughout this experience, I strongly reconfirmed the importance of close collaboration among relevant parties, which is the key to combat against cyber incidents and criminals.

    Well, of course it was Barcelona – Iberian pork and black paella were wonderful, but I would like to add that “agua con gas” (sparkling water) was also good!

    Thank you for reading my post.


    - Shoko Nakai

    May 28, 2015

    Fiddler Core's insecure Default flag may lead to Open Proxy Issue

    NOTE: This article, originally published on May 28, 2015, was updated as of June 8, 2015 (See below).

    Just 2 days ago, we published an advisory (in Japanese) on an open proxy issue of a widely used, open source, web browser game utility app called KanColleViewer. The game, Kantai Collection, has explosive popularity. Its official Twitter account has over 1 million followers, and according to its Tweet, the game has 3 million registered players as of May 2015. The issue was due to the insecure configuration of a proxy server launched in the app, allowing any Internet user to access the proxy. Due to the large user base of the app and the nature of the issue, Internet-wide scan against 37564/TCP (the app's proxy port) has been observed.

    In this article, I will elaborate a bit more on the technical aspect of the issue to provide secure coding tips for developers.

    KanColleViewer is a Windows Desktop app written in C# WPF. The app uses IE shell for web browsing and Fiddler Core for capturing HTTPS traffic between the client and the game server. The app was designed to improve the UI experience of the game, thus acquiring larger user base (2 million downloads as of August 2014, says the developer).

    Fiddler Core is a .Net class library for C# apps. By using this library, developers can launch a web proxy in their apps, capture and modify HTTP/HTTPS traffic just like using Fiddler, a well-known web debugging proxy tool.

    Now, who is going to use the web proxy launched in the app?

    Because the app only needs to capture its user's (game player’s) traffic, the proxy should be exclusively used by the user. However, the proxy was launched in a way that is accessible from remote users as well, serving as an "Open Proxy".

    If you take a look at the source code of the vulnerable version 3.8.1, the proxy was launched by calling FiddlerApplication.Startup() in the following way:

    63  public void Startup(int proxy = 37564)
    64  {
    65      FiddlerApplication.Startup(proxy, false, true);
    66      FiddlerApplication.BeforeRequest += this.SetUpstreamProxyHandler;
    68      SetIESettings("localhost:" + proxy);
    70      this.compositeDisposable.Add(this.connectableSessionSource.Connect());
    71      this.compositeDisposable.Add(this.apiSource.Connect());
    72  }

    FiddlerApplication.Startup() is an overloaded method. There are three implementations where two, three and four arguments are taken. Those that take three and four arguments are NOT RECOMMENDED to be used according to the FiddlerCore documentation (which you can download from http://www.telerik.com/fiddler/fiddlercore).

    Now, the recommended way to start the proxy instance of FiddlerCore is by calling the following two-argument version of the Startup():

    public static void Startup(
           int iListenPort,
           FiddlerCoreStartupFlags oFlags

    The first argument is the port number of the proxy. The second argument is the flag options passed into the Startup method.

    How should we specify the flag? According to the documentation, using the 'Default' is recommended as below:

    The FiddlerCoreStartupFlags option you want to set;

    FiddlerCoreStartupFlags.Default is recommended

    Unfortunately, the 'Default' flag is NOT SAFE. It will open the door for 'Open Proxy'.

    If you use FiddlerCoreStartupFlags.Default, your app will start listening at I used the FiddlerCoreAPI SampleApp (which comes with the free download of FiddlerCore) for testing purposes and got the following result:


    The 'Default' flag will enable 'AllowRemoteClients' option which may not be what you exactly want.


    Going back to KanColleViewer, the issue was fixed in version 3.8.2. The app now calls Startup() method in a safer way:

    63  public void Startup(int proxy = 37564)
    64  {
    65      FiddlerApplication.Startup(proxy, FiddlerCoreStartupFlags.ChainToUpstreamGateway);

    'ChainToUpstreamGateway' option will instruct FiddlerCore to use the system proxy as an upstream gateway proxy.

    It seems that there are a number of websites that show the insecure call of the Startup(). I briefly searched stackoverflow.com with the keyword 'FiddlerApplication.Startup' to find enough examples that may lead to this issue.

    So tips for developers:

    • Use the two-argument Startup() method
    • Don't use FiddlerCoreStartupFlags.Default
    • Instead, specify the options you really need

    Lastly, I'd like to thank the developer Mr. Manato KAMEYA for coordinating with JPCERT/CC smoothly and disclosing the security issue in a responsible manner.

    Masaki Kubo @ Vulnerability Analysis Team

    Update on June 8, 2015

    After a few discussions with the developer of FiddlerCore@Telerik, they've decided to exclude AllowRemoteClients from the Default flag in their next release:

    ... out of an abundance of caution we will be making a breaking change to the next build of FiddlerCore to require developers explicitly opt-in to Allowing Remote clients.(http://www.telerik.com/forums/fiddlercorestartupflags-default-enables-allowremoteclients#1xtYFqA1LUqoNGXx-h6aKw)

    I appreciate Telerik for the decision to make developers and their users more secure.

    Apr 10, 2015

    Malware with a Fake Thumbnail Preview

    Hello all, this is Yohei Tanaka from Analysis Center.

    In this article, I will introduce how recent malware tries to trick users with fake thumbnail previews – I hope this information prevents you from encountering troubles.

    The majority of malware distributed via email nowadays are executable files (.exe) or compressed executable files, rather than document files that attempt to leverage software vulnerabilities. We at JPCERT/CC have seen cases where users themselves opened and executed .exe files and unfortunately got infected by the malware.

    Thanks to awareness raising efforts, many of you now recognise that those suspicious executable attachments should not be opened. In order to get users infected with malware, attackers now have started to “camouflage” the malicious attachments to look harmless, so they get opened and executed without any doubt of it being malicious. Until recently, malware was disguised by assigning an icon of a well-known application, but it seems that even this method no longer works against security-conscious users.

    Figure 1: Samples of malware with disguised icons


    This article describes a little more sophisticated camouflage technique abusing thumbnail preview, which is a relatively new function in Windows.

    Thumbnail Preview

    Since Windows Vista, if you select icons larger than “Small Icons”, a thumbnail preview of the image file (.jpg, .bmp, etc.), instead of an application icon will be shown (as in “header_logo.gif” in Figure 2). Also, some files other than images can be previewed as an icon. For example, in an environment with Microsoft Power Point, a thumbnail preview will be displayed (as in slide.pptx in Figure 2). When “Medium Icons” or larger is selected, an overlay icon showing the assigned application can be seen in thumbnail preview. For more information on this configuration, please see Appendix A.

    Figure 2: An Image file with a thumbnail preview (left) and a Power Point Presentation file (right)


    This feature allows you to easily grasp an overview of the files in Explorer and choose what they are looking for.

    Malware with “fake” thumbnail preview

    JPCERT/CC has observed malware which use "fake" icons that can be seen as invoice or receipt files as shown in Figure 3. This way, file recipients may tend to focus on the “content” itself rather than the file type – which may give them the idea that the files are safe to open.

    Figure 3: Malware with a fake document/image thumbnail preview (Medium icon)

    We have also seen malware with a fake overlay icon as in Figure 4. It is difficult for you to tell if it is fake or not, just by looking at application icons.

    Figure 4: Malware with fake overlay icon


    How are they displayed when choosing “Extra Large Icons”? In Figure 5, I tried displaying the same malware in the Figure 3 with Extra Large Icons. “malware1.exe” does not have any Extra Large Icon, and it just shows the medium-sized icon in a large-sized frame. From this, you may actually detect that it is a malicious file. However, “malware2.exe” does also have a large-sized icon, and you cannot verify just by looking at this.

    Figure 5: Malware with a fake thumbnail preview of document or image (Extra large Icons)


    However, even for malware with a fake icon as in the second example above, there are ways for you to verify if it is malware or not. You can do so by either checking the “type of file” in Properties as in Figure 6 or in Explorer by expanding to view the details as in Figure 7.

    Figure 6: Properties of "malware2.exe"


    Figure 7: Malware with fake thumbnail preview of document or image (Detail view on Explorer)



    Attackers create icons with fake thumbnail previews in alignment with e-mail addressees and/or the contents that they are attached to, so that the recipients feel urged to open the attachment. Malware which looks like invoice or receipt files, as introduced here, is commonly used. Particularly in cases of targeted attack, recipients are deceived by a fake document that reasonably could have been created by the target or someone within the target's organization.

    We believe it is important to raise awareness of the general public about these risks so that they have more discretion when it comes to email attachments – not be deceived by the icon “look” but to stop for a second and check before opening.

    Thank you for reading.

    - Yohei Tanaka

    Appendix A: Options on Folders related to Thumbnail Preview
    Figure 8: "View" tab in "Folder Option"


    1. “Always show icons, never thumbnails”

    • Ÿ   Checked: Not show thumbnail previews as icons
    • Ÿ   Unchecked: Show thumbnail previews as icons (Default setting)

    2. “Display file icon on thumbnails”

    • Ÿ   Checked: Show an overlay icon in addition to the thumbnail (Default setting)
    • Ÿ   Unchecked: Not show an overlay icon
    Appendix B: Sample’s SHA-256 Hash Value
    • malware1: 43cec9a519610592f58c216c7bd1d8a6859f0df506675e32e4834ad021604588
    • malware2: 13b02346c79f79d85eb4c8a0ac4b455bb5e69ae25fae3001bdd2040ffb28eedf
    • malware3: 8605cb1ef0a1cdd89f38fac4e1964cf3f65c5f159edd3d2c5f8b64e93f1aeaee