14 posts categorized "#Incident management" Feed

Aug 21, 2017

Detecting Datper Malware from Proxy Logs

This is Yu Nakamura from Analysis Center.

This entry is to explain features of Datper, malware used for targeted attacks against Japanese organisations and how to detect it from the logs.

JPCERT/CC has been observing attacks using Datper since around June 2016. Research reports on the adversary are published from LAC [1], SecureWorks [2] and Palo Alto Networks [3]. The adversary had also conducted attacks using Daserf malware in the past, and Symantec refers to them as “Tick” in their report [4].

Attack vectors

We have confirmed that Datper infection occurs by:

  • Drive-by download attacks
  • Exploiting vulnerabilities in asset management software

In the former attack vector, we observed that a vulnerability of Adobe Flash Player (CVE-2016-7892) was leveraged for downloading and executing Datper. For the latter, there were cases where devices also got infected with a downloader called “wali”. Some analysis of this downloader has been published by Kaspersky [5] and Cybereason [6]. We have seen that wali can download several types of malware, and Datper is one of them.

Detailed behaviour

Datper communicates with a C&C server using HTTP protocol and operates based on the received commands. One of the characteristics is that it only communicates within a specific period of time.

Here below is a sample HTTP request that Datper sends to a C&C server. User-Agent is hard-coded in the malware.

GET /hoge/index.php?fnyup=940785246f0c22b41joikeddfngjokyptui HTTP/1.1
Accept: */*
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Host: [host name]
Pragma: no-cache
Connection: close

The malware receives a command as a response to the above HTTP request, and it executes functions based on the commands. Functions that Datper can execute are the following:

  • Obtain host names, OS versions etc.
  • Obtain drive information
  • Configure communication intervals
  • Sleep for a set period of time
  • Execute a program
  • Operate on files (Obtain file lists, download, upload, delete)
  • Execute shell commands

After executing these functions, Datper sends the results to a C&C server.

How to detect Datper’s communication

Datper sends HTTP GET requests with two types of query strings as in format 1 and 2 in the following figure.

Figure 1: Query string formats

As in the Figure 1, <a>, <b> and <c> in the query strings vary for each communication. If the fixed value which comes after <c> is “1” (as in format 1 in the Figure), it represents a request for commands, while those with “2” (format 2 in the Figure) are sent when sending command execution result to a C&C server. Command execution results are contained in the encrypted data. When the encrypted data is larger than 1024 bytes, POST method is used instead of GET.

Strings as in the above Figure is typical for Datper’s communication and barely observed during usual web browsing. Based on the characteristics, it is possible to detect Datper’s communication by checking for logs that match the format - that strings are aligned in the order of <a>=<b><c> format and <b>’s CRC32 value matches <c>. For easy verification, the following is an example of Python script for checking proxy server logs. Regular expressions need to be modified according to the log format.

import re
import sys
from binascii import crc32
from ctypes import c_uint

filter_1 = re.compile('(http://[\da-z\.-]+\.[a-z\.]{2,6}/[\/\w_\.-]+\?[\da-z]{3,8}=([\da-f]{8})([\da-f]{8})[1-2]{1}\S+)\s', re.IGNORECASE)

def main():
    for line in sys.stdin:
        m1 = filter_1.search(line)
        if m1:
            url = m1.group(1).lower()
            d1 =  m1.group(2).lower()
            d2 =  m1.group(3).lower()
        d1_crc32 = "%08x" % c_uint(crc32(d1)).value
        if d1_crc32 == d2:
            print "hit: %s" % line            
if __name__ == '__main__':

Change in compression algorithm

As mentioned above, Datper’s communication contains encrypted data. More precisely, plain text data is compressed, encrypted and then encoded. As for the compression algorithm, LZNT1 had been used, however, it was replaced with LZRW1/KH around November 2016. Below is the list of compression and encryption methods that Datper uses.

Table 1: List of compression and encryption methods
  Compression algorithm Encryption algorithm Encode algorithm
Datper (Until October 2016) LZNT1 RC4 Base64 (alternative table)
Datper (After November 2016) LZRW1/KH xor + RC4 Base64 (alternative table)

The adversary has often used LZNT1 for attacks using Datper and other types of malware (xxmm/Minzen). While LZNT1 is easy to use with a Windows API “RtlDecompressBuffer”, LZRW1/KH is not covered in Windows API. The reason for this inconvenient choice is unclear, however, this change together with the slight update in the encryption algorithm may be due to the intention of the adversary to disturb the malware analysis processes.


The adversary using Datper had conducted targeted attacks using Daserf malware for a long period of time against Japanese organisations. Activity with Datper is also likely to continue for a while, and we will carefully watch the malware and its attack activity.

- Yu Nakamura

(Translated by Yukako Uchida)


[1] CYBER GRID VIEW Vol.2 | Security Information | LAC Co. Ltd. (Japanese)


[2] A whole picture of cyber attacks targeting Japanese companies – BRONZE BUTLER (Japanese)


[3] “Tick” Group Continues Attacks


[4] Tick cyberespionage group zeros in on Japan


[5] Old Malware Tricks To Bypass Detection in the Age of Big Data – Securelist


[6] ShadowWali: New variant of the xxmm family of backdoors | Cybereason


Appendix A SHA-256 Hash value of Datper Samples
  • Datper(LZNT1)







  • Datper(LZRW1/KH)




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)

Jul 05, 2017

Clustering Malware Variants Using “impfuzzy for Neo4j”

In a past article, we introduced “impfuzzy for Neo4j”, a tool to visualise results of malware clustering (developed by JPCERT/CC). In this article, we will show the result of clustering Emdivi using the tool. Emdivi had been seen until around 2015 in targeted attacks against Japanese organisations. For more information about Emdivi, please refer to JPCERT/CC’s report.

Clustering Emdivi with impfuzzy for Neo4j

Emdivi has two major variants - t17 and t20, and we chose the former for this analysis. Figure 1 shows the output of running impfuzzy for Neo4j.

Figure 1: Emdivi t17’s clustering result using impfuzzy for Neo4j

As a result of the analysis, 90 samples were clustered into 4 types. Figure 2 visualises the clustering results. Detailed results are documented in Appendix A. (For detailed instructions on the tool, please see our past blog article.)

Figure 2: Visualised result of Emdivi t17 clustering (Colouring provided for better understanding.)

It stood out that each cluster (Type 1 through Type 4) highly corresponds to the compiled date of the malware sample (see Appendix A).

Hash values of malware samples are generated by impfuzzy (Import API), which is then used to calculate the similarity. Therefore, the reason for this type clustering is unknown solely from this analysis. Manual analysis is required to examine what makes Import APIs different in each type.

The following sections will describe the reason why Emdivi t17 samples were clustered into 4 types and how the transition occurred from one type to another.

From Type 1 to 2

The clustering results in Appendix A indicate the transition from Type 1 to 2 occurred around September 2014. We noticed a change in linker versions.

PE files have header information called IMAGE_OPTIONAL_HEADER[1]. This contains MajorLinkerVersion and MinorLinkerVersion, which indicates its linker version. Looking into the linker version used when creating Emdivi t17, Type 1 mainly uses 10.0 (Visual Studio 2010) while Type 2 uses 9.0 (Visual Studio 2008). It is considered that these samples were differentiated due to the change in the linker version, which accordingly changed the Windows APIs that the malware loads.

From Type 2 to 3

It was around November 2014 when Type 2 changed to Type 3, and this transition reflects the change in the method of loading Windows API. Usually, PE file loads Windows API upon execution by specifying an API name in Import Name Table (INT) inside the PE header. (Please refer to a past blog article for more information.)

However, Type 3 samples possess some obfuscated Windows API names and load it when using Windows API. Figure 3 is the results of decoding obfuscated strings in Emdivi t17, which indicates that Type 3 contains some obfuscated Windows API names (marked in red).

Figure 3: Comparison of decoded strings in Emdivi t17 clustered as Type 2 and 3

The Windows APIs obfuscated in Type 3 are deleted from its INT. This means that the Windows API that the malware aims to execute cannot be identified by just looking at the INT.

This change in Windows API load method is thought to be the reason for the difference between Type 2 and 3.

From Type 3 to 4

Transition from Type 3 to 4 occurred around May 2015. This is due to a new bot (remote control) function being added. Here is the list of bot functions that Type 4 has. “GOTO” is the new function to Type 4.

  • GOTO

The added bot function resulted in new Windows APIs being used, which distinguishes Type 4 from 3.


It is not practical to manually analyse a large number of malware samples. It is rather important to automate malware clustering process to find new types of malware and changes in malware features. With the analysis example, we demonstrated an example of effective malware analysis using impfuzzy for Neo4j by focusing on samples with different features. The tool is available on Github, and we hope this helps your malware analysis.

- Shusei Tomonaga

(Translated by Yukako Uchida)


[1] Microsoft: IMAGE_OPTIONAL_HEADER structure

Appendix A Emdivi t17 Clustering Results
Table 1: List of Emdivi t17 Clustering Results
No. Compile Time EmdiviVersion LinkerVersion Type SHA256
1 2013-11-21 17:00:52 t17.08.2 10.0 1 6b0192ec4f0290c0c00517eeb75648e340dacc58189d9d6adee844283cda4a5f
2 2013-12-24 12:13:21 t17.08.2 10.0 1 c162df8761e09c95160e9d432d310a4673d53615c2ff837a1a6f322e45038180
3 2014-01-06 11:33:48 t17.08.2 10.0 1 bf8cba80f4d80e13f11c8231477f0b96c3a9e9abc8da798e6cede052f6801aa8
4 2014-01-06 11:48:05 t17.08.2 10.0 1 742c70238ea0b2b0a1d66660913b18deaff2af35c6dc5b19e9d2158249cae433
5 2014-01-19 16:12:41 t17.08.2 10.0 1 18dfb3ff38c802f54c66c7d06380e7aff4834ac7a0c9ea35e50f46cf40266c3a
6 2014-01-21 12:29:03 t17.08.2 10.0 1 08a542fe7f8450d2c66b5e428872860d584bc5be714a50293a10aef415310fe8
7 2014-01-21 20:07:01 t17.08.2 10.0 1 bf9229b342c144970358308ccb017802cb2ff5c2086bf0367d9d72f34556b7c1
8 2014-01-23 16:32:01 t17.08.2 10.0 1 2bf87ec696356a685b081b9e0aec88c3ac3e3353927f712e978db0d2f5a9476b
9 2014-02-28 10:52:43 t17.08.5 10.0 1 396c7766eb8873227c270eae2b13357dbcd68fa7f07053dd280375418eeee614
10 2014-03-13 13:05:13 t17.08.9 10.0 1 138e7c2e5cf0caba02d005752686a66482df23f4b4b648f446f2afada32a5750
11 2014-04-01 12:08:03 t17.08.9 10.0 1 4df19e155cac0735500cffae49007b3d971979cccca779a5af685db489b4b042
12 2014-05-07 13:52:46 t17.08.10 10.0 1 b97ab11d1154fae07d2cfab055cdc6b745a5117fc1d8e557f6a244040ba7cce3
13 2014-05-08 12:22:24 t17.08.10 10.0 1 04b9a6ef5ef6cdaf42e90431039bd56b68082c5056889cf4b9ababc6e0834b56
14 2014-05-11 15:44:46 t17.08.9 10.0 1 83620f29a19a4d372e256d98ebfd2d3e5cb4b8db97b385c2942914298b8d2870
15 2014-06-03 10:41:46 t17.08.9 10.0 1 4422d1568f729c316e8d02a35fe147c4c36c91d650989e9ac3caa6fbbc086b37
16 2014-07-17 10:48:24 t17.08.9 10.0 1 e7ae0995e3d4dd9c3fed51d5bca73ea9fa3edd90e2e87fc0cfac58165afdf4e8
17 2014-07-22 17:40:31 t17.08.9 10.0 1 7875c21473cf5f8d936f1335c049ae6df9e0b0574b263060d7a526f3d53cbf07
18 2014-07-28 18:01:59 t17.08.16 10.0 1 c805af2204c1d8612cd929b93fc5c38a448a03561d410d7a198c313553e47e39
19 2014-08-04 13:57:34 t17.08.16 10.0 1 3243925baa06dc69731da91da49242fd73aea38afe46e171708de4ecd4e53b80
20 2014-08-05 12:51:43 t17.08.18 8.0 1 92860e0a9e7dc49c43a0db87d4fb345294000ac3191af1dc6d702b89628c97eb
21 2014-08-06 09:22:32 t17.08.16 10.0 1 df97dd9607f0fdcc10f9ba99e6c3d01eb8453ceeeab840ef6b965458e24485bc
22 2014-08-12 18:09:41 t17.08.16 10.0 1 d26eb51e2787353b18c8f290f0710510423e3925a796697ff15aafd14fea6f2d
23 2014-08-18 12:21:10 t17.08.16 10.0 1 37f43f9c4298dc41f6b1ed03396cc1f7da664ed25e97c4263e6c360f59f3a51b
24 2014-08-19 20:01:29 t17.08.16 8.0 1 9fc76d0fb4f01819c0d9af09a0357dab6c33a4d5f6e41cafebeb9ef7ae35c99e
25 2014-09-09 13:34:21 t17.08.18 9.0 2 f017218f05d225cdb62f3081c4dac4b09a3fb2b93c01096bd4141b67d3eb3bbf
26 2014-09-18 09:26:42 t17.08.18 9.0 2 139e22abe7aaec635e2b570935636c4894a19a7b284516b77f190b78a369c4d6
27 2014-09-22 09:51:33 t17.08.18 9.0 2 a00e37d1d3fe990ebac26a4805a7ab42bd1dcf7ef65f151906204eee7b0c71fd
28 2014-09-25 10:34:10 t17.08.18 9.0 2 3d084155e6f79b45acba165cd4a17a3bed42daba478c14a795dc2c2809f302b6
29 2014-09-28 20:52:36 t17.08.18 9.0 2 196364b3e78add557b6f0471fb32061468bb2b20e16acd1a7686122234c984a7
30 2014-09-30 12:10:55 t17.08.21 9.0 2 8c3666940afd65835e4251fbd14942d210323d46adf57c5e8f29b61d552fd386
31 2014-10-07 11:50:57 t17.08.21 9.0 2 878937da134339ccd8c6bbc5ac020472c20a42fb1f07b56152cfcc1656077d62
32 2014-10-08 18:31:01 t17.08.21 9.0 2 b99f08be6a476d359820c48345ddf4f2f0fcc1ca041f3630680635c675a1d7be
33 2014-10-21 15:13:53 t17.08.21 9.0 2 1209d8b3c83c72df781b805a2c17a0939c841384aadc32e4e9005536a3bba53f
34 2014-10-24 17:16:08 t17.08.21.3 9.0 2 c89823eba2bdcdfcae33b33fb358154debe3fd88c75c684aa6b510e2d4b3ca53
35 2014-10-27 10:29:00 t17.08.21 9.0 2 884cbc1f0e70efae4815127bda7bab50883a707581d9d4061d268249c154ff2d
36 2014-10-28 12:48:54 t17.08.21 9.0 2 682b6c9d468e8d0ab8b5d4080cecf52a9dd66b59b99936a4941b8190c5f3fff9
37 2014-11-04 19:15:32 t17.08.23 9.0 3 23449109f0d4b07fd8010bb36b3b1084b48d5ac515725b68bf32322b4902397e
38 2014-11-05 21:15:57 t17.08.23 9.0 3 a79cfba79489d45a928ef3794d361898a2da4e1af4b33786d1e0d2759f4924c3
39 2014-11-05 22:00:42 t17.08.23 9.0 3 9801caaf44ce9a6be3f497e706f5b71dcc7c50351374c33dc2c9fcbb55f55e05
40 2014-11-06 13:55:46 t17.08.23 9.0 3 b19a233b07a1342f867aef1b3fb3e473b875bd788832bb9422cacb5df1bda04e
41 2014-11-13 10:52:56 t17.08.23 10.0 1 6c4c3bc7b0dfe531790bfb023b141c23f3c17a9971fed704d1b46e43f97d41c1
42 2014-11-13 11:34:31 t17.08.23 10.0 1 21a51f69d08aaf0aaaeb5b8413bb710c1727d9d08a9a1f46883f6f93691e0870
43 2014-11-14 13:10:40 t17.08.25 9.0 3 28a774235865924a7fec405aaf6463164a03f6e646c9fd964c3191304e59d35b
44 2014-11-18 11:56:13 t17.08.25 9.0 3 29a480579353c85e48b996ebc38cad9313ad6b9e495a3a69bf1519837acab04f
45 2014-12-08 15:19:29 t17.08.25 9.0 3 34bc147423f565bf38100913d25f85057e252755eef622abc1b788d511caf605
46 2014-12-11 18:28:38 t17.08.25 9.0 3 a188b87e495e4b0aad0d0595987677f9758479b120fb2ed3a04fba308a66830a
47 2014-12-16 18:13:13 t17.08.25 9.0 3 e39b1b36a5da4ad0f9c103478ab469b13a0528540ddbd1679eb24349a6726dbf
48 2014-12-24 10:37:26 t17.08.25 9.0 3 037b0dbfc2643a4a4779f6e3a8e5c8c41cbcd64533d2245c9a26dfd1d4f55dd8
49 2015-01-12 11:58:46 t17.08.25 9.0 3 9e74825e251a4f4cef9bc98273082f3b58695a224b1ed16ba6dedaa4c154cb21
50 2015-01-20 11:10:12 t17.08.26 9.0 3 5e221bd0eef231b7a948d8f6a2f660f8d6685cf2711fe50311485227ebcf9e51
51 2015-01-20 11:59:37 t17.08.26 9.0 3 635b43f7c0508f5e2cbf26f81daf0a730a0f0b06303c54c747b780f91430bb7f
52 2015-01-22 11:25:49 t17.08.26 9.0 3 efa57d43145de9a1e3c7541f94837a9c7b76d604b779d9847637d4a55b1ee723
53 2015-01-22 16:06:33 t17.08.26 9.0 3 9ace48ecef568bb9f5ccd462ca3efb4c2fbc15f0316323f1729e88cbe184158d
54 2015-01-23 10:14:46 t17.08.26 9.0 3 42e6b7afe4da672ab9bf647e73201135b3faf2121b629612b35307dc0d8698e4
55 2015-01-26 10:15:10 t17.08.26 9.0 3 9ebef65f00fc6ad70f591f7fb1f39f0f6b1766ff3fd9f47693ce669e70f84abb
56 2015-02-03 11:35:23 t17.08.26 8.0 3 6aed51b108d9f9f197842e17b0f58d4dec3709ca1eae4d42146d0bba0c145eaf
57 2015-03-02 10:18:13 t17.08.27 9.0 3 f6fce0464f1ad8044092e6812bdfb8545e1df5ee23aba828b4dcb86fb6d0e62b
58 2015-03-04 13:08:13 t17.08.27 9.0 3 fca765c535d1870d71ee152e5b004e73515ade1ee1c9a512a0858a508380465d
59 2015-03-05 12:59:51 t17.08.27 9.0 3 eac8441227077edb28adf096c5493710e2ca1978f4e4c4b2b93d481cd482d890
60 2015-03-17 12:50:29 t17.08.27 9.0 3 9f66ad282373b8b0df45dd32723dcdfcd4821e22cba4912678c3c8632e722730
61 2015-03-19 16:03:19 t17.08.27 9.0 3 77fa012060884d17eea1e54d97176a7a88c499f03315dfd602c1e1e17e556ede
62 2015-03-20 11:44:49 t17.08.27 9.0 3 3cade660e227faadad0060d793b69cb778842a514ac6996bc6aaddb6a055f445
63 2015-03-20 13:04:19 t17.08.27 9.0 3 6c3b955ad677ff26428d95a35b3a22ca3d523265674f08b6a0b59df270e6bf19
64 2015-03-24 13:07:23 t17.08.27 9.0 3 400a08b4a067b1e2fb3bee509bf933a746cf3ef2d000bb3181c7176344641a01
65 2015-04-22 12:29:48 t17.08.29 9.0 3 e3a2d62a997d4e9ee581fd86d312ac34caddd3165c07ca30c6741b4c21088d08
66 2015-04-24 12:07:43 t17.08.29 10.0 1 782b3bed336eab77a49df51e697bc64d830f7f11a32ff49abc599fe5b074e0b9
67 2015-05-20 12:52:28 t17.08.30 9.0 4 e03e6f7d98b214b5051b7484e4099ce5bd8c46e49faf44002c8ba146977127ef
68 2015-05-21 16:38:39 t17.08.30 9.0 4 28426751f30de4091dee898c70f49ec2ece607b6b642b45f5dcd9ae73ac38739
71 2015-05-22 12:51:18 t17.08.30 9.0 4 09178fa9c4be32982619a183b8b76bfc2ff57486aac04c8fed654a4d9fe91436
69 2015-05-22 12:51:18 t17.08.30 9.0 4 cb3976965f2105492193889f3f58f2ef2ccfeb8604e2b9448055ec6608d4aa85
70 2015-05-22 12:51:18 t17.08.30 9.0 4 de8759fe34eb2f395574be79479832402aa4d113e102d6945df493abee3d8b34
72 2015-05-28 13:48:14 t17.08.30 9.0 4 05ef4e0de8d57e6cd10d1673fcfca9c03b6e9a271d54028781e96235c4530e15
73 2015-06-02 12:15:26 t17.08.30 9.0 4 07b7041016c16341ea1f35a8c5fb5312d15f089ed5e925f78ffdd2568a8cf17c
74 2015-07-06 11:34:56 t17.08.31 9.0 4 c59ebe1fa6abe52c85f5f56a7da810a35e44c4772746bc829fa7d9e4e6a59477
75 2015-07-10 09:40:15 t17.08.31 9.0 4 3e850306025c231f09fa1922d1bb8e1a40bd8acc142d92219d9e9c8f8911b77d
76 2015-07-10 10:58:16 t17.08.31 9.0 4 008f4f14cf64dc9d323b6cb5942da4a99979c4c7d750ec1228d8c8285883771e
77 2015-07-13 01:23:13 t17.08.31 9.0 4 e919ae6a3bdc6abe6b695215a53b74072a39b86757e049f930866b3f69000957
78 2015-07-13 11:46:27 t17.08.31 9.0 4 567fa6bf28862ce7d14a2f3cf5b718780213fa3ee73f59557c29525f8daa200c
79 2015-07-14 10:57:44 t17.08.31 9.0 4 a94bf485cebeda8e4b74bbe2c0a0567903a13c36b9bf60fab484a9b55207fe0d
80 2015-07-14 11:16:54 t17.08.31 9.0 4 5a30f9010a316cc74ed271e732741c6d5d38f0e1c6f3b547176adcd40cb547ae
81 2015-07-14 18:44:14 t17.08.31 9.0 4 bfcd987ca3e79bd7ba8dde95a392dbba02ffa30242954a0cfa35ec81182f0cc8
82 2015-07-16 10:10:07 t17.08.31 9.0 4 3caf60dd3bb551d4da244dffaeb68fe01b59cd19bd0f0509611b706048b3382f
83 2015-07-28 13:56:35 t17.08.31 9.0 4 280371475442917b782f6a834003313f3aa0e5bb65f0acac5aab673d04336ba4
84 2015-08-05 09:51:31 t17.08.31 9.0 4 3cebf71221af741ea0b0883b45c092f900b513de3a004f81d3c595648311b7e9
85 2015-08-07 10:23:11 t17.08.34 8.0 4 90d07ea2bb80ed52b007f57d0d9a79430cd50174825c43d5746a16ee4f94ea86
86 2015-08-13 09:48:01 t17.08.34 8.0 4 6a331c4e654dd8ddaa2c69d260aa5f4f76f243df8b5019d62d4db5ae5c965662
87 2015-08-13 10:35:15 t17.08.34 8.0 4 17e646ca2558a65ffe7aa185ba75d5c3a573c041b897355c2721e9a8ca5fee24
89 2015-08-19 10:16:01 t17.08.34 8.0 4 22957429e8ab527ff8bb45fbc50aa8400ea643a68de8d43da3fee3239e2159d4
88 2015-08-19 10:16:01 t17.08.34 8.0 4 3553c136b4eba70eec5d80abe44bd7c7c33ab1b65de617dbb7be5025c9cf01f1
90 2015-10-13 10:52:52 t17.08.34 8.0 4 e68e835904aaef2da5b38e9532036117996d58d3fba05cbe454f9d418be60ef4

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


Jan 30, 2017

Anti-analysis technique for PE Analysis Tools –INT Spoofing–

When analysing Windows executable file type (PE file) malware, a tool to parse and display the PE file’s structure (hereafter “PE analysis tool”) is often used. This tool enables referring to a list of APIs that the malware imports (Import API) and functions that it exports. By analysing the data, it is possible to presume the malware’s function as in communicating with external servers or creating registry entries, etc. In this way, PE analysis tools are often used for malware analysis, however, a type of malware which has techniques to disturb operations of PE analysis tools has already been observed [1].

This entry introduces techniques to deceive analysts by displaying incorrect information in the Import API, and measures to implement in PE analysis tools against the issue.

INT (Import Name Table) and IAT (Import Address Table)

PE files contain 2 address tables related to Import API – INT and IAT. INT describes the address of the area which stores API names imported by the PE file. IAT is used when actually calling an API, and writes an entry address of the functions corresponding to the API when the module which exports the function is loaded. For more information about PE file formats, please refer to Microsoft’s website [2].

NT header in a PE file describes various kinds of information required for executing the file. NT header is structured as “IMAGE_NT_HEADERS”, and INT and IAT can be identified by tracing the address in “IMAGE_DATA_DIRECTORY” of Optional Header within the structure (Figure 1) [3].

Figure 1: INT and IAT related section within NT header in a PE file

The Name field of “IMAGE_IMPORT_BY_NAME” structure, which is referred to by INT, describes importing API names as a string. Generally, IMAGE_IMPORT_BY_NAME lists API names in a sequence as in Figure 2.

Figure 2: Example of IMAGE_IMPORT_BY_NAME

INT Spoofing

IMAGE_IMPORT_BY_NAME contains strings specifying API names. Even if someone tries to alter the API name in IMAGE_IMPORT_BY_NAME to disguise it as another PE file, it would not be executed properly since it would import unintended API when executing the PE file. As the red part in Figure 3 indicates, however, if the PE file is modified by adding new API names at the end of the INT to existing API names within the INT, it will not attempt to load a module since the IAT does not have a field that stores the entry address of the functions corresponding to the added API name. If PE analysis tools display such deliberately added API names, analysts would believe that the PE file has new APIs that is imported, which would confuse the analysis.

Figure 3: Example of INT spoofing

Check for INT-spoofed PE files using PE analysis tools

Many of the existing PE analysis tools refer to only INT when listing Import API, and recognise and display strings in IMAGE_IMPORT_BY_NAME as API names. When handling normal PE files, there is no issues with the behaviour since importing API addresses corresponding to the strings in IMAGE_IMPORT_BY_NAME, are written in the IAT.

However, if INT is spoofed by the above mentioned method, extra APIs are also listed. As an experiment, JPCERT/CC generated some INT-spoofed PE files, and tested how their Import API would be displayed in several PE analysis tools. As a result, many of them displayed extra APIs that are not actually imported.

Figure 4: Analysis examples of INT-spoofed executable files on PE analysis tools (Indicates the number of Import API increased due to INT spoofing)

Countermeasures against INT spoofing

One countermeasure against such spoofing would be to compare INT and IAT on a PE analysis tool and only display APIs that are actually imported (and not display added API names marked in red in the Figure 3). pyimpfuzzy, which was introduced in a past blog entry, is also a tool which performs analysis based on Import API. In its first version, there was an issue where INT-spoofed samples could not be analysed correctly. As such, the tool was updated with a new feature to compare INT and IAT, and only analyse the APIs that are actually imported.

Many PE analysis tools display strings in IMAGE_IMPORT_BY_NAME as they are. However, many debuggers and IDA refer to IATs when displaying Import API, and thus most of them do not seem to be affected by INT spoofing. When referring to the information on Import API in malware analysis, it is recommended to check APIs that are actually loaded in IAT by using a debugger, as well as INT strings.


JPCERT/CC has not yet observed any INT-spoofed samples, however, this disguising technique could possibly be abused in the near future. Automated analysis tools based on Import API may be affected by INT spoofing. As introduced above, pyimpfuzzy has been updated to a new version – please make sure that you are using the latest version (version 0.02).

Thanks for reading.

- Shusei Tomonaga
(Translated by Yukako Uchida)


[1] Palo Alto Networks - The Dukes R&D Finds a New Anti-Analysis Technique

[2] Microsoft - PE Format

[3] Microsoft - IMAGE_NT_HEADERS structure

Dec 05, 2016

Evidence of Attackers’ Development Environment Left in Shortcut Files

A shortcut file, also referred to as a shell link, is a system to launch applications or to allow linking among applications such as OLE. As we introduced in a previous blog post “Asruex: Malware Infecting through Shortcut Files”, shortcut flies are often used as a means to spread malware infection. Generally, shortcut files contain various types of information including the dates and environment that the shortcut file was created. This also applies to shortcut files created by attackers. By extracting and correlating information recorded in the shortcut files used in attacks, it is possible to identify the shortcut files that may have been created by the same attacker.

This blog entry explains how to classify an attack subject through information recorded in the shortcut files used in attacks. Furthermore, the article will also introduce trends in the system environments used by the latest attackers, which JPCERT/CC learned through statistical analysis of information gained from a number of shortcut files used in attacks.

Information Contained in Shortcut Files

Among the various types of information recorded in shortcut files, the following is the list of items that JPCERT/CC focused on for the purpose of this analysis (For the shortcut file format, please refer to the information released by Microsoft [1]).

  • Code page number: Number describing the character encoding configured in the OS where the shortcut file was created
  • ŸVolume serial number: Volume serial number of the drive where the shortcut file was located at the time of creation
  • ŸNetBIOS name: Computer name of the machine where the shortcut file was created
  • ŸMAC address: MAC address of the machine’s network adapter where the shortcut file was created

(Part of the DroidBirth field (GUID value) may contain the MAC address [2]. If neither network nor adapter exists, this will be a random value instead of a MAC address).

JPCERT/CC has confirmed that these types of information are being left in many of the shortcut files used in actual attacks. If these are available, it is possible to presume the system environment that the attackers use.

The following section explains the results of the study and classification of 83 shortcut files that JPCERT/CC collected from actual attack cases.

Classification of Shortcut Files Used in Actual Attacks

Among the above-listed information that shortcut files contain, the following 3 are useful in terms of identifying the system environment used when the shortcut file was created.

  • Volume serial number
  • NetBIOS name
  • MAC address

Shortcut files that have the same information in the above items are likely to be created by the same attacker. The image below illustrates the similarity of the shortcut files in terms of the 3 types of information. The nodes show either a shortcut file, MAC address, NetBIOS name or volume serial number, and represented in different colours – for example gray for shortcut file. For the above 3 types of information, the values are connected to the corresponding nodes with a line if the respective values are contained in the shortcut file.

Figure 1: Shortcut file clustering

Shortcut files used in attacks may contain the same volume serial number, NetBIOS name and MAC address and form a cluster. For example, the shortcut files which infect Asruex (obtained by JPCERT/CC) contained the following information:

  • Volume serial number: 4ec5-2eee
  • NetBIOS name: pc1-pc
  • MAC address: d0:50:99:27:d0:fc
Figure 2: The cluster of shortcut files infecting Asruex

In this way, multiple shortcut files may be correlated by comparing volume serial number, NetBIOS name and MAC address in the shortcut file. The coming section demonstrates the environments that attackers used for creating shortcut files, which can be seen from the analysis of shortcut file information.

Attackers’ Environment Identified from Shortcut Files

The first 3 bytes of MAC address are allocated for the Organizationally Unique Identifier (OUI), which shows the vendor of the product. Vendor names that can be identified from the 3 bytes of the MAC address in the shortcut files used in attacks are listed in Table 1.

Table 1: Results of first 3 bytes of MAC address
First 3 bytes of MAC addressVendor NameNumber
00-0c-29 VMware, Inc. 22
d0-50-99 ASRock Incorporation 15
00-50-56 VMware, Inc. 10
44-37-e6 Hon Hai Precision Ind.Co.Ltd 2
00-15-5d Microsoft Corporation (Hyper-V) 1
08-00-27 CADMUS COMPUTER SYSTEMS (VirtualBox) 1
20-c9-d0 Apple Inc. 1

It is clear that attackers tend to use a virtual environment for creating files. Many malware analysts use a virtual environment for analysis so that the actual environment does not get infected with malware. For the same reason, malware creators seem to use a virtual environment as well.

We also searched for code page information of shortcut files used in attacks and identified that the information remained in 22 of the artifacts. All of them had the same code page 936, which indicates simplified Chinese language.

For other noteworthy results taken from information left in the shortcut files, please see Appendix A.


Information on attackers’ system environment remains in many shortcut files used in attacks. By utilising the information, classification of the attack subject can be easily conducted. When analysing shortcut files used in attacks, there may be new findings by focusing not only on malicious scripts that attackers intentionally created, but also on evidence that they left unintentionally in the shortcut files.

Thank you for reading – see you soon.

- Shusei Tomonaga

(Translated by Yukako Uchida)


[1] Microsoft - [MS-SHLLINK]: Shell Link (.LNK) Binary File Format

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

Appendix A: List of information contained in shortcut files used in attacks
Table A-1: List of NetBIOS name (Top 10)
NetBIOS nameNumbers
pc1-pc 15
host-473640c404 8
kitchen 8
lenovo-60ff5341 4
seasbo 4
john-a00bf62302 3
user-1aecf0882a 3
google-329ea5f8 2
microsof-92e057 2
win-qn3bc0dqd7e 2

Table A-2: List of volume serial number (Top 10)
Volume serial numberNumbers
4ec5-2eee 15
3ee4-c3c3 8
78e5-aa39 8
602c-9a8a 7
10bc-fa5f 4
6659-b92f 4
b017-3d5c 4
ac5c-ff44 3
b45e-f641 3
365f-818f 2

Table A-3: List of MAC address (Top 10)
MAC addressNumbers
d0:50:99:27:d0:fc 15
00:50:56:c0:00:08 11
88:3b:a8:bd:d5:37 8
ab:33:5b:4f:99:a0 8
00:0c:29:2c:21:be 3
00:0c:29:34:86:a9 3
00:0c:29:ea:a9:9c 3
00:0c:29:cb:0b:aa 2
44:37:e6:84:72:77 2
00:0c:29:20:d2:d9 1

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

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
Type impfuzzy (%) 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.

Jan 26, 2016

Windows Commands Abused by Attackers

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

In Windows OS, various commands (hereafter “Windows commands”) are installed by default. However, what is actually used by general users is just a small part of it. On the other hand, JPCERT/CC has observed that attackers intruding into a network also use Windows commands in order to collect information and/or to spread malware infection within the network. What is worth noting here is the gap between those Window commands used by general users and by attackers. If there is a huge difference, it would be possible to detect or limit the attackers’ behaviour by monitoring/controlling the Windows command execution.

This entry will demonstrate how to mitigate the attack impact by revealing Windows commands that attackers use on the intruded Windows OS, and by restricting the execution of those commands that are unnecessary for general users.

Malware for remote control (Remote Access Tool/Trojan – RAT) has a function to execute shell commands from a remote environment. With this, attackers can execute Windows commands from a remote environment.

Attackers who successfully installed such malware in a network will attempt to take control of the system within the network in the following sequence in order to collect confidential information, etc.

  1. Initial investigation: Collect information of the infected machine
  2. Reconnaissance: Look for information saved in the machine and remote machines within the network
  3. Spread of infection: Infect the machine with other malware or try to access other machines

Windows commands are used in all of the phases above. Respective Windows commands used in each phase are introduced here below.

Initial Investigation

Table 1 lists the commands that are often used by attackers in an attempt to collect information of the infected machine. “Times executed” is derived from the sum of Windows commands used by 3 different attack groups in their respective C&C servers (Please refer to Appendix A, B and C for details).

Table 1: Initial Investigation (Top 10 commands)
RankingCommandTimes executed
1 tasklist 155
2 ver 95
3 ipconfig 76
4 systeminfo 40
5 net time 31
6 netstat 27
7 whoami 22
8 net start 16
9 qprocess 15
10 query 14

Attackers use commands such as “tasklist”, “ver”, “ipconfig” and “systeminfo”, etc., and collect information of the network, process and OS in order to investigate what kind of machine they succeeded in infecting. This is presumably how they make sure that the machine is not a sandbox for malware analysis purposes and so on.


Commands shown in Table 2 are often used to search for confidential information and remote machines within the network.

Table 2: Reconnaissance (Top 10 commands)
RankingCommandTimes executed
1 dir 976
2 net view 236
3 ping 200
4 net use 194
5 type 120
6 net user 95
7 net localgroup 39
8 net group 20
9 net config 16
10 net share 11

Attackers use “dir” and “type” to search for files. Sometimes they collect a list of all the document files in the infected machine by setting appropriate options and arguments for “dir” command.

For searching networks, “net” is used. In particular, the following commands are often seen:

  • net view: Obtain a list of connectable domain resources
  • net user: Manage local/domain accounts
  • net localgroup: Obtain a list of users belonging to local groups
  • net group: Obtain a list of users belonging to certain domain groups
  • net use: Access to resources

Furthermore, the following commands may be used in an environment where Active Directory is used (Please refer to Table 5 in Appendix A). These commands are installed in Windows Server and do not originally exist in client OS such as Windows 7 and 8.1 – but attackers download and install these commands from outside and execute them.

  • dsquery: Search for accounts in Active Directory
  • csvde: Obtain account information in Active Directory

Spread of Infection

To intrude remote machines and spread malware infection within the network, the following commands are often executed:

Table 3: Spread of Infection
RankingCommandTimes executed
1 at 103
2 reg 31
3 wmic 24
4 wusa 7
5 netsh advfirewall 4
6 sc 4
7 rundll32 2

*”wmic” is also used for reconnaissance.

“at” and “wmic” are often used to execute malware on remote machines.

With “at” command, attackers can execute commands on remote machines, by registering tasks to execute files against connectable machines as follows.

at \\[remote host name or IP address] 12:00 cmd /c "C:\windows\temp\mal.exe"

Also, by setting the following options and arguments with “wmic” command, attackers can execute commands on remote machines.

wmic /node:[IP address] /user:”[user name]” /password:”[password]” process call create “cmd /c c:\Windows\System32\net.exe user”

Restricting Execution of Unnecessary Windows Commands

It is fair to say that these Windows commands used by attackers include those that are unused by general users, if carefully selected. With AppLocker and software restriction policy, which restrict such commands from being executed, it would be possible to limit the attackers’ behaviour. For example, if you wish to restrict “net” commands, you can set rules as in Figure 1. (For details of AppLocker configuration, please see Microsoft’s Website [1]).

Figure 1: AppLocker Rules

Also, by enabling AppLocker, events where selected Windows commands were executed or attempted but denied will be recorded in the event logs, which can be utilized for investigation on Windows commands that attackers executed after infecting the machine with malware.

Figure 2: Logs of the Processes Restricted by AppLocker

AppLocker can also just monitor Windows commands [2]. With this, AppLocker cannot prevent unintended Windows commands from being executed, but the execution history will be recorded in the event log. If the users themselves use Windows commands that may be used for attacks, it is a good idea to set AppLocker just for monitoring purpose. (Windows command execution can also be monitored by activating “Audit Process Creation” in the local security policy.)


In targeted attacks, attackers not only use functions implemented in the malware, but also often use Windows commands to pursue their purposes. If such activities can be hindered, spread of incidents can be prevented in a fairly early stage. However, it may be difficult to limit the usage of Windows commands right away – so our recommendation is to start by collecting logs of executed processes by using AppLocker, etc.

Thank you for reading and best wishes for the New Year!

- Shusei Tomonaga


[1] Microsoft - Windows AppLocker

[2] Microsoft – Using Auditing to Track Which Applications Are Used


Appendix A: List of Executed Commands by respective Attack Groups (Attack Group A)
Table 4: Initial Investigation (Attack Group A)
RankingCommandTimes executedOption
1 tasklist 119 /s /v
2 ver 92
3 ipconfig 58 /all
4 net time 30
5 systeminfo 24
6 netstat 22 -ano
7 qprocess 15
8 query 14 user
9 whoami 14 /all
10 net start 10
11 nslookup 4
12 fsutil 3 fsinfo drives
13 time 2 /t
14 set 1

Table 5: Reconnaissance (Attack Group A)
RankingCommandTimes executedOption
1 dir 903
2 net view 226
3 ping 196
4 net use 193
5 type 118
6 net user 74
7 net localgroup 35
8 net group 19
9 net config 16
10 net share 11
11 dsquery 6
12 csvde 5 /f /q
13 nbtstat 5 -a
14 net session 3
15 nltest 3 /dclist
16 wevtutil 2

Table 6: Spread of Infection (Attack Group A)
RankingCommandTimes executedOption
1 at 98
2 reg 29 add export query
3 wmic 24
4 netsh advfirewall 4
5 sc 4 qc query
6 wusa 2
Appendix B: List of Executed Commands by respective Attack Groups (Attack Group B)
Table 7: Initial Investigation (Attack Group B)
RankingCommandTimes executedOption
1 tasklist 29 /m /svc
2 whoami 6
3 ipconfig 5 /all
4 net start 4
5 netstat 3 -ano
6 nslookup 3
7 ver 2
8 time 1 /t

Table 8: Reconnaissance (Attack Group B)
RankingCommandTimes executedOption
1 dir 62
2 net user 21 /domain /add
3 net view 9 /domain
4 ping 4
5 net localgroup 4 /add
6 tree 3 /F
7 type 2
8 net group 1 /domain

Table 9: Spread of Infection (Attack Group B)
RankingCommandTimes executedOption
1 at 5
2 wusa 5
3 reg 2
4 rundll32 2
Appendix C: List of Executed Commands by respective Attack Groups (Attack Group C)
Table 10: Initial Investigation (Attack Group C)
RankingCommandTimes executedOption
1 systeminfo 16
2 ipconfig 13 /all /?
3 tasklist 7
4 netstat 5 -ano
5 whoami 2
6 net start 2
7 arp 1 -a
8 chcp 1
9 net time 1
10 ver 1

Table 11: Reconnaissance (Attack Group C)
RankingCommandTimes executedOption
1 dir 11
2 net user 1 /all /?
3 net view 1
4 qwinsta 1 -ano

*Commands for “Spread of Infection” by Attack Group C are omitted since they did not spread the infection.

Nov 06, 2015

Emdivi and the Rise of Targeted Attacks in Japan

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

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

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

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

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

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


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

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

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



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

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



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

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

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

- Keishi Kubo and Shiori Kubo


(1) Official Reports:

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