Agent Tesla’s Unique Approach: VBS and Steganography for Delivery and Intrusion | McAfee Blog

Authored by Yashvi Shah

Agent Tesla functions as a Remote Access Trojan (RAT) and an information stealer built on the .NET framework. It is capable of recording keystrokes, extracting clipboard content, and searching the disk for valuable data. The acquired information can be transmitted to its command-and-control server via various channels, including HTTP(S), SMTP, FTP, or even through a Telegram channel.

Generally, Agent Tesla uses deceptive emails to infect victims, disguising as business inquiries or shipment updates. Opening attachments triggers malware installation, concealed through obfuscation. The malware then communicates with a command server to extract compromised data.

The following heat map shows the current prevalence of Agent Tesla on field:

Figure 1: Agent Tesla heat map

McAfee Labs has detected a variation where Agent Tesla was delivered through VBScript (VBS) files, showcasing a departure from its usual methods of distribution. VBS files are script files used in Windows for automating tasks, configuring systems, and performing various actions. They can also be misused by cybercriminals to deliver malicious code and execute harmful actions on computers.

Technical Analysis

The examined VBS file executed numerous PowerShell commands and then leveraged steganography to perform process injection into RegAsm.exe as shown in Figure 2. Regasm.exe is a Windows command-line utility used to register .NET assemblies as COM components, allowing interoperability between different software. It can also be exploited by malicious actors for purposes like process injection, potentially enabling covert or unauthorized operations.

Figure 2: Infection Chain

VBS needs scripting hosts like wscript.exe to interpret and execute its code, manage interactions with the user, handle output and errors, and provide a runtime environment. When the VBS is executed, wscript invokes the initial PowerShell command.

Figure 3: Process Tree

First PowerShell command

The first PowerShell command is encoded as illustrated here:

Figure 4: Encoded First PowerShell

Obfuscating PowerShell commands serves as a defense mechanism employed by malware authors to make their malicious intentions harder to detect. This technique involves intentionally obfuscating the code by using various tricks, such as encoding, replacing characters, or using convoluted syntax. This runtime decoding is done to hide the true nature of the command from static analysis tools that examine the code without execution. Upon decoding, achieved by substituting occurrences of ‘#@$#’ with ‘A’ and subsequently applying base64-decoding, we successfully retrieved the decrypted PowerShell content as follows:

Figure 5: Decoded content

Second PowerShell Command

The deciphered content serves as the parameter passed to the second instance of PowerShell..

Figure 6: Second PowerShell command

Deconstructing this command line for clearer comprehension:

Figure 7: Disassembled command

Steganography

As observed, the PowerShell command instructs the download of an image, from the URL that is strore in variable “imageURL.” The downloaded image is 3.50 MB in size and is displayed below:

 

Figure 8: Downloaded image

This image serves as the canvas for steganography, where attackers have concealed their data. This hidden data is extracted and utilized as the PowerShell commands are executed sequentially. The commands explicitly indicate the presence of two markers, ‘<<BASE64_START>>’ and ‘<<BASE64_END>>’. The length of the data is stored in variable ‘base64Length’. The data enclosed between these markers is stored in ‘base64Command’. The subsequent images illustrate these markers and the content encapsulated between them.

Figure 9: Steganography

After obtaining this data, the malware proceeds with decoding procedures. Upon examination, it becomes apparent that the decrypted data is a .NET DLL file. In the subsequent step, a command is executed to load this DLL file into an assembly.

Figure 10: DLL obtained from steganography

Process Injection into RegAsm.exe

This DLL serves two purposes:

1. Downloading and decoding the final payload
2. Injecting it into RegAsm.exe

Figure 11: DLL loaded

In Figure 11, at marker 1, a parameter named ‘QBXtX’ is utilized to accept an argument for the given instruction. As we proceed with the final stage of the PowerShell command shown in Figure 7, the sequence unfolds as follows:

$arguments = ,(‘txt.46ezabwenrtsac/42.021.871.591//:ptth’)

The instruction mandates reversing the content of this parameter and subsequently storing the outcome in the variable named ‘address.’ Upon reversing the argument, it transforms into:

http://195.178.120.24 /castrnewbaze64.txt

Figure 12: Request for payload

Therefore, it is evident that this DLL is designed to fetch the mentioned text file from the C2 server via the provided URL and save its contents within the variable named “text.” This file is 316 Kb in size. The data within the file remains in an unreadable or unintelligible format.

Figure 13: Downloaded text file

In Figure 11, at marker 2, the contents of the “text” variable are reversed and overwritten in the same variable. Subsequently, at marker 3, the data stored in the “text” variable is subjected to base64 decoding. Following this, we determined that the file is a .NET compiled executable.

Figure 14: Final payload

In Figure 11, another activity is evident at marker 3, where the process path for the upcoming process injection is specified. The designated process path for the process injection is :

“C:WindowsMicrosoft.NETFrameworkv4.0.30319RegAsm.exe”.

Since RegAsm.exe is a legitimate Windows tool, it’s less likely to raise suspicion from security solutions. Injecting .NET samples into it allows attackers to effectively execute their malicious payload within a trusted context, making detection and analysis more challenging.

Process injection involves using Windows API calls to insert code or a payload into the memory space of a running process. This allows the injected code to execute within the context of the target process. Common steps include allocating memory, writing code, creating a remote thread, and executing the injected code. In this context, the DLL performs a sequence of API calls to achieve process injection:

Figure 15: Process Injection

By obscuring the sequence of API calls and their intended actions through obfuscation techniques, attackers aim to evade detection and make it harder for security researchers to unravel the true behavior of the malicious code. The function ‘hU0H4qUiSpCA13feW0’ is used for replacing content. For example,

“kern!”.Replace(“!”, “el32”)  à  kernel32

Class1.hU0H4qUiSpCA13feW0(“qllocEx”, “q”, “VirtualA”) à VirtualAllocEx

As a result, these functions translate into the subsequent API calls:

1. CreateProcessA : This API call is typically employed to initiate the creation of a new process, rather than for process injection. In the context of process injection, the focus is generally on targeting an existing process and injecting code into it.
2. VirtualAllocEx: This is often used in process injection to allocate memory within the target process to host the injected code.
3. ReadProcessMemory: This is used to read the memory of a target process. It is typically used in reflective DLL injection to read the contents of a DLL from the injector’s memory and write it into the target process.
4. GetThreadContext: This API is used to retrieve the context (registers, flags, etc.) of a thread within a target process. It’s useful for modifying thread execution flow during injection.
5. Wow64GetThreadContext: This is like GetThreadContext, but it’s used when dealing with 32-bit processes on a 64-bit system.
6. SetThreadContext: This API is used to set the context of a thread within a target process. This can be useful for modifying the execution flow.
7. Wow64SetThreadContext: Like SetThreadContext, but for 32-bit processes on a 64-bit system.
8. ZwUnmapViewOfSection: This is used to unmap a section of a process’s virtual address space, which could potentially be used to remove a DLL loaded into a target process during injection.
9. WriteProcessMemory: This is used to write data into the memory of a target process. It’s commonly used for injecting code or data into a remote process.
10. ResumeThread: This is used to resume the execution of a suspended thread, often after modifying its context or injecting code.

Upon successful injection of the malware into RegAsm.exe, it initiates its intended operations, primarily focused on data theft from the targeted system.

The ultimate executable is heavily obfuscated. It employs an extensive array of switch cases and superfluous code, strategically intended to mislead researchers and complicate analysis. Many of the functions utilize either switch cases or their equivalent constructs, to defend detection. Following snippet of code depicts the same.

Figure 16: Obfuscation

Collection of data:

Fingerprinting:

Agent Tesla collects data from compromised devices to achieve two key objectives: firstly, to mark new infections, and secondly, to establish a unique ‘fingerprint’ of the victim’s system. The collected data encompasses:

• Computer Name
• IP information
• Win32_baseboard
• Serial number
• win32_processor
• processorID
• Win32_NetworkAdapterConfiguration
• MacAddress

Web Browsers:

Agent Tesla initiates the process of gathering data from various web browsers. It utilizes switch cases to handle different browsers, determined by the parameters passed to it. All of these functions are heavily obscured through obfuscation techniques. The following figures depict the browser data that it attempted to retrieve.

Figure 17: Opera browser

Figure 18: Yandex browser

Figure 19: Iridium browser

Figure 20: Chromium browser

Similarly, it retrieves data from nearly all possible browsers. The captured log below lists all the browsers from which it attempted to retrieve data:

Figure 21: User data retrieval from all browsers -1

Figure 22: User data retrieval from all browsers – 2

Mail Clients:

Agent Tesla is capable of stealing various sensitive data from email clients. This includes email credentials, message content, contact lists, mail server settings, attachments, cookies, auto-complete data, and message drafts. It can target a range of email services to access and exfiltrate this information. Agent Tesla targets the following email clients to gather data:

Figure 23: Mail clients

Exfiltration:

Agent Tesla employs significant obfuscation techniques to evade initial static analysis attempts. This strategy conceals its malicious code and actual objectives. Upon successful decoding, we were able to scrutinize its internal operations and functionalities, including the use of SMTP for data exfiltration.

The observed sample utilizes SMTP as its chosen method of exfiltration. This protocol is frequently favored due to its minimal overhead demands on the attacker. SMTP reduces overhead for attackers because it is efficient, widely allowed in networks, uses existing infrastructure, causes minimal anomalies, leverages compromised accounts, and appears less suspicious compared to other protocols. A single compromised email account can be used for exfiltration, streamlining the process, and minimizing the need for complex setups. They can achieve their malicious goals with just a single email account, simplifying their operations.

Figure 24: Function calls made for exfiltration.

This is the procedure by which functions are invoked to facilitate data extraction via SMTP:

1. A specific value is provided as a parameter, and this value is processed within the functions. As a result, it ultimately determines the port number to be utilized for SMTP communication. In this case, port number 587 is used for communication.

Figure 25: Port number

2. Next, the malware retrieves the hostname of the email address it intends to utilize i.e., corpsa.net.

Figure 26: Domain retrieval

3. Subsequently, the email address through which communication is intended to occur is revealed.

Figure 27: Email address used

4. Lastly, the password for that email address is provided, so that attacker can log in and can start sending out the data.

Figure 28: Password

The SMTP process as outlined involves a series of systematic steps. It begins with the processing of a specific parameter value, which subsequently determines the port number for SMTP communication. Following this, the malware retrieves the associated domain of the intended email address, revealing the address itself and ultimately providing the corresponding password. This orchestrated sequence highlights how the malware establishes a connection through SMTP, facilitating its intended operations.

Following these steps, the malware efficiently establishes a login using acquired credentials. Once authenticated, it commences the process of transmitting the harvested data to a designated email address associated with the malware itself.

Summary:

The infection process of Agent Tesla involves multiple stages. It begins with the initial vector, often using email attachments or other social engineering tactics. Once executed, the malware employs obfuscation to avoid detection during static analysis. The malware then undergoes decoding, revealing its true functionality. It orchestrates a sequence of PowerShell commands to download and process a hidden image containing encoded instructions. These instructions lead to the extraction of a .NET DLL file, which subsequently injects the final payload into the legitimate process ‘RegAsm.exe’ using a series of API calls for process injection. This payload carries out its purpose of data theft, including targeting browsers and email clients for sensitive information. The stolen data is exfiltrated via SMTP communication, providing stealth and leveraging email account. Overall, Agent Tesla’s infection process employs a complex chain of techniques to achieve its data-stealing objectives.

Indicators of compromise (IoC):

File	MD5	SHA256
VBS file	e2a4a40fe8c8823ed5a73cdc9a8fa9b9	e7a157ba1819d7af9a5f66aa9e161cce68d20792d117a90332ff797cbbd8aaa5
JPEG file	ec8dfde2126a937a65454323418e28da	21c5d3ef06d8cff43816a10a37ba1804a764b7b31fe1eb3b82c144515297875f
DLL file	b257f83495996b9a79d174d60dc02caa	b2d667caa6f3deec506e27a5f40971cb344b6edcfe6182002f1e91ce9167327f
Final payload	dd94daef4081f63cf4751c3689045213	abe5c5bb02865ac405e08438642fcd0d38abd949a18341fc79d2e8715f0f6e42

Table 1:Indicators of Compromise