Author: Dr. Philip Cao

(This blog post is also available in Japanese.)

Palo Alto Networks has identified a malware family known as ‘Aveo’ that is being used to target Japanese speaking users. The ‘Aveo’ malware name comes from an embedded debug string within the binary file. The Aveo malware family has close ties to the previously discussed FormerFirstRAT malware family, which was also witnessed being used against Japanese targets. Aveo is disguised as a Microsoft Excel document, and drops a decoy document upon execution. The decoy document in question is related to a research initiative led by the Ido Laboratory at the Saitama Institute of Technology. Upon execution, the Aveo malware accepts a number of commands, allowing attackers to take full control over the victim machine.

Deployment

The Aveo malware sample disguises itself as a Microsoft Excel document, as the icon below demonstrates. Note that the filename of ‘malware.exe’ is simply a placeholder, as the original filename is unknown.

Figure 1 Microsoft Excel icon used by Aveo malware

The executable is in fact a WinRAR self-extracting executable file, which will drop the decoy document and Aveo Trojan upon execution. The following decoy document is dropped and subsequently opened when run.

Figure 2 Decoy document used with Aveo malware

This decoy document is hosted on the Ido Laboratory and contains information about a 2016 research initiative. The document lists participants in the 16^th CAVE workshop, including names, affiliations, and email addresses of those involved. The document, written in Japanese, as well as the filename of this document, “CAVE研究会参加者.xls”, indicates that this malware was used to target one or more Japanese speaking individuals. Additionally, the similarities between the Aveo and FormerFirstRAT malware families, which will be discussed later in the post, further add evidence that Japanese speakers are being targeted.

Infrastructure

The Aveo Trojan is configured to communicate with the following domain name over HTTP.

• snoozetime[.]info

This domain was first registered in May 2015 to ‘jack.ondo@mail.com’. Since that time, it has since been associated with the following three IP addresses:

• 104.202.173[.]82
• 107.180.36[.]179
• 50.63.202[.]38

All IP addresses in question are located within the United States.

Figure 3 PassiveTotal screenshot showing associated IP addresses with snoozetime[.]info

The WHOIS information for snoozetime[.]info lists a registrant email address of ‘jack.ondo@mail[.]com’ and a name of ‘aygt5ruhrj aygt5ruhrj gerhjrt’. Pivoting off of these two pieces of information to domains that share the same yields the following additional domains and email addresses.

• bluepaint[.]info
• coinpack[.]info
• 7b7p[.]info
• donkeyhaws[.]info
• europcubit[.]com
• jhmiyh.ny@gmail[.]com
• 844148030@qq[.]com

Malware Analysis

After running the self-extracting executable, a number of files are dropped to the file system and the following execution flow is witnessed:

Figure 4 Malware execution flow

When the mshelp32.exe executable runs, it begins by reading in the setting32.ini file, which contains the name of the decoy document. This information is used to build a batch script, such as the following.

This batch script is executed within a new process, and acts as a simple cleanup script that runs after Aveo and the decoy document are executed.

Aveo Malware Family

The Aveo malware initially runs an install routine, which will copy itself to the following location:

• %APPDATA%\MMC\MMC.exe

If for any reason the %APPDATA%\MMC directory is unable to be created, Aveo will use %TEMP% instead of %APPDATA%.

After the malware copies itself, it will execute MMC.exe in a new process with an argument of the original filename. When executed, if this single argument is provided, the malware will delete the file path provided.

After the installation routine completes, Aveo will exfiltrate the following victim information to a remote server via HTTP.

• Unique victim hash
• IP Address
• Microsoft Windows version
• Username
• ANSI code page identifier

This information is exfiltrated to the ‘snoozetime[.]info’ domain, as seen in the following example HTTP request:

To encrypt the provided data, the malware makes use of the RC4 algorithm, using a key of ‘hello’. As shown in the following image, the encryption routines between Aveo and FormerFirstRAT are almost identical, with only the algorithms and keys being changed.

Figure 5 Comparison of encryption function between Aveo and FormerFirstRAT

In order to decrypt the data provided via HTTP, the following code may be used:

Running the code above yields the following results:

After the initial victim information is exfiltrated, the malware expects a response of ‘OK’. Afterwards, Aveo will spawn a new thread that is responsible for handling interactive command requests received by the command and control (C2) server, as well as requests to spawn an interactive shell.

Aveo proceeds to set the following registry key to point towards the malware’s path, thus ensuring persistence across reboots:

HKCU\software\microsoft\windows\currentversion\run\msnetbridge

A command handler loop is then entered, where Aveo will accept commands from the remote C2. While the Aveo malware family awaits a response, it will perform sleep delays of randomly chosen intervals between 0 and 3276 milliseconds. Should the C2 server respond with ‘toyota’, it will set that interval to 60 seconds. Aveo accepts the following commands, shown with their associated function.

• 1 : Execute command in interactive shell
• 2 : Get file attributes
• 3 : Write file
• 4 : Read file
• 5 : List drives
• 6 : Execute DIR command against path

The following example request demonstrates the C2 server sending the ‘ipconfig’ command to the Aveo malware.

C2 Request

Aveo Response

Conclusion

Aveo shares a number of characteristics with FormerFirstRAT, including encryption routines, code reuse, and similarities in C2 functionality. Aveo is far from the most sophisticated malware family around. As witnessed in the previously discussed FormerFirstRAT sample, this related malware family also looks to be targeting Japanese speaking users. Using a self-extracting WinRAR file, the malware drops a decoy document, a copy of the Aveo malware, and a cleanup script.

Palo Alto Networks customers are protected from this threat in the following ways:

• An AutoFocus tag has been created to track and monitor this threat
• WildFire classifies Aveo samples as malicious
• C2 domains listed in this report are blocked through Threat Prevention.

Indicators of Compromise

SHA256 Hashes

9dccfdd2a503ef8614189225bbbac11ee6027590c577afcaada7e042e18625e2
8101c298a33d91a985a5150d0254cf426601e4632250f5a03ddac39375e7fb4d

C2 Domains

snoozetime[.]info

Registry Keys

HKCU\software\microsoft\windows\currentversion\run\msnetbridge

File Paths

%APPDATA%\MMC\MMC.exe
%TEMP%\MMC\MMC.exe

Josh Grunzweig and Robert Falcone

[Palo Alto Networks Research Center]

Threat actors tend to reuse certain tools, a trend we observed during recent Unit 42 research published on MNKit. In this post, we will discuss a fresh toolkit, which on the surface, appeared similar to MNKit, but functionally was found to be quite different.

This toolkit, which we named “HOMEKit”, is similar to MNKit in that it is also designed to generate weaponized Microsoft Word documents containing an exploit for CVE-2012-0158, but it uses OLE instead of MHTML files. In addition, we have been able to track the use of HOMEKit by its operators since 2013 across a variety of campaigns, using several different variants of the toolkit. For this post, we will be focusing on the most recent example of the HOMEKit toolkit, in addition to an interesting overlap we discovered with the well-known attack campaign DarkHotel. In a follow-up post, we will discuss the other campaigns associated with HOMEKit, along with other variants of HOMEKit that we discovered.

In addition to analysis of HOMEKit, we will also examine a new payload we discovered embedded in one of the malicious documents created by HOMEKit, which we have named “Cookle.” It is a fairly simple downloader tool, but until now has not been publicly discussed. Cookle deploys some interesting tactics to obfuscate its activity.

Telemetry

In late June 2016, we collected an e-mail file (Figure 1) that appeared to carry a phishing attack with a malicious file attached. The sender address was spoofed, using the identity of a coordination associate for the United Nations Environment Programme (UNEP). The content of the email seemed legitimate, using the subject line of “Pyongyang International Phonebook and Mailing lists – JUNE,” attempting to appear as a global directory for residents of the Democratic People’s Republic of Korea under UNEP. To further increase the legitimacy of the phishing attack, the threat actor copied the coordination associate’s signature block as well.

Figure 1 Phishing email carrying HOMEKit exploit file

The email contained two file attachments, a Microsoft Word document and a Microsoft Excel document. The Excel document proved to be benign, but the Word document exploited the CVE-2012-0158 vulnerability. If the victim were to open the Word document, it would silently install the Cookle Trojan, while opening a decoy document in Word (Figure 2), displaying the expected content to the victim.

Figure 2 Decoy document containing message intended for residents of Pyongyang

The benign Excel document and the Word document used as decoys both appeared to be legitimate, internal documents; the Word document containing the email addresses of all DPRK UNEP residents, along with mailing lists to use for specific topics. The Excel document contained additional contacts for other related agencies, in addition to emergency contact information for the DPRK UNEP residents. Examination of the metadata of the two files revealed the Excel document was last modified by the spoofed sender’s identity on June 22, 2016, while the decoy Word document showed the original author as the Coordination Officer in 2012, with a creation timestamp of July 19, 2012. The “last modified” field of the decoy document though revealed its true nature, showing that it was last modified on April 5, 2016, by “Windows User” indicating the decoy document was likely to be last modified by the threat actor.

By using the specific documents observed in this attack, the threat actor demonstrated that he or she may have already gained unauthorized access to some extent. Also, the contents of these internal documents show that the threat actor currently has access to data that could be further leveraged to craft additional phishing attacks at related targets.

HOMEKit

The HOMEKit toolkit creates Microsoft Word documents (OLE) that exploit the CVE-2012-0158 vulnerability. All malicious documents created by the HOMEKit toolkit have the same metadata within the SummaryInformation and DocumentSummaryInformation streams of the OLE document, as seen in Figure 3.

Figure 3 HOMEKit Meta Data

HOMEKit creates documents designed to exploit a vulnerability within the TreeView ActiveX control, specifically the CLSID of 9368265E-85FE-11d1-8BE3-0000F8754DA1. Upon successful exploitation, the malicious document will execute shellcode to open a decoy document (~.doc) while it installs and executes a payload on the system (~.dat).

The shellcode executed by this variant of HOMEKit begins with a decryption stub that is responsible for decrypting the functional shellcode. The decryption stub uses a combination of right bit shifting (ROR 3) and an XOR operation (key of 0xAF) on each byte of ciphertext.

The functional shellcode exposed by the decryption stub starts by enumerating open file handles looking for files that have a file size greater than zero. It then reads the last 20 bytes of each file looking for the value “0xDEADFOOD” at the very end of the file to find the delivery document. Once it finds the appropriate file, it parses the last 20 bytes of the file to locate the payload and decoy document using the following structure:

To decrypt the payload and decoy, the shellcode uses an algorithm that starts from the end of the ciphertext, using the lowest byte of the initial value of “0xDEADFOOD” to XOR the first byte and then rotating the key value by 1 for each subsequent operation. The shellcode will save the payload to %TEMP%\~.dat and the decoy to %TEMP%\~.doc after the decryption routines are finished. Once the payload and decoy are saved to the system, the shellcode creates a process with %TEMP%\~.dat to execute the payload and creates a process with the following command line to open the decoy document:

cmd.exe /c dir /s %windir%\system32\*.sys&&taskkill /im winword.exe /f&dir /a /s %windir%\system32\*.msc && DOCUME~1\ADMINI~1\LOCALS~1\Temp\~.doc

When creating the processes to run the payload and open the decoy, the shellcode calls GetCurrentProcess to get a handle to the current Word process, then OpenProcessToken to access the Word process’s token. Finally, it uses this token to call CreateProcessAsUserA to run the payload and the decoy with the same context as the current Word process.

Cookle Trojan

At a high level, the payload delivered in this attack is a downloader Trojan that we are tracking as “Cookle” based on a header value in HTTP requests made by the malware.

After initial execution, the Trojan creates the mutex “LDE_160425” and copies itself from %TEMP%\~.dat to %APPDATA%\Microsoft\WindowsUpdate\~.exe. For persistence, the Trojan creates the following registry key with a path to the newly copied Trojan:

SOFTWARE\Microsoft\Windows\CurrentVersion\Run\Startup

A majority of the pertinent strings embedded within the Trojan are encoded, which the Trojan decodes using a modified base64 decoding function that swaps the uppercase letters in the base64 alphabet with lowercase letters, and vice versa. It uses this custom base64 decoder to decode the following strings:

The Trojan contains two command and control (C2) domains within the encoded strings listed above, dyn.kaleebso[.]com and dyn.pwnz[.]org. The Trojan sets a sleep timer of 20 minutes to wait before generating and sending network beacons to the C2 servers. The initial beacon seen in Figure 4 contains a misspelled “Cookie” field that includes the same value the Trojan uses as a mutex.

Figure 4 C2 Beacon sent from Cookle Trojan

If the Trojan receives a response to this beacon from the C2 server, it runs several system commands, specifically systeminfo, tasklist, netstat /ano, and ipconfig /all. It will then take the output from those system commands and save the output to a text file in the %TEMP% folder with a filename of “<year><month><day><hour><minute><second>.tmp”. The Trojan will then send the contents of this file to the C2 server as cleartext within a HTTP POST request that will resemble the following:

Figure 5 HTTP POST request issued by Cookle that sends system information to C2 server

The C2 server will respond to this request with a command that the Trojan will parse. The Trojan’s command handler has three available commands:

Figure 6 Commands within Cookle’s Command Handler

The functionality available within the Trojan is limited, however, it allows the actor to perform system reconnaissance before delivering a secondary payload. The secondary payload is delivered via the ‘d’ command, wherein the Trojan will decrypt an executable using the XOR operation on each byte in the C2’s response with 0xA7. During the analysis period, the C2 servers did not respond with a secondary payload.

Overlap with DarkHotel

Collection of additional HOMEKit delivery documents revealed use of this toolkit by its operators since at least 2013 and most recently, late June 2016. Each of these malicious documents created by the HOMEKit toolkit installed different payloads including PlugX, Sutr, and HIMAN/Mirage, among others. As mentioned earlier, we will be publishing a follow up to this post that contains details of these prior attacks.

As part of the collected sample set, we found two documents that have a very similar structure as the delivery document used in the attack delivering the Cookle payload but with very slight variations in the exploit code. The most curious aspect of these two documents was the payload embedded in them.

Both of the additional HOMEKit samples have the same functional shellcode and install a downloader associated with the Tapaoux Trojan, a tool related to the DarkHotel threat group. We compared the shellcode embedded in the HOMEKit delivery documents with previous samples associated with DarkHotel and found striking similarities (Figure 7).

Figure 7 Comparison of notable static attributes within HOMEKit documents installing Cookle and DarkHotel

The major difference between the HOMEKit documents dropping Cookle and DarkHotel begins with the stub decrypter, as seen in Figure 7. The stub decrypter decrypts a second piece of shellcode that carries out the main functionality as mentioned previously in this post. The decryption routines themselves differ, as seen in the green highlighted instructions in Figure 8. The size of the decrypted shellcode differs between the two samples as well, as seen in the yellow highlighted “mov cx” instructions in Figure 8.

Figure 8 Comparison of stub decrypters found in the shellcode within Cookle and DarkHotel samples

Even though the size of the shellcode differs between the Cookle and DarkHotel samples, the shellcode itself is extremely similar. A simple binary difference between the two functional shellcodes result in over a 90 percent similarity. Static analysis determined that the two shellcodes resolve the same API functions and store them on the stack in the same order. Also, many identical code blocks exist between the two shellcodes that results in significant code overlap. The similarities in shellcode suggest that the author of the HOMEKit toolkit variant used to deliver the Cookle Trojan had access to the same shellcode as the HOMEKit toolkit used to install DarkHotel.

The difference between the functional shellcode that installs Cookle and DarkHotel lies in the way a process is created to execute the payload and to open the decoy document. While the difference between the two is very minor, it is worth discussing as it suggests the author of the Cookle shellcode intentionally modified the DarkHotel shellcode, possibly as an anti-analysis technique. Figure 9 shows a side-by-side comparison of the process creation functionality within the DarkHotel and Cookle shellcodes, which highlights the differences between the two (red and blue highlighted instructions and two new gray code blocks).

Figure 9 Side-by-side comparison of the shellcode dropping DarkHotel and Cookle, specifically code used to create a process

The comparison in Figure 9 shows the differences between the two functions using highlighted instructions and additional boxes, but it does not explain what the changes mean from a functionality standpoint. We will explain how the two functions go about creating a process and how they differ.

The DarkHotel shellcode first uses the GetCurrentProcess function to get a handle to the Word process, then uses OpenProcessToken and finally CreateProcessAsUserA to open the decoy and execute the payload just like the Cookle shellcode. However, the DarkHotel shellcode calls the API functions in a very straightforward manner, specifically using CALL instructions (highlighted red in Figure 9).

In contrast, the Cookle shellcode uses CALL instructions to call the GetCurrentProcess and OpenProcessToken functions, but jumps to the CreateProcessAsUserA function using a JMP instruction. To allow the use of JMP in place of a CALL, the shellcode must provide a way to return to the function that called it, as the JMP instruction does not automatically handle this like the CALL instruction. Instead, it references a specific location (top four blue highlighted instructions) and starts looking for the value “0xC3” (first gray box in Figure 9), which is the value for the instruction “RETN”. Once found, the shellcode will push to the stack so the JMP instruction can be used to call the CreateProcessAsUserA function and return to the original calling function.

The similarities between the delivery documents dropping Cookle and DarkHotel payloads suggest that both were generated by the HOMEKit toolkit, albeit using slightly different versions. The slight differences between the stub decrypters and the functional shellcode within the malicious documents hints that the actor may have used the same codebase to create a modified version of HOMEKit for use in the Cookle attack.

Conclusion

As we have highlighted several times in the past, the reuse of tools is quite common amongst various threat actor groups. Our next post will further map out the various campaigns associated with HOMEKit, along with the multiple variants discovered in the span of several years. The DarkHotel payload however, is a curious outlier in the grouping of payloads we were able to identify. It is possible that the DarkHotel threat actors were able to obtain a copy of the HOMEKit codebase somehow, or even possible that the Tapaoux Trojan was obtained by operators with access to HOMEKit. It is also possible that HOMEKit is a toolkit available to multiple threat actors, via a connected intermediary. Unfortunately, at this time, a lack of data does not allow us to come to a definitive answer. Regardless, it is yet another example of tool sharing and overlap, this time with surprising results.

• Palo Alto Networks customers are protected and can learn more via the following resources:
• All samples of this HOMEKit variant and Cookle are detected as malicious by WildFire
• All domains described in this post are classified as malicious
• HOMEKit and Cookle AutoFocus tags created

Indicators of Compromise

HOMEKit SHA256

ed676d191684fa03b2b57925fe081cf32d5d6b074637f6f2a6401dd891818752
ab7b5c35786813ed874483d388edbee3736eb6af7bc4946c41794209026eeac4
f9bf645a3a7d506136132fcfa18ddf057778d641ff71d175afd86f1a4fed7ee9

Cookle SHA256

4a5807bab603d3a0a5d36aaec75729310928a9a57375b7440298fb3f3e4a2279

Cookle C2s

dyn.kaleebso[.]com
dyn.pwnz[.]org

DarkHotel SHA256

2437d0a9cc019e33fe8306fceed99605dd5ab67a8023da65fa20b9815ec19d06
bb06bfad96535ad04a6e65a6e68f34cb51f311cae48a2ff1c305f3957b2c8a4b

DarkHotel C2s

apply-wsu.ebizx[.]net
apply.ebizx[.]net

Bryan Lee and Robert Falcone

[Palo Alto Networks Research Center]