IXESHE Derivative IHEATE Targets Users in America

Since 2012, we’ve been keeping an eye on the IXESHE targeted attack campaign. Since its inception in 2009, the campaign has primarily targeted governments and companies in East Asia and Germany. However, the campaign appears to have shifted tactics and is once again targeting users in the United States.

We also noticed that there were some changes to the underlying behavior of the malware used. While there were some incremental improvements in the observed behavior of the new sample, the underlying pattern of behavior is similar to what we observed earlier from IXESHE.

These attacks targeting users in the United States used a variant of IXESHE which has been seen in Taiwan since 2009 named IHEATE. These showed some differences from known IXESHE variants: they had a different command-and-control (C&C) communication model and encryption methods.

One IHEATE sample we found contains the string “EMC112” as part of the C&C traffic. Such strings are frequently used to identify different campaigns. In this particular case, the 112 part of the string matched the malware sample’s compilation date of January 12.

The sample we acquired connects to a C&C server whose domain was first registered in 2004, but whose information was modified in December 2015. This suggests that threat actors were able to pose as the original registrant and modify the information for their own needs.

Technical Analysis

IXESHE is a well-known targeted attack campaign which has mainly targeted East Asian governments, electronics manufacturers, and a telecommunications company in Germany. Other targets include G20 government officials as well as the New York Times. The campaign is known for targeting users with fake documents using exploits and right-to-left override (RTLO) techniques.

The particular sample we found has a SHA1 hash of 3de8ef34fb98ce5d5d0ec0f46ff92319a5976e63. We detect it as BKDR_IHEATE. Unlike common IXESHE variants which usually communicate with C&C servers via HTTP and a customized Base64-ecoded payload, IHEATE communicates with C&C servers in the TCP layer. (HEATE is a command that is sent by some members of this family to servers that acts as a notice that it’s still online; we derived the name IHEATE from this command and its ties to the IXESHE family.)

We have learned from IXESHE variants that even though the encryption routine changed in different variants but the decrypted messages are almost similar.

Information gathering

Once the backdoor is installed, it collects information on the victim’s system and sends it to C&C server with the following format :

| [Computer name] | [User name] | [IP] | [OS version] | [Process ID or Tag]

Not all samples include a tag in their message. This tag could be a process ID, victim information, or the date when the malware was compiled. In this IHEATE sample, the tag is “EMC112”. The 112 portion may refer to when the malware was compiled, as its compile date/time is 2016/01/12 03:22:27.

The threat actors behind IHEATE could use these tags to manage victims. The traffic back to their C&C servers could easily be sorted using these tags.

Sometime they slightly change the feedback format, such as

Removing spaces:“[Computer name]|[User name]|[IP]|[OS version]|[Tag]”
Changing the delimiter:“* [Computer name] * [User name] * [IP] * [OS version] * [Tag]”

Backdoor instructions

IHEATE provides a similar set of commands as most IXESHE variants. Note that the following list is case insensitive:

/WINCMD %s – Launch command and get the output
/GETCMD %s – copy cmd.exe and rename
/DISK – List all disks
/CD – get current directory
/CD %s – change directory
/DIR %s – browse directory
/DEL %s – delete file
/GETFILE %s – upload file
/PUTFILE %s – download file
/TASKLIST – list running processes
/TASKKILL %s – kill a running process
/SHUTDOWN – shut down the malware
/SLEEP %s – sleep for specific period

Encryption

While IXESHE variants have fairly similar phone-home and backdoor routines, they have a wide variety of encryption routines. IHEATE is no different, and has its own unique behavior.

The traffic below simulates the traffic between a IHEATE-affected machine and its C&C server. Traffic from the client to the server is in red; traffic from the server to the client is in blue. The C&C server has sent a /DISK command to the machine.

Figure 1. Captured IHEATE network traffic

The first part of the network traffic is from the client to the C&C server. It is as follows:

The first six bytes make up the hardcoded portion of the encryption key. In this case, it is “36 59 6d 56 7c 22”. We have seen different encryption keys in other IHEATE variants; in some variants this part is ten bytes long.
The following eight bytes make up the randomly generated portion of the encryption key. Here it is “b0 84 e8 44 a4 55 85 c7”. In some samples, this portion is ten bytes long.
The next two bytes say how long the encrypted data is, here it is “61 8a”. The contents are encrypted with RC4, using the randomly generated encryption key.
Last is the data itself. This is also encrypted using RC4, with the hardcoded and randomly generated portions of the encryption key concatenated together.

The second part is the response of the server to the client. It is described as follows:

The encryption procedure is identical to that used by the client to talk to the server.
The six-bit hardcoded portion of the encryption key must be identical to the one used by the client earlier. Otherwise, if the keys do not match, the connection is dropped.

However, some newer IHEATE samples use yet another technique. These use asymmetric encryption:

Before communicating with C&C server, the malware client generates a random session key.
The client encrypts the session key using RSA-1024, using a public key hardcoded inside of malware.
The client encrypts the data to be sent using a custom encryption routine.
On top of this, the data sent to the C&C server is encrypted with RC4, using the previously generated session key,

Figure 2. Asymmetric encryption as used by IHEATE

File properties

The IHEATE sample with the “EMC112” identifier passes itself off as legitimate Media Player-related .DLL file, as can be seen below:

Figure 3. IHEATE pretending to be a Media Player .DLL file

C&C Servers

IXESHE was known for using compromised hosts for its C&C servers, and IHEATE behaves similarly.

The IHEATE sample with the “EMC112” identifier used the subdomain cknew[.]{abused domain}[.]com as the location of its C&C server. This domain appears to contain the personal blog of the original registrant, who has been using it since the domain was registered in 2004. We do not believe that the registrant is tied to IHEATE; instead we believe that his credentials were compromised so that threat actors could set up subdomains. This site was active briefly in the middle of 2015, but came back online at the start of 2016.

Other IHEATE samples showed interesting behavior as well. In one case, the attackers planted a fake C&C server address in the code:

Figure 4. Fake C&C server in code

The address here is not an actual C&C address; instead it is used to calculate the port that the client will use (in this case, 443: (24*18)+11.) Other attacks are known to have used similar tactics as well.

Other domains used by IHEATE also overlapped with servers used by IXESHE. Two domains (ipv6pro[.]root[.]sx and gimeover[.]psp-moscow[.]com) were used by IHEATE and resolved to the IP address 200[.]93[.]193[.]163. At approximately the same time, IXESHE also used the same server – except it did so by accessing the domain skype[.]silksky[.]com.

Conclusions

IXESHE and associated threats like IHEATE have not gone away, and they continue to evolve and change with the times. We will continue to monitor this threat and apprise our readers of any future developments.