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.
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
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:
- Downloading and decoding the final payload
- 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:
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 :
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:
- 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.
- VirtualAllocEx: This is often used in process injection to allocate memory within the target process to host the injected code.
- 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.
- 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.
- Wow64GetThreadContext: This is like GetThreadContext, but it’s used when dealing with 32-bit processes on a 64-bit system.
- 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.
- Wow64SetThreadContext: Like SetThreadContext, but for 32-bit processes on a 64-bit system.
- 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.
- 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.
- 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:
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
- Serial number
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
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
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:
- 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
- Next, the malware retrieves the hostname of the email address it intends to utilize i.e., corpsa.net.
Figure 26: Domain retrieval
- Subsequently, the email address through which communication is intended to occur is revealed.
Figure 27: Email address used
- 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.
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):
Table 1:Indicators of Compromise
Follow us to stay updated on all things McAfee and on top of the latest consumer and mobile security threats.