« November 2016 | Main | January 2017 »

3 posts from December 2016

Dec 22, 2016

Update from the CyberGreen Project

Hi, this is Moto Kawasaki from Global Coordination Division. It has been a little while since I wrote about the CyberGreen Project last time, and I would like to update the achievements of the Project.

The most impressive news in the first half of this fiscal year 2016 (Apr-Sep in Japan) is the renewal of its web site. Please have a look at the Info site and you'll find nice pages introducing distinguished advisers and board members of the Project, the mission statement and Project goals, and much more.

Figure 1: CyberGreen Info site

It is a good summary and outcome of what we have been aiming for years, and especially the Blog page shows cutting-edge stories around the Project, including investments not only from JPCERT/CC over the years, but also from the newly-joined Foreign & Commonwealth Office of the United Kingdom and Cyber Security Agency of Singapore, which proves the project is well-supported by various organizations.

If you click the Statistics tab, you'll find the Stats site that describes the Beta-2 version of the statistics with a colored map and scores by region and by AS number. These scores are based on the data from the Open Resolver Project and other data sources, as listed in the Data Inventory page. The calculation algorithm is described in the About page, and the score is a kind of density as per the formula: the natural logarithm of the number of open servers found in a region over the natural logarithm of the maximum number of nodes per country in that region, which is expressed by the score between 0 (best) and 100 (worst).

Figure 2: Colored map on Stats site
Figure 3: Scores indicating risks

With these renewed sites, we had several promotions such as CyberGreen Workshop at the APCERT Annual General Meeting & Conference 2016 (please find a blog post on the Conference here), a session on “CyberGreen: Improving Ecosystem Health through Metrics based Measurement and Mitigation Support” at the FIRST Regional Symposium for Arab and African Regions, and another CyberGreen Index proposed as “Measuring CyberGreen Readiness” at the 9th Annual National Conference on Cyber Security, Sri Lanka.

Figure 4: Green Index proposed at the Conference in Sri Lanka

In addition to the continued efforts by the CyberGreen Project team, there was another big news: “CyberGreen Metrics v.2 Method and Report Finalized.” As described in the news page, we will see another revision in the Info and Stats sites, hopefully in early 2017.

As such, we wish you to join CyberGreen to make the Internet safer together.

Thank you very much.

- Moto Kawasaki

Dec 16, 2016

A New Tool to Detect Known Malware from Memory Images – impfuzzy for Volatility –

Hi again, this is Shusei Tomonaga from the Analysis Center. Today I will introduce a tool “impfuzzy for Volatility”, which JPCERT/CC has created for extracting known malware from memory images and utilises for analysis operations.

Malware Detection in Memory Forensics

To judge if a file type malware sample is a known kind, the easiest and fastest way is to check the hash value (e.g. MD5 or SHA 256) of the entire file to see if it matches any of those in malware databases. However, this method is not applicable for memory forensics. This is because executable files loaded on the memory are partially altered by the OS or the malware itself (for example, when an executable file is loaded on the memory, IAT – import address table – is replaced with the API’s address loaded on the memory), and therefore hash values of the file before and after being loaded on the memory do not match.

In this sense, for memory forensics, signature matching using Yara scan is often used for detecting known malware. In order to use this method, however, details of the malware need to be analysed and also its signature needs to be generated beforehand.

Overview and Main Features of impfuzzy for Volatility

“impfuzzy for Volatility” is a tool that solves such issues and enables extracting known malware from memory images. This tool is implemented as a plugin for The Volatility Framework (hereafter “Volatility”), a memory forensics tool. To enable detection even after information in the malware executable file is partially altered when loaded on the memory, the tool uses “impfuzzy” method which compares the similarities of Windows executable files based on hash values generated from Import API. impfuzzy was introduced in a past article on this blog.

impfuzzy for Volatility offers the following functions and is applicable for investigations using imphash [1] as well.

  • impfuzzy – Compares and displays hash values of executable files in memory images using impfuzzy
  • Ÿimphashlist – Displays the imphash value of executable files in memory images
  • imphashsearch – Compares hash values of executable files in memory images using imphash

When executing the following command line, impfuzzy hash values of the executable files and DLL files loaded on the memory will be listed as in Figure 1.

$ python vol.py -f [memory.image] --profile=[profile] impfuzzy -a (-p [PID]) 
Figure 1: Executable files in memory images and their hash values

To search memory images for files which are similar to certain executable files, the following command line can be executed.

$ python vol.py -f [memory.image] --profile=[profile] impfuzzy -e [PE File or Folder] (-p [PID])

The executable file to compare with or the folder where it is stored can be specified as option “-e”.

By executing the above command line, similar executable files can be detected as in Figure 2 (The “Compare” field indicates the similarity by percentage).

Figure 2: Detecting similar files from memory images

Figure 2 demonstrates the example where Citadel, a type of banking malware, is detected. Citadel is usually packed and starts running by injecting unpacked code into Explorer, etc. impfuzzy for Volatility compares executable files loaded on the memory, which makes it possible to calculate hash values of unpacked samples. Therefore, similarities can be judged even for packed malware.

impfuzzy for Volatility can also detect code that is injected into processes, as well as executable files and loaded DLL files. In Figure 2, “INJECTED CODE” in the “Module Name” field indicates that there is code injected into the processes.

The following shows other options that are available in impfuzzy for Volatility.

(Example 1) Compares impfuzzy hash values listed in the file with executable files in the memory, and displays the results:

$ python vol.py -f [memory.image] --profile=[profile] impfuzzy -i [Hash List File] (-p [PID])

(Example 2) Lists imphash values of executable files loaded on the memory

$ python vol.py -f [memory.image] --profile=[profile] imphashlist (-p [PID])

(Example 3) Compares imphash values listed in the file with executable files in the memory, and displays the results that match

$ python vol.py -f [memory.image] --profile=[profile] imphashsearch -i [Hash List] (-p [PID])

Advantages of Using impfuzzy in Memory Forensics

Even though executable files loaded on the memory are partially altered as previously discussed, their Import API remain the same. impfuzzy judges the similarity based on hash values derived from Import API of the executable files. This makes it possible to identify the same file even from executable files loaded on the memory.

Furthermore, since impfuzzy can generate hash values automatically, unlike Yara scan, there is no need to generate signatures manually.

Obtaining and Installing impfuzzy for Volatility

This tool is available on GitHub, a shared web service for software development projects. Feel free to download from the following website for your use:

JPCERTCC/aa-tools GitHub - impfuzzy for Volatility

In order to use this tool, the following Python module needs to be installed.

  • Ÿpyimpfuzzy

Please see the following website regarding installation of pyimpfuzzy.


When executing, impfuzzy.py needs to be installed from the aforementioned website, stored in the “contrib/plugins” folder in Volatility and then executed. (It is also possible to specify the folder where impfuzzy.py is stored using option “--plugins”.)


Memory may contain some information including malware that is not left on the hard disk, and therefore memory forensics is important in incident investigations involving malware infection. We hope that this tool is utilised as to effectively conduct investigations on memory forensics in such security incidents.

Thanks for reading.

- Shusei Tomonaga

(Translated by Yukako Uchida)


[1] FireEye - Tracking Malware with Import Hashing

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