From Email to RAT: Deciphering a VBS Script-Driven Campaign

Authored by Preksha Saxena and Yashvi Shah

McAfee Labs has been tracking a sophisticated VBS campaign characterized by obfuscated Visual Basic Scripting (VBS). Initially delivering the AgentTesla malware, the campaign has evolved into a multi-faceted threat, employing VBS scripts as a versatile delivery mechanism. Notably, this campaign extends beyond AgentTesla, now distributing a range of malware such as Guloader, Remcos RAT, Xworm, and Lokibot.

This campaign illustrates a comprehensive infection process initiated by a VBS file delivered via email. Starting with the activation of a VBS script, it progresses through PowerShell phases, utilizing the BitsTransfer utility for fetching a second-stage PowerShell script. The decoded and executed Shellcode A conceals and loads Shellcode B. In the final phase, wab.exe downloads the encrypted Remcos RAT payload. Shellcode B decrypts and injects it into wab.exe, making it function as the Remcos RAT.

The observed campaign has been noted for targeting diverse regions worldwide. Presented below is a geographical heatmap depicting McAfee customers who have been targeted and saved over the past three months.

Figure 1: Geo Heatmap showing targeted regions.

In the featured blog post, malicious actors utilized GuLoader to deploy the Remcos RAT.

Execution Chain

Figure 2: Infection chain

The execution begins by running a VBS script. then it triggers the execution of the first-stage PowerShell. Subsequently, the BitsTransfer utility is employed to fetch a second-stage PowerShell which is base64 encoded.

The second stage PowerShell is then encoded and executed. Following this, the First Shellcode is meticulously carved out and loaded reflectively. The second Shellcode encoded within Shellcode A, undergoes decoding and is also reflectively loaded.

The final step involves a second Shellcode which is leveraged to retrieve and inject the Remcos RAT (Remote Control and Surveillance Tool) into a legitimate Windows process. In this case, wab.exe. This intricate series of actions allows for the stealthy deployment and operation of the Remcos RAT within the Windows environment.

Figure 3: Process Tree

Obfuscated VBScript Technical Overview:

Stage 1: (Deobfuscating vbs)

Attached to the email is a ZIP file seemingly labeled as “revised_quotation_for_purchase_invoice_order_design_6th_november_2023“, resembling an invoice to the user. The intent, much like similar deceptive emails, is for the recipient not to scrutinize the email closely.

Inside the zip file attachment is a heavily obfuscated VBS file. The VBS script employed several techniques to make the analysis quite difficult. It has many garbage variables, decoy functions, and unnecessary comments, and all the malicious functions are obfuscated.

Figure 4: Heavily obfuscated script

The code appears streamlined after removing redundant lines, resulting in a more concise and efficient version. After removing all the comments, the script turned out to be as follows:

Figure 5: Post-removing the junk code

In the script, there’s a frequent appending of new strings to the variable “Fu6”. This method serves to increase the complexity of the analysis. Once all the strings are concatenated and formatted, the result emerges in a more intriguing manner. As shown in the below image.

Figure 6: After deobfuscating the code

The function “Mikr9” will handle the conversion of strings, rendering them readable. We converted all the lines to a readable format, with the help of the “Fu6” function. For example, as shown in Figure 5, the string

‘DelfhAdvetFagstStatpYapp:Nona/fisk/Indh1 Sic0 Tra3parc. Mon1Gens7Vide6Eufo.Tast1Outs1Midd1afte.Dors1husg6 Hal3Beja/ Hypm RenuColonSprgdNasahToasuRafflchon.GyttpBrnefMuckbAcci ‘ became http://103.176.111[.]163/mundhul.pfb.

Likewise, the entire script is decoded, and we get the following script:

Figure 7: After applying decrypting function Mikr9()

The script conducts the following sequence of activities:

• Retrieves the second-level file from “hxxp://103.176.111[.]163/mundhul.pfb” using BitsTransfer.
• Save the acquired file in the Appdata folder.
• Decodes the file from Base64, converting it into a string format.
• Navigates to offset 229981 and extracts the subsequent 28050 units of data.
• Executes the extracted data using IEX (Invoke-Expression).

Stage 2:

Powershell execution

The file retrieved shows zero detection on VT, appears to be base64 encoded, and has a size of 336KB.

Figure 8: Second Powershell script

Figure 9: Content is base64 encoded

Upon decoding “mundhul.pfb,” a detailed analysis can be conducted to comprehend its functionality, enabling further examination of the malware’s execution. Once the file gets decoded, it reveals a code resembling the image provided below.

Figure 10: Base64 decoded data

As specified in the script, execute a jump to offset 229981 and retrieve the ensuing 28050 units of data. This marks the start of the second PowerShell script, which is 28050 bytes, marked as follows.

Figure 11: Start of encrypted second PowerShell

The code contains various comments, so we followed the same procedure, as we did for the first script, removed all the junk code and we got a function that seems to handle the decryption of all the strings.

</centerFigure 12: After removing the junk

The decryption process iterates multiple times to unveil the strings, and the malware employs the “Invoke” method to execute its commands. After decoding all the strings using “Bedroges02” function, we finally got the intent of the script.

Figure 13: After applying decryption logic

The PowerShell script initially loads the VirtualAlloc() function and stores the memory handle in variables named “trll3” and “Akuammin195”. These sections possess permissions for writing, reading, and executing. The latter segment of the script appears to invoke a concealed shellcode embedded within it.

The execution sequence involves copying the bytes as follows: The initial 644 bytes from the beginning of this PowerShell script constitute the first shellcode. Subsequently, starting from byte 644, the script copies the next 229337 bytes, constituting the second shellcode.

Figure 14: Constituting shellcode

Following the execution sequence, malware initiates the API call CallWindowProcA, leading subsequently to the invocation of the native function NtProtectVirtualMemory. Then the process transitions directly to initiating the first shellcode.

Stage 3: Shellcode-A execution

The shellcode-A’s primary action involves copying the shellcode B into memory, as depicted in the figure below.

Figure 15: Loop used for copying shellcode B

The shellcode B undergoes decryption via XOR operation. This operation serves to transform the code into its executable form, allowing the decrypted shellcode to execute its intended instructions within the system’s memory.

Figure 16: Decryption loop used for decrypting shellcode B

Stage 4: Shellcode-B

The shellcode is designed to establish a new process named “wab.exe” and it replicates 0x3FC4000 bytes of decrypted shellcode into its memory space. As indicated by the highlighted blue box, the content decrypted from the second shellcode (shown in Figure 15) is subsequently injected into the wab.exe process (depicted in Figure 16).

Figure 17: Injection of second shellcode

The objective of the shellcode is to fetch the Remcos RAT from the specified URL, “hxxp://103.176.111.163/lnHxQotdQb132.bin” and subsequently inject it into the “wab.exe” process. Once “wab.exe” is injected by the final payload, it undertakes all malicious activities.

Figure 18: wab.exe connecting to C2

The file obtained from the provided URL seems to be an encrypted binary. Upon decryption, it has been recognized to initiate communication with the IP address 94.156.65.197 through port 2404. An observation revealed the creation of a mutex named “Rmc-R7V4VM.” Data keylogged during its operation is stored in a file labeled “logs.dat.” Additionally, screenshots captured are saved in a directory named “Screenshots,” while the overall repository for the collected data is titled “Remcos.”

Conclusion:

This campaign outlines the comprehensive infection process initiated by a VBS file received through email. The process begins with the activation of a VBS script, initiating the initial PowerShell phase. Subsequently, the BitsTransfer utility is used to fetch a second-stage PowerShell script, encoded in base64. After decoding and execution, the first Shellcode is carefully extracted and loaded reflectively. Simultaneously, Shellcode A conceals and loads the decoded Shellcode B.

In the final phase, the injected wab.exe proceeds to download the encrypted final payload of the Remcos RAT. Shellcode B is responsible for decrypting the payload, and it is subsequently injected into wab.exe. Consequently, this particular instance of wab.exe functions as the Remcos RAT.

VBScript in the Windows Environment: A Security Perspective

VBScript, introduced by Microsoft in 1996, was crucial in the Windows environment as a scripting language for task automation, tightly integrated with Internet Explorer, and a key component of technologies like Windows Script Host, Active Server Pages, and Office automation. It provided a simple scripting solution for system tasks, web development, and server-side logic. Microsoft is deprecating VBScript, and it will be available as a feature on-demand before eventual removal from Windows, said the company. This decision aligns with a broader strategy to reduce malware campaigns exploiting Windows and Office features. VBScript, disabled by default in Internet Explorer 11 since 2019, has been used by malicious actors for distributing malware, and Microsoft aims to enhance security by eliminating this infection vector. Attackers exploit vulnerabilities in phased-out technologies due to lingering use in legacy systems, slow adoption of updates, custom applications, stringent industry requirements, and user resistance to change. To mitigate risks, proactive measures such as prompt updates, security education, and staying informed about software lifecycles are crucial.

Mitigation:

Avoiding falling victim to email phishing involves adopting a vigilant and cautious approach. Here are some common practices to help prevent falling prey to email phishing:

• Verify Sender Information
• Think Before Clicking
• Check for Spelling and Grammar
• Be Cautious with Email Content
• Verify Unusual Requests
• Implement Email Filters
• Check for Secure Connections
• Report Suspicious Emails
• Keep the software up-to-date
• Align with security patches

IOCs

The post From Email to RAT: Deciphering a VBS Script-Driven Campaign appeared first on McAfee Blog.