Chafer threat actor group delivers mechanical flounder, overlaps with Oilrig

News by Robert Falcone, Brittany Ash

New research on Chafer threat actor group - which is known for targeting Middle Eastern targets - found using a Python-based payload, shows an overlap with Oilrig.

New research from Palo Alto Networks Unit 42 finds that Chafer threat actor group who are known for targeting middle eastern targets have an an overlap with Oilrig.

The Chafer threat group has been active since at least 2015 focused on both private and publiccsector entities within the Middle East. Unit 42 has specifically observed the targeting of Turkish government entities since at least 2016; however, this (research below)  is the first instance where Unit 42 has observed Chafer using a Python-based payload.

This payload, now known as MechaFlounder was created by Chafer using a combination of actor developed code and code snippets freely available online in development communities. The MechaFlounder Trojan contains enough functionality for the Chafer actors to carry out the necessary activities needed to accomplish their goals, specifically by supporting file upload and download, as well as command execution functionality.

The overlap in Oilrig’s Clayside VBScript and Chafer’s AutoIT payloads does not come as a complete surprise. Oilrig and Chafer have for quite some time appeared very similar operationally and potentially having access to the same code or resources for payload
development makes sense. Unit 42 has taken reference to the various overlaps in the two sets of activities and continues to track these operations separately.

The research

In November 2018 the Chafer threat group targeted a Turkish government entity reusing infrastructure that they used in campaigns reported earlier in 2018 by Clearsky, specifically, the domain win10-update[.]com. While there was no visibility into the initial delivery mechanism of this attack, a secondary payload was observed hosted on 185.177.59[.]70, the IP address to which this domain resolved at the time of the activity.

Unit 42 has observed Chafer activity since 2016, however, Chafer has been active since at least 2015. This new secondary payload is  Python-based and compiled into executable form using the PyInstaller utility. This is the first instance where Unit 42 has identified a Python-based payload used by these operators. The research also identified code overlap with OilRig’s Clayside VBScript but at this time track Chafer and OilRig as separate threat groups. This payload has been named MechaFlounder for tracking purposes and to discuss details below.

Turkish government targeting

Visibility into this Chafer activity involves the identification of a malicious executable downloaded from the IP address 185.177.59[.]70. How the attackers are targeting victims
and causing them to download this file are currently not known.

The file named ‘lsass.exe’ was downloaded from win10-update[.]com via an HTTP request. The win10-update[.]com domain has been noted in open source as an indicator associated with Chafer threat operations. The lsass.exe file downloaded from this domain is a
previously unreported python-based payload that is currently being tracked as MechaFlounder.

Unit 42 believes Chafer uses MechaFlounder as a secondary payload that the group downloads from a first-stage payload to carry out its post-exploitation activities on the compromised host. Based on Unit 42 telemetry, the first-stage payload was not observed in this activity.

In February 2018, IP address 134.119.217[.]87 resolved to win10-update[.]com and several other domains likely associated with Chafer activity. Of interest, the domain turkiyeburslari[.]tk, which mirrors the legitimate Turkish Scholarship government domain Turkieyburslari[.]gov[.]tk, also resolved to this IP and may likely have
been used in other Chafer collection operations. The domains associated with this IP address are included within the Appendix and displayed in Figure 1 below.


Figure 1. Infrastructure associated with 134.119.217[.]87

The MechaFlounder payload

The python-based payload, ‘lsass.exe’ was retrieved from a command and control (C2) server via an HTTP request to the following URL: win10-update[.]com/update.php?req=&m=d

This payload, (SHA256: 0282b7705f13f9d9811b722f8d7ef8fef907bee2ef00bf8ec89df5e7d96d81ff), being tracked as MechaFlounder, was developed in Python and bundled as a portable executable using the PyInstaller tool. This secondary payload acts as a backdoor allowing the operator to upload and download files, as well as run additional commands and applications on the compromised system.

MechaFlounder begins by entering a loop that will continuously attempt to communicate with its C2 server. The Trojan will use HTTP to send an outbound beacon to its C2 server that contains the user's account name and hostname in the URL.

The code, seen in Figure 2, builds the URL by concatenating the username and hostname with two dashes "--" between the two strings. The code then creates the URL string by using the username and hostname string twice with the back-slash "\" character between the two and by appending the string "-sample.html".

Figure 2. Trojan code used to build anomalous HTTP request

During this analysis, the code in Figure 2 generated anomalous HTTP requests for its beacons, as shown in Figure 3 below. One might notice that the GET request in Figure 3 does not start with a forward-slash "/" character and includes a back-slash character "\" in the URL. This causes a legitimate web server, such as nginx used in our test environment, to respond with a '400 Bad Request' error message. This may suggest that even though the code in Figure 2 uses the HTTPConnection class from the httplib module to generate the anomalous HTTP beacon, it is likely that the threat actors created a custom server to handle this C2 channel instead of relying on a standard web server.

Figure 3. Example HTTP request issued by Trojan in test environment

Additionally, Figure 2 shows that the malware author used the variable name 'cmd' to build the string used for the HTTP method and path and checks the HTTP method portion of the string for the word 'exit'. Unit 42 says it is unsure of the purpose of this check, as the HTTP method in this string would never be 'exit' and therefore would never be true. Unit 42 believes this is an artifact likely derived from a previous version of the script that the author forgot to remove.

If the C2 server were to accept the above beacon, it would respond with HTML that contains a command intended for the Trojan to parse and execute. The Trojan begins by converting the HTML in the response to text using the code seen in Figure 4 below. The HTML to text code in Figure 4 is available in several locations on the Internet, but it appears to have possibly originated from a discussion at Stack Overflow titled Extracting text from HTML file using Python, which may be where the malware author obtained this code.

Figure 4. HTML to text code in Trojan possibly obtained from Stack Overflow discussion

After converting the HTML to text, the Trojan discards the first 10 characters of the response and treats the remainder of the string as a command. The C2 can also provide the string "yes " in this command string, which instructs the Trojan to decode the command as a base16 encoded string with the "yes " substring removed. The Trojan subjects the command supplied by the C2 to a handler that determines the activities the Trojan will perform. Table 1 shows a list of commands available within the Trojan's command handler and the corresponding activities. The commands in the command handler provides the necessary functionality for Chafer to interact with the remote system.

Command description

Terminate Terminates the connection download Downloads provided that it will obtain from http://and saves it to C:\Users\Public\. runtime Sets the sleep interval between beacons. upload Uploads provided to http:// via HTTP POST.

cd Changes the current working directory. empty Does nothing, likely an Idle command.  Attempts to run the supplied data as a command on the command line.

Table 1. Commands available in Trojan’s command handler. Unit 42 gained more insight into the custom C2 server application by analysing the activities that MechaFlounder carries out if it receives the ‘upload’ command. To upload a specified file from the compromised system to the C2 server, the Trojan uses the Browser class in the mechanise module (partial basis of the MechaFlounder name) to submit the file to an HTML form on the C2 server. This suggests that in addition to being able to handle the anomalous HTTP GET requests previously mentioned, the custom C2 server application must also be able to:
1. Serve HTML that contains a form to receive uploaded files,
2. Handle legitimate HTTP POST requests generated by the mechanise module, and
3. Save files uploaded with the HTTP POST request.
After carrying out the activities for the command, the Trojan will encode the results or output message of the command using the 'base64.b16encode' method. Each command has an output message for both a successful and failed execution of the command with the exception of ‘empty’ and ‘terminate’. Table 2 below shows the success and failure messages associated with each command.

Command Message type Output message structure
download Success --||download
**download success\n
Fail ||--
**download failed,
download \n
upload Success --||upload
**upload success \n
Fail (no file) --<hostname
>||**no such

file\n
Fail (exception) ||--
**upload failed,upload
\n
runtime Success ||--
**runtime changed to

Fail --
||<command
issued>**runtime change failed
because of large mount
cd Success --
||<command
issued>**directory changed success
to
Fail --
||<command
issued>**Couldn"t change directory
(command
execution)
Success --
||<command
issued>**

Fail --
||<command
issued>**

Table 2. Success and failure messages associated with commands

Unlike the initial beacon that uses the anomalous HTTP GET request, the Trojan will send the encoded results to the C2 server using the same socket as the initial HTTP beacon. The use of the same socket and the anomalous portions of the HTTP beacon further suggests that the threat actor likely created a custom C2 server to handle this network traffic.

To show these network communications, Unit 42patched the Trojan to issue beacons that use legitimate HTTP GET requests that the HTTP server (nginx) in our test environment could support. The patches involved changing the paths within the HTTP request, specifically setting the path to start with a forward-slash "/" and have the forward-slash "/" instead of a back-splash "\" within the URL path itself. In its test environment, Unit 42 added the string "0123456789runtime 5" to the file ‘rob--rob-virtual-machine-service.html’ in the ‘rob--robvirtual-machine’ folder.

When the Trojan issues the beacon, the HTTP server responds with contents of the ‘rob--rob-virtual-machine-service.html’ file, which effectively issues a command to the Trojan. The Trojan responds to the command ‘runtime 5’ with the message "5||rob--rob-virtual-machine**runtime changed to runtime 5" that it encodes in base16. It then sends this to the C2 server without any HTTP headers using the same socket as the initial HTTP request.

Figure 5 shows the TCP session showing the initial beacon sent from the patched Trojan, the HTTP server responding with a command, and the Trojan responding to the command all in the same TCP session.


Figure 5. Single TCP Session used by the Trojan to receive commands and send command results to the C2

And one more thing...

If you think you’ve seen the "&m=d" parameter before, you’d be correct. The "&m=d" parameter seen in the initial download URL of the MechaFlounder payload appears in many URLs related to both Chafer and OilRig threat groups. This parameter has been seen in VBScript downloader payloads installed by delivery documents associated with both Oilrig and Chafer.

Unit 42 has also seen this parameter used in URLs generated by Chafer’s AutoIT payload. The VBScript and AutoIT payloads also share common variable names and the same overall functionality, which suggests there may be some code sharing occurring between the two threat groups. Figure 6 below shows a VBScript run by an OilRig delivery document (SHA256: 1b2fee00d28782076178a63e669d2306c37ba0c417708d4dc1f751765c3f94e1) on the left compared to a Chafer AutoIT script (SHA256: 332fab21cb0f2f50774fccf94fc7ae905a21b37fe66010dcef6b71c140bb7fa1) on the right, which have colored boxes surrounding code overlaps.

Unfortunately, Unit 42 was unable to ascertain the specifics between the code sharing between OilRig and Chafer. At this time, it is not combining the two threat groups together based on these code overlaps.

Figure 6. Oilrig Clayside VBS | Chafer AutoIT

Palo Alto Networks says it protects its customers against this threat in the following ways:

• WildFire detects MechaFlounder with a malicious verdict
• Domains identified as command and control servers are flagged as malicious
• AutoFocus tags MechaFlounder and Chafer.

Palo Alto Networks has shared its findings, including file samples and indicators of compromise, in this report with fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. 

Find this article useful?

Get more great articles like this in your inbox every lunchtime

Video and interviews