- Ongoing malware distribution campaigns are using ISO disk images to deliver AsyncRAT, LimeRAT and other commodity malware to victims.
- The infections leverage process injection to evade detection by endpoint security software.
- These campaigns appear to be linked to a new version of the 3LOSH crypter, previously covered here.
Malware distributors often leverage tools to obfuscate their binary payloads and make detection and analysis more difficult. These tools often combine functionality normally associated with packers and crypters and, in many cases, are not directly tied to the malware payload itself. Over the past several months we have observed a series of campaigns that leverage a new version of one of these tools, referred to as 3LOSH crypter. The threat actor(s) behind these campaigns have been using 3LOSH to generate the obfuscated code responsible for the initial infection process. Based on analysis of the embedded configuration stored within the samples associated with these campaigns, we have identified that the same operator is likely distributing a variety of commodity RATs, such as AsyncRAT and LimeRAT. These RATs feature various functionality that enables them to be used to gain access to systems and exfiltrate sensitive information from victims.
The infection process begins with an ISO that contains a malicious VBScript that, when executed, initiates a multi-stage infection process. The file naming convention for the ISO and the VBS match and typically follow a convention consistent with the following:
Stage 1 Execution
The VBS contains junk data and uses string replacement to attempt to obfuscate the executed code. An example of this is shown below.
Once deobfuscated, the VBS execution is straightforward: It retrieves and executes the next stage from an attacker-controlled server.
Stage 2 retrieval
As expected, the retrieved content is a PowerShell script passed to the Invoke-Expression (IEX) cmdlet and executed to continue the infection process. It is mainly responsible for creating a series of scripts that are executed and carry out various tasks needed for the malware to function.
Across various samples analyzed, the directory locations and file names vary, but are functionally equivalent.
First, the script checks for the existence of a directory at the following location:
If it doesn't already exist, the directory is created. This folder is used as the working directory for the malware and stores all the components used throughout the rest of the infection process.
The script then creates several additional scripts, writing content into each of them using a format similar to the following example.
Script creation code example.
The following files are created in this manner:
All of these scripts are stored in the previously created directory.
Malicious script components.
Finally, the Stage 2 PowerShell executes "Office.vbs" to begin the next step of the infection process.
Stage 3 operations
Stage 3 is responsible for the majority of malicious activities performed on infected systems. The first script, "Office.vbs," is executed by the Stage 2 PowerShell and invokes WScript to execute a batch file called "Office.bat" to continue the infection process.
WScript batch file execution.
This batch file, in turn, executes a PowerShell script called 'Office.ps1'.
PowerShell script execution.
The next PowerShell script attempts to achieve persistence by creating a new Scheduled Task called "Office" that is executed immediately and then repeated every two minutes, as shown below.
Scheduled task creation.
This scheduled task then executes "Microsofd.vbs" as part of the creation process. This next VBS initiates a short sleep before continuing. It is only responsible for executing "Microsofd.bat" to continue the infection process.
This next batch file only contains a single line, which invokes PowerShell and executes 'Microsofd.ps1'
This PowerShell script is the final script executed in this chain. It was written by the Stage 2 PowerShell, along with the other scripts that we've described. This script contains two large GZIP blobs and another function responsible for decompressing them.
Stage 3 decompression function.
One of the blobs is an injector and the other is the final payload that is injected and executed. This is accomplished by invoking aspnet_compiler.exe, injecting the final payload, and executing it.
Stage 3 injection process.
The diagram below shows the execution flow.
Infection flow diagram.
The final payload varied across samples analyzed, the majority of which were AsyncRAT and LimeRAT. Based on the RAT configuration embedded in the samples, we believe with high confidence that the same threat actor(s) are likely leveraging both RATs in these campaigns.
Links to 3LOSH crypter
During our analysis of the samples, infrastructure and final payloads associated with these campaigns, we identified several characteristics that indicated a new version of the 3LOSH builder/crypter used to obfuscate the RAT payloads and facilitate the infection process. 3LOSH crypter is a malware crypter we previously analyzed here.
In analyzing the code execution of the Stage 2 PowerShell, we noticed some similarities with later stages of the infection process described in our previous analysis of the 3LOSH builder. The code present in our initial sample set featured a significant amount of similarities and overlap with samples we identified associated with a new version of 3LOSH. This new version of the crypter features the following notable changes from previous versions.
- Binary payloads are now embedded using GZIP compression rather than simply Base64 encoded and scripts feature a decompression function that is the same across both sample clusters.
- The infection chain is more complicated, featuring the use of multiple script-based components (BAT, VBS, PS1) that facilitate the infection process.
While there are also differences between the two clusters, this may be due to the threat actor only utilizing the portion of the builder output required for their purposes, or this may be due to options selected during the build process.
Additionally, while analyzing our original sample cluster and new samples created using the 3LOSH crypter, we identified several final payloads in both clusters that use the same infrastructure for post-compromise C2 communications.
Matching RAT configs in both sample clusters.
While analyzing one of the AsyncRAT payloads in our original sample cluster, we also observed that the Group_ID in the embedded RAT configuration was set to "3LOSH."
3LOSH group identifier
3LOSH continues to be under active development and in use by threat actors distributing a variety of commodity RATs. We expect that this activity will continue and organizations should ensure they maintain the ability to detect malicious activity associated with 3LOSH, independent of the final payload itself.
These malware distribution campaigns have been ongoing for the past several months, with new samples being uploaded to public repositories on a daily basis. The 3LOSH crypter continues to be actively maintained and improved by its author and will likely continue to be used by various threat actors attempting to evade detection in corporate environments. Organizations should be aware that even commodity malware can take advantage of the complexity and evasiveness offered by crypters to increase their operational effectiveness as adversaries attempt to leverage them to achieve their mission objectives. A layered defense-in-depth security architecture should be implemented to ensure that organizations maintain the ability to successfully defend against these threats.
Ways our customers can detect and block this threat are listed below.
Cisco Secure Web Appliance web scanning prevents access to malicious websites and detects malware used in these attacks.
Cisco Secure Firewall (formerly Next-Generation Firewall and Firepower NGFW) appliances such as Threat Defense Virtual, Adaptive Security Appliance and Meraki MX can detect malicious activity associated with this threat.
Cisco Secure Malware Analytics (Threat Grid) identifies malicious binaries and builds protection into all Cisco Secure products.
Umbrella, Cisco's secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs and URLs, whether users are on or off the corporate network. Sign up for a free trial of Umbrella here.
Cisco Secure Web Appliance (formerly Web Security Appliance) automatically blocks potentially dangerous sites and tests suspicious sites before users access them.
Additional protections with context to your specific environment and threat data are available from the Firewall Management Center.
Cisco Duo provides multi-factor authentication for users to ensure only those authorized are accessing your 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. Snort SIDs: 58087, 58773.
Cisco Secure Endpoint users can use Orbital Advanced Search to run complex OSqueries to see if their endpoints are infected with this specific threat. For specific OSqueries on this threat, click here and here.
Indicators of Compromise
The following indicators of compromise have been observed to be associated with these malware campaigns.
Stage 1 ISOs
The following ISOs have been observed to be associated with these malware campaigns.
Stage 1 VBS
The following VBS have been observed to be associated with these malware campaigns.
Stage 2 Retrieval
The following URLs have been observed hosting malicious content retrieved during the infection process.
Stage 2 PowerShell
The following PowerShell scripts have been observed to be associated with these malware campaigns.
Stage 3 Binaries
The following executables have been observed to be associated with these malware campaigns.
The following domains have been observed to be associated with these malware campaigns.