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.
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.
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.
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.
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.
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:
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.
The lists below describe encrypted data contained in the first HTTP request and explanation of the values for each ChChes version.
|<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
Appendix D: List of communication destination