eSentire is The Authority in Managed Detection and Response Services, protecting the critical data and applications of 2000+ organizations in 80+ countries from known and unknown cyber threats. Founded in 2001, the company’s mission is to hunt, investigate and stop cyber threats before they become business disrupting events.
We provide sophisticated cybersecurity solutions for Managed Security Service Providers (MSSPs), Managed Service Providers (MSPs), and Value-Added Resellers (VARs). Find out why you should partner with eSentire, the Authority in Managed Detection and Response, today.
Adversaries don’t work 9-5 and neither do we. At eSentire, our 24/7 SOCs are staffed with Elite Threat Hunters and Cyber Analysts who hunt, investigate, contain and respond to threats within minutes.
We have discovered some of the most dangerous threats and nation state attacks in our space – including the Kaseya MSP breach and the more_eggs malware.
Our Security Operations Centers are supported with Threat Intelligence, Tactical Threat Response and Advanced Threat Analytics driven by our Threat Response Unit – the TRU team.
In TRU Positives, eSentire’s Threat Response Unit (TRU) provides a summary of a recent threat investigation. We outline how we responded to the confirmed threat and what recommendations we have going forward.
Here’s the latest from our TRU Team…
What did we find?
At the beginning of September 2023, our 24/7 SOC received an alert on the suspicious execution of the VBS file.
Upon completing a thorough investigation, the eSentire Threat Response Unit (TRU) identified the VBS file in question as malicious. This file contains code to retrieve AsyncRAT.
AsyncRAT is a Remote Access Tool (RAT) written to enable encrypted remote monitoring and control of remote systems and is commonly used for malicious purposes by threat actor(s) to gain access to systems.
The user received a phishing email containing an .htm file. This is a well-known technique previously employed by malware strains like Qakbot
and AsyncRAT, known as HTML smuggling (T1027.006).
HTML smuggling is a technique used by attackers to hide and deliver malicious code to a victim's browser through seemingly benign HTML and JavaScript. The attack involves tricking a web application into loading and executing malicious JavaScript code.
The .htm file contains the JavaScript code shown below.
Figure 1: The content of .htm file
The variable “LBZQ” in the cleaned code contains a base64-encoded ZIP archive with a VBS file inside.
Figure 2: Cleaned up JavaScript code (.htm)
In summary, the script above performs the following actions:
Decodes a base64 string to get the zip file content.
Splits the decoded string into chunks of size 1024 or less, converts each chunk to an array of character codes, and places them into a Uint8Array.
Combines all Uint8Array objects into a blob with a specific MIME type (application/octet-stream).
Constructs a string with the "zip" extension and stores it in the variable GONV.
Programmatically clicks on the anchor element, which initiates the download of the zip file that is named “Rep_3414316295577.zip”.
Rep_3414316295577.zip
We will investigate the content of the VBS file, as shown below.
Figure 3: Contents of the VBS file
The VBS file contains simple string replacements and splits used as obfuscation. Below is the deobfuscated script:
Figure 4: Deobfuscated VBS script
The script does the following:
Creates a WebClient object and calls the “DownloadString” method on it to download a file from the URL “hxxps://buypropertyinuae[.]com/.QnWrd9ratf6jwsVf.txt”.
Executes the downloaded content.
The second argument in the .Run method (0) indicates that the window should be hidden.
.QnWrd9ratf6jwsVf.txt
The downloaded text file is a PowerShell script (a cleaned-up version can be seen in Figure 5) The PowerShell script performs the following actions:
The script creates a directory under the "C:\ProgramData\Document" path.
Creates a VBS file (IEEAstra22.vbs) in the newly created directory mentioned above, with the content that runs a PowerShell script (REExPLORE100.ps1) located in the same directory, but with the execution policy bypassed, which means it can run without restrictions.
Creates a scheduled task named "IExMWhats22"
that executes the VBS file and then repeats every 2 minutes.
Checks for the existence of files related to McAfee and Norton Security software installations.
Depending on the security software detected, it retrieves different files (.M1.jpg (if it detects McAfee), .N1.jpg (if it detects Norton), or .O1.jpg) from the C2 server and saves it as REExPLORE100.ps1 in the created directory. These files have a .jpg extension but are being saved with a PowerShell (.ps1) extension.
It then executes the VBS file created earlier, which executes the downloaded PowerShell script.
Finally, it executes the function FLstudio to perform all the actions described above.
Figure 5: Cleaned- up PowerShell script.
.M1.jpg
If the previous PowerShell script finds the presence of C:\Program Files\Common Files\McAfee\Platform\McUICnt.exe
binary on the infected host, it assumes that the host has McAfee AV installed and proceeds with executing the .M1.jpg or REExPLORE100.ps1 script.
The script contains two embedded binaries. The first binary contains an AsyncRAT payload:
Figure 7: Output from AsyncRAT configuration extractor (.M1.jpg)
The binary does not have anti-VM / persistence features enabled.
In the cleaned-up PowerShell code block shown in Figure 8 (.M1.jpg), we can see the following:
The code defines a string $tdgx that points to C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegSvcs.exe
It then attempts to get a type from the previously loaded assembly ($fvda) named "NewPE.PE" (the second embedded .NET DLL payload) and invokes the 'Execute' method with $tdgx and $iyqz as parameters. $iyqz parameter holds the AsyncRAT payload.
Figure 8: Cleaned up snippet of .M1.jpg
Let’s break down the “Execute’
method:
The code within the "Execute"
method tries to create a new process in a suspended state (0x8000004 – CREATE_NO_WINDOW and CREATE_SUSPENDED) using the CreateProcessA API function, with the path parameter specifying the target process to hollow out. Depending on whether the process is 32 or 64-bit, it retrieves the context of the main thread of the newly created process using either the GetThreadContext or Wow64GetThreadContext functions.
It then checks if the base address of the new process's main module matches the preferred base address of the payload. If they match, it unmaps the target process's memory using ZwUnmapViewOfSection.
It allocates new memory in the target process using VirtualAllocEx
It writes the payload into the newly allocated memory using WriteProcessMemory. It reads information from the payload's PE header to properly write sections (VirtualAddress, SizeOfRawData, PointerToRawData) to the allocated memory, as shown in the image below.
Figure 9: Reading information from the payload's PE header
It modifies the entry point in the target process's context to point to the entry point of the payload. On line 113, it’s getting the entry point from the payload) and then setting it to the context array (line 119). num6 is the base address where the payload was written, and num12 is the relative offset to the entry point from the base of the payload.
The code then updates the thread context with the modified entry point using either SetThreadContext or Wow64SetThreadContext, depending on if the process is 32-bit or 64-bit.
Finally, it resumes the main thread of the target process using ResumeThread, which will begin execution of the payload at the new entry point, effectively injecting the payload into the new process (RegSvcs.exe) via process hollowing (T1055.012).
Figure 10: Setting entry point and resuming the thread
It’s worth mentioning that DLL injector uses dynamic API loading via LoadApi method and string obfuscation for API functions responsible for process hollowing. The strings representing the library names and APIs are reversed in the ReturnParams method then are separated by the “[||]” string.
Figure 11: Dynamic API loading and string obfuscation
.N1.jpg
If the previous PowerShell script finds the presence of “C:\Program Files\Norton Security\isolate.ini” file on the infected host, it assumes that the host has Norton installed and proceeds with executing the .N1.jpg (REExPLORE100.ps1).
The .N1.jpg file contains two binaries in the form of a byte array instead of base64-encoded blobs as the previous one.
From the PowerShell script, we can learn the following:
$H1 is a variable that contains the projFUD .NET DLL injector.
Once the assembly is loaded, it tries to get a type named “projFUD.alosh_rat” within the injector.
It then gets a method named “Execute” from that type.
After getting the “Execute” method, it invokes that method with two arguments: a string representing the path to the aspnet_compiler.exe process and the $new byte array, which is AsyncRAT payload.
ProjFUD (alosh_rat) injector was mentioned in various articles delivering RATs such as AgentTesla and AveMaria. The injector is similar to the previously mentioned DLL injector that uses process hollowing to inject the payload into aspnet_compiler.exe. The injector is obfuscated with Confuser.Core 1.5.0.
We will proceed and extract the configuration from the second AsyncRAT payload:
Figure 14: AsyncRAT configuration from .N1.jpg payload
If none of the conditions matches – McAfee and Norton are not present on the infected host, the initial VBS script proceeds to retrieve and run .O1.jpg file, which is the same as the .M1.jpg file.
What did we do?
We investigated and confirmed the activity is malicious.
Our team of 24/7 SOC Cyber Analysts isolated affected hosts to contain this incident in accordance with the customer’s policies.
What can you learn from this TRU positive?
AsyncRAT was delivered via a phishing email using HTML Smuggling technique.
Threat actor(s) use obfuscated injectors to bypass security solutions and complicate analysis.
AsyncRAT uses process hollowing to inject the malicious payload into RegSvcs.exe and aspnet_compiler.exe processes; the latter is achieved via the ProjFUD injector.
Recommendations from our Threat Response Unit (TRU) Team:
The eSentire Threat Response Unit (TRU) is an industry-leading threat research team committed to helping your organization become more resilient. TRU is an elite team of threat hunters and researchers that supports our 24/7 Security Operations Centers (SOCs), builds threat detection models across the eSentire XDR Cloud Platform, and works as an extension of your security team to continuously improve our Managed Detection and Response service. By providing complete visibility across your attack surface and performing global threat sweeps and proactive hypothesis-driven threat hunts augmented by original threat research, we are laser-focused on defending your organization against known and unknown threats.
Cookies allow us to deliver the best possible experience for you on our website - by continuing to use our website or by closing this box, you are consenting to our use of cookies. Visit our Privacy Policy to learn more.
