53 posts categorized "#JPCERT news" Feed

Nov 10, 2016

APT workshop and Log analysis training in Jakarta

Selamat pagi!! This is Mariko and Wataru from Watch and Warning Group.

We were in Indonesia for APT (Advanced Persistent Threat) workshop and log analysis training from October 4th to 6th. This was part of JICA’s (Japan International Cooperation Agency) project on “Capacity building for Information security”, which aims to provide practical trainings for information security staff in the ASEAN region.

At first we were a little nervous since we had never conducted trainings overseas, and moreover, there were some new training contents which we hadn’t taught even in Japanese. So we rehearsed even on the airplane. The climate was like summer in Japan, but we spent most of the time in the training room. That was comfortable!!

The first day had come.

Trainees were from Indonesia, Brunei, Cambodia, Laos, Myanmar, Timor Leste and Vietnam. We talked about the overview of APT, especially log conservation based on the APT Guideline. JPCERT/CC published the APT Guideline on our website in 2015, but the guideline is only available in Japanese at this time.

The trainees listened to us seriously and gave us a lot of questions and comments. Discussions included how to conserve logs in a secure way at low cost, such as by using syslog server or SIEM, etc. In addition we recommended to prioritize the logs to conserve.

After that Wataru showed a simple demo of malware infection to help trainees understand typical attack methods.

All trainees worked on the training seriously

On the second day, we held a log analysis hands-on for detecting traces of attacks. Through the hands-on, trainees experienced analyzing sample logs of proxy servers and Active Directory based on an APT attack scenario by using our log-analysis tool.

We also arranged some group discussions so that trainees could have opportunities to discuss with participants from different cultures. Everyone discussed actively, and reached almost perfect answers. We were deeply impressed by their enthusiasm and cooperativeness.

Heated discussion at hands-on training

After that we showed a demo of an attack against Active Directory in order to inform threats and mitigations of the attack. The demo was based on an attack scenario sometimes observed in APT attacks: conduct privilege escalation by leveraging vulnerability in Active Directory and creating a Golden ticket. 

It seemed that some trainees found the demo a little complicated since about half of them weren't familiar with Active Directory. However we were able to draw their interest and some said they became interested in Golden ticket and mimikatz (attack tool against Windows).

We are very glad if the trainees recognized the importance of log analysis and protecting Active Directory through this hands-on. Also there were some feedbacks that trainees wanted to learn more details or use our log-analysis tool, so we’d like to consider deepening and providing such hands-on and demos to various countries.

We were deeply impressed by their great answers

On the last day we conducted a training on network forensics using Wireshark. We prepared various packet data and several questions from basic to advance. The trainees discussed, helped each other and gave us almost perfect answers. Also we showed demos of attacks leveraging famous vulnerabilities: ShellShock and Apache Struts.

After all sessions, we got feedbacks from trainees through questionnaires. Many took interest in all sessions, but especially hands-on and network forensics (advanced) got favorable feedbacks. We believe the discussions and support for each other stimulated their interests and curiosities. As a result they were able to learn deeply.

At night, a banquet was held and all attendees talked about various topics such as security issues in their own countries with nibbles and drinks. That was a great time for all of us. We are very glad if trainees spent a good time during the training, and also hope that the rest of the trainings were also fruitful.

We are grateful for everyone and look forward to meeting you somewhere again. We are sure that we can, since it’s a small world, especially in IT security.

Selamat tinggal!

All of us had a wonderful time at the banquet

Jul 29, 2016

Workshop and Training in Botswana


This is hello in Tswana, a widely spoken language in Botswana. I’m Moris, Katsuhiro Mori, working at Global Coordination Division of JPCERT/CC. Recently I visited Gaborone, Botswana with Sparky, my colleague and an expert of cyber security training in Africa, for joining Africa Internet Summit (AIS) 2016 held from May 29 through June 10. AIS is an annual, regional, multi-stakeholder ICT conference since 2013, which aims to bring the African Internet community, drawn from governmental institutions, public and private sectors, academia and civil society, to interact with the global Internet community on Internet development in Africa. JPCERT/CC has been joining events by the African Internet community about twice a year since 2010. Dr. Suguru Yamaguchi, who had served as one of JPCERT/CC’s board members, was a key person to start outreach activities in Africa. In the African CSIRT community, he is known for sowing the seeds of CSIRT capacity building activities in Africa. But sadly, he passed away on May 9, 2016. We would like to take over his will to enhance cyber security and create close communication with African countries, especially CSIRT communities.

Here, I would like to write about the workshop which I engaged as a trainer for the first time.

June 1st

This time, we conducted a training for AfricaCERT members on malware analysis. The curriculum consisted of malware basics, malware analysis basics, malware analysis environment setup, surface analysis methods and runtime analysis methods. These five sections are the basics of malware analysis, and JPCERT/CC’s Analysis Center also uses these methods. We hope attendees have learned a lot from this material.

Malware Basics About technical terms of Malware
Malware Analysis Basics About technical terms of Malware Analysis
Malware Analysis Environment Setup Installing software and setting configuration
Surface Analysis Methods Introducing Malware tools and analyzing files using the tools
Runtime Analysis Methods Analyzing sample malware, watching network packets, registry, and process activities
Photo taken at the training

When I started to lecture on malware analysis environment setup, I felt it was difficult to prepare the same environment in each attendee’s device. Although what we had prepared was for Windows 7 64 bit, there were some participants with Mac OS.

Figure 1: Setting of environment using Virtualbox

It is very important to create malware analysis environment in a proper manner; otherwise malware may spread to another PC through the LAN or USB devices. This setup took a lot of time, so we moved to lecture on surface analysis methods, which does not require environment setup.

Basically, we started to analyze malware from surface analysis – that is, observing malware without actually running it. Sometimes we can obtain enough information from surface analysis, or in other cases, we would need to get further information from runtime analysis. We analyzed malware by using tools and searching information through the Internet.

June 2nd

Runtime analysis method is analyzing malware by executing it on a PC (with a special environment). We observed malware behavior from process, network activity and registry by using some tools. It is important that CSIRTs have malware analysis skills, especially in case of malware observed in a limited range of regions, or customized malware, since sometimes they are not yet adapted by anti-virus vendors.

After malware analysis, Sparky conducted a workshop on CyberGreen. This is a project lead by JPCERT/CC to measure and improve cyber health. We help CSIRTs focus their remediation efforts on the most important risks; to help understand where improvements can be made and how, together, we can achieve a more sustainable, secure, and resilient cyber ecosystem.

Sparky talking about CyberGreen project

June 3rd

There was a cerebration for CERT-FR and JPCERT/CC who have been supporting the African Internet community. JPCERT/CC, Dr. Suguru Yamaguchi and Sparky were given the “Meritorious Service Award” by AfricaCERT. AfricaCERT members talked about memories with Dr. Suguru and his contribution. I was moved by their stories. Unfortunately, I did not and will not ever have a chance to meet him, but I felt his great achievements will be alive here in Africa. I have to take over his will and support CSIRT establishment in the African region as a member of JPCERT/CC.

Sparky was given an award from Prof. Nii Quaynor
Certificate of achievement given for Dr. Suguru Yamaguchi

Thank you for reading.

- Katsuhiro Mori

Jul 08, 2016

Japan Vulnerability Notes (JVN) Site Update

Hello, Taki here. This is more of an update to my previous entry:

Some coordinated vulnerability disclosures in April 2016


Towards the end of the entry, I had mentioned that we were working on upgrading our systems to get more advisories out on our JVN English site. As of May 16th, the JVN site has been updated so that we can release advisories for vulnerability reports that are directly reported to us from various sources.

When you go to the JVN English site now, there are 2 new categories under the "List of Vulnerability Report" on the right. They are "VN_VU" and "TA". Details on these categories are provided on JVN site, but let me briefly explain here.

"VN_VU" is a section used for reports directly reported to JPCERT/CC, where JPCERT/CC is involved in the coordination process in some manner. Advisories will be published here for such reports and when there is no information source in English that we can find.

"TA" is a section that will be used to warn JVN readers on large scale issues, not just a specific vulnerability. As an example, on the JVN Japanese site, we recently published an alert on "WPAD Name Collision Vulnerability". This was a localization of a US-CERT Technical Alert, which is why it is not on the JVN English Site, but we would like to publish similar information here in the future.

We hope that we can provide more information through JVN that helps our readers.

If you have any questions, please contact us at vultures (at) jpcert (dot) or (dot) jp.

Until next time,

Takayuki (Taki) Uchiyama

May 25, 2016

Classifying Malware using Import API and Fuzzy Hashing – impfuzzy –

Hello all, this is Shusei Tomonaga again.

Generally speaking, malware analysis begins with classifying whether it is known malware or not. In order to make comparison with the enormous number of known malware samples in the database in a speedy manner, hash values are used, derived by performing hash functions to the malware sample.

Among the different hash functions, traditional ones such as MD5 and SHA1 derive totally different hash values if the input data is different even by 1 bit. So this would not be useful when you have a sample that is similar to a known malware, and would like to classify it as “known”.

These days, malware used in attacks is mostly customised for each case, so it is ideal to use hash functions which can classify those samples as similar to known ones.

Therefore, fuzzy hash function (of which the hash value for modified codes is close to that of the original codes) is used if modifications are simple and mechanical, and for Windows executable file samples, imphash [1] (import hash) is used, which calculates values from PE (portable executable)’s import table.

One of the known examples of fuzzy hash is ssdeep [2].

However, there are various issues with these methods used for malware classification; hash values derived by ssdeep often do not coincide with the similarity of malware samples, while imphash derives different values once new functions are added to the malware.

This blog article proposes a new method “impfuzzy”, and demonstrates how it can accurately classify similar malware, in comparison to existing methods.


The proposed method, as in imphash, calculates values from Import API, however, it also uses Fuzzy Hashing to calculate hash values of Import API, in order to supplement the shortcomings of imphash. With this process, a close value will be derived if just a part of Import API was added or modified.

Furthermore, it reduces time for calculation and enables efficient comparison by specifying the object of the hash value calculation to Import API (and not to the Fuzzy Hashing value of the whole executable file).

Implementing impfuzzy

“pyimpfuzzy”, a Python module for calculating and comparing impfuzzy, is available on GitHub (a public web service for software development projects). Feel free to download it from the following URL for your use:

JPCERTCC/aa-tools GitHub - impfuzzy


Volatility Plugin is also released on the portal, which searches for similar files based on hash values of executable files loaded from memory images by using impfuzzy.

In order to use pyimpfuzzy, the following tools need to be installed.

For this implementation, ssdeep is used as Fuzzy Hashing.

pyimpfuzzy has the following functions:

  • get_impfuzzy: calculates hash values from selected PE files
  • get_impfuzzy_data: calculates hash values from PE files in a data format
  • hash_compare: compares two hash values and returns the degree of similarity within the range of integer 0-100 (100 when same)

The similarity of the two PE files is calculated as follows:

import pyimpfuzzy
import sys

hash1 = pyimpfuzzy.get_impfuzzy(sys.argv[1])
hash2 = pyimpfuzzy.get_impfuzzy(sys.argv[2])
print "ImpFuzzy1: %s" % hash1
print "ImpFuzzy2: %s" % hash2
print "Compare: %i" % pyimpfuzzy.hash_compare(hash1, hash2)

The following result is derived when executing the above script:


Evaluation of impfuzzy

This section describes the results of an experiment of comparing, and evaluating, how the 3 different methods (proposed impfuzzy, imphash and ssdeep) are capable in classifying similar types of malware.

For the experiment, 10 different samples for 20 types of malware (200 samples in total) were prepared. For all the combinations that select two samples out of the 200, the similarities of the samples were calculated using the three methods. The two samples were classified as the same if the calculated value was 30 and larger.

For the experiment, packed samples were unpacked beforehand.

Figure 1 shows the results of the experiment.

There were no false positives detected which classified different types of malware as the same.

Figure 1: Success rates of malware type classification among impfuzzy, imphash and ssdeep

*1 The threshold value for classifying the same malware type is set as 30, for impfuzzy and ssdeep

*2 ssdeep’s target of comparison is the whole executable file

The results reveal that impfuzzy is more capable of classifying the same malware type than the other two methods. For the details of the results, please see Appendix A.

This method judges the samples’ similarities based on Import API, and therefore it is clear that the identification rates are higher for samples whose malware generation tools (builders) are publicly available (e.g. Pony and ZeuS), because their Windows API rarely change. On the other hand, samples whose functions are frequently updated or changed (e.g. Emdivi) have lower rates.

For the experiment, the threshold value for impfuzzy was set as 30, however, it may detect false positives depending on the executable files. We recommend adjusting the threshold value for each executable file.

In case impfuzzy is not applied effectively

Some malware have few Import APIs.

For example, some samples called downloader use only around 5 Windows APIs. For those samples, impfuzzy may not be able to compare the hash values accurately due to the limited size of data to compare. Also, samples generated by .NET Framework have different mechanisms from applications which directly execute Windows API. Therefore, hash values for those samples cannot be calculated.


In the current situation where huge numbers of malware samples emerge day by day, it is important to efficiently classify malware samples, and identify new ones which need to be analysed. We believe that the method introduced here will be one approach to support this process.

Also, Volatility Plugin that we released together with impfuzzy, is useful for memory forensics to check malware infection.

Since this tool can calculate hash values of samples which are unpacked in the memory, it is capable of judging the similarities of the samples, even if the malware is packed.

This Plugin is available at the following URL. We will introduce this tool on this blog at another occasion.

JPCERTCC/aa-tools GitHub – impfuzzy for Volatility


Thanks for reading.

- Shusei Tomonaga

(Translated by Yukako Uchida)


[1] FireEye - Tracking Malware with Import Hashing


[2] Fuzzy Hashing and ssdeep


Appendix A

Comparison of impfuzzy, imphash and ssdeep

Table 1: Malware Identification Rate
Typeimpfuzzy (%)imphash (%)ssdeep (%)
Agtid 100 35.6 26.7
BeginX Server 15.6 11.1 11.1
IXESHE 196 44.4 4.4 2.2
IXESHE 2 28.9 6.7 2.2
IXESHE 2sw 100 15.6 17.8
Daserf 35.6 4.4 4.4
Dyre 100 6.7 2.2
Fucobha 44.4 4.4 2.2
Gstatus 60 4.4 2.2
Hikit 64.4 35.6 6.7
Netwire 80 15.6 28.9
NfIpv6 24.4 4.4 4.4
Emdivi t17 37.8 0 0
Emdivi t20 4.4 0 0
plurk 15.6 6.7 11.1
Derusbi 80 8.9 8.9
Pony 95.6 15.6 0
sregister 100 11.1 15.6
Sykipot 8.9 0 2.2
ZeuS 80 35.6 35.6

*Types of malware used in this experiment are those analysed and classified by JPCERT/CC.

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


May 06, 2016

Some coordinated vulnerability disclosures in April 2016

Hello, Taki here. It has been a long time since I have written here.

Today, I will be writing about some activities within our Vulnerability Coordination Group.

Over the past few years, we have received some coordination requests directly from overseas researchers and other sources, in addition to the reports through the " Information Security Early Warning Partnership".

I would like to introduce some recent cases that we have published on Japan Vulnerability Notes (JVN - https://jvn.jp/) but due to system limitations, are not in English at the moment.

The first case is,

JVNVU#92116866 – Published on 2016/4/26

Keitai Kit for Movable Type vulnerable to OS Command Injection.

An OS command injection vulnerability was reported to us in the Movable Type plugin, Keitai Kit. Leveraging this vulnerability may result in arbitrary OS commands being executed on the server.

Versions affected are 1.35 through 1.641.

Attacks in the wild leveraging this vulnerability have been confirmed.

The vendor has provided an updated version, 1.65 to address the vulnerability. For those that cannot update, emergency patches have been provided for affected versions.

This vulnerability has been assigned, CVE-2016-1204.

The second case is,

JVNVU#90405898 – Published on 2016/4/27

ManageEngine Password Manager Pro fails to restrict access permissions.

An access permission bypass vulnerability was reported to us in ManageEngine Password Manager Pro. Leveraging this vulnerability may result in unauthorized users being able to access password entry records for other users.

Versions affected are 8.3.0 (Build 8303) and 8.4.0 (Build 8400, 8401, 8402).

The vendor has provided an update version, 8.4.0 (Build 8403) to address the vulnerability.

And this vulnerability has been assigned, CVE-2016-1159.

Internally, we are working to upgrade our systems so that we can get this information onto JVN in an advisory format. For the time being, I hope to update through this blog periodically on some of our coordinated disclosures.

If you have a vulnerability report and are having difficulty reaching a vendor or are trying to reach a Japanese vendor and having a language issue, feel free to contact us. While we may not always be successful, we can at least give it our best try to contact and coordinate with a vendor.

For coordination assistance, please contact us at vultures (at) jpcert (dot) or (dot) jp.

- Takayuki (Taki) Uchiyama

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)

Mar 29, 2016

Experience in MNSEC 2015, Ulaanbaatar

Hello all, my name is Shinichi Horata working at Watch and Warning Group. It’s my first time posting here.

It’s already been quite a while ago, but last year I went to Mongolia for the first time in my life. The purpose was to attend MNSEC 2015 (Conference website: Mongolian only), a Mongolian local cyber security conference hosted by MNCERT/CC (Organisation website: Mongolian only) on 29-30 September 2015, where I delivered a talk.

Event Overview

MNSEC is the largest cyber security conference in Mongolia, which has been held annually since 2013. JPCERT/CC has been invited to this event since the first time (See the blog entry from 2014 here). The event attracted about 200 locals who are engaged in cyber security from the Mongolian Government, private entities, ISPs, banks, universities and so on. A wide range of discussions took place including the relations between big data and security, malware involved in online banking and sophisticated cyber attacks. The program was as follows:

29 Sep - Presentations:

  1. “Big data and its security” (Bat-Ulzii B, Director of IT Department of Ulaanbaatar)
  2. “Weak point, threats and violations of E-Bank” (Jung Hyong Chul, Beyond Security)
  3. “FreeBSD Content filter” (Ganbold Ts, Director of MSTRIDE LLC and Head of Mongolian Unix group)
  4. “Current Cyber Threats in Japan” (Shinichi Horata, JPCERT/CC)
  5. Kharuul Zangi 2015 (CTF competition)

30 Sep - Presentations:

  1. “Understanding Exploit Analysis” (Shinichi Horata, JPCERT/CC)
  2. “Information security in cyber environment” (Altangerel. B, Communications Regulatory Commission of Mongolia)
  3. “APT attack” (Otgonpurev M, Cyber security expert)
  4. “Cyber threat and decreasing it” (Andrew Chen, Channel manager of Checkpoint LLC)
  5. “Child security in cyber environment” (Altangerel B, Communications Regulatory Commission of Mongolia)
  6. “DDoS attack” (Enkhsaikhan P, Cyber security researcher)
  7. “About Mongolian cyber emergency response team” (Batjargal B, MNCERT/CC)

MNCERT/CC gave me an opportunity to deliver two presentations entitled “Current Cyber Threats in Japan” and “Understanding Exploit Analysis”.

In the first presentation, I provided an overview of JPCERT/CC activities, especially focusing on our efforts in incident response and early warning. Furthermore, I introduced the current situation of cyber incidents observed in Japan, mainly case studies of illegal money transfer involving banking Trojan, and cases of sophisticated cyber attacks.

The second presentation discussed some of the know-how required for providing early warning information, and software vulnerabilities in Use After Free (CWE-416), taking Adobe Flash Player’s vulnerability (CVE-2015-5119, etc.) as an example. In Mongolia, they are currently focusing on implementing efforts to enhance industrial development and human resource development in cyber security, so it was a good opportunity for us to exchange information and views regarding these topics.


(Photo of me at the event)

Remarks on the Event

I felt that the key throughout the event was also “human resource development”. On 29 September, there was a CTF competition entitled “Kharuul Zangi 2015”, and there were also some programs running in parallel that gave practical lectures. Aside from the CTF, some exercises were also given to the participants so that everyone could make the most of the event. I saw a lot of youngsters among a wide range of participants. I felt that the participants and the venue were filled with enthusiasm – probably because the conference is a new and young project, and organisers as well as attendees had great motivation.

MNCERT/CC, who has been hosting the conference, says that they consider the discussion on local cyber security among the persons in charge and researchers as a key component of the event. This made me wonder – what about Japan? Is there as much momentum in Japanese cyber security conferences, involving young students and those working at the front line? The event provided me a good opportunity to look back on my own experience too. Actions for cyber security discussions in Mongolia has just started – we look forward to seeing MNCERT/CC’s and Mongolian local CSIRTs’ even stronger involvement in enhancing the industry and its human resources.

Thank you for reading.

- Shinichi Horata

(Translated by Yukako Uchida)

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


Dec 21, 2015

Malware Analysis Training Course at Security Camp Japan 2015

Hi, this is You 'Tsuru' Nakatsuru again from Analysis Center.

This past summer, I joined the “Security Camp 2015” in Japan as a trainer for a malware analysis training course, which was held for students aged 22 and under living in Japan, with the aim of discovering top, young talents.

This blog entry is to introduce the malware analysis training materials which I used at Security Camp 2015 as below.

Malware Analysis Training Materials for Security Camp Japan 2015
Published DateTitleFilePGP Signature
2015-09-10 "10-D: Understanding Malware"
You Nakatsuru, Analysis Center, JPCERT/CC
Digitally Signed
PGP Signature
2015-09-10 "13-D, 14-D: Understanding Malware"
You Nakatsuru, Analysis Center, JPCERT/CC
Digitally Signed
PGP Signature
2015-09-10 "Understanding Malware Exercises"
You Nakatsuru, Analysis Center, JPCERT/CC
PGP Signature

Understanding Malware

My course covered 6 hours of the 5-day Security Camp. As you may know, malware analysis requires a variety of knowledge such as OS, network, etc., and you also need to know how to create a safe analysis environment and how to use various tools. However, because it is difficult to cram everything in a limited course, I focused mainly on one of the popular topics at Security Camp – “Static analysis method (Reverse engineering).” Static analysis is a method used to read codes in the malware, which is more difficult and time-consuming than other analysis methods. However, more details on malware behavior can be revealed by using this method.

The training course consisted of 2 parts as below:

  • ŸFirst half (2 hours)

I explained basic knowledge of the current state of malware and analysis methods, followed by basics of static analysis (assembly language, efficient ways to read codes, etc.) in a hands-on style.

  • Second half (4 hours)

Trainees read malware codes on their own, while I explained the required knowledge to actually analyze malware, such as the mechanism of Windows and techniques used by malware.

The course aimed to bring the trainees to properly understand about malware, to master static analysis method, as well as to recognize the challenge in malware analysis and to utilize those knowledge and skills in the future. All the course materials were compiled in English, as JPCERT/CC has various opportunities to conduct trainings abroad.

The Security Camp had a few Japanese students as young as Junior High School students, and it may have been a bit of a challenge to study malware analysis, which requires advanced technical skills, in English. Even so, the trainees earnestly worked on penetrating codes and were able to find out the actual behavior of the malware. At the end of the course, there were positive feedbacks such as “The course was informative,” “It was difficult but fun,” and “I hope to be able to read and understand codes more,” and I feel happy to be able to contribute to the future of the trainees.

In Closing

The course materials have been published in hope that it will also be useful for anyone who has interest in malware analysis. We would highly appreciate your comments or feedback on the materials. Please contact aa-info@jpcert.or.jp.

Thank you.

- You Nakatsuru


Security Camp Japan 2015: Information-technology Promotion Agency, Japan (IPA) (Japanese only)


Security Camp Executive Committee (Japanese only)