58 posts categorized "#JPCERT news" Feed

Mar 06, 2018

Malware “TSCookie”

Around 17 January 2018, there were some reports on the social media about malicious emails purporting to be from Ministry of Education, Culture, Sports, Science and Technology of Japan [1]. This email contains a URL leading to a malware called “TSCookie”. (Trend Micro calls it “PLEAD” malware [2]. Since PLEAD is also referred to as an attack campaign, we call this malware TSCookie in this article.) TSCookie has been observed in the wild since 2015, and it is suspected that an attacker group “BlackTech” is related to this campaign [3]. JPCERT/CC confirmed that adversaries using the malware had conducted targeted attacks against Japanese organisations in the past. This article presents findings from TSCookie analysis.

Overview of TSCookie

Figure 1 describes the flow of TSCookie’s execution.

Figure 1: Overview of TSCookie

TSCookie itself only serves as a downloader. It expands functionality by downloading modules from C&C servers. The sample that was examined downloaded a DLL file which has exfiltrating function among many others (hereafter “TSCookieRAT”). Downloaded modules only runs on memory.

Behaviour of TSCookie and TSCookieRAT will be explained in detail in the following sections.

Behaviour of TSCookie

TSCookie communicates to C&C servers using HTTP protocol and downloads “a module” and “a loader” for loading the module. The malware has an encrypted DLL file in its resource. When the malware is executed, the DLL file is loaded and executed on memory. The DLL file performs main functions such as communicating with C&C servers. (In some cases, the main function part is not encrypted and stored in the malware as is. Also, some samples launch another process and inject decrypted DLL file.) The malware has configuration information encrypted with RC4, including C&C server information. Please refer to Appendix A for the details of the configuration.

Below is an example of an HTTP GET request that TSCookie sends at the beginning. The outbound message is encoded and included in the Cookie header.

GET /Default.aspx HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Date: Thu, 18 Jan 2018 10:20:55 GMT
Pragma: no-cache
Accept: */*
Cookie: 1405D7CD01C6978E54E86DA9525E1395C4DD2F276DD28EABCC3F6201ADAA66F55C15352D29D0FFE51BC9D431EB23E8E58959653D9366E372B5CFCC49BB
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Win32)
Host:[host name]:443

The data contained in the Cookie header is encrypted with RC4 (The key is the Date header value). Please refer to Appendix B, Table B-1 for the data format.

The data obtained by this HTTP GET request is RC4-encrypted with the 8byte value which is made up with the fixed value in the configuration (Appendix A, Table A-1) and the value in the sent data (“4byte generated from system information” in Appendix B, Table B-1). This data includes loader for the module.

TSCookie then downloads a module. Below is an example of HTTP POST request for downloading a module.

POST /Default.aspx HTTP/1.1
Connection: Keep-Alive
Date: Thu, 18 Jan 2018 10:30:55 GMT
Content-Type: application/x-www-form-urlencoded
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Win32)
Content-Length: 34
Host: [host name]:443


The sent data is RC4-encrypted as well (the key is the Date header value). Please refer to Appendix B, Table B-2 for the data format. The data obtained by this HTTP POST request is RC4-encrypted with the same key as in the HTTP GET request. The downloaded module can be executed by loading it on memory and calling the loader obtained by the HTTP GET request.

Behaviour of TSCookieRAT

TSCookie provides parameters such as C&C server information when loading TSCookieRAT. Upon the execution, information of the infected host is sent with HTTP POST request to an external server. (The HTTP header format is the same as TSCookie.)

The data is RC4-encrypted from the beginning to 0x14 (the key is Date header value), which is followed by the information of the infected host (host name, user name, OS version, etc.). Please refer to Appendix C, Table C-1 for the data format.

Figure 2 is an example of sent data (decoded).

Figure 2: Part of sent data (decoded): Sending out information on the infected hosts)


After that, TSCookieRAT sends an HTTP GET request. (The HTTP header payload is the same as TSCookie.) With this request, commands are sent from a C&C server, and TSCookieRAT executes functions as listed below. (Please refer to Appendix C, Table C-2 for received data, and to Appendix D, Table D-1 for the list of commands.)

  • Execute arbitrary shell command
  • Send drive information
  • Send system information
  • File operation
  • Collect passwords from Internet Explorer, Edge, Firefox, Chrome, Outlook

The result of command execution is sent in the same format as in the first HTTP POST request (for sending the information of the infected host). The commands sent from a C&C server are not encoded. Below is the example of sent data (decoded) when executing a command for listing processes and modules.

Figure 3: Part of sent data (decoded): Result of the command 0x930 execution

TSCookie Decode Tool

JPCERT/CC made a tool to decode and extract TSCookie’s configuration information. This is available on Github for your use.

JPCERTCC/aa-tools · GitHub


Figure 4: Running tscookie_decode.py (example)

In closing

The adversaries using TSCookie have been conducting attacks against Japanese organisations using various types of malware. As this attack campaign is likely to continue, JPCERT/CC will continue to watch the trend carefully.

The hash value of the samples that were examined for this article are listed in Appendix E. Some of the destination hosts associated with TSCookie are also listed in Appendix F. Please make sure that none of your devices is communicating with such hosts.

For any inquiries, please contact global-cc[at]jpcert.or.jp.

- Shusei Tomonaga

(Translated by Yukako Uchida)


[1] piyolog: Summary on Ministry of Education, Culture, Sports, Science and Technology Scam in January 2018 (Japanese)


[2] Trend Micro: Following the Trail of BlackTech’s Cyber Espionage Campaigns


[3] Trend Micro: Following the Trail of BlackTech’s Cyber Espionage Campaigns


Appendix A: TSCookie configuration information
Table A: List of configuration information
Offset Description Remarks
0x000 Flag for host 1 Perform communication if 0x01
0x004 Port number 1 for host 1  
0x008 Port number 2 for host 1  
0x010 Host 1  
0x100 Flag for host 2  
0x104 Port number 1 for host 2  
0x108 Port number 2 for host 2  
0x110 Host 2  
0x200 Flag for host 3  
0x204 Port number 1 for host 3  
0x208 Port number 2 for host 3  
0x210 Host 3  
0x300 Flag for host 4  
0x304 Port number 1 for host 4  
0x308 Port number 2 for host 4  
0x310 Host 4  
0x400 Proxy server  
0x480 Proxy port number  
0x484 Flag for proxy configuration  
0x500 ID  
0x604 Fixed value RC4 key for 4byte (0x925A765D)
0x89C Suspended time  
Appendix B Data that TSCookie sends/receives
Table B-1: Format of data contained in Cookie header
Offset Length Contents
0x00 4 4byte generated from system information (*)
0x04 4 0x10050014
0x08 4 0x10001
0x0C 4 0xAB1
0x10 4 0x04
0x14 4 4byte generated from system information
0x18 - Random data

(*) RC4-encrypted with the fixed value (0x925A765D)

Table B-2: Format of data contained in HTTP POST data
Offset Length Contents
0x00 4 4byte generated from system information
0x04 4 0x10050014
0x08 4 0x10001
0x0C 4 0xAAD
0x10 4 Data length after 0x14
0x14 - Random data
Appendix C: Data that TSCookieRAT sends/receives
Table C-1: Format of data contained in HTTP POST data
Offset Length Contents
0x00 4 4byte generated from system information
0x04 4 0x10050014
0x08 4 0x10001
0x0C 4 0xAAD
0x10 4 Data length after 0x14
0x14 - Information of the infected host (RC4 encrypted with the key for “4byte generated from system information”)

*RC4-encrypted with Date header value up to 0x14

Table C-2: Format of data received
Offset Length Contents
0x00 4 Command
0x04 4 Data length after 0x8
0x08 - Parameter
Appendix D: Commands used by TSCookieRAT
Table D-1: List of commands
Value Contents
0x912 Configure suspended time
0x930 List processes and modules
0x932 Terminate
0x934 Start remote shell
0x935 Execute remote shell command
0x936 End remote shell
0x946 Obtain IP address
0x950 Execute files (with window display)
0x951 Execute files (without window display)
0x952 Send message
0x953 Send drive information
0x954 Send file list
0x955 Send file size
0x956 Send file
0x957 Close object handle
0x958 Select file to send (send file with 0x955, 0x956)
0x959 Download file
0x95A Delete file
0x95C Move file
0x95E -
0x960 -
0x96B Obtain window title
0x96E Collect password from Internet Explorer, Edge, Firefox, Chrome, Outlook
Appendix E: SHA-256 values of the samples


  • 6d2f5675630d0dae65a796ac624fb90f42f35fbe5dec2ec8f4adce5ebfaabf75
  • cdf0e4c415eb55bccb43a650e330348b63bc3cbb53f71a215c44ede939b4b830
  • 17f1996ad7e602bd2a7e9524d7d70ee8588dac51469b08017df9aaaca09d8dd9
  • 1fa7cbe57eedea0ebc8eb37b91e7536c07be7da7775a6c01e5b14489387b9ca8
  • e451a1e05c0cc363a185a98819cd2af421ac87154702bf72007ecc0134c7f417
  • 1da9b4a84041b8c72dad9626db822486ce47b9a3ab6b36c41b0637cd1f6444d6
  • 35f966187098ac42684361b2a93b0cee5e2762a0d1e13b8d366a18bccf4f5a91
  • 0683437aebd980c395a83e837a6056df1a21e137e875f234d1ed9f9a91dfdc7f
  • 0debbcc297cb8f9b81c8c217e748122243562357297b63749c3847af3b7fd646
  • 96306202b0c4495cf93e805e9185ea6f2626650d6132a98a8f097f8c6a424a33
  • 6b66c6d8859dfe06c0415be4df2bd836561d5a6eabce98ddd2ee54e89e37fd44
  • 06a9c71342eeb14b7e8871f77524e8acc7b86670411b854fa7f6f57c918ffd2b
  • 20f7f367f9cb8beca7ce1ba980fafa870863245f27fea48b971859a8cb47eb09
  • f16befd79b7f8ffdaf934ef337a91a5f1dc6da54c4b2bee5fe7a0eb38e8af39e
  • 12b0f1337bda78f8a7963d2744668854d81e1f1b64790b74d486281bc54e6647
  • 201bf3cd2a723d6c728d18a9e41ff038549eac8406f453c5197a1a7b45998673
  • 5443ee54a532846da3182630e2bb031f54825025700bcd5f0e34802e7345c7b2
  • 39d7d764405b9c613dff6da4909d9bc46620beee7a7913c4666acf9e76a171e4
  • afe780ba2af6c86babf2d0270156da61f556c493259d4ca54c67665c17b02023
  • 4a8237f9ecdad3b51ffd00d769e23f61f1e791f998d1959ad9b61d53ea306c09
  • 203c924cd274d052e8e95246d31bd168f3d8a0700a774c98eff882c8b8399a2f


  • 2bd13d63797864a70b775bd1994016f5052dc8fd1fd83ce1c13234b5d304330d
Appendix F: Destination hosts associated with TSCookie
  • jpcerts.jpcertinfo.com
  • jpcert.ignorelist.com
  • twnicsi.ignorelist.com
  • twcertcc.jumpingcrab.com
  • okinawas.ssl443.org
  • apk36501.flnet.org
  • appinfo.fairuse.org
  • carcolors.effers.com
  • edu.microsoftmse.com
  • eoffice.etowns.org
  • epayplus.flnet.org
  • fatgirls.fatdiary.org
  • gethappy.effers.com
  • iawntsilk.dnset.com
  • inewdays.csproject.org
  • ktyguxs.dnset.com
  • lang.suroot.com
  • langlang.dnset.com
  • longdays.csproject.org
  • lookatinfo.dnset.com
  • newtowns.flnet.org
  • ntp.ukrootns1.com
  • office.dns04.com
  • savecars.dnset.com
  • splashed.effers.com
  • sslmaker.ssl443.org

Feb 20, 2018

Identify Mirai Variant Infected Devices from SSDP Response

As it has been discussed in some reports from security researchers, devices infected with Mirai and its variants are forming large-scale botnets, which are often leveraged as a platform for attacks such as DDoS and other malicious activities.

JPCERT/CC has been conducting investigation and analysis of infection activities caused by Mirai variants from 2016 and providing measures to prevent further infection both in Japan and overseas. At the end of October 2017, given the significant increase in the devices infected with Mirai and its variant, JPCERT/CC issued a security alert on 19 December. For the release of this alert, JPCERT/CC coordinated with a device vendor in identifying the infected device models. This entry introduces the approaches that we took for this investigation.

Observation results and initial investigation

In late October 2017, we confirmed through JPCERT/CC’s packet traffic monitoring system (TSUBAME) that devices infected with a Mirai variant were carrying out scans to global IP addresses, targeting Port 23/TCP and 2323/TCP. Further detailed analysis revealed some of the source IP addresses used for the scan activities. [1]

Comparing the IP addresses against the network scan results provided by local/global security organisations, it turned out that most of the affected hosts were accessible directly from the Internet through Simple Service Discovery Protocol (SSDP).

How to Identify MAC address from SSDP response

SSDP is one of the protocols used for Universal Plug and Play (UPnP), which enables searching for devices connected to the network, and Port 1900/UDP is assigned. Communication performed when searching for devices with SSDP is described in Figure 1.

Figure 1: Part of communication for searching devices using SSDP

In this protocol, a client sends a query (M-SEARCH) to the network, and devices received this query returns a response (NOTIFY).

The NOTIFY response contains information about the device itself, including Universally Unique Identifier (UUID). This is a string to uniquely identify an object on the software. There are 5 versions for UUID [2], and the version 1 is based on the timestamp (when the UUID was generated) and the MAC address of the device. Figure 2 explains the data structure of the UUID version 1.

Figure 2: Structure of UUID version 1

In this version, the device’s MAC address is inserted in the UUID’s last 12 digits. This means that the device itself can be identified by looking at the NOTIFY payload in response to a SSDP query. The device vendor can also be determined from the vendor ID, which lies in the first 3 octets of the MAC address.

Identify infected devices and take measures

Most of the devices that were found infected with a Mirai variant had been used with SSDP service publicly available on the Internet, and its UUID was version 1. This made us possible to identify the MAC address and consequently the vendor of the affected devices. From the MAC addresses and packet traffic observed through TSUBAME, JPCERT/CC coordinated with the vendor in question and identified the affected device models, which led to the release of the security alert together with some related organisations to raise users’ awareness.

JPCERT/CC continues to coordinate with vendors in investigation on devices and request for security measures, so that the any further infection can be prevented.


We introduced how we came to identify infected devices. If SSDP port is left publicly accessible on the Internet, it has potential risks to be used for DDoS attacks [3] and other malicious activities leveraging UPnP vulnerability [4] [5]. If you are using UPnP-equipped devices, please make sure that the security measures are properly taken such as 1) keep the firmware up-to-date, 2) not expose UPnP service on the Internet and 3) disable UPnP function if not being used.

If you have any questions, please contact global-cc[at]jpcert.or.jp.

Thanks for reading.

- Tomoaki Tani

(Translated by Yukako Uchida)


[1] JPCERT/CC Internet Threat Monitoring Report [October 1, 2017 - December 31, 2017] [JPCERT/CC]


[2] RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace


[3] Alert (TA14-017A) UDP-Based Amplification Attacks [US-CERT]


[4] US-CERT Vulnerability Note VU#357851

UPnP requests accepted over router WAN interfaces


[5] CVE-2014-8361 Detail [NIST]


Dec 05, 2017

Research Report Released: Detecting Lateral Movement through Tracking Event Logs (Version 2)

In June 2017, JPCERT/CC released a report “Detecting Lateral Movement through Tracking Event Logs” on tools and commands that are likely used by attackers in lateral movement, and traces that are left on Windows OS as a result of such tool/command execution. After the release, we received a lot of feedback on the report, and until now we had been working on the revision based on the comments. Today, we are happy to announce that the updated report is released.

Detecting Lateral Movement through Tracking Event Logs (Version 2)


Tool Analysis Result Sheet


Here is a quick summary of the update.

Updated Contents

This report is intended for incident investigation and explains what logs are recorded and what files are created upon execution of tools/commands that are often used in lateral movement. While the previous report mainly focused on investigation on event logs and registry entries, this revision also takes forensic investigation into account, as to what to examine in USN Journal, AppCompatCache and UserAssist. Other updated contents are as listed below:

  • Verification using Windows 10
  • Verification using Sysmon version 5
  • Added evidence to investigate
    • USN Journal, AppCompatCache, UserAssist etc.
  • Investigation on network communication
    • Proxy, firewall etc.
  • Added/Replaced attack tools to examine
  • Report released in HTML format

Please see Appendix A for the list of 49 tools/commands that are covered in this report.

Report Format

Unlike the previous single PDF document, this updated report consists of two parts: “Report” and “Tool Analysis Results Sheet”. The “Report” provides an overview on how the research was conducted, how this report can be used for actual investigation and things to note upon usage. “Tool Analysis Result Sheet” provides the actual detailed information that is recorded when the 49 tools/commands are executed.

We recommend that you go through the investigation instructions on the “Report”, before stepping into “Tool Analysis Result Sheet”.


As our understanding towards attack methods deepens, adversaries would come up with new attack techniques. We intend to cover such new attack methods in the potential revisions. If you like us to investigate any specific tool or any items on Windows, please let us know. We welcome your feedback at global-cc[at]jpcert.or.jp.

- Shusei Tomonaga

(Translated by Yukako Uchida)

Appendix A Examined Commands and Tools
Table 1: List of Examined Commands and Tools
Attacker's Purpose of Using Tool Tool
Command execution PsExec
Password and hash dump PWDump7
Quarks PwDump
(Obtain password hash lsadump::sam)
(Obtain password hash sekurlsa::logonpasswords)
(Obtain ticket sekurlsa::tickets)
Get-GPPPassword (PowerSploit)
Invoke-Mimikatz (PowerSploit)
Out-Minidump (PowerSploit)
PowerMemory (RWMC Tool)
Malicious communication relay Htran
Fake wpad
Remote logon RDP
WCE (Remote login)
Mimikatz (Remote login)
Escalation to SYSTEM privilege MS14-058 Exploit
MS15-078 Exploit
SDB UAC Bypass
Capturing domain
administrator rights account
MS14-068 Exploit
Golden Ticket (Mimikatz)
Silver Ticket (Mimikatz)
Adding or deleting
local user and group
net user
File sharing net use
Deleting evidence sdelete
klist purge
Information collection ntdsutil

Nov 30, 2017

Visualise Event Logs to Identify Compromised Accounts - LogonTracer -

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

Event log analysis is a key element in security incident investigation. If a network is managed by Active Directory (hereafter, AD), can be identified by analysing AD event logs. For such investigation, it is quite difficult to conduct detailed analysis in AD event viewer; it is rather common to export the logs to text format or import them into SIEM/log management system. However, since the amount of event logs can be massive depending on the environment, this can be a struggle for analysts.

JPCERT/CC has developed and released a tool “LogonTracer” which supports such event log analysis. This entry introduces how it works and how to launch it.

Event Log Visualisation by LogonTracer

LogonTracer associates a host name (or an IP address) and account name found in logon-related events and displays it as a graph. This way, it is possible to see in which account login attempt occurs and which host is used. Figure 1 is a graph created by LogonTracer, which shows the relations of some IP addresses and accounts.

Figure 1: Result of AD event log visualisation on LogonTracer

Here are the details of each node. An account (Red/Blue) that is connected to a host (Green) with a line shows that it is logged on using the host.

  • Red: SYSTEM privilege account
  • Blue: Standard user account
  • Green: Host/IP address

This visualisation makes the analysis simple even for those without detailed knowledge about event logs.

Extract More Important Accounts and Hosts

In addition to event log visualisation, LogonTracer is able to display possibly leveraged accounts/hosts by ranking. Figure 2 is an example of importance rank of accounts and hosts.

Figure 2: Ranking of accounts and hosts that have higher importance

For this ranking, LogonTracer performs network analysis on the event log graph, and creates a ranking based on the “centrality” of each node. Centrality is an index which indicates each node’s proximity to the centre in a network. For calculation of centrality, PageRank [1] is applied. In this algorithm, nodes that have connection to many other nodes are located towards the centre of the graph and therefore have a higher centrality.

As compromised accounts are used to perform login attempts to many hosts, they tend to have a higher centrality. Consequently, by comparing the centrality, possibly affected accounts/hosts can be identified.

Chronological Display of Event Logs

With LogonTracer, it is also possible to display event logs in a chronological order. Figure 3 shows the number of event logs for each account in a time series.

Figure 3: Event logs in timeline

By checking the number of logs in the course of time, unauthorised logon attempts during a short period of time or outside of working hours can be spotted.

Drastic increase of event logs is automatically highlighted. For detecting the increase of the count, Change Finder [2] is applied as an anomaly detection method. 

How to Install LogonTracer

This tool is available on GitHub. You can download it from the following webpage:

JPCERTCC GitHub - LogonTracer


Here is the instruction on how to use LogonTracer. The tool was tested on a Linux environment.

  1. Obtain and install Neo4j community edition

Download Neo4j community edition from the below website and install it:


  1. Download LogonTracer

Download from the below webpage and deploy it in a folder.


  1. Install Neo4j JavaScript driver

Install Neo4j JavaScript driver in static folder of LogonTracer.

$ cd LogonTracer/static
$ npm install neo4j-driver
  1. Install Python module

Install Python module for LogonTracer

$ pip install -r requirements.txt

*If statsmodels installation fails, install numpy first.

  1. Launch Neo4j

Launch Neo4j by GUI or command line.

How to use LogonTracer

Launch LogonTracer using the below option:

$ python3 logontracer.py -r -o [PORT] -u [USERNAME] -p [PASSWORD] -s [IP Address]
  • -r: Launch web server
  • -o: Port number where the web server operates (ex: 8080)
  • -u: Neo4j username (“neo4j” by default)
  • -p: Neo4j password
  • -s: Address where the web server operates (ex: localhost)

Below is an example of executing LogonTracer.


To access the web interface, please go to the below URL from your browser. (In this environment, LogonTracer was installed in a local environment and runs on the port 8080).


To import logs, you can upload in EVTX format.

Figure 4: Upload event logs

How to Use Docker Image

Docker image of LogOnTracer is available on Docker Hub.


If using Docker, the image can be launched by the following command:

$ docker run \
   --detach \
   --publish=7474:7474 --publish=7687:7687 --publish=8080:8080 \
   -e LTHOSTNAME=[IP Address] \

Event Logs that LogonTracer can Analyse and Points to Note

A research conducted by JPCERT/CC “Detecting Lateral Movement in APTs” identifies that monitoring the following events is effective in investigating unauthorised logon. Based on that, LogonTracer is also designed to visualise the following event IDs for visualization:

  • Event ID 4624: Login successful
  • Event ID 4625: Login failed
  • Event ID 4768: Kerberos authentication (TGT request)
  • Event ID 4769: Kerberos authentication (ST request)
  • Event ID 4776: NTLM authentication
  • Event ID 4672: Privilege assignment

Because not all of the above event IDs are recorded with the default settings, Audit Policy needs to be enabled to retain such logs. We recommend enabling Audit Policy. For detailed instructions on the configuration, please see “Readme” of LogonTracer, which is also available on GitHub.


Although event logs analysis is crucial in incident investigation, it can be a time-consuming process if you do not know what to analyse and where to begin. This tool offers easy event log analysis by visualising the relations among accounts and hosts. We hope that you try this tool in preparation to actual incident investigation.

We will update soon with more information on how to conduct actual analysis using this tool.

Thank you for reading.

- Shusei Tomonaga

(Translated by Yukako Uchida)


[1] Wikipedia: PageRank


[2] IEEE: A unifying framework for detecting outliers and change points from time series


Aug 04, 2017

What the Avalanche Botnet Takedown Revealed: Banking Trojan Infection in Japan

Internet banking services across the globe have been exposed to the threat by unauthorized money transfers and suffering large-scale losses.

In this landscape, an operation led by international law enforcement agencies has been in effect since November 2016 to capture criminal groups conducting unauthorised online banking transfers and dismantle the attack infrastructure (the Avalanche botnet). JPCERT/CC is one of the many supporters of this operation.

For more information about the operation, please see below:

Europol Press Release:

‘Avalanche’ network dismantled in international cyber operation



‘Avalanche’ network dismantled in international cyber operation


This blog entry presents how JPCERT/CC supports this operation and the current state of malware infection in Japan revealed through our local coordination.

JPCERT/CC’s activities in the operation

Some organizations in support of this operation register domains related to the Avalanche botnet to observe communication between any infected devices and the DNS sinkhole. From all the observed data, CERT-Bund (the National CSIRT of Germany) provides information related to Japanese networks to JPCERT/CC. We then notify administrators of the infected hosts to request investigation and coordination to address the issue.

Characteristics of infected devices in Japan

Figure 1 shows the number of malware infected hosts linked to the Avalanche botnet, which were observed between 5 December 2016 and 31 May 2017. Note that extreme spikes caused by irregularities such as dates without any received data are excluded from the graph.

Figure 1: Number of malware infected hosts in Japan (per day)

In December 2016, when we first received data on the Avalanche botnet, there was a daily average of about 17,000 hosts communicating with the DNS sinkhole. However, it decreased to about 11,000 hosts per day at the end of May 2017, thanks to cooperation from our local partners.

In addition, multiple malware families have been observed within the Avalanche botnet. From the data, JPCERT/CC received between 5 December and 4 January, the ratio of malware observed in Japan was as follows:

Figure 2: Ratio of malware (linked to the Avalanche botnet) found in infected hosts in Japan

Rovnix, KINS, Shiotob (a.k.a. URLZone, Bebloh) are known as malware that harvest credentials for Internet banking services. We have confirmed that Rovnix and Shiotob were distributed as attachments to spam emails written in Japanese in 2016.


Through this operation, many infected hosts in Japan have been isolated from the botnet, which resulted in the decreasing trends as in Figure 1. However, besides the malware families hosted in the Avalanche botnet, other types of banking trojans such as Ursnif (or DreamBot) have also been distributed recently through spam emails written in Japanese. JPCERT/CC continues to alert local constituents about these threats.

- Shintaro Tanaka

(Translated by Yukako Uchida)

Jun 12, 2017

Research Report Released: Detecting Lateral Movement through Tracking Event Logs

JPCERT/CC has been seeing a number of APT intrusions where attackers compromise a host with malware then moving laterally inside network in order to steal confidential information. For lateral movement, attackers use tools downloaded on infected hosts and Windows commands.

In incident investigation, traces of tool and command executions are examined through logs. For an effective incident investigation, a reference about logs recorded upon tool and command executions would be useful.

JPCERT/CC conducted a research on typical tools and commands that attackers use after intrusion, and traces that they leave on Windows when executed. The result of the research is available on the report below:

Detecting Lateral Movement through Tracking Event Logs


This entry will introduce the overview of the report.

Intended Audience

This report is designed for technical staff including those responsible for initial investigation of incidents. Even without forensic software or knowledge in forensics, readers capable of examining event logs and registry entries can understand the contents.

Tools and Commands

44 typical tools and commands have been featured on the report (as described in Appendix A) based on what JPCERT/CC has seen in multiple incident cases. Since these tools and commands are used by multiple attackers, it is likely that analysts encounter some of them during incident investigation.

Need for Detailed Logs

Under the default configuration of Windows, many of these tools and commands are not logged. In order to investigate what attackers did during the incident, preparation for log retention is necessary. The report describes how to record tools and command executions by setting audit policy and installing Sysmon. Other than the methods explained in the report, it is also possible to collect such logs with audit applications or EDR products.

Way Forward

We are planning to examine other tools and commands as well. In addition to event logs and registry entries, we will also look into forensic artifacts such as MFT and journal files.

We welcome any feedback from you at global-cc [at] jpcert.or.jp.

-         Shusei Tomonaga

(Translated by Yukako Uchida)

Appendix A:  Examined Commands and Tools
Table 1: List of Examined Commands and Tools
Attacker's Purpose of Using ToolTool
Command execution PsExec
Obtaining password hash PWDump7
Quarks PwDump
Mail PassView
Remote Desktop PassView
Malicious communication relay
(Packet tunneling)
Fake wpad
Remote login RDP
Escalation to SYSTEM privilege MS14-058 Exploit
MS15-078 Exploit
Privilege escalation SDB UAC Bypass
Capturing domain administrator
rights account
MS14-068 Exploit
Golden Ticket (mimikatz)
Silver Ticket (mimikatz)
Capturing Active Directory database
(Creating a domain administrator user or
adding it to an administrator group)
Adding or deleting a user group net user
File sharing net use
net share
Deleting evidence sdelete
Deleting event log wevtutil
Obtaining account information csvde

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. redleavesscan.py 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 redleavesscan.py in ”contrib/plugins/malware” folder within Volatility, and execute the following command:

$python vol.py [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


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 impfuzzy_for_neo4j.py

From the following webpage:


3. Install the software required for executing impfuzzy_for_neo4j.py

  • 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 pylouvain.py from the following webpage and save it to the same folder as impfuzzy_for_neo4j.py


4. Run Neo4j

Run Neo4j by GUI or a command line.

5. Configure a password for Neo4j in impfuzzy_for_neo4j.py

Configure the login password for Neo4j in impfuzzy_for_neo4j.py (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