Nick Biasini and Edmund Brumaghin authored this blog post with contributions from Matthew Molyett.
Over the past several months, Cisco Talos has been monitoring various malware distribution campaigns leveraging the malware loader Brushaloader to deliver malware payloads to systems. Brushaloader is currently characterized by the use of various scripting elements, such as PowerShell, to minimize the number of artifacts left on infected systems. Brushaloader also leverages a combination of VBScript and PowerShell to create a Remote Access Trojan (RAT) that allows persistent command execution on infected systems.
Brushaloader is an evolving threat that is being actively developed and refined over time as attackers identify areas of improvement and add additional functionality. We have identified multiple iterations of this threat since mid-2018. Most of the malware distribution activity that we observe associated with Brushaloader leverages malicious email campaigns targeting specific geographic regions to distribute various malware payloads, primarily Danabot. Danabot has already been described in detail here and here, so this post will focus on the analysis of Brushaloader itself. Talos has recently identified a marked increase in the quantity of malware distribution activity associated with Brushaloader, as well as the implementation of various techniques and evasive functionality that has resulted in significantly lower detection rates, as well as sandbox evasion.
The advanced command-line auditing and reporting available within ThreatGrid make analyzing threats such as Brushaloader much more efficient. Threats such as Brushaloader demonstrate the importance of ensuring that PowerShell logging is enabled and configured on endpoints in most corporate environments.
History of Brushaloader
The first Brushaloader campaign that caught our attention was back in August 2018. It was initially notable because it was only using Polish language emails targeting Polish victims. Although it is common to see threats target users in multiple languages, attackers typically don't target a single European country. Below is a sample of one of the emails from that initial campaign and shows the characteristics that we would come to expect from Brushaloader: a RAR attachment containing a Visual Basic script that results in a Brushaloader infection ending in the eventual download and execution of Danabot.
As far as the attachment itself, it typically consists of a RAR file with a filename that contains the word "faktura." The RAR files typically contain a VBScript that reaches out for additional payloads. The script itself already had some interesting techniques associated with sandbox or network simulation evasion, which we will discuss later in the blog. This script wasn't heavily obfuscated, and efficiently established command and control (C2) communication with a hard-coded IP address via HTTP using wscript. The specific URL being queried in this particular campaign was:
& & & http://162[.]251[.]166[.]72/about.php?faxid=446708802&opt=.
Over time, a pattern started to emerge: The campaigns would run for a week or two and then go quiet for a couple of weeks before restarting. The modus operandi for the actor was largely the same throughout, Polish language spam campaigns related to invoices or "Faktura" that contained a RAR file with malicious VBScript inside. One thing of note about these campaigns is in the downtime changes and improvements were being made to the way the VBScript tries to evade detection and analysis or how the C2 communication was established. Let's walk through some examples.
Network simulation evasion, multi-path C2 implemented
The second major campaign we analyzed had already added some functionality. Initially, the threat was trying to connect to a non-existent domain to check for things like network simulation. This second campaign implemented an "infinite" recursive loop that continues to repeat itself if that GET request resulted in an HTTP/200 indicating a successful request. Here is a quick screenshot showing that new functionality.
A campaign that launched just a few days later had already gone through some additional revisions. Early versions of the script only communicated via hard-coded IP address. This campaign implemented a random choice between a domain and a hard-coded IP. Below is an example of this type of evolution.
Legitimate URLs added to obfuscate
Over the next couple of campaigns throughout the rest of September and early October, there were subtle changes around the non-existent domains being used, and the ways they tried to obfuscate the C2 communication, but no significant changes. In early October, the actors added a third legitimate domain to the round robin, which can be seen below:
Streamlined version emerges
There were more significant changes taking place during October 2018, including the removal of the non-existent domain check and instead implementing what appears to be a registry check in wscript to try and read a value from the registry. It appears to be using this for some permissions check, but all users of all privilege levels would be able to query the key HKEY_CURRENT_USER. Below is a screen capture of this check as it was implemented.
New campaign, new languages targeted
It was also around this time that Cisco Talos started to observe the spam campaign beginning to target languages besides Polish. The first campaign involving multiple languages included launched around this same time, an example of the German campaign is shown below.
After a couple more weeks, around mid-November, the actors began to re-implement some of the non-existent domain checking an example of which is shown below.
End of November overhaul
The campaign at the end of November brought a full re-work of the VBScript implementing several improvements. The first change is that the VBScript begins by creating a file system object, which allows the actors to start reading and writing files to disk.
The actors then referenced what is effectively a sleep function and then called the function HttpsSend. This is where some of the significant changes occurred in the C2 communication. Below is that HttpsSend function.
A new spam campaign kicked off in late January delivering malicious RAR files containing a Visual Basic script (.vbs). At the time the majority of the spam messages were in Polish and appeared to be targeting Polish users. All of the filenames and subjects were centered on invoices, commonly using "Faktura" or some similar term. This campaign began with primarily Polish-based emails, as is typical for this loader, an example of which is shown below.
As far as the attachments are concerned, there have been a couple of additional improvements from the previous version in late November, but the overall functionality is primarily the same.
One of the most significant changes in this campaign was the move toward PowerShell and away from wscript that was previously used to execute commands, gather system information, and provide additional payloads. Additionally, this campaign was on a scale we previously hadn't seen from Brushaloader and could be an indicator the loader may be ready for more widespread distribution, with the potential to have reach outside of just Europe. The full detail of the new functionality will be covered in a later section of the blog, providing a deeper dive into the HTTPS C2 communications that occurred.
This campaign ended the first week of February and the activity has been mostly dark since then. Over the last half year, Brushaloader has gone from a new VBScript-based loader with some basic evasion techniques to an increasingly advanced and increasingly distributed threat. The timeline below illustrates how aggressive the development of Brushaloader has been. If the past is any indication, Brushaloader will be an interesting threat to follow going forward.
In many corporate networks, files that are introduced into the environment are automatically submitted to automated analysis platforms, such as sandboxes, that will execute the file and observe system activity to determine if the file is malicious or benign before allowing the file to be transmitted to the system for which it was initially destined. Threat actors are aware of these security controls and often employ creative mechanisms for bypassing them. In most cases, these mechanisms are designed to minimize the amount of malicious file activity so that automated analysis platforms do not detect the file as malicious and allow it to be transmitted further into the network environment.
Some techniques include the use of sleep() timers that will cause the malware to wait for a predefined period before resuming malicious execution. In other cases, malware distributors might leverage password-protected email attachments that require the user to input information prior to opening the attachment. These techniques are often successful, as many automated detection and analysis platforms are not designed to interact with sample submissions in these ways and as a result are not able to properly initiate the infection process. Brushaloader is no different, and we have recently observed multiple techniques being leveraged to maximize the success rate of Brushaloader infections.
One of the changes we have observed over the past couple of months of Brushaloader campaigns is the use of malware downloaders that require user interaction before the execution of malicious behavior on infected systems. Attackers will often make use of infection processes that require user interaction as a way to bypass automated analysis platforms such as sandboxes.
In the case of Brushaloader, the malicious emails contain RAR archives. The RAR archives typically contain a VBScript (VBS) that is responsible for making an HTTP request to an attacker-controlled distribution server to download a malicious PE32 executable. The VBScript calls a dialog box that prints various characters of the Fibonacci sequence:
The downloader scripts leveraged in various Brushaloader campaigns have also made use of invalid domains as a way to determine whether or not the downloader is executed in an analysis environment where network simulation is occurring. In many malware analysis environments, network simulation is used to allow analysts to interact with malware samples even when resources that the malware requests are not available. This is especially helpful when C2 infrastructure is no longer available, or when analysis is occurring in an environment that lacks internet connectivity. There are several utilities available that provide this functionality — two of the most commonly used are inetsim and FakeNet-NG.
In the case of Brushaloader, they even went so far as to use non-existent TLDs like www[.]weryoseruisasds[.]oedsdenlinsedrwersa or just hostnames instead of legitimate domains like someserver. Obviously, neither of these domains should resolve and it makes for a simple test to determine if this network simulation is in use. In some ways, this technique could also be used to aid in the detection of potentially compromised hosts and provides another reason why logging DNS resolutions can be an invaluable tool for analysts and security teams.
Once the initial infection process starts, the previously described multi-stage VBS execution begins. The infected system makes an HTTP POST request to the C2 infrastructure. The scripting engine then executes the response to the HTTP POST request. This loop is delayed by the server sending WScript.Sleep commands.
The first stage VBS is responsible for the execution of the following encoded PowerShell command:
- Windows operating system version
- Currently logged in Username
- Installed Antivirus Products
- System Make/Manufacturer
- Powershell version
- IP address information
- Available memory
- Current Working Directory
- System Installation Date/Time
- Display Adapter Information
The Powershell process running on the infected system also achieves persistence by creating a Windows shortcut (LNK) which is added to the Startup directory on the system:
Campaign distribution over time
Cisco Talos has been monitoring malware distribution campaigns associated with Brushaloader since mid-2018. Historically, these campaigns have been relatively low volume compared to other commodity malware distribution campaign activity, such as Emotet. In most of the cases we analyzed, the majority of the distribution activity occurred towards the end of each month. This recently changed — we have observed a significant increase in the volume and duration of the malspam campaigns.
Below is a graph showing current distribution activity when compared to the volume seen in campaigns observed throughout most of 2018.
The threat landscape is ever changing — this is true for both the malware and the mechanisms to deliver the malware, like Brushaloader. This blog outlines yet another key example of how these loaders are changing and evolving constantly. The things that make Brushaloader stand out are how quickly threat actors evolved the loader, indicating it is actively in development. Additionally, it's interesting to note that after the long break over December and most of January, the loader has exploded onto the scene. Going from small-scale campaigns targeting exclusively Polish users to branching out in both scale and countries being targeted. It's not common to see regional specific usage of loaders, which Brushaloader does.
This is also a key example of the levels of obfuscation and sophistication these loaders can posses. This simple VBS based campaign implemented several clever evasion and obfuscation techniques in a minimal amount of code, showing that adversaries will continue to think outside the box and develop novel ways to deliver threats to users. This is why users need organizations with visibility around the world, since it's just a matter of time until this successful loader starts being sought out by other attackers looking to deliver threats. We will continue to monitor this threat and the payloads it provides and will continue to be vigilant in protecting our customers from any evolutions that will inevitably occur.
CoverageAdditional ways our customers can detect and block this threat are listed below.
AMP) is ideally suited to prevent the execution of the malware used by these threat actors.
Cisco Cloud Web Security (CWS) or Web Security Appliance (WSA) web scanning prevents access to malicious websites and detects malware used in these attacks.
Email Security& can block malicious emails sent by threat actors as part of their campaign.
Network Security appliances such as Next-Generation Firewall (NGFW), Next-Generation Intrusion Prevention System (NGIPS), and Meraki MX& can detect malicious activity associated with this threat.
AMP Threat Grid& helps identify malicious binaries and build protection into all Cisco Security products.
Umbrella, our secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs, and URLs, whether users are on or off the corporate network.
Open Source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on& Snort.org.
Indicators of Compromise
The following Indicators of Compromise (IOCs) have been observed as being associated with various campaigns leveraging Brushaloader to install malware on systems.
(Thank you to Kafeine for sharing additional sample data.)
The following IOCs are associated with the malicious attachments observed as part of malicious spam campaigns.
A list of hashes associated with the malicious RAR archives can be found here.
A list of hashes associated with malicious VBS files can be found here.
Fake Domains (Sandbox Evasion)