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.
The content of the phishing documents.
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”.
Initial infection as shown in the Cybereason Defense Platform.
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”.
The DLL dropping the JavaScript file.
First Stage: Gaining Initial Foothold
Attack flow for the first stage of Valak.
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.
Malware configuration in the script sly4.0.
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”.
URI embedded in the script.
*in version 30, the file was renamed to “go.aspx”.
URI embedded in the script.
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.
Function “rot13_str” decodes a string using XOR.
The code for downloading the encoded file and decoding it with the first function (rot13_str) and Base64.
The “GetID” functions used to create the XOR key and collect information about the user.
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.
Files and registry keys written by Valak.
After downloading the payloads and setting the registry keys and values, Valak sets it’s persistence via a scheduled task.
Creation of the scheduled task to establish persistence.
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 execution of the scheduled task as shown in the Cybereason Defense Platform.
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.
Registry modifications done by Valak.
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.
Attackflow for the second stage.
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:
Configuration section of the second stage JS.
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.
The “ParseTask” function checks the payload.
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.
The “CreateOleExecJob” function.
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.
The “LaunchPlugin” function.
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.
The “CreateExecJob” function.
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 process tree to establish persistence as seen in the Cybereason Defense Platform.
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.
GetID() andGetC2() reading from the registry.
The RegistryReadInfo() function in the Utils class.
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.
GetPluginBytes function used to download 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.
PluginHost’s main function downloads the ManagedPlugin module.
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.
The Ipogeo module, which collects information using an IP discovery service.
The Procinfo module, which collects information about the running processes.
The Netrecon module, which collects network information.
The Screencap module, which takes screenshots of the infected machine.
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 plugin components in Valak.
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 ManagedPlugin (SystemInfo), which determines if the user is a local or domain admin.
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”.
ManagedPlugin (SystemInfo) checks for antivirus products.
The module also collects the physical address (MAC) and the IP address of the infected machine.
The ManagedPlugin (SystemInfo) collects the machine’s physical address.
Additional reconnaissance activity occurs with several other functions, including:
ManagedPlugin (SystemInfo) reconnaissance functions.
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.
ManagedPlugin (SystemInfo) data exfiltration function post.
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.
Example of the final URL created by the GetQuery function.
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.
ManagedPlugin execution activity.
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”.
Exchgrabber classes.
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.
The ManagedPlugin (Exchgrabber) Credential function.
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.
ManagedPlugin (Exchgrabber) credential types.
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” .
Microsoft exchange data extraction.
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.
ManagedPlugin (Exchgrabber) used for data exfiltration using a predefined 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.
Code from older versions of Valak that only uses Base64 decryption.
Code from a newer version of Valak that uses a more complex decryption function.
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.
Raw data downloaded from the C2.
Decoded content of the “PLUGIN” task.
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>
Creation of the URI in Valak’s source code.
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.
VirusTotal graph showing the connection between the different Valak domains.
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.
Traffic - Ursnif downloading IcedID and Valak.
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:
Russian and Arabic keyboard traces found in a Valak phishing document.
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.
VirusTotal screenshot with the file names used in the recent campaigns.
Content of the document targeting Germany.
Content of the document targeting the US.
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 |
The Cybereason Nocturnus Team has brought the world’s brightest minds from the military, government intelligence, and enterprise security to uncover emerging threats across the globe. They specialize in analyzing new attack methodologies, reverse-engineering malware, and exposing unknown system vulnerabilities. The Cybereason Nocturnus Team was the first to release a vaccination for the 2017 NotPetya and Bad Rabbit cyberattacks.
All Posts by Cybereason Nocturnus
The ITG23 group is partnering with the TA551 (Shatak) threat group to distribute ITG23’s TrickBot and BazarBackdoor malware which attackers use to deploy Conti ransomware on compromised systems...
In this Threat Analysis report, Cybereason Security Services investigate the rising activity of the malware GootLoader. GootLoader is a malware loader known to abuse JavaScript to download post-exploitation malware/tools and persist within the infected machine.
