# 2015 2015

Insight in to advances of adversary tactics, techniques and procedures
through analysis of an attack against an organisation in the Asia Pacific
region.

|Col1|June 28 2015 2015|
|---|---|


## June 28

# 2015 2015


D r a g o n T h r e a t L a b s H o n g K o n g Author: Dan


-----

### Contents

Introduction ........................................................................................................................................ 2

Phishing with a hook and LINE ............................................................................................................ 2

Mocelpa .............................................................................................................................................. 4

Detection & mitigation ..................................................................................................................... 10

Appendix ........................................................................................................................................... 12

Contact .............................................................................................................................................. 13


D r a g o n T h r e a t L a b s H o n g K o n g Page 1


-----

#### Introduction
The summer months dawn on us the financial year comes to a close. It is in the run up to this time
that most organisations see an increase in targeted attack activity.

We begin by reading news of an attack against the Taiwanese Government. Whilst we would prefer
to disassociate ourselves with APT attacks against Governments our interest was piqued by a
particular blog written by our friends over at TrendMicro[1]. There were several things that struck us
as both interesting and concerning about the details; a threat actor known to operate in South East
Asia is now using secure sockets layer (“SSL”) encryption in their malware. SSL is typically used to
encrypt data between the client and the server, thus making the content unreadable by any systems
sitting between the two end points, and significantly raising the cost of defence. Without the use of
SSL interception traditional IDS/IPS systems will cease to detect compromised systems. For large
organisations the cost of this can run from the hundreds of thousands in to the millions of dollars.
For smaller organisations this single expense easily can run over the yearly security budget. Whilst a
small, fun loving, not-for-profit group of misfits such as ourselves are not concerned with financial
costs we are concerned with an adversary’s change in behaviour, especially the use of encryption have Snowden’s actions[2] really affected the entire world?

#### Phishing with a hook and LINE
As most spearphishing stories begin, Mary receives an email from John, except the email isn’t really
from John, it’s from somebody pretending to be John in an attempt to gain Mary’s trust so that she’ll
open an email attachment that contains malware.

1 The blog posting has unfortunately since been removed
2 Snowden’s actions: we don’t care what effect he had - he’s still a prick. Welcome to Hong Kong 


D r a g o n T h r e a t L a b s H o n g K o n g Page 2


-----

In this case ‘Mary’ is an employee of the Taiwanese Government and ‘John’ is supposedly a coworker also working for the Government. Based on the format of the email addresses it appears
that the attacker has some working knowledge of their target organisation but the body of the email
does not give away further ‘guilty knowledge’ and simply asks the user to open the attachment to
install LINE, a popular instant messaging program used in millions of people in Taiwan.
The malware is very simply contained within a zip file. The zip file does not have a password.
Fortunately in this case it seems that this email was noticed as suspicious by the recipient and they
uploaded it to a popular anti-virus website.

This method of delivering malware isn’t uncommon in Asia. Due to a lack of general awareness in IT
security many users fall victim to such attacks be it APT or common crimeware. It is of course good
practice to block all executable files in email attachment (.exe, .bat, .cmd, .scr, .jar etc.). Whilst this
method isn’t the most sophisticated don’t let it fool you – it proves to be very effective.

A further look into the email headers shows us that the email did not come from a co-worker; it in
fact came from somebody outside of the organisation.


D r a g o n T h r e a t L a b s H o n g K o n g Page 3


-----

Many organisations worldwide complain of spearphishes coming from HiNet IP ranges and
brandishing the DreamMail X-mailer. Unfortunately this combination of characteristics is very
common in Asia and thus does not always make a good heuristic detection rule.

#### Mocelpa
Upon first look we notice that the executable file contained with the zip archive is fairly small being
[just 11 Kilobytes in size. Up until recently Mocelpa had a very low detection rate, being detected by](https://malwr.com/analysis/ZWEwYWM3YjM1MzNmNDg1MWE0MGM3YjQ2MjQ3YjMzOTY/)
just 1 out of 57 anti-virus engines tested against.

The first characteristic we notice is the lack of bootstrap mechanism. Should the user logout,
shutdown or reboot the malware will not survive. This is interesting behaviour and suggests that the
malware author is confident in Mocelpa’s stability.

To begin with I will describe the network functions, since my main interest in this malware stems
from the use of SSL. An initial glance at network traffic produced by Mocelpa reveals something
interesting and surprising: an SSL handshake followed by quite blatant non-SSL traffic.

Delving into the disassembly behind the malware we can see that this SSL handshake is clearly faked
and generated using hardcoded values within the malware.


D r a g o n T h r e a t L a b s H o n g K o n g Page 4


-----

In this situation it would appear that the author has simply copy & pasted values from a packet
capture and in doing so they have revealed what is most likely the exact time and date that the
packet was generated.

Interestingly there is one identifiable string in the data: www.apple.com. I think we have just
discovered why this malware is called Mocelpa: ApleCom <> Mocelpa. This suggests that the
individual who named the malware knew that the connection data was hardcoded and not actually
encrypted. Those of you who are familiar with IDS/IPS and network detection will know that this
behaviour makes a highly reliable signature. In all Mocelpa samples we analysed (see appendix for
MD5’s) this string remained the same.

Now that we know the traffic data is hardcoded let’s take a look at what follows the ‘SSL’ handsake.

Firstly, Mocelpa grabs the MAC address of the machine and runs it through an encoding routine. The
encoding performed simply increases each number/character in the MAC address by 1. This value is
then modified, by inserting hardcoded hexadecimal values at the beginning and end of the string.

Before connecting to the command and control server Mocelpa looks up the proxy server that is
configured in Internet Explorer. This can be found in the registry under
_“HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings” in the_
_“ProxyServer” key. It appears that at least one of the samples we analysed (see appendix) has a bug[3]_
and will fail to connect to the command and control server unless the system is configured to use a
proxy server. Failure to connect to the command and control server results in the malware sleeping
for 5 minutes before trying again.

3 Thanks to Tillmann Werner for pointing this out


D r a g o n T h r e a t L a b s H o n g K o n g Page 5


-----

Upon connecting to the command and control server several exchanges of information take place.
During the initial ‘SSL’ connection (described above) certain responses are expected from the
command and control server. These responses are only validated by length and in fact can contain
any data; the first response should be 3162 bytes in length and the second 59 bytes.

The encoded MAC address is also sent to the command and control server. It is likely that the
attacker’s use this value to identify unique victims. Once the connection has been established
command and control can take place.

The command and control functionality is very simple, however the structure is not. From this very
high-level view we can see that this is not as easy as a simple IF, NOT, THEN structure.


D r a g o n T h r e a t L a b s H o n g K o n g Page 6


-----

Ultimately this breaks to commands and sub-commands, denoted by a specific packet structure.


D r a g o n T h r e a t L a b s H o n g K o n g Page 7


-----

The functionality can be broken down into the following groups:

  - **0x3: Execute command**

`o` Uses cmd.exe to execute a command, logs the output and sends it back to the c2

server

  - **0x0A: File operations**

`o` Sub-options:

         - **0x0B: Create a file (filename specified by in the data packet) in the user’s**
temporary directory

         - **0x0C: Write data (specified in the data packet) to the currently open file**

         - **0x0D: Open the file that was created/written to, perform an MD5 hash on**
the contents and compare it to the attacker specified MD5 (contained within
the data packet)

The structure behind the protocol is fairly simple and involves packet data being passed through a
decoding routine before being processed. For example, a decoded packet executing C2 command
0x0A, sub-command 0x0D looks like the following:

The data decoding routine begins by taking a series hardcoded values and appending it to the
beginning of the data, it then proceeds to run an XOR operation against each byte of the packet in
reverse order, for example:

Clearly at this stage we can see that this implant does not use SSL.
Server-side protocol analysis has unfortunately been thwarted by a lack of response from the
command and control servers so the examples are above are just that: examples. In any case we are


D r a g o n T h r e a t L a b s H o n g K o n g Page 8


-----

confident in saying that responses from live command and control servers are unlikely to be fully
static and thus creating a reliable IDS signature or detection heuristic would be challenging at best.

During the process of analysing the malware samples we created a fully functioning command and
control server module. After careful consideration we have decided not to release the code for this.

Ultimately Mocelpa is a simple downloader with basic functionality. Given the seemingly
unnecessary amount of complexity involved and the obscure method of verifying file download
success we would be quick to assume that this was written by an inexperienced programmer, but
there are in fact a number of reasons why such methods were used in the development of this
implant. Taking into consideration things like reverse engineering, network detection devices, antivirus and human ‘hunter’ teams it does not take much thought to theorise why the codebase and
functionality are somewhat creative.

Still, through this extra code it does not make Mocelpa less detectable – in fact quite the opposite.


D r a g o n T h r e a t L a b s H o n g K o n g Page 9


-----

#### Detection & mitigation
This implant can be detected at both disk and network level. In order to help organisations protect
themselves we have created a number of network IDS rules and disk-scan rules that can be used
with Snort and Yara. Rules are provided in a best-effort basis and we cannot vouch for their
efficiency in your environment.

**Mocelpa YARA disk signature**
```
rule apt_win_mocelpa {
meta:
   author = "@int0x00"
   description = "APT malware; Mocelpa, downloader."
strings:
   $mz = {4D 5A}
   $ssl_hello = {16 03 01 00 6B 01 00 00 67 03 01 54 B4 C9 7B 4F
CF BC 5A 01 EC 4A 73 C8 6D BB C0 86 9F 7B A9 08 6A 60 37 05 81 97 1A
C8 9F 45 E5 00 00 18 00 2F 00 35 00 05 00 0A C0 13 C0 14 C0 09 C0 0A
00 32 00 38 00 13 00 04 01 00 00 26 00 00 00 12 00 10 00 00 0D 77 77
77 2E 61 70 70 6C 65 2E 63 6F 6D 00 0A 00 06 00 04 00 17 00 18 00 0B
00 02 01 00}
condition:
   ($mz at 0) and ($ssl_hello)
}

```
**Mocelpa SNORT network beaconing**
```
alert tcp $HOME_NET any -> $EXTERNAL_NET 443 (msg:"APT MALWARE –
Mocelpa beacon"; flow:established,to_server; content:"| 16 03 01 00
6B 01 00 00 67 03 01 54 B4 C9 7B 4F CF BC 5A 01 EC 4A 73 C8 6D BB C0
86 9F 7B A9 08 6A 60 37 05 81 97 1A C8 9F 45 E5 00 00 18 00 2F 00 35
00 05 00 0A C0 13 C0 14 C0 09 C0 0A 00 32 00 38 00 13 00 04 01 00 00
26 00 00 00 12 00 10 00 00 0D 77 77 77 2E 61 70 70 6C 65 2E 63 6F 6D
00 0A 00 06 00 04 00 17 00 18 00 0B 00 02 01 00|"; classtype:trojanactivty; sid:YOUR_SID; rev:14062015)

```
**Mocelpa SNORT C2 server IP** **#1**
```
alert ip $HOME_NET any <> 213.179.57.178 any (msg:"APT MALWARE –
Mocelpa C2 address"; classtype:trojan-activity; sid:YOUR_SID; rev:
14062015;)

```
**Mocelpa SNORT C2 server IP** **#2**
```
alert ip $HOME_NET any <> 128.91.34.188 any (msg:" APT MALWARE –
Mocelpa C2 address"; classtype:trojan-activity; sid:YOUR_SID; rev:
14062015;)

```

D r a g o n T h r e a t L a b s H o n g K o n g Page 10


-----

**Mocelpa SNORT C2 server IP** **#3**
```
alert ip $HOME_NET any <> 200.87.48.4 any (msg:"APT MALWARE –
Mocelpa C2 address"; classtype:trojan-activity; sid:YOUR_SID; rev:
14062015;)

```
**Mocelpa SNORT C2 server IP** **#4**
```
alert ip $HOME_NET any <> 128.91.34.175 any (msg:"APT MALWARE –
Mocelpa C2 address"; classtype:trojan-activity; sid:YOUR_SID; rev:
14062015;)

```

D r a g o n T h r e a t L a b s H o n g K o n g Page 11


-----

#### Appendix
The following artefacts were found during the investigation

**MD5s** **Network artefacts**
6e4e030fbd2ee786e1b6b758d5897316 `213.179.57.178`
27f5b6e326e512a7b47e1cd41493ee55[4] `128.91.34.188`
```
                     128.91.34.175
```
548884eabebef0081dd3af9f81159754
```
                     200.87.48.4 
```
05bc4a9b603c1aa319d799c8fba7a42a
cdf0e90b0a859ef94be367fdd1dd98c6

4 “Broken”; will not connect to the internet unless a system proxy is configured

|6e4e030fbd2ee786e1b6b758d5897316 27f5b6e326e512a7b47e1cd41493ee554 548884eabebef0081dd3af9f81159754 05bc4a9b603c1aa319d799c8fba7a42a cdf0e90b0a859ef94be367fdd1dd98c6|213.179.57.178 128.91.34.188 128.91.34.175 200.87.48.4|
|---|---|


D r a g o n T h r e a t L a b s H o n g K o n g Page 12


-----

#### Contact
For all questions relating to the publication or specifics in this document please contact us via one of
the following methods:

[Twitter: @dragonthreatlab](https://twitter.com/DragonThreatLab)
[Website: http://dragonthreat.blogspot.hk](http://dragonthreat.blogspot.hk/)
[Email: dragonthreatlabs@gmail.com](mailto:dragonthreatlabs@gmail.com)

Kind regards,

Dan (@int0x00)
Dragon Threat Labs


D r a g o n T h r e a t L a b s H o n g K o n g Page 13


-----