Research by: Eli Salem, Lior Rochberger and Assaf Dahan
Check out a condensed, high level version of this report on our threat alerts page.When Valak was first discovered in late 2019, it was classified as a loader and used in multiple campaigns primarily targeting the US. It was often paired with Ursnif (aka. Gozi) and IcedID. Upon investigation by Cybereason Nocturnus in April 2020, Valak was identified as being used in campaigns mainly targeting the US and Germany. The campaigns involved new versions, revealing that the malware authors have been working on a better, improved version of the malware quickly. Over thirty different versions of the malware were found, revealing tremendous improvements in a very short period of time. Valak’s key features include:
Among it’s improvements, the most important and interesting addition to the newer versions of Valak is a component called “PluginHost”. PluginHost provides communication with the C2 server and downloads additional plugins under the name “ManagedPlugin”. Among the plugins observed are “Systeminfo” and “Exchgrabber”, both of which appear to specifically target enterprises.
In this research, we evaluate the differences between the old and new versions of Valak and elaborate on the malware capabilities, its infrastructure, and its connection to other malware.
Initial infection
In these campaigns, the most common infection vector is via Microsoft Word documents embedded with malicious macro code. The contents of the documents are in English and German depending on the target.
Malicious macro code is used to download a DLL file with .cab extension named “U.tmp” and saved into the temp folder.
DLL file download address: “hxxp://v0rzpbu[.]com/we201o85/aio0i32p.php?l=hopo4.cab”
After downloading the DLL, the code launches the malicious DLL using “regsvr32.exe”.
When executed, the DLL drops and launches using a WinExec API call. This stage of the Valak malware uses a malicious JavaScript file with a random name that changes per execution. In the example below the name of the JavaScript file is “sly4.0”.
First Stage: Gaining Initial Foothold
The downloaded JavaScript code, “sly4.0”, contains a variable called “PRIMARY_C2” that holds multiple fake and legitimate domains, including Google, Gmail, Avast, and Microsoft. The domain list varies between samples.
Valak creates connections to the different C2 servers in the list with two predefined URIs:
*in version 30, the file was renamed to “rpx.aspx”.
*in version 30, the file was renamed to “go.aspx”.
Both files are decoded by the malware using Base64 and an XOR cipher. The key is a combination of a predefined string and information collected from memory during runtime.
The malware sets information like the C2 server, ID, the downloaded payload, and the decoded project.aspx in a registry key under “HKCU\Software\ApplicationContainer\Appsw64”. These keys will be used in the second stage.
After downloading the payloads and setting the registry keys and values, Valak sets it’s persistence via a scheduled task.
The scheduled task is set to launch wscript that executes JavaScript stored as an Alternative Data Stream named “Default2.ini” in the file “Classic2Application.bz”.
The script in the ADS (“Default2.ini”) executes the content of the registry key, “HKCU\Software\ApplicationContainer\Appsw64\ServerUrl”, which holds the contents of “project.aspx”, the second stage JavaScript file.
In the first stage, Valak laid the foundation for the attack. In the second stage, it downloads additional modules for reconnaissance activity and to steal sensitive information.
The two payloads (“project.aspx” and “a.aspx”) and the configuration in the registry keys are used in the second stage to perform malicious activities.
The “project.aspx”, or as we refer to it, the second stage JS, is a JavaScript file that looks very similar to the first stage JavaScript (“sly4.0”). However, on closer inspection it contains additional functions.
The script is executed by the scheduled task used to maintain persistence, with its main goal being:
In the second stage, the configuration file has been altered to contain a unique “Client_ID” and a different file that it will try to download called “bounce.aspx”.
Stage 2 also contains three unique functions, “CreateExecJob”, “CreateOleExecJob” and “LaunchPlugin”.
These functions are called from the “ParseTask” function, and receive the parsed tasks from the C2.
If the malware downloads a payload that starts with the word “ODTASK”, it calls “CreateOleExecJob”, which writes the payload as an ADS of the file “C:\\Users\\Public\\PowerManagerSpm.jar” and creates a scheduled task “PerfWatson_%taskname%” to run it.
If the malware receives a content start with the word “PLUGIN”, it calls “LaunchPlugin”, which executes the PluginHost.exe file using WMI with the content as an argument.
If the malware receives a content starting with the word “TASK”, it calls “CreateExecJob”, which writes the content as an ADS of the file “C:\\Users\\Public\\PowerManagerSpm.jar” and creates a scheduled task “PowerUtility_%taskname%W” to run it.
Our analysis reveals that this time, the payload downloaded by Valak was IcedID. However, the payload can vary, as the attackers can download other payloads to the infected system.
In previous infections, Valak downloaded different remote administration tools like putty.exe and NetSupport Manager.
The decoded “a.aspx” is saved in the temporary folder as %TEMP%\<ID>.bin. This file, internally named “PluginHost.exe”, is an executable file, and will be used to manage additional components.
Valak’s Modular Plugin Architecture
The functionality of the executable “PluginHost.exe” is divided into four classes: Bot, HTTPClient, Program and Utils, which will allow it to perform its main goal of downloading and loading additional components of the malware.
The Bot Class:
The bot class is responsible for reading from several registry entries set by the first stage.
Both functions use the Utils class to read registry entries.
The HTTPClient Class:
The HTTPClient class contains two functions, post and GetPluginBytes.
The GetPluginBytes() function gets the C2 domain using GetC2() and adds an embedded URI. The URL is used to download an additional module for the plugin.
The Program Class:
The Program class contains the main function of the file main(). This function executes the function GetPluginBytes() to download the module components with type “ManagedPlugin”. These components will be loaded reflectively to the executable’s memory and expand the plugin capabilities.
The Utils Class:
The Utils class contains several maintenance functions used by the other classes.
When referring to additional plugins, it is worth noting that in early versions of Valak the plugins were downloaded by the second stage JS via PowerShell. More recent versions of Valak abandoned the popular yet easily detectable PowerShell downloader approach and transitioned to PluginHost as a means of managing and downloading additional payloads. This transition indicates that the Valak authors are looking for stealthier approaches and ways to improve their evasion techniques.
During this analysis, we discovered several different modules with the same internal name, “ManagedPlugin.dll”.
These modules are downloaded and loaded by “PluginHost.exe”.
Among these components, some focus on one single, specific activity to achieve their goal and are relatively less robust than others when it comes to capability and potential impact. This includes ipgeo, procinfo, netrecon and screencap.
Below is a deep dive of “systeminfo” and “exchgrabber”, which are more advanced and complex than the aforementioned plugin components.
“Systeminfo” shares many similarities to “PluginHost.exe” when it comes to class names. However, unlike “PluginHost”, it contains several reconnaissance functions that focus on gathering information about the user, the machine, and existing AV products.
The module gathers information about the user and attempts to verify whether this is a local admin or a domain admin. This shows that after infecting the machine, Valak chooses to target mainly administrators and domain admins. This indicates a propensity to target higher profile accounts such as enterprise admins.
The module attempts to find whether the infected machine has any security products installed using the AntivirusSoftware() function. The information collected about installed AV programs is gathered using the WMI query “SELECT * FROM AntiVirusProduct”.
The module also collects the physical address (MAC) and the IP address of the infected machine.
Additional reconnaissance activity occurs with several other functions, including:
In order to exfiltrate data, the plugin uses the function “post” in the HTTPClient class. “Post” gives the plugin the ability to upload content and exfiltrate data to the remote C2 whose domain is stored in the registry.
Similar to “PluginHost”, “SystemInfo” uses another function called GetQuery() that builds the URL to send the information to the remote C2. The URL is encoded using Base64 and some char replacements.
The core functionality of the “ManagedPlugin” module is in the “ManagedPlugin” class. The function loops endlessly and continues to execute the reconnaissance activity and send it to the attacker.
Exchgrabber, similar to systeminfo, shares some similarities with PluginHost when it comes to several function names like Bot, HTTPClient, and Utils; however, it has its own differentiated capabilities.
At first glance, the module appears to solely be used to steal credentials, which can be seen in several classes and data arguments with clear names like “Credential” and “CredentialType”.
The module handles its credential management in the class “Credential”, which includes several functions that handle the credential management activity and data types that will hold these credentials.
One of the most interesting functions in this class is “Credential” which receives four arguments: username, password, target, and CredentialType. It inserts these credentials into the respective module variable.
The “target” variable is used in the core ManagedPlugin function to store strings related to Microsoft Office applications.
Another interesting argument in the “credential” function is “CredentialType”. The type of credentials is determined by another part of the enum variable called “CredentialType”, which contains each of the credentials that the module will attempt to extract.
The credential types are sensitive information that can be extracted from the enterprise Microsoft Exchange server data, including Domain Password & Domain Certificate.
Extracting this sensitive data allows the attacker access to an inside domain user for the internal mail services of an enterprise along with access to the domain certificate of an enterprise. With systeminfo, the attacker can identify which user is a domain administrator. This creates a very dangerous combination of sensitive data leakage and potentially large scale cyber spying or infostealing. It also shows that the intended target of this malware is first and foremost enterprises.
When inspecting the core logic behind the class MainPlugin, it’s clear how each class collaborates with others to extract data from Microsoft Exchange and Outlook.
The module attempts to check if the extracted data is related to Microsoft Office or MS.Outlook. If so, it attempts to access the file “Autodiscover.xml” using the function GetFiles. “Autodiscover.xml” is a dynamically generated file that contains the data Microsoft Outlook needs to access the mailbox entered in the configuration wizard. The primary purpose of the Exchange Autodiscover service is to establish initial connections to Exchange user mailboxes. It then attempts to collect the AutoDiscover SMTP address of the dedicated exchange forest, and eventually puts all the extracted data in a variable called “text” .
After collecting the sensitive data, the module compresses it using Base64. This is a new feature of this specific module within the “Utils” class. Then, it sends the sensitive data to the attacker’s C2 with the POST function and an embedded URI.
As of writing this report, we have seen Valak change tremendously. It is currently on version number 24.
This section highlights the major differences between the previous versions and newer versions of Valak by analyzing version 6, version 9, version 23, and version 24.
In older versions, Valak downloads the second stage JS and uses only one obfuscation technique: Base64. The newer versions use XOR in addition to Base64.
The newer versions of Valak download two payloads in the first stage. The first payload is Valak’s plugin management component (“pluginhost.exe”), and the second is the second stage JavaScript payload of Valak. In earlier versions, Valak did not include the “pluginhost” payload.
In older versions of Valak, the second stage JS downloads additional content just like the newer versions, including“TASK” / ”ODTASK” / ”PLUGIN”. In the newer versions, Valak also downloads “PluginHost” in stage one and executes it once receiving the task “PLUGIN” in stage two, which then downloads ManagedPlugin.dll. In the older versions, Valak uses the task “PLUGIN” in stage two to leverage PowerShell and download “ManagedPlugin.dll” as a Base64 binary.
As mentioned previously, later versions of Valak abandon the popular yet easily detectable PowerShell downloader approach and transition to “PluginHost” to manage and download additional payloads. This transition may indicate that Valak authors are looking to leverage stealthier approaches and improve their evasion techniques.
Analyzing the different samples reveals a repetitive pattern of URIs used to connect to a “bucket” of domains, all of which are embedded in the code.
For example, the URI used to download the “PluginHost” (a.aspx) is always built off: “a.aspx?redir=1&clientUuid=91&r_ctplGuid=” +<the encoded_ID>+ “&TS2=” +<random string>
This URI is not the only similarity across samples; Valak has several URIs that match this behavior across components.
Valak’s Observed URI Patterns:
Another interesting aspect of the Valak malware is that it has a shared infrastructure among almost all of it’s different versions. As the graph below shows, most of the known domains have a connection between them, whether it be the URIs similarities, downloaded files, or connected files.
Valak infections were initially characterized as rather unilateral, where Valak mainly downloaded other known malware like Ursnif or IcedID. However, over the course of this investigation, it became clear that Valak’s relationship with other malware is actually multilateral.
For example, the following network traffic recording provided by malware-traffic-analysis illustrates an infection chain that is initiated by Ursnif, which downloads IcedID and Valak, both from the same C2 server.
While the nature of the partnership between each of these specific malware is not fully understood, we suspect it is based on personal ties and mutual trust from underground communities. Given the fact that both Ursnif and IcedID are considered to be part of the Russian-speaking E-Crime ecosystem, it is possible that the authors of Valak are also part of that Russian-speaking underground community. This community is known to keep rather close ties based on trust and reputation.
Another clue that may tie the authors behind Valak to a Russian-speaking community are traces of both Russian and Arabic (Saudi Arabia) language settings left in the phishing documents. These language traces appear in all the samples we analyzed, an example of which is shown below:
It is important to mention that the above mentioned language traces can be easily manipulated and put there on purpose by the threat actors, and therefore, it is not enough to determine with certainty the origin of the threat actors.
Although initially downloaded as a payload of other malware, in more recent appearances of Valak, the malware appears to come as a standalone unit in traditional phishing campaigns.
Recent campaigns target two specific geographic locations, including the US and Germany, where the content and the name of the files were written in English and German with files masquerading as legitimate.
Even though Valak appears to have evolved over time and has infostealer capabilities, it is clear that the threat actors behind Valak continue to collaborate with other malware like IcedID and and Ursnif to maximize their revenue.
In this research, the Cybereason Nocturnus team analyzed the emerging malware Valak. Though Valak first made its appearance at the end of 2019 and was classified as a malware loader by several security analysts, our investigation shows that Valak is more than a simple loader of malware. It is a sophisticated modular malware packed with a myriad of reconnaissance and information stealing features.
Over the course of roughly six months, Valak’s developers made tremendous progress and released more than 30 different versions. Each version extended the malware’s capabilities and added evasive techniques to improve its stealth. Valak has at least six plugin components that enable attackers to obtain sensitive information from its victims.
The extended malware capabilities suggest that Valak can be used independently with or without teaming up with other malware. That being said, it seems as though the threat actor behind Valak is collaborating with other threat actors across the E-Crime ecosystem to create an even more dangerous piece of malware.
These malware campaigns seem to focus on targets in the US and Germany. The Cybereason Nocturnus team will continue to monitor Valak’s progress to determine whether Valak infections will spread to other regions as the malware continues to evolve and grow popular among cybercriminals.
Click here to download this campaign's IOCs (PDF)
Click here to download the threat alert (PDF)
|
Initial Access |
Execution |
Persistence |
Privilege Escalation |
Defense Evasion |
Credential Access |
Discovery |
Collection |
Exfiltration |
C&C |