How a Windows Batch Script Quietly Delivered AZALEA RAT

AZALEA RAT in the Underground Ecosystem

AZALEA RAT has recently gained attention within underground cybercriminal communities, where it is actively promoted through dedicated operator portals and administration tools. Unlike standalone malware, AZALEA RAT is presented as a complete remote administration platform, offering features such as remote access, credential theft, keylogging, HVNC, Active Directory enumeration, privilege escalation, and system management. The availability of a dedicated management portal and direct communication channels suggests that the malware is being actively maintained and distributed to a wider audience.

Our investigation also identified an AzaleaControl operator panel and administration client, indicating that the threat extends beyond a single malware sample. These platforms provide operators with centralized management capabilities, allowing them to build payloads, manage infected systems, and monitor active campaigns. The presence of such infrastructure highlights the increasing commercialization of malware and demonstrates how sophisticated attack tools are becoming more accessible within the underground ecosystem.

This growing underground presence suggests that AZALEA RAT is an emerging threat that organizations should monitor closely, as its continued development and distribution could lead to increased adoption by cybercriminals in future campaigns.

AZALEA RAT Malware-as-a-Service (MaaS) Portal

AZALEA RAT Administration Client

The image above shows the AzaleaControl Administration Client, which serves as the management console used by operators to monitor and control infected endpoints. The interface provides a centralized view of connected victims, displaying information such as country, connection status, sleep interval, username, process name, integrity level, IP address, operating system, installed security products, and the status of the last executed task. The lower pane contains a live event log that records agent communications, task execution, and beacon activity.

The menu options, including Server, Build, Operate, and Maintain, indicate that the platform supports the complete malware lifecycle from payload generation and deployment to post-compromise management. The presence of multiple online agents and task status messages further suggests that AZALEA RAT is designed to manage multiple compromised hosts through a single administration interface.

Note: The screenshot is presented solely for threat intelligence and malware analysis purposes to illustrate the operator interface associated with AZALEA RAT. It is not intended to promote or facilitate the use of the software.

Executive Summary

During routine threat hunting, PointWild researchers identified a suspicious Windows batch file that initially appeared benign, receiving 0/61 detections on VirusTotal. Although the file showed no obvious signs of malicious activity, reverse engineering revealed a carefully designed multi-stage loader built to evade traditional static detection.

Rather than executing malware directly, the batch file copies a legitimate Microsoft .NET executable (jsc.exe or csc.exe) into a user-controlled directory and creates a custom configuration file that abuses the .NET AppDomain Manager feature. This technique allows an attacker-controlled DLL (AppModule.dll) to execute automatically before the application’s normal entry point.

Further analysis showed that the loader uses the trusted Windows utility certutil.exe to decode embedded components, including an encrypted file named profile.bin. The DLL then decrypts this file using AES-256-CBC, writes the recovered executable to a randomly generated directory under %APPDATA%, and silently launches the final payload.

Our investigation confirmed that the decrypted payload is AZALEA RAT, a remote access trojan capable of providing attackers with persistent remote access to an infected system. By combining trusted Windows binaries, AppDomain Manager hijacking, encrypted payloads, and self-deleting scripts, the loader minimizes its detection footprint and complicates traditional malware analysis.

This research demonstrates how modern malware loaders increasingly rely on legitimate operating system features instead of obvious malicious code. It also highlights the importance of analyzing the complete execution chain, as a clean antivirus verdict does not necessarily indicate that a file is safe.

Threat Landscape

While analyzing this sample, we observed that the final payload was AZALEA RAT. Interestingly, recent research published by Rubrik Zero Labs also documented AZALEA RAT. In their analysis, the infection chain begins with a malicious LNK (shortcut) file. In contrast, the sample analyzed in this blog starts with a Windows batch file that uses .NET AppDomain Manager hijacking and encrypted payloads to deliver the RAT.

Although the initial delivery methods differ, both investigations highlight that AZALEA RAT is being distributed through multiple loader techniques. This suggests that threat actors are adapting their initial access methods while continuing to deploy the same malware family, making detection based solely on the first-stage loader increasingly challenging.

Possible Infection Vectors

Although the sample analyzed in this blog is delivered through a Windows batch (.bat) file, threat actors can distribute AZALEA RAT using multiple initial access methods. Based on our analysis and publicly available research, the following infection vectors are possible:

Infection Vector	Description
Phishing Emails	Attackers may distribute ZIP archives containing BAT, LNK, or JavaScript files disguised as invoices, shipping documents, or business-related attachments.
Malicious LNK Files	A recently published analysis by Rubrik Zero Labs observed AZALEA RAT being delivered through a malicious Windows shortcut (LNK) file that initiates the infection chain.
Windows Batch (BAT) Files	In our analysis, the infection begins with a BAT script that copies a legitimate .NET executable, creates an AppDomain Manager configuration, decodes embedded components, and launches the loader.
Compressed Archives	ZIP or RAR archives may contain BAT, LNK, or other script files to bypass email filtering and encourage users to extract and execute the contents.
JavaScript or HTA Files	Script-based downloaders can retrieve and execute the first-stage loader from a remote server.
Drive-by Downloads	Compromised or fake websites may trick users into downloading files that ultimately install the loader.
Malvertising	Fake software installers or advertisements may distribute the loader through seemingly legitimate downloads.
Trojanized Software	Cracked software, key generators, or fake installers may include the loader as part of the installation process.

Our investigation shows that AZALEA RAT is not tied to a single delivery mechanism. While our sample uses a BAT-based loader, this indicates that attackers are adapting the initial access vector while continuing to deploy the same malware family.

Beyond 0/61: Looking Deeper into a Suspicious Batch File

While hunting for emerging threats, we encountered a batch file that appeared completely legitimate at first glance. Automated security scanners reported a clean 0/61 detection score, suggesting that the sample contained no known malicious indicators.

During our research, we observed that AZALEA RAT is gaining significant traction in the Malware-as-a-Service (MaaS) ecosystem on underground markets. As part of our hunting efforts, we identified a batch file associated with the campaign. However, the batch file failed to execute successfully in our analysis environment, preventing the payload from being launched through its intended execution flow. We therefore manually traced the batch file’s commands and extracted the embedded payload to continue our investigation.

Attack Chain

Analysis of First Stage Loader (BAT Script)

The infection begins with a Windows batch file that acts as the first-stage loader. Instead of directly executing the final malware, it prepares the execution environment by creating a working directory under %APPDATA%, copying a legitimate Microsoft .NET executable (jsc.exe or csc.exe) as ServiceHost.exe, and generating a custom ServiceHost.exe.config file that abuses the .NET AppDomain Manager feature to load a malicious DLL.

To avoid downloading additional components from a remote server, the batch file contains Base64-encoded copies of the second-stage loader (AppModule.dll) and the encrypted payload (profile.bin) embedded directly within its source code. During execution, the script reconstructs the Base64 data into temporary files (t.b64) and uses the trusted Windows utility certutil.exe to decode them into AppModule.dll and profile.bin. Once decoding is complete, the temporary Base64 files are deleted to minimize forensic artifacts.

Finally, the script launches ServiceHost.exe, which automatically loads AppModule.dll through the AppDomain Manager configuration, initiating the next stage of the infection chain.

Extracting the Encrypted Payload (profile.bin)

Following the extraction of AppModule.dll, the batch script reconstructs another embedded component named profile.bin. Unlike AppModule.dll, this file is not a DLL or executable, but an AES-encrypted payload that contains the final malware.

The script stores the encrypted payload as a large Base64-encoded block directly within the batch file. During execution, it writes the Base64 data into a temporary file (t.b64) and uses the trusted Windows utility certutil.exe to decode it into profile.bin. After successful decoding, the temporary Base64 file is deleted to reduce forensic artifacts.

Once both AppModule.dll and profile.bin have been extracted, the script launches the copied Microsoft .NET executable (ServiceHost.exe). Because ServiceHost.exe.config specifies AppModule.dll as the AppDomain Manager, the .NET Common Language Runtime (CLR) automatically loads the malicious RuntimeController class before the application’s normal execution begins. The loader then reads profile.bin, decrypts it using AES-256-CBC, writes the recovered executable to a randomly generated directory under %APPDATA%, and executes the final payload.

To further reduce forensic evidence, the batch script deletes itself after starting the loader.

This self-deletion technique removes the original batch file from disk, making post-infection investigation more difficult.

Decrypting Final Payload using AppModule.dll

The RuntimeController class is responsible for decrypting the encrypted payload stored in profile.bin. Before decryption, it verifies that the file is at least 48 bytes long, ensuring it contains the required cryptographic material.

The loader divides the file into three parts:

• Bytes 0–31 (32 bytes): AES-256 encryption key
• Bytes 32–47 (16 bytes): Initialization Vector (IV)
• Bytes 48 onwards: Encrypted payload

The decryption is performed using the RijndaelManaged class configured with AES-256 in CBC mode and PKCS7 padding. Once decrypted, the resulting byte array contains the final executable payload, which is passed to the next stage of the infection chain.

After decryption, the malware:

• Creates a random folder inside %AppData%.
• Writes the decrypted payload as a randomly named .exe file.
• Uses random names to make detection more difficult.

Payload Execution

Finally, the malware launches the staged executable using Process.Start() with:

• UseShellExecute = false
• CreateNoWindow = true
• WindowStyle = Hidden

This allows the second-stage payload to execute silently in the background without displaying any visible window.

Analysis of AZALEA RAT

Runtime Resource Extraction, Decryption & String Recovery:

During execution, the Azalea RAT retrieves its own assembly using Assembly.GetExecutingAssembly() and extracts two embedded resources via GetManifestResourceStream(). The first resource is copied into a MemoryStream and converted into a byte array using ToArray(). By loading the resource into memory, the Azalea RAT prepares it for subsequent operations such as decryption and decompression without writing any temporary files to disk.

After extracting an embedded resource, the Azalea RAT invokes the custom Kb27() function to decrypt the protected string blob. The function uses one resource as the encrypted data and the other as the decryption key, returning the decrypted content as a byte array. The Azalea RAT then converts the decrypted bytes into a UTF-8 string and stores them in memory for later use. By encrypting its runtime strings and decrypting them only during execution, the RAT conceals its functionality from static analysis and complicates reverse engineering.

The Azalea RAT decrypts the embedded resource using AES-256 in CBC mode. It uses a 32-byte key extracted from one embedded resource and derives the 16-byte Initialization Vector (IV) from the first 16 bytes of the encrypted data. The remaining bytes are treated as the ciphertext and decrypted entirely in memory using a ‘CryptoStream’.

After decrypting the embedded resource with AES-256, the malware decompresses the resulting data using the .NET ‘GZipStream’ class. The decompressed byte array contains a runtime string blob that is converted into plaintext and used throughout the malware’s execution.

Following AES decryption and GZip decompression, the Azalea RAT recovers a plaintext string blob that contains the runtime resources required by the RAT. The recovered data includes installation and persistence messages, Registry paths, HTTP communication parameters, plugin management routines, remote desktop functionality, SOCKS5 proxy support, AMSI bypass messages, process injection routines, and numerous debug and error messages. By storing these operational strings in an encrypted and compressed format and reconstructing them only at runtime, the Azalea RAT conceals its functionality from static analysis while dynamically accessing the resources needed during execution.

Runtime Status Message Construction of Azalea RAT 

The file retrieves additional strings from the decrypted string blob and uses them to construct runtime status messages. In this case, DateTime.Now provides the current timestamp, while the custom string-resolution function retrieves the “Azalea Agent starting…” message and the “Information” label. These values are then combined to generate a timestamped informational log message during the RAT’s initialization.

Azalea RAT Configuration

During analysis, the decrypted configuration of the Azalea RAT reveals several parameters controlling its execution, persistence, communication, and plugin functionality. The configuration indicates that the implant has anti-analysis features enabled, including AntiDebug, AntiSandbox, and AntiVM. It also contains an antivirus exclusion mode with a configured exclusion path.

The configuration specifies a 5-second beacon interval and uses /api/health as the beacon path. Several burst and reconnect parameters control the frequency and behavior of HTTP requests. The configuration also contains an agent mutex, which can be used to identify or prevent multiple instances of the RAT from running simultaneously.

Persistence-related settings show that the implant can use Explorer Run-key persistence and Scheduled Task persistence. The configured installation directory is %UserProfile%\AppData\Roaming, with updatehost.exe specified as the installed filename and UpdateTask as the scheduled task name. A temporary file path is also configured for persistent queue data.

The configuration further exposes extensive plugin management and recovery settings, including plugin health checks, heartbeat intervals, recovery attempts, and automatic plugin unloading. Other parameters control task repetition, user-agent strings, logging, and security-related functionality.

Overall, the configuration demonstrates that Azalea is a highly configurable RAT, with dedicated options for anti-analysis, persistence, C2 communication, plugin management, task execution and runtime recovery.

Runtime Loading of the Embedded MsgPack Library

This implementation highlights Azalea’s multi-stage runtime loading mechanism, where both the RAT configuration and its MsgPack dependency are embedded within the final .NET assembly. Over the past year, the threat actor has used MsgPack to protect and deserialize the RAT’s configuration, while the embedded library is protected through custom decryption and compression techniques and loaded directly into memory at runtime. This approach minimizes disk artifacts, reduces reliance on externally deployed dependencies, and makes the malware more self-contained and difficult to analyze through static analysis.

Anti-Analysis and Defense Evasion Mechanisms

The RAT performs an anti-debugging check during initialization by evaluating the AntiDebug configuration option along with a custom detection routine. If the AntiDebug option is enabled and the detection routine indicates a debugging environment, the malware calls Process.GetCurrentProcess().Kill() to immediately terminate its own process. This behavior helps prevent analysts from dynamically debugging the RAT and can disrupt automated analysis environments.

The above figure shows the RAT resolving the AmsiScanBuffer function and obtaining its memory address using GetProcAddress(). It then prepares a small patch (getPatch) and changes the protection of the target memory region using VirtualProtect() before copying the patch with Marshal.Copy().

This behavior is consistent with an AMSI bypass, where the RAT modifies the in memory AmsiScanBuffer routine to interfere with AMSI scanning and evade detection during execution.

C2 Communication Configuration

Figure 20 shows the RAT’s C2 server configuration, containing a single configured server:

Address: foreclosure-autobiography.with.playit.plus

Port: 1150

UseTls: true

This indicates that the RAT is configured to communicate with its C2 infrastructure over TLS-enabled communication using port 1150. The presence of a specific domain and communication parameters in the runtime configuration allows the implant to establish its C2 connection during execution.

Conclusion

The AZALEA RAT campaign highlights how modern cyber threats are becoming increasingly stealthy and difficult to detect. In our analysis, the malware used legitimate Windows components and multiple stages of execution to hide its activity, allowing it to bypass traditional security checks during the early stages of the attack. This demonstrates that a file appearing “clean” at first glance should not be assumed to be safe.

The growing availability of AZALEA RAT through dedicated operator panels and management tools also indicates that advanced malware is becoming more accessible to cybercriminals. As these tools continue to evolve, organizations of all sizes face an increased risk from attackers who can launch sophisticated campaigns with minimal technical expertise.

At PointWild, we continuously track emerging threats and analyze new attack techniques to help organizations stay ahead of the evolving cyber threat landscape. By sharing timely threat intelligence and actionable insights, we aim to help businesses strengthen their security posture and make informed decisions before emerging threats become widespread incidents.

Detection and Mitigation

UltraAV, powered by Point Wild, helps defend against such threats by focusing on initial-stage files received from various sources, including abused GitHub Pages, compromised websites, Social engineering campaigns, and trojanized applications disguised as legitimate software installed by users.

As threats like AZALEA RAT continue to rise, so does the need for robust antivirus software. Whether you’re working, gaming or shopping, let UltraAV safeguard your digital life. Download UltraAV now and stay safe from malware, viruses, and emerging threats like AZALEA RAT.

Indicators of compromise

SHA-256	Description
8bc68ae8b33e8bdff01dad86647021203d97dd71ef5f5178673a02782f957411	agent_20260630_150331_FUD.bat
41609feacf589f2707975b2242c6cfd2ff179bdb8a725172ac27e4919271b904	AppModule.dll
4923e904bb4645e950eeed97d0028d85eaf9854f10965bfade895bfa7460ddc5	AZALEA RAT
foreclosure-autobiography.with.playit.plus:1150	C2 Server