May 12, 2017

Fact-finding Report on the Establishment and Operation of CSIRTs in Japan

Hello, this is Misaki Kimura from Watch and Warning Group.

JPCERT/CC conducted “Survey on the Establishment and Operation of CSIRTs in Japan” in the end of 2015. Following the Japanese report released in 2016, we have just released the English version of the report on JPCERT/CC website to share the outcomes with the information security community member all around the globe. Although the basis of social composition, culture, organizational constitution and so on may differ in each economy, we hope that this document will serve as a useful reference in terms of establishing a CSIRT or comparing the situation with those organizations in overseas.

Here in this blog will cover an executive summary of the report.

Background of the survey

Cyber attacks in recent years have become increasingly diverse in terms of their aims, targets, and TTPs (Tactics, Techniques, and Procedures) used that the impact can be large enough to shake the foundation of a business. One approach that is drawing attention is to establish a Computer Security Incident Response Team (CSIRT) that will serve as the linchpin of an organization to effectively handle security incidents. Cybersecurity Management Guidelines released from Ministry of Economy, Trade and Industry in December 2015 also referred to the need to establish CSIRTs, and this has been boosting the number of CSIRTs in Japan.

Cyber security communities, including the CSIRT community, are quite active in Japan. Nippon CSIRT Association (NCA) is the venue for local CSIRTs to come together for information sharing and joint activities, which has 232 member organizations (as of May 2017). JPCERT/CC conducted the survey targeting 66 organizations which belongs to NCA with an aim to assist those who wish to establish a new CSIRT by compiling the facts of CSIRT activities in various local organizations. The survey took place in December 2015, by means of a questionnaire and interviews, covering questions on organizational structure, scale, functions, policies and other various aspects of CSIRTs. Here below will introduce some interesting findings described in the report.

Items to be defined upon establishing a CSIRT

Business activities, scales, department structures, and anticipated risks differ according to the organization. For this reason, based on the results of the survey, the following six items were identified as matters that organizations should define upon establishing an internal CSIRT.

  • Scope of services provided by CSIRTs
  • Authority granted to CSIRTs
  • Deployment and members of CSIRTs
  • Point(s) of contact (PoC)
  • Reporting structure to effectively communicate the effects of CSIRT activities within the company
  • Periodic review of CSIRT activities

 Among these, I would like to highlight a few findings of the survey, which are considered noteworthy for organizations in overseas as followings;

Scope of services provided by CSIRTs

A CSIRT is required to receive, review and respond to various incident reports. Therefore, scope of its service such as contents, targets, range of responsibility, and so forth need to be considered.

NCA categorizes services offered by CSIRTs roughly into the following three types: reactive services, proactive services, and security quality control services. Of these three categories, the survey results identified the main services provided by CSIRTs in each category as follows;

 - Reactive services
  • More than 80% answered "Incident handling," "Issuing security alerts" "Log Analysis" and "Vulnerability handling" are provided to respond promptly in the event of an incident
 - Proactive services
  • More than 80% answered "Security warning announcement” is provided ahead of an incident
  • Nearly 70% answered "Provision of security related information" and "Intrusion detection" are provided to monitor any signs of an attack
 - Security quality control services
  • More than 70% answered "Conducting awareness raising activity", "Organizing educational programs" and "Consulting security related issues" as a service aimed at increasing the knowledge and skills to respond to cyber security

In some CSIRTs, all of these services are provided whereas some CSIRTs only provide one or two of those. It is not the variety of services they provide that matters to a CSIRT, but the capability to provide the kinds of services that the organization needs.

Also, the results of the survey showed that about 60% of the organizations has documented their service definition, and over 80% of the organizations has defined and documented their security policies that were approved by the management.

Authority granted to CSIRTs

In responding to security incidents, it is necessary as an organization to make appropriate and timely decisions. While CSIRTs are in a position to provide assistance to departments or persons for decision-making, it is important to understand about up to what point a CSIRT authority is granted.

For example, when a system needs to be suspended for risk avoidance in the event of an urgent incident, about 12% of the CSIRTs answered that they themselves have the authority to order the systems to be stopped, while 85% of the CSIRTs answered that they do not have the authority to order but are in a position that allows them to advise on the decision-making.

Figure 1. Authority of the CSIRT in the event of an incident

These results show that not so many organizations possess a strong authority in decision-making. However, some CSIRTs answered in the interview that they do not necessarily need to have such a powerful authority as to suspend systems in order to function effectively as a CSIRT. What matters to them is how effectively can the CSIRT collaborate with the management level to expedite accurate and rapid business decision.

Incident handling and Escalation

In case of an incident, an escalation process must be clearly defined, documented and officially approved to ensure that the incident is directed towards appropriate departments. The result shows that 74% of the CSIRTs have these processes implemented towards management, 52% implemented towards public relations department, and 50% implemented towards legal department. This indicates that CSIRTs are working closely with the management level in case of an incident, but more effort can be taken towards other related departments as well.

Information Sharing

It is essential for CSIRTs to share information and cooperates with other departments not only within the organization but also with other external partners such as other CSIRTs. Joining the information sharing framework allows the team to obtain and respond to a cyber threat in an effective way that it ultimately helps to protect the organization.

The result shows that all the survey respondents participate in more than one framework for information sharing. Specific frameworks that they join are WAISE (Watch and Warning Analysis Information for Security Experts - operated by JPCERT/CC), CCI (Counter Cyber Intelligence - operated by National Police Agency), working groups of Financials ISAC Japan, J-CSIP (Initiative for Cyber Security Information sharing Partnership of Japan - operated by Information-technology Promotion Agency, Japan) and so on.

When asked about the primary methods of expression used for sharing information, all the respondents selected text format. At the time when this survey was conducted (December 2015), some CSIRTs have already implemented STIX/TAXII, which is a globally recognized standard for incident information sharing. The protocol has been gradually accepted by an increasing number of CSIRTs over the two years after the survey.

Figure 2. Primary method(s) of expression used for sharing information

Information sharing and collaboration requires investment of time and technical resources, however, it benefits by far than negatives. Some of the respondents have said in the interview that information sharing with other CSIRTs enables them to acquire knowledge and exchange insights, which helps to keep up the motivation of their CSIRT members. The importance of building trust relationships with other CSIRTs was also pointed out by other interviewees. They spoke of participating NCA and other community activities had provided opportunities to reframe how they interact with their organizations.


The report points to six items that should be defined at the time of establishing an internal CSIRT. However, it does not necessarily mean that fulfilling all these conditions will ensure its activities live up to the expectations of the organization. For the sake of an internal CSIRT to function effectively, it is extremely important that the team shares information and cooperates with other departments within the organization and other CSIRTs. In addition, through day-to-day operations including exercises and training, as well as responding to actual incidents, we believe that newly established CSIRTs develop into a trusted and indispensable part of the organization.

The full report can be downloaded here:

- Misaki Kimura

May 02, 2017

Volatility Plugin for Detecting RedLeaves Malware

Our previous blog entry introduced details of RedLeaves, a type of malware used for targeted attacks. Since then, we’ve seen reports including those from US-CERT that Management Service Providers (MSPs) have been targeted [1] [2]. In the US-CERT report, some instances have been identified where RedLeaves malware has only been found within memory with no on-disk evidence because of the behavior of self-elimination after the infection.

To verify the infection without on-disk evidence, investigation needs to be conducted through memory dump or logs (e.g. proxy logs) stored in network devices.

This article introduces a tool to detect RedLeaves in the memory.

It is available on GitHub:

JPCERTCC/aa-tools · GitHub

Tool Details

The tool works as a plugin for The Volatility Framework (hereafter “Volatility”), a memory forensic tool. has the following functions:

  • redleavesscan: Detect RedLeaves in memory images
  • redleavesconfig: Detect RedLeaves in memory images and extract malware configuration

To run the tool, save in ”contrib/plugins/malware” folder within Volatility, and execute the following command:

$python [redleavesscan|redleavesconfig] –f <memory.image> ––profile=<profile>

Figure 1 shows an example output of redleavesscan. You can see the detected process name (Name), Process ID (PID) and the name of detected malware (Malware Name).

Figure 1: Output of redleavesscan

Figure 2 shows an example output of redleavesconfig. For details about RedLeaves configuration, please see our previous blog entry.

Figure 2: Output of redleavesconfig

In closing

It has been confirmed that the attacker group who uses RedLeaves also uses PlugX. To detect PlugX in memory, please use the Volatility plugin released by Airbus [3].

- Shusei Tomonaga

(Translated by Yukako Uchida)


[1] US-CERT: Intrusions Affecting Multiple Victims Across Multiple Sectors

[2] PwC: Operation Cloud Hopper

[3] Volatility plugin for PlugX

Apr 03, 2017

RedLeaves - Malware Based on Open Source RAT

Hi again, this is Shusei Tomonaga from the Analysis Center.

Since around October 2016, JPCERT/CC has been confirming information leakage and other damages caused by malware ‘RedLeaves’. It is a new type of malware which has been observed since 2016 in attachments to targeted emails.

This entry introduces details of RedLeaves and results of our analysis including its relation to PlugX, and a tool which is used as the base of this malware.

How RedLeaves runs

To have the RedLeaves injected into the process of Internet Explorer, the following steps will be taken (Figure1):

Figure 1: Flow of events until RedLeaves runs

Malware samples that JPCERT/CC has analysed create the following three files in %TEMP% folder and execute a legitimate application when executed.

  • A legitimate application (EXE file): a signed, executable file which reads a DLL file located in the same folder
  • A Loader (DLL file): a malicious DLL file which is loaded by the legitimate application
  • Encoded RedLeaves (DATA file): Encoded data which is read by the loader

When the legitimate application is executed, it loads the loader located in the same folder through DLL Hijacking (DLL preloading).

The loader, which is loaded in the legitimate application, reads and decodes the encoded RedLeaves and then executes it. The executed RedLeaves launches a process (Internet Explorer) depending on its configuration, and injects itself there. Then, RedLeaves starts running in the injected process. The following section explains the behaviour of the injected RedLeaves.

Behaviour of RedLeaves

RedLeaves communicates to specific sites by HTTP or its custom protocol and executes commands that are received. Figure 2 is the PE header of the injected RedLeaves. Strings such as “MZ” and “PE” are replaced with “0xFF 0xFF”.

Figure 2: Injected RedLeaves

The injected RedLeaves connects to command and control (C&C) servers by HTTP POST request or its custom protocol. Destination hosts and communication methods are specified in its configuration. Please refer to Appendix A for more information.

Below is an example of the HTTP POST request. Table B-1 and B-2 in Appendix B describe the format of the data sent.

POST /YJCk8Di/index.php
Connection: Keep-Alive
Accept: */*
Content-Length: 140


The data is encrypted with RC4 (the key is stored in its configuration) and contains the following:


The data received from the C&C servers contain commands. Depending on the received commands, RedLeaves executes the following functions (Please see Table B-3 in Appendix B for the details of received data):

  • Operation on files
  • Execute arbitrary shell commands
  • Configure communication methods
  • Send drive information
  • Send system information
  • Upload/download files
  • Screen capture
  • Execute proxy function

Base of RedLeaves’s Code

JPCERT/CC analysed RedLeaves and confirmed that its code has a lot in common with the source code of Trochilus[1], a type of RAT (Remote Administration Tool), which is available on Github. Figure 3 shows part of the code to process received data. It is clear that it processes the same data as listed in Table B-3 in Appendix B.

Figure 3: Part of Trochilus’s source code

It is presumed that RedLeaves is built on top of Trochilus’s source code, rather than from scratch.

Relation to PlugX

Comparing RedLeaves samples that JPCERT/CC has observed with PlugX, used by certain attacker groups in the past, we identified that similar code is used in some processes. Below are the sequence of instructions observed when the sample creates three files (a legitimate application, a loader and encoded RedLeaves or PlugX).

Figure 4: Comparison of file creation process

Furthermore, the process in which the loader decodes the encoded data (encoded RedLeaves or PlugX) is similar.

Figure 5: Comparison of file decode process

JPCERT/CC has also confirmed that some of the RedLeaves and PlugX samples that share the above code also communicate with common hosts. From this observation, it is presumed that the attacker group using RedLeaves may have used PlugX before.


RedLeaves is a new type of malware being observed since 2016 in attachments to targeted emails. Attacks using this malware may continue.

The hash values of the samples introduced here are listed in Appendix C. Some of the RedLeaves’ destination hosts that JPCERT/CC has confirmed are also listed in Appendix D. Please check your devices for any suspicious communication with such hosts.

- Shusei Tomonaga

(Translated by Yukako Uchida)


[1] Trochilus: A fast&free windows remote administration Tool

Appendix A: Configuration information
Table A: List of Configuration Information
0x000 Destination 1
0x040 Destination 2
0x080 Destination 3
0x0C0 Port number
0x1D0 Communication mode 1=TCP, 2=HTTP, 3=HTTPS, 4=TCP and HTTP
0x1E4 ID
0x500 Mutex
0x726 Injection Process
0x82A RC4 key Used for encrypting communication

RC4 key examples:

  • Lucky123
  • problems
  • 20161213
  • john1234
  • minasawa
Appendix B: Communicated data
Table B-1: Format of data sent through HTTP POST request
0x00 4 Length of data encrypted with RC4 (XOR encoded with the first 4 bytes of the RC4 key)
0x04 4 Server id (XOR encoded with the first 4 bytes of the RC4 key)
0x08 4 Fixed value
0x0C - Data encrypted with RC4

Table B-2: Format of data sent through its custom protocol
0x00 4 Random numerical value
0x04 4 Fixed value
0x08 4 Length
0x0C 4 Length of data encrypted with RC4 (XOR encoded with the first 4 bytes of the RC4 key)
0x10 4 Server id (XOR encoded with the first 4 bytes of the RC4 key)
0x14 4 Fixed value
0x18 - Data encrypted with RC4

Table B-3: Contents in received data
__msgid Numeric Command
__serial Numeric
__upt true, etc. Whether the command is executed by a thread
__data data Command parameter, etc.
Appendix C: SHA-256 hash value of the samples


  • 5262cb9791df50fafcb2fbd5f93226050b51efe400c2924eecba97b7ce437481


  • fcccc611730474775ff1cfd4c60481deef586f01191348b07d7a143d174a07b0
Appendix D: Communication destination host

Mar 28, 2017

Board game on Cyber Security for Awareness Raising

Hi this is Sho Aoki from Watch and Warning Group.

Have you ever tried “game-based learning”?

Learning through games is useful since it is not only fun and easy, but also provides opportunities for thinking. It has been applied widely for educational purposes. In the area of cyber security as well, there are board games released from security vendors, and they have been conducted at schools and companies.

Today I would like to introduce “SEC WEREWOLF”.

Board game package

This board game was released by Japan Network Security Association (JNSA) [1], which is an NPO consisting of information security related organizations (mainly vendors) in Japan. They aim to raise awareness and provide information security solutions through various activities. One of their Working Group activities is to promote game-based learning, where this board game was developed. JPCERT/CC is also part of this Working Group.

“SEC WEREWOLF” is a board game based on a famous party game “Werewolf” (also known as “Mafia”), which is a communication type game between a group of “villagers” and “werewolves” who attack villagers. Players probe other players in an attempt to find enemies to eliminate. In “SEC WEREWOLF”, “villagers” work as “CSIRT members” in an organisation, while “werewolves” are the evils in the organisation who are engaged in corruption.


“Corrupt workers” have been stealing confidential information of their organisation with the assistance from “Black hat hackers” and gaining profit out of the information. However, the management finds out about the malicious act. “Corrupt workers”, who have been dissatisfied about the company’s treatment, try to put the blame on other employees and get them fired. A CSIRT is launched to retrieve a peaceful workplace and deal with issues with an aim to get rid of the corrupt workers.

HOW TO PLAY (Overview)

  1. Players pick up a role card to decide which team they belong to (CSIRT or attackers)
  2. All the players have a conversation without disclosing their roles to figure out who are the “corrupt workers”. “Corrupt workers” will also pretend to be a CSIRT member.
  3. Out of the conversation, each player points out the person who they think is the “corrupt worker” at the end of the turn. The person who has the higher number of votes is dismissed from the game. “Corrupt workers” secretly put the blame to a CSIRT member to get them out of the game.

Process 2 and 3 will be repeated until either of the following conditions is met:

a) All the “corrupt workers” are dismissed (CSIRT wins)

b) The number of remaining “corrupt workers” becomes the same as CSIRT members (“Corrupt workers” win)

Among the board games on cyber security, “SEC WEREWOLF” is relatively easy and suitable for beginners since there is not much prerequisite. This game presents the concept of cyber security and roles within CSIRTs (some role cards have different technical skills). Furthermore, it comes with post-game materials to learn about internal fraud by looking back on how a “corrupt worker” would behave and what CSIRT members needed to do about it. It is also a good material to learn what kind of personnel a CSIRT would need to have.

A model of internal fraud “the Fraud Triangle”, was proposed by D.R. Cressey, a criminologist from the US. It suggests that internal fraud can occur when the following three factors are present: Perceived unshareable financial need, Perceived opportunity and Rationalisation [2].

The post-game material provides a review of the game from the above three perspectives. Also, by looking back at the conversation that occurred during the game, the facilitator can guide participants to further discuss lessons learned from the game. Consequently, they can consider what sort of environment they need to establish/maintain to keep their workplace from such fraud.

Facilitator explaining about internal fraud based on the triangle

The Working Group designed this game for people who are not familiar with cyber security. It is often said that cyber security operations are difficult to draw attention from employees unless they are actually involved. Given the current situation where cyber security is a hot topic not only for organisations but also for individuals, it is important to raise security awareness to wide range of employees and users. This board game provides a good opportunity to familiarise the players with the concept of cyber security and the role of CSIRTs.

Role cards
Trial at JPCERT/CC

To fully utilise this game, it is also important to develop game facilitators. This role is important in presenting the knowhow in cyber security, how CSIRTs work and the components of CSIRT employees, besides just leading the game.

There is another board game about initial response to cyber incidents, which the Working Group is planning to release in the coming Fiscal Year. JPCERT/CC is willing to assist awareness raising activities through the Working Group.

- Sho Aoki

Translated by Yukako Uchida


[1] About JNSA

[2] The Fraud Triangle – The Association of Certified Fraud Examiners

Mar 23, 2017

Malware Clustering using impfuzzy and Network Analysis - impfuzzy for Neo4j -

Hi again, this is Shusei Tomonaga from the Analysis Center.

This entry introduces a malware clustering tool “impfuzzy for Neo4j” developed by JPCERT/CC.

Overview of impfuzzy for Neo4j

impfuzzy for Neo4j is a tool to visualise results of malware clustering using a graph database, Neo4j. A graph database is a database for handling data structure comprised of records (nodes) and relations among the records. Neo4j provides functions to visualise registered nodes and relations in a graph.

impfuzzy for Neo4j operates in the following sequence:

  1. Calculate the similarity of malware using impfuzzy
  2. Generate a graph (network) based on the similarity
  3. Conduct network analysis over the graph (clustering)
  4. Register and visualise the clustering results on Neo4j database

First, the tool calculates the similarity of malware using impfuzzy; the techniques to estimate the similarity of Windows executables based on a hash value generated from Import API. impfuzzy was introduced in our blog article before, so please take a look for further details.

After that, a graph is generated by connecting nodes that were judged to be similar based on the impfuzzy results. The graph is then analysed using Louvain method [1]. This is one of the methods to cluster network graphs, which outperforms other algorithms in speed. With this analysis, malware is automatically classified into groups.

Finally, the information of analysed malware and its group is registered in Neo4j database.

Figure 1 describes the clustering result of Emdivi malware using impfuzzy for Neo4j.

Figure 1: Clustering result of Emdivi by impfuzzy for Neo4j

In this graph, types of malware (pink nodes) that are judged to be similar are connected with lines. From the above visualisation, it is clear that there are several groups of their variants with high similarity.

Since impfuzzy for Neo4j automatically clusters related samples through network analysis, it is possible to extract samples that belong to a specific group. Figure 2 visualises the relationship of a specific group from the example in Figure 1. The numbers on the grey lines (grey edges) between samples indicate the similarity of the malware in the range from 0 to 100 (the higher the number is, the more similar the samples are).

Figure 2: Visualisation results of samples belonging to a specific group

How to obtain and use impfuzzy for Neo4j

The tool is available on GitHub. Please refer to the following webpage:

JPCERTCC/aa-tools GitHub - impfuzzy for Neo4j

Here are the instructions for using impfuzzy for Neo4j.

1. Obtain and install Neo4j community edition

Download Neo4j community edition from the following webpage and install it:

2. Download

From the following webpage:

3. Install the software required for executing

  • Install Python module pyimpfuzzy
$ pip install pyimpfuzzy

For more information on the install procedures, please see:

  • Install Python module py2neo v3
$ pip install py2neo

For more information on the install procedures, please see:

  • Download Python script from the following webpage and save it to the same folder as

4. Run Neo4j

Run Neo4j by GUI or a command line.

5. Configure a password for Neo4j in

Configure the login password for Neo4j in (change the {password} below).

NEO4J_PASSWORD = "{password}"

How to use impfuzzy for Neo4j

To use impfuzzy for Neo4j, use these options to specify the input of malware to cluster.

  • -f - Specify malware (a file)
  • -d - Specify a folder where malware is stored
  • -l - Specify a CSV file(*) which lists malware

(*) The format of CSV files are the following:

File name, impfuzzy hash value, MD5 hash value, SHA1 hash value, SHA256 hash value

In the following example, malware is stored in the folder ‘Emdivi’ which is passed as a parameter.

Figure 3: impfuzzy for Neo4j execution result

Clustering results are registered in Neo4j database. Visualisation is available through the web interface of Neo4j, which is accessible from the URL below (The following is an example of Neo4j installed in a local environment).


For visualising a graph of clustering results, a Cypher query (a command to operate Neo4j database) needs to be executed through the web interface. Figure 4 is an example of executing a Cypher query through the web interface.

Figure 4: Example of Cypher query execution

Cypher queries to execute are different depending on what kind of clustering results you would like to visualise. Below are the examples of Cypher queries to visualise different clustering results.

[Example 1] Visualise all clustering results (Figure 1 is the result of the following Cypher query)

$ MATCH (m:Malware) RETURN m

[Example 2] Visualise a group of samples with a specific MD5 hash value (Figure 2 is an example of the following Cypher query)

MATCH (m1:Malware) WHERE m1.md5 = "[MD5 hash value]"
MATCH (m2:Malware) WHERE m2.cluster = m1.cluster


[Example 3] Visualise all clustering results with impfuzzy similarity level over 90

$ MATCH (m:Malware)-[s:same]-() WHERE s.value > 90 RETURN m,s


Clustering large amount of malware to distinguish unknown types that needs to be analysed in a quick manner is crucial in malware analysis. We hope that impfuzzy for Neo4j will help such analysis tasks.

In a future entry, we will introduce the clustering and analysis results that we gained through this tool.

- Shusei Tomonaga

(Translated by Yukako Uchida)


[1] The Louvain method for community detection in large networks