Tracking MiniDionis: CozyCar’s New Ride Is Related to Seaduke

Executive Summary

Unit 42 has uncovered a new campaign from the CozyDuke threat actors, aka CozyCar [1], leveraging malware that appears to be related to the Seaduke malware described earlier this week by Symantec. [2]

This campaign, which began on July 7, 2015, appears to be targeted at government organizations and think-tanks located in democratic countries [3], and utilizes compromised, legitimate websites for spear phishing and command and control activity.

Unit 42 discovered the extent of this attack using the Palo Alto Networks AutoFocus service, which allows analysts to quickly find correlations among malware samples analyzed by WildFire. All files referenced throughout the analysis are contained in the IOC table at the end of this blog.

Malware Details

The Initial Droppers: Decoy and Downloader

The current CozyCar campaign includes spear phishing emails that deliver the payload from either by a link to a .zip file on a compromised website or by direct delivery as an attachment to the phish.

At the time of our analysis, the phishing link was no longer active. When a user opens the attached file a poorly detected executable file [VT 1/54] is extracted. The initial dropper is a self-extracting archive (SFX). Upon execution, this executable file will drop two files in the %TEMP% directory: a decoy .wav file and the secondary dropper.

The CozyDuke group commonly uses legitimate media files to trick users. In reality, while the media -- a .wav file with a female voice claiming to be a reporter looking for commentary -- is played, the secondary dropper executes in the background. The secondary dropper requests a .swf file using SSL as illustrated in the HTTP traffic below.

As of this writing, the domain extranet.qualityplanning[.]com resolved to 64.244.34[.]200.

The secondary dropper then cleans up after itself with a simple vbs script (md5:0d132ee171768dc30d14590ed2dbadd1) that leaves only the decoy multimedia file behind. But what did the dropper do with the .swf file?

The Real Payload

While the player.swf file downloaded by the second stage dropper does contain media, it is, again, a decoy.

The actual flash component of this file is roughly 16kb, leaving approximately 200kb of the file unaccounted for. The second stage dropper contains decoding routines that decode the arbitrary binary data into an executable file.

The executable file is dropped in %appdata%/Roaming and appears to try and emulate legitimate software names: TimbuktuDaemon, SearchIndexer, RtkAudioService64, dirmngr, o2flash, and usbrefs64. This file was not observed on VirusTotal until July 9 and has extremely low detection rates [VT: 3/54].

It appears that the authors of this particular iteration of the CozyCar group's malware internally call it "miniDionis" according to pdb strings left in the binary (c:\BastionSolution\Shells\Projects\miniDionis4\miniDionis\obj\Release\miniDionis.pdb). It also appears to be an iteration on the “forkmeimfamous” aka Seaduke malware analyzed by Unit 42 in a previous blog [4].

The malware stores 2 files in the %temp% directory: a configuration file and a secondary dll. The configuration file's name matches the final characters of the bot_id that is contained within as per the sample below:

Figure 1. .net disassembly of the primary payload shows the author's name for the project, "miniDionis".

Analysis of the secondary dll file (name matches [A-Z0-9]{1}\.tmp) indicates that its primary function is to serve as a cleanup mechanism for the dropped binary. This is likely an attempt to thwart forensic investigations.

Further examination of memory dumps taken following the execution of miniDionis reveals some clues into the beaconing activity exhibited. The malware stores configuration values in memory as key:value pairs:

The configuration of miniDionis is a JSON blob with several important sections, which are described in the table below:

Table 1. 'miniDionis' configuration keys

Network Communications

The functional payload of this Trojan starts by creating a Mutex by splitting the "bot_id" value in the configuration on the hyphen ("-") and using the second portion of the split string (specifically, "01MRLXW" in the case of this configuration).

From a functionality standpoint, the Trojan uses the concept of tasks that are processed and completed using a pool of threads. To obtain tasks, the Trojan will issue an HTTPS request to the C2 server ("host_scripts" in the configuration) that resembles the following example beacon:

The Trojan manually creates the cookie in this HTTP request. The cookie contains ciphertext that the Trojan creates based on the "bot_id" in the JSON configuration. The Trojan compresses the "bot_id" string using zlib and then encrypts it using the RC4 algorithm using a generated key. The generated key is a SHA1 hash of two randomly created strings: the first of which is between 2 and 8 bytes long and the second is between 1 and 7 characters in length.

The ciphertext of the "bot_id" is then based64 encoded and finally the appended to the "cookie_name" ("SSID=") in the configuration and sent within the HTTP request to the C2 server.

Unit 42 did not observe the first random string (between 2 and 8 characters in length) sent to the C2 in the first beacon, which would be required by the C2 to reproduce the exact SHA1 hash used as a key to generate the ciphertext in the cookie. Upon further examination we believe that the C2 will not be able to decrypt the cookie in the first beacon. Instead, the C2 will respond to the first beacon with data that the Trojan will use to extract a string, using a function named TrExtractKey seen in Figure 2, to replace the first random string used to generate the SHA1 hash.

Once the C2 and Trojan have synchronized using this string, the C2 will be able to decrypt subsequent network beacons because the Trojan includes the random string between 1 and 7 characters that makes up the second half of the SHA1 hash within the cookie field before the ciphertext.

Figure 2. TrExtractKey Function Used by MiniDionis to Obtain String from C2 to Synchronize Keys

The C2 communications, and several of the commands we will discuss in this blog, include a rather interesting technique to manually handle HTTP redirection, such as the HTTP 301 Moved Permanently and HTTP 302 Found status codes.

The technique used to handle these redirections involves checking for the presence of a "Location" field within the HTTP headers of the server response, then using regular expressions to parse the HTML within server response to find the appropriate URL.

The code contains three regular expressions to parse the HTML to locate the URL, the first of which is "<a.*?>.*?</a>" that locates all of the tags associated with link within the HTML.

The second regular expression of "onclick=\"Accept();\"" locates only links within the HTML with a specific "onclick" action.

The last regular expression of "href\\s*=\\s*(?:[\"'](?<1>[^\"']*)[\"']|(?<1>\\S+))" to obtain the correct URL to interact with as the C2 server.

Command handler

Once the C2 and Trojan have synchronized and can decrypt their network communications the C2 server will begin responding to beacons from the Trojan with JSON blobs.

Unit 42 has not received any JSON blobs from an active C2 server, but based on static analysis of the Trojan determined the JSON would look as follows:

The Trojan takes this JSON blob and adds each task in the list into a pool for processing. Separate worker threads access this pool of tasks and process the commands and perform the necessary activities.

Unit 42 analyzed the Trojan’s command handler and found several commands, as seen in Table 2, which allows the threat actors to carry out a full range of activities on the system.

Table 2. Available Commands within MiniDionis’ Command Handler

Conclusion

The actors behind the CozyDuke framework are highly sophisticated, motivated, and have become increasingly bold in their campaigns.

We recommend that other security practitioners review the included Indicators of Compromise (IoCs) to ensure they have not been targets in this campaign, and add the appropriate security controls to prevent future attacks.

This group is reliant on social engineering, and thus, user education remains of paramount importance.

Palo Alto Networks customers using WildFire were protected from this campaign. All known elements of this campaign have been accurately identified by WildFire as malicious.

IOCs

Sources

[1] https://securelist.com/blog/research/69731/the-cozyduke-apt/
[2] http://www.symantec.com/connect/blogs/forkmeiamfamous-seaduke-latest-weapon-duke-armory
[3] http://www.theregister.co.uk/2015/04/22/cozyduke_hackers_white_house_state_dept_malware/
[4] http://blog.paloaltonetworks.com/2015/07/unit-42-technical-analysis-seaduke/