Our researchers Paul Litvak and Michael Kajilolti have discovered a new campaign conducted by APT34 employing an updated toolset. Based on uncovered phishing documents, we believe this Iranian actor is targeting Westat employees, or United States organizations hiring Westat services.
Westat is a United States-based company that “provides research services to agencies of the U.S. Government, as well as businesses, foundations, and state and local governments”. One example of the services Westat offers is a survey for federal workers, which leads us to believe this attack may target Westat customers.
Official Westat response: “Westat understands that in their effort to identify threats and malware, Intezer has identified a malicious file that uses the Westat name and logo. This file was not created by, hosted by, or sent from Westat, and is likely the result of a bad actor stealing the Westat brand name and logo. Our cybersecurity team is working with Intezer and others to fully understand the nature of this report. We will continue to monitor the situation and respond accordingly.”
APT34 (also known as OilRig or Helix Kitten) is a cluster of Iranian government-backed cyber espionage activities that has been active since 2014. The group is known to target various international organizations, mainly in the Middle East. Among their targeted industries are government agencies, financial services, energy and utilities, telecommunications, and oil and gas.
More light was shed on this group in April 2019 as leaks emerged from a mysterious individual with the pseudonym “Lab Dookhtegan”. This individual exposed data belonging to victims of this group, together with source code of hacking tools and data about previous APT34 operations; including IP addresses and domains where the group hosted web shells related to past operations.
Most recently, FireEye exposed a spear-phishing operation conducted by APT34, which enabled us to connect this operation to this Iranian actor due to similarities in the techniques and tools employed in both campaigns.
In late January 2020, we discovered a file named survey.xls that was designed to look like an employee satisfaction survey tailored to either Westat employees or Westat customers.
At first the spreadsheet appeared to be blank. Only once the victim enables macros, the survey is displayed to the user and the malicious VBA code begins to execute.
The embedded VBA code unpacks a zip file into a temporary folder, extracts a “Client update.exe” executable file and installs it to “C:Users<User>valsClient update.exe”.
“Client update.exe” is actually a highly modified version of the TONEDEAF malware, which we named TONEDEAF 2.0. Finally, the crtt function creates a scheduled task “CheckUpdate” that runs the unpacked executable five minutes after being infected by it, as well as on future log-ons.
Survey.xls VBA Code
Both the extracted VBA code and the functionality of the code look similar to the one analyzed in the FireEye report:
APT34 VBA Code from the FireEye Report
In addition, we found a similar document labelled as “Employee satisfaction survey.xls” containing the same survey as the previous document.
Employee Satisfaction survey.xls
However, it’s important to highlight that the code page field of this document is Arabic as can be seen when examining its file metadata, denoting the preferred language installed on the document author’s version of Microsoft Excel:
Employee Satisfaction survey.xls Metadata
At first glance, “Client update.exe” seems like a completely new backdoor malware. However, further examination reveals it’s most likely a highly modified version of the previously seen TONEDEAF backdoor. TONEDEAF is a backdoor that communicates with its Command and Control server via HTTP in order to receive and execute commands. It was mentioned in FireEye’s recent report about an ongoing APT34 operation, as one of the group’s custom tools. We have named the new variant TONEDEAF 2.0.
TONEDEAF 2.0 is an advanced version of TONEDEAF, serving the same purpose as the original, but with a revamped C2 communication protocol and a substantially modified code base. In contrast to the original TONEDEAF, TONEDEAF 2.0 contains solely arbitrary shell execution capabilities, and doesn’t support any predefined commands. It’s also more stealthy and contains new tricks such as dynamic importing, string decoding, and a victim deception method.
Upon execution the backdoor checks whether it was executed with “…” as an argument, which is the way it’s configured to execute by the scheduled task, as part of the proper infection chain.
In the case it’s executed without the correct argument, such as by launching it via a double click, it will display a blank GUI Window to the user. This is most likely intended to serve as a deception method, to make the malware appear like a legitimate (alibiet broken) application titled “Bee”.
GUI Window Used for Deception
TONEDEAF 2.0 also attempts to be more stealthy than its predecessor by hiding many of the interesting API imports it uses. The names of these APIs, and the DLLs that contain them, are stored as encoded strings and are decoded and resolved on demand during runtime.
Decoding and Resolving API Functions
The backdoor uses HTTP for C2 communication, with a custom encoding and handshake mechanisms. Messages sent by the backdoor always contain the HTTP query parameter “?ser=<6 digits>” as an identifier. The first three digits are the <server_id> and the last three are the <client_id>. The backdoor will use one of the following two messages:
1. GET /dow?ser=<server_id><client_id> – request message, used to obtain commands to execute from the server.
2. POST /upl?ser==<server_id><client_id> – reply to command message, used to send the executed command’s output to the server.
Before performing the first request, the malware will generate the <client_id> derived from the environment variables %HOMEPATH% and %COMPUTERNAME% using a custom formula.
It will then send an initial GET message to the C2 using that ID.
One odd element about the communication is the usage of a Windows Phone User-Agent value in the HTTP message.
During our analysis the C2 was alive but continuously replied with a 403 Forbidden HTTP error code to our requests. It’s possible that the C2 is filtering the targets since this backdoor is part of a targeted operation and our client_id parameter does not match that of one of the intended victims.
Should the C2 accept the ID, it will reply with an encoded message that contains the <server_id> and the command the backdoor needs to execute. The malware extracts the command by looking for an HTTP div element in the response with a special class name.
Parsing of C2 Response
The malware will then execute the command by prepending it with “cmd U c” and will send the output of the command back to the C2 using the POST reply message (2).
When entering the C2 via a browser, the site tries to imitate https://docs.microsoft.com/en-us/, although it fails to display it properly due to a misconfiguration with the CSS, as can be seen in the console:
manygoodnews[.]com C2 webpage
We have also observed that an SSL certificate has been recently generated that matches the domain of the C2.
SSL Certificate for the C2 Domain that was Issued One Month Ago
These findings might indicate that the attackers are in the process of transitioning into HTTPS for C2 communication, in an attempt to improve their OPSEC capabilities and avoid detection.
Traces from the Original TONEDEAF
With all of the changes and new additions, there are still enough similarities that link TONEDEAF 2.0 to the original. While the code is mostly modified, the general flow and functionality are similar. The C2 communication is different but still has similarities to its predecessor, such as the usage of three digit identifiers for both the victim and the server. However, most notably there are several places in the code where the similarity is most clear. One such place is a function that exists in both variants, which oddly enough creates a notification icon in the Windows status bar. The only notable changes are the usage of dynamic API resolution and the shortening of the notification message from “Updating” to “up”.
Specific Function Comparison
Another instance is the code that sets the working directory of the program. It appears in different stages for each variant, but is identical:
Similar Code Snippets
We were unable to download further modules, however, we believe this operation also includes the usage of a VALUEVAULT implant. VALUEVAULT is a browser credential theft tool built in Golang, discovered by FireEye in the aforementioned APT34 operation analysis.
We found the survey.xls file uploaded to VirusTotal with a VALUEVAULT instance and a TONEDEAF 2.0 instance, uploaded from Lebanon by the same user, only a few minutes apart. This may indicate that these malware were delivered together as part of the same attack.
This VALUEVAULT takes a more minimalistic approach than its predecessor. Many functionalities and strings were stripped from the new binary in order to lower its noise. Only Chrome password dumping is now supported, although interestingly the use of the file “fsociety.dat” as a password data store under the “AppData\Roaming” directory stayed the same.
VALUEVAULT 2.0 Compilation Paths
VALUEVAULT 1.0 Compilation Paths
Furthermore, VALUEVAULT 2.0 is a 64-bit binary as opposed to VALUEVAULT 1.0 which is a 32-bit binary. These relatively minor changes were enough to create a fully undetected implant.
The last APT34 operation was exposed only a few months ago by FireEye, and judging by our current findings we can confidently state that the group has since evolved its operations. The technical analysis of the new malware variants reveals this Iranian government-backed group has invested substantial efforts into upgrading its toolset in an attempt to evade future detection.
The binary code from these new malware samples are now indexed in our Genetic Malware Analysis platform, Intezer Analyze. We encourage you to use our free community edition to detect and classify threats that share code with APT34 malware.