[June | Malware Analysis Report] Multistage Loading and Exfiltration Techniques in Recent AgentTesla Malware

The SANDS Lab Threat Analysis Team selects malware each month and publishes an analysis report.

By sharing malware characteristics, threat trends, and related intelligence identified through expert analysis, we aim to help build a safer cyberspace.

More detailed information about this malware is available through the cyber threat intelligence service <CTX>.

1. Overview

AgentTesla is an information-stealing malware family that has continued to evolve since it first appeared around 2014. It remained among the top 10 most frequently detected malware families worldwide in 2024, indicating a persistently high threat level. It is primarily distributed through phishing emails and combines a range of information-gathering capabilities, causing widespread harm to both organizations and individual users.

The AgentTesla sample analyzed in this report uses an AutoIt script-based dropper for initial loading. The dropper decrypts embedded shellcode and loads it into memory; the shellcode then executes the infostealer payload through process hollowing. This minimizes explicit file creation and handles the execution flow entirely in memory to evade detection. To hinder static analysis, it also employs string obfuscation, CRC32 hash-based dynamic API resolution, and manual parsing of export tables. Persistence is established by placing a VBS script in the Startup folder.

The sample implements capabilities common to the AgentTesla family, including environment detection, credential harvesting, keylogging, and SMTP-based exfiltration. In particular, it steals authentication information from a broad range of applications, including web browsers, email clients, VPN clients, and FTP clients.

This report divides the malware’s overall operation into three stages: initial loading through an AutoIt script, shellcode decryption and execution, and information collection and exfiltration by the infostealer. It describes the technical characteristics and evasion techniques used at each stage in detail, providing a clear view of the advanced detection-evasion techniques used by recent AgentTesla variants.

2. Malware Information

The samples used in this analysis are distributed under seemingly legitimate filenames such as "VALVES.bat" and "Project-Materials-RJ700-P73Q800-Technical-Details-pdf.txt". In fact, they are PE executables compiled with Microsoft Visual C++ and based on an AutoIt script. The executable contains two binary resources, "Roca" and "underbalanced". When the user launches the distributed file, the AutoIt script installs and decrypts these resources in the "%TEMP%" directory before executing the final payload.

The AutoIt script, "script.au3", is the entry point for the entire infection chain. On execution, it decodes embedded data and runs it. Function calls, API names, and strings are split or wrapped in custom functions to complicate static analysis. Meaningless variables and functions are also inserted throughout the script to confuse analysts.

[Figure 1] Obfuscated AutoIt script ("script.au3")

The main actions performed by "script.au3" are as follows.

① Copy the "Roca" and "underbalanced" binaries to the "%TEMP%" directory.

② Decrypt the "Roca" binary, load it into memory, and execute it from offset 9200.

Once decrypted, "Roca" executes as x86 shellcode and acts as an intermediate loader that loads the final infostealer payload, "underbalanced", into memory. It first decrypts "underbalanced" using a hard-coded XOR key, creates a target process in a suspended state, and continues execution by injecting the decrypted payload into that process through process hollowing.

When calling APIs, the shellcode does not reference function names directly. Instead, it uses CRC32 hash-based dynamic resolution. It accesses the PEB directly and manually parses each DLL’s export table to extract the required API addresses, adding another layer of evasion. Debugger-detection logic also allows it to avoid execution in analysis environments. For persistence, "Roca" copies the initially distributed file to "%LOCALAPPDATA%\recomplaint" as "eupolyzoan.exe", then creates a VBS script in the Startup folder that launches "eupolyzoan.exe" automatically at system startup.

The final payload, "underbalanced", is a .NET executable written in Microsoft Visual C# that performs the infostealer’s functions.

Within the code, function and variable names are replaced with meaningless strings, and unnecessary branches and control-flow constructs are inserted to hinder static analysis.

[Figure 2] Examples of control-flow manipulation and obfuscation in "underbalanced"

"underbalanced" collects credentials stored in web browsers, email clients, FTP/VPN clients, and other applications on the infected system, along with system information and real-time keystroke logs. It consolidates the collected information, converts it to HTML, and sends it to the hard-coded SMTP destination "smt.treat@yandex.com", enabling the attacker to receive it remotely in real time.

The following table summarizes the malware’s component files and their roles discussed in this report.

[Table 1] Malware component files and their roles

Overall, this malware follows a layered, multistage infection chain consisting of an AutoIt dropper, an x86 shellcode loader, and a .NET infostealer. It represents an advanced example that combines file masquerading, in-memory execution, anti-analysis techniques, and process hollowing to evade detection and sustain malicious activity.

3. Malware Execution Flow

The attacker distributes executables disguised as legitimate files, using names such as "VALVES.bat" and "Project-Materials-RJ700-P73Q800-Technical-Details-pdf.txt". When the user runs the file, the embedded AutoIt-based dropper, "script.au3", executes first.

"script.au3" copies its two embedded resources, "Roca" and "underbalanced", to "%TEMP%". It then restores "Roca" using a custom decryption routine and executes it directly in memory from offset 9200. This stage uses fileless execution without creating an executable file to evade analysis.

The decrypted "Roca" copies the initially distributed file as "eupolyzoan.exe", launches the copy, and terminates the current process.

Next, "eupolyzoan.exe" creates "eupolyzoan.vbs" in "%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup". This VBS script launches the executable, registering it for automatic startup so that its malicious activity continues after a system reboot.

"eupolyzoan.exe" then loads "underbalanced" into memory, decrypts it with a hard-coded XOR key, and creates a legitimate target process, either "svchost.exe" or "RegSvcs.exe". It injects the decrypted "underbalanced" into that process through process hollowing to execute the final payload covertly.

Once executed, "underbalanced" collects the following information.

- Login credentials stored in web browsers, email clients, FTP clients, and VPN clients

- User and computer names, operating system name, CPU model, and memory capacity

- Keystroke logs

The collected information is formatted as HTML and sent to the external SMTP destination "smt.treat@yandex.com".

[Figure 3] Malware execution flow

4. Malware Analysis

4.1. Initial Payload Loading Through an AutoIt Script

The initial executable is a dropper based on an AutoIt script, "script.au3", which is obfuscated throughout. Function names, strings, and API names are constructed through string concatenation or custom function calls. Even AutoIt’s built-in "Call" function is invoked using split strings. Important APIs such as VirtualProtect are called only after encrypted numeric arrays are restored to plaintext, hindering static analysis. For this analysis, we manually removed the obfuscation and reorganized the script by function to explain its behavior.

[Figure 4] Example of an obfuscated AutoIt script ("script.au3")

The script creates "Roca" under "%TEMP%", reads the entire file, and runs a custom decryption routine. This routine splits strings using the delimiter "' & '", converts each string to a number, applies a -5¹ operation, and converts the result back to a character. This process restores the original "Roca" binary in memory.

¹ 4294967291 represents -5 in two’s complement.

[Figure 5] Custom decryption function

After decrypting "Roca", the script also creates "underbalanced" under "%TEMP%" in the same way. It grants read, write, and execute permissions to the memory region containing the decrypted "Roca" binary, sets offset 9200 as the entry point, and invokes CallWindowProc to start execution directly in memory. Unlike the traditional approach of dropping "Roca" to disk or launching it as a standalone PE executable, this is a typical fileless technique in which the entire code executes in memory. It thereby bypasses security-product detection and avoids leaving execution traces on the system.

[Figure 6] Granting permissions with VirtualProtect and invoking CallWindowProc

4.2. Infostealer Loading and Execution Through Roca Shellcode

The decrypted "Roca" is x86 shellcode that acts as an intermediate loader, loading and executing the infostealer payload "underbalanced" in memory.

[Figure 7] Entry-point code of the decrypted "Roca"

To evade static analysis, "Roca" does not explicitly include Windows API function names in its code. Instead, it uses CRC32 hash-based dynamic resolution. It directly parses the export table in each DLL’s PE structure, calculates a hash for each function name, and finds the function address whose hash matches the target value.

"Roca" dynamically resolves the following APIs.

- "kernel32.dll": 37 API functions

- "user32.dll": 1 API function

- "advapi32.dll": 3 API functions

- "shlwapi.dll": 1 API function

- "shell32.dll": 2 API functions

To locate API function addresses, "Roca" first accesses the PEB (Process Environment Block), traverses the list of loaded DLLs, and compares their "BaseDllName" values to obtain the ImageBase address of each DLL.

[Figure 8] Obtaining the base addresses of loaded DLLs through the PEB structure

It then parses the Export Table of each DLL, traversing function names using the name, address, and ordinal tables and comparing CRC32 hashes to identify the function addresses.

[Figure 9] Dynamically resolving API addresses by parsing the Export Table

"Roca" also includes an anti-debugging feature. Immediately after calling Sleep(500ms), it measures the actual elapsed time. If this is less than 0.5 seconds, it identifies the environment as a debugging environment and terminates the process.

[Figure 10] Debugger detection logic

"Roca" then copies the currently running process, “VALVES.bat,” to “%LOCALAPPDATA%\recomplaint” under the name "eupolyzoan.exe" and executes the copy.

[Figure 11] Configuring parameters for creating “eupolyzoan.exe”

[Figure 12] Reading the contents of the running “VALVES.bat” into memory

[Figure 13] Writing the “VALVES.bat” binary to “eupolyzoan.exe”

The newly created "eupolyzoan.exe" is a copy of "VALVES.bat" and repeats the same logic, but an internal conditional statement identifies it as a copy and branches the execution flow. It then writes "eupolyzoan.vbs," which launches itself, to the startup folder ("%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup"), configuring automatic execution when the system boots.

The generated VBS script contains the following:

Because this method achieves persistence through a VBS file instead of the registry, it can evade detection by some security products.

Next, "eupolyzoan.exe" loads "underbalanced" into memory and decrypts it using XOR with the hard-coded key "X0OHZLDCON3SG6XP92NOHLNH". Once decryption is complete, the malware creates one of the following legitimate processes in a suspended state and injects the decrypted "underbalanced" to perform process hollowing.

- "C:\Windows\System32\svchost.exe"

- "C:\Windows\Microsoft.NET\Framework\v2.0.50727\RegSvcs.exe"

- "C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegSvcs.exe"

In the newly created process, the originally loaded executable is unmapped, the decrypted "underbalanced" is mapped into memory, and the section information is reconstructed. The malware then changes the entry point and resumes the process to begin execution. This sequence evades detection by hiding and executing malicious code inside a legitimate process without leaving separate traces on disk. Thus, "Roca" is more than simple shellcode: it serves as a multifunction loader that performs decryption, process hollowing, and persistence to execute the infostealer.

[Figure 14] Unmapping existing memory and mapping underbalanced

[Figure 15] Changing the entry point and resuming the process

4.3. Information Collection and Exfiltration by the underbalanced Infostealer

4.3.1. Environment Evasion and Anti-Analysis Techniques

Before collecting and exfiltrating information, “underbalanced” first employs several analysis-evasion techniques. It disables certificate validation for HTTPS to ensure reliable communication and checks its execution environment for debugging, virtualization, and system-time manipulation. Based on these results, it obstructs analysis by pretending that the program has terminated.

First, the malware registers a callback that always returns true with ServerCertificateValidationCallback, which validates server certificates during .NET communication, causing HTTPS certificates to be trusted unconditionally. This allows invalid or self-signed certificates to pass validation. It also enables protocols from SSL3 through TLS 1.2 to ensure reliable communication with the attacker’s C2 server. This configuration appears intended both to evade detection and to prevent connection failures caused by certificate errors.

[Figure 16] Certificate validation bypass logic

[Figure 17] Configuring security protocols for HTTP communication

The malware then checks five conditions in its execution environment. If any condition is met, it calls Application.Exit() to make the program appear to have terminated. However, this call does not actually terminate execution, and there is no connection to an execution routine such as Application.Run(). In other words, this code is intended to mislead analysts into believing the program has exited; the malicious activity continues internally even after Application.Exit() is called. The execution-environment checks are as follows.

[Figure 18] Execution-environment checking logic

① Debugger detection

It calls the CheckRemoteDebuggerPresent API to check whether a debugger is attached to the current process. If one is attached, the environment is considered an analysis environment.

[Figure 19] Debugger detection logic

② Hosting-environment detection

It calls the external API "http://ip-api.com/line/?fields=hosting" and treats a "true" response as indicating a hosting environment.

[Figure 20] API call for detecting a hosting environment

③ System-time manipulation detection

It compares the system Tick values before and after calling Thread.Sleep(10). If the elapsed time is less than 10L², it assumes that Sleep has been hooked or the time manipulated, and identifies the environment as an analysis environment.

² 10L = 1,000ns

[Figure 21] Detecting time manipulation

④ Detection of DLLs associated with analysis tools

If any of the following DLLs is loaded into the process, the environment is considered an analysis environment.

- "SbieDll.dll" (Sandboxie)

- "SxIn.dll" (360 SOFTWARE)

- "Sf2.dll" (Avast)

- "snxhk.dll" (Avast)

- "cmdvrt32.dll" (Comodo Container)

⑤ Virtual-machine detection

It uses WMI queries to check the system manufacturer and GPU information. If any of the following conditions is satisfied, it identifies a virtual environment.

- "Win32_ComputerSystem.Manufacturer" is "Microsoft Corporation" and "Win32_ComputerSystem.Model" contains "VIRTUAL"

- "Win32_ComputerSystem.Manufacturer" or "Win32_ComputerSystem.Model" contains "vmware" or "VirtualBox"

- "Win32_VideoController.Name" contains both "VMware" and "VBox" (this condition contains a logic error)

These detection routines serve as a defensive strategy to recognize exposure to analysis tools or virtual environments and evade analysis.

In particular, pretending to have stopped running makes the actual malicious behavior harder to analyze.

4.3.2. System Information Collection

“underbalanced” first collects unique identifiers from the infected system. Its first priority is generating a hardware-based identifier, HWID, for which it extracts the following three values.

- Motherboard serial number: "Win32_BaseBoard.SerialNumber"

- Unique CPU ID: "Win32_Processor.ProcessorId"

- MAC address: "Win32_NetworkAdapterConfiguration.MACAddress" (from the first adapter whose IPEnabled property is true)

The malware concatenates these values to generate a unique HWID that can be used to identify the victim.

[Figure 22] Collecting and hashing unique system identifiers to generate an HWID

The malware also extracts the following execution-related information and stores it in internal variables.

- Full path of the currently running process

- Hard-coded directory and executable paths

- Logged-in username and computer name

Depending on its configuration, it can also send a request to an external API and collect the response. When enabled, this feature sends an HTTP request to the configured external API and stores the response. However, the setting was disabled in the sample analyzed in this report, so no request was actually made.

By collecting these identifiers, the malware establishes a basis for later conditional command execution, system differentiation, and victim tracking.

[Figure 23] Structure for storing the execution directory and user information

4.3.3. Credential Collection

“underbalanced” collects credentials stored by various applications on the infected system, including web browsers, email clients, FTP clients, and VPNs. It first registers Chromium- and Mozilla-based browsers using hard-coded paths to locate the browser user profiles containing login information. The registered browsers are listed below.

- Chromium-based browsers

Opera Browser, Yandex Browser, Iridium Browser, Chromium, 7Star, Torch Browser, Cool Novo, Kometa, Amigo, Brave, CentBrowser, Chedot, Orbitum, Sputnik, Comodo Dragon, Vivaldi, Citrio, 360 Browser, Uran, Liebao Browser, Elements Browser, Epic Privacy, Coccoc, Sleipnir 6, QIP Surf, Coowon, Chrome, Edge Chromium

- Mozilla-based browsers

Firefox, SeaMonkey, Thunderbird, BlackHawk, CyberFox, K-Meleon, IceCat, PaleMoon, IceDragon, WaterFox, Postbox, Flock

The malware uses these paths as the base locations for subsequent browser credential extraction.

[Figure 24] Browser profile path registration logic

The malware then registers application-specific collectors in its credential collector list. Target applications are grouped as follows.

- Web browsers

Chromium, Mozilla, Internet Explorer/Edge, UC Browser, QQ Browser, Safari, Falkon

- Email clients

Outlook, Windows Mail, The Bat!, Becky!, IncrediMail, Eudora, Claws Mail, FoxMail, Opera Mail, Mailbird, eM Client, PocoMail

- FTP clients

FileZilla, WinSCP, CoreFTP, FlashFXP, FTP Navigator, SmartFTP, WS_FTP, FTP Commander, FTPGetter

- VPN and security software

OpenVPN, NordVPN, Private Internet Access

- Other applications

Windows Credential Store, VNC, Discord, Trillian, Psi, MySQL Workbench, Internet Download Manager(IDM), JDownloader

[Figure 25] Credential collector registration and execution flow

After registering all collectors, the malware iterates through them to extract stored credentials. Each collector searches application-specific settings files, databases, and configuration files for credentials and appends the results to a list.

[Figure 26] Iterating through registered collectors and executing the Grab() method

The collected credential list is converted into an HTML string and sent to an external server via SMTP.

The entire routine includes exception handling, so an error in one collector does not affect the overall collection process. This structure enables reliable information collection across different environments and is designed to extract application credentials effectively.

4.3.4. Information Exfiltration via SMTP

“underbalanced” sends the collected credentials and system information to an external SMTP server. It first collects the following system information and assembles it into an HTML string.

- Current time

- Username and computer name

- Operating system name

- CPU model

- Memory capacity

- Public IP address (conditional)

It then creates a file with the .html extension from HTML content containing the collected credentials and system information and uses it as an attachment. The filename follows the "PW_사용자명/컴퓨터명_yyyy_MM_dd_HH_mm_ss.html" format. The email is sent with the attachment only and no message body.

SMTP settings are hard-coded internally and use the following fixed values.

- Sender account: "airlet@nffplp.com" / Sender Password: "$Nke%8XIIDtm"

- Recipient account: "smt.treat@yandex.com"

SMTP transmission uses port 587 over a TLS-secured connection (STARTTLS).

The malware logs into the SMTP server using account credentials hard-coded in its code instead of credentials stored on the system.

[Figure 27] Communication with the SMTP server and transition to TLS using STARTTLS

The malware thus also transmits stolen data to an external SMTP server used by the attacker. All email addresses and SMTP credentials used for transmission were hard-coded, and traces of communication with an SMTP server that was operational at the time of analysis were also identified.

4.3.5. Keylogging and Periodic Data Transmission

“underbalanced” performs keylogging by monitoring system-wide keystrokes in real time.

The malware records all user input and periodically sends it to an external server. It first calls SetWindowsHookEx to intercept keyboard input across the system; its callback converts the pressed keys into strings and records them. Input is processed according to the following rules for each key type.

- Standard keys: “a”, “1”, etc. (accurately records case based on CapsLock and Shift state)

- Arrow keys: {KEYUP}, {KEYDOWN}, {KEYLEFT}, {KEYRIGHT}

- Function keys: {F1} ~ {F12}

- Control keys: {CTRL}, {ALT+TAB}, {ALT+F4}, {Win}

- Editing keys: {BACK}, {TAB}, {DEL}, {Insert}

- Input keys: {ENTER}, Space

- Others: {ESC}, {CAPSLOCK}, {HOME}, {END}, {PageUp}, {PageDown}, {NumLock}

- When the active window changes, the title of the currently focused window is also recorded

The malware sends keystroke logs every 30 minutes. This periodic transmission repeats the following sequence.

① First, it checks whether "%TEMP%\log.tmp" exists.

② If the file does not exist, it assembles the currently collected keystroke log and system information in HTML format and attempts SMTP transmission using a filename in the "KL_사용자명/컴퓨터명_yyyy_MM_dd_HH_mm_ss.html" format.

③ If transmission fails, it converts the keystroke data into HTML and saves it in "log.tmp".

④ If "log.tmp" exists, it first combines its contents with system information into an HTML file and sends it via SMTP using the same filename format.

⑤ If transmission succeeds, it deletes "log.tmp".

⑥ It then also attempts to send the currently collected keystroke log via SMTP using the same naming format; if this fails, it saves the log in "log.tmp" again.

[Figure 28] SMTP transmission flow for keylogging data

Clipboard monitoring is also included, but is enabled according to a configuration setting.

When this feature is enabled, the malware records clipboard content only when it changes, escaping characters such as "<" and ">" to prevent HTML parsing errors. A screenshot-capture setting also exists in the code, but no actual image collection or transmission routine is implemented. The feature is therefore inactive: although it appears in the code structure, no corresponding activity occurs.

By contrast, keyboard monitoring has a sophisticated structure with detailed logic for distinguishing special keys and detecting window changes. This design shows that the attacker focuses on information entered directly by the user rather than visual information. Its purpose is to collect sensitive text-based information such as login credentials (ID/PW), email drafts, internal messenger conversations, and URLs.

5. Information Collected and Exfiltrated

6. Conclusion

The malware analyzed in this report is a sophisticated information stealer built around a multistage structure consisting of an AutoIt dropper, an x86 shellcode loader, and a .NET infostealer. During execution, it minimizes actual file creation and evades detection by loading in memory and using process hollowing to hide and execute its malicious payload. It also establishes persistence through startup registration and collects and exfiltrates information through credential harvesting, keylogging, and other features.

Analysis shows that the malware closely resembles the AgentTesla family in its overall structure and behavior.

Specific similarities include the following.

✅ Executes the main infostealer through multistage loading and uses fileless techniques

✅ The infostealer is written in .NET

✅ Collects credentials from numerous applications, including web browsers, email clients, and VPNs

✅ Organizes collected information in HTML format and creates .html files

✅ Uses filenames in the "PW_사용자명/컴퓨터명_yyyy_MM_dd_HH_mm_ss.html" format

✅ Exfiltrates data via SMTP using hard-coded account credentials

These similarities go beyond a simple overlap in functionality and provide grounds for considering the sample an AgentTesla variant or custom build. Its initial distribution method is therefore also likely to involve phishing emails, a technique frequently used by AgentTesla.

The malware sends collected data to an external SMTP server. The sender account, "airlet@nffplp.com", is an email address registered under the official domain of a Thai food company ("nffplp.com"). Inspection of the website found the domain to be operating normally at the time. The attacker likely compromised and abused an actual corporate email account for SMTP authentication.

[Figure 29] Legitimate corporate domain “nffplp.com”, suspected of being abused by the attacker

The recipient, “smt.treat@yandex.com”, is an email account registered under the domain of the Russian portal Yandex.

Yandex is Russia’s most widely used portal and search engine. The user of this email account is likely familiar with a Russian-language environment, which may be interpreted as indirect evidence for estimating the attacker’s nationality or area of operation.

[Figure 30] Login screen for Yandex, where the recipient email account is registered

In conclusion, this is an advanced infostealer that goes beyond information theft to incorporate detection evasion, persistence, and the use of a legitimate domain to disguise its exfiltration route. It exhibits many technical traits repeatedly observed in the AgentTesla family and is likely to reappear in various modified forms.

In particular, abusing a legitimate company’s email server as an exfiltration route appears to be a strategy for evading security products. The evidence clearly indicates the use of advanced techniques throughout information collection and theft. Proactive detection measures, including enhanced monitoring of anomalous SMTP transmission, are therefore needed to prepare for similar threats.

The malware was also identified on the SANDS Lab CTX platform under the detection name “exe.trojan.autoit”. Related executables and various IoCs

are available there. These IoCs include malicious file hashes, related IP addresses, and domains used for communication, and can support the detection and tracking of similar samples.

[Figure 31] Malicious files detected as "exe.trojan.autoit" in SANDS Lab CTX and their associated IoC information

7. Indicators of Compromise

7.1. SHA-256 Hashes

7.2. IP

TCP 163.44.198.71:587

7.3. Domains

nffplp.com

7.4. SMTP

smt.treat@yandex.com

airlet@nffplp.com (PW: $Nke%8XIIDtm)

7.5. File Drop Paths

C:\Users\<사용자명>\AppData\Loca\Temp\Roca

C:\Users\<사용자명>\AppData\Loca\Temp\underbalanced

C:\Users\<사용자명>\AppData\Loca\recomplaint\eupolyzoan.exe

C:\Users\<사용자명>\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\eupolyzoan.vbs