[July | Malware Analysis Report] PureLogs Infostealer Distributed by Email: Evidence of Integration with Violet RAT

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

We aim to create a safer cyberspace by sharing malware characteristics, threat trends, and related intelligence identified through expert analysis.

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

1. Overview

This report provides a technical analysis of .NET-based multistage malware distributed by email in July 2025.

The attacker directs users to a malicious URL to download an executable. Once executed, the malware proceeds through a multistage infection chain comprising a dropper, downloader, infostealer, and RAT (Remote Access Trojan). The overall execution flow incorporates in-memory loading (fileless execution), while obfuscation of strings and key logic throughout the code impedes static analysis.

The core of this malware consists of two main modules, PureLogs and Violet RAT, responsible for information theft and system control respectively. PureLogs is an infostealer that collects a broad range of sensitive information, including system information, browser credentials, email client data, cryptocurrency wallets, Discord tokens, clipboard contents, screenshots, and local files, then encrypts and compresses it for transmission to a C2 server. Violet RAT, executed next, is an advanced remote access tool with 119 command-handling functions. It supports remote command execution, file system manipulation, screen and input control, audio playback, DoS (Denial-of-Service) attacks, and other malicious activities. Both payloads are distributed as MaaS (Malware-as-a-Service)¹ services, and the actual attacker combines them to collect information and establish remote control in stages on infected systems.

This analysis examines the malware’s overall behavior through four modules: the dropper, downloader, PureLogs, and Violet RAT. It details the detection-evasion techniques and strategies used at each stage. By focusing on the structure, communication methods, collection workflows, and command processing of PureLogs and Violet RAT, it aims to clarify the threat posed by recent MaaS-based malware and support the development of countermeasures.

¹ MaaS (Malware-as-a-Service): A cybercrime service model in which, instead of developing or distributing malware themselves, attackers

rent or purchase malware or malware creation and distribution tools developed by their creators.

2. Malware Information

The attacker distributes the malware by email, directing users to "hxxp://176.46.157.32/files/5373782173/QvG0bbo.exe" to download "QvG0bbo.exe". This file is actually an executable named "Hypgkdn.exe" that acts as a dropper, loading other malicious components into memory when run.

On execution, the dropper decrypts and decompresses a hard-coded binary and loads the DLL directly into memory. It is loaded under the name “AIfA66mqs.dll”, although its build filename is “Hjlslg.dll”. This module acts as a downloader: it decodes the embedded C2 server address and attempts to communicate with the server. It then receives an encrypted payload from C2, decrypts and decompresses it, and uses an embedded DLL and argument array to execute the next-stage DLL in memory.

The next module, “ClassLibrary4.dll”, is an infostealer that collects system environment information, browser logins, email and FTP client accounts, cryptocurrency wallets, Discord tokens, and other sensitive data. It also recursively traverses the infected PC’s file system, compresses targeted files in memory, and exfiltrates them. This module copies and deletes itself to remove traces and registers an autorun path in the registry to maintain persistence. It then accesses the hard-coded URL “hxxps://rdmfile.eu/install/PoaZWvOtN6wJ” to download and execute an additional executable.

The downloaded file, “VioletClient.exe”, is a RAT (Remote Access Trojan). It sends information about the infected system to C2, then receives command codes and performs various remote-control operations. Its 119 command-handling functions support a broad range of malicious activity, including remote command execution, screen and audio control, file manipulation, process management, information theft, and network attacks.

All files are .NET-based and obfuscated, making analysis difficult. The table below summarizes the role of each component.

[Table 1] Malware component files and the role of each module

In summary, the analyzed malware has a multistage infection chain from dropper to downloader, infostealer, and RAT. Each stage uses common malware techniques such as fileless execution, external payload loading, and autorun registration. The attacker separates capabilities into payload layers, allowing functionality to be extended flexibly according to the attack objective. In particular, the transition from infostealer to RAT can give the attacker full control of the victim’s PC, posing a severe security risk.

3. Malware Execution Sequence

The malware performs a sequence of malicious actions through its dropper, downloader, infostealer, and RAT stages. The attacker embeds the malicious URL “hxxp://176.46.157.32/files/5373782173/QvG0bbo.exe” in an email and entices the user to click it, downloading the first executable, “Hypgkdn.exe”. When the user runs it, the program decrypts the hard-coded downloader (“Hjlslg.dll”) and loads it into memory. The downloader receives the encrypted infostealer (“ClassLibrary4.dll”) from C2 (144.172.91.41:8805, TCP), decrypts and decompresses it, and loads it into memory.

The loaded infostealer collects system information, browser credentials, email and FTP client accounts, cryptocurrency wallets, Discord tokens, clipboard contents, screenshots, local files, and other sensitive data. It serializes and encrypts this information before sending it to C2. It also copies the currently running file (“Hypgkdn.exe”) to %APPDATA% and registers an autorun entry (“HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run”) to establish persistence. It then deletes the original executable to remove traces and accesses “hxxps://rdmfile.eu/install/PoaZWvOtN6wJ” to download and execute the RAT payload (“VioletClient.exe”).

Immediately after execution, the RAT collects system information, a list of security products, and user environment information, sends it to C2 (144.172.91.41:7708, TCP), and waits for commands. The server can issue 119 commands, enabling remote command execution, file system manipulation, screen and input control, audio playback, process management, information theft, network attacks, and other activities.

The malware thus executes modular capabilities and encrypts and compresses payloads before loading them in memory, creating a structure optimized for detection evasion. Its design places remote control immediately after information theft, allowing the attacker to use the stolen data for further manipulation and increasing the potential risk.

[Figure 1] Malware execution flowchart

4. Malware Analysis

All analyzed files were obfuscated. This document explains each feature using decompiled code after deobfuscation.

4.1. Hypgkdn.exe (Dropper)

4.1.1. Payload Decryption and In-Memory Loading

“Hypgkdn.exe” decrypts an encrypted payload binary using a hard-coded AES key and IV. The attacker embeds the Base64-encoded key and IV in the code for use by the decryption routine. The decrypted payload is also GZip-compressed; decompression reveals a .NET binary (“Hjlslg.dll”). Without saving the assembly to disk, the dropper loads it into memory, locates the type “HN94DoyCexiOXenFms.vJy7OW7XF5hyR53H4r.AIfA66mqs”, and executes it dynamically. This fileless execution bypasses disk-based detection and complicates analysis.

[Figure 2] Decrypting the hard-coded payload, loading it into memory, and executing it dynamically

4.2. Hjlslg.dll (Downloader)

4.2.1. Decrypting Initial Configuration

On execution, “Hjlslg.dll” decrypts a hard-coded Base64 string and deserializes it to load its initial configuration into memory. This conceals C2 server information and execution parameters within the code. The restored settings include the C2 IP address (144.172.91.41) and port number (0x00002265).

[Figure 3] Examining decrypted C2 IP and port information through debugging

4.2.2. Preventing Duplicate Execution and Evading Analysis

“Hjlslg.dll” hashes a string extracted from its initial configuration to generate a mutex name. If the same mutex already exists, it exits immediately to prevent duplicate execution. This prevents multiple instances from running simultaneously on the same PC.

[Figure 4] Preventing duplicate execution using a mutex

It also employs several analysis-environment detection techniques and is designed to terminate the running process immediately if any of the following conditions is detected.

[Figure 5] Detecting sandbox analysis modules (SbieDll.dll, cuckoomon.dll)

[Figure 6] Querying BIOS information (version, SerialNumber) through WMI to detect virtual machines such as VMware

[Figure 7] Checking for an analysis environment using the parent process name (cmd)

[Figure 8] Detection through the presence of a VMware system file (vmGuestLib.dll)

[Figure 9] Virtual-machine detection based on the manufacturer and model returned by WMI

[Figure 10] Conditional checks for an analysis environment based on screen resolution

[Figure 11] Detecting an analysis environment based on whether the operating system is 64-bit

[Figure 12] Conditional detection of an analysis environment using usernames such as john and anna

4.2.3. C2 Communication and Payload Processing

“Hjlslg.dll” creates a TCP socket to communicate directly with C2 and sets unusually large send and receive buffers (5MB) to handle large volumes of data. It connects using the IP address (144.172.91.41) and port (8805) from its initial configuration.

[Figure 13] Creating a TCP socket and setting send and receive buffers to 5MB

After connecting, it performs a health-check routine to verify the session state, exchanging specific byte values to check that the server responds correctly.

[Figure 14] Single-byte send/receive health check to verify the server connection

To receive the payload, it first reads a 4-byte size value sent by the server to determine the payload length, then receives that many bytes. The received data is decrypted using 3DES with a key extracted from the initial configuration, decompressed with GZip, and deserialized. The deserialized object contains another payload as a byte array. Applying the same 3DES decryption and decompression produces the final .NET assembly (“ClassLibrary4.dll”).

[Figure 15] Reading the payload size and receiving all data in blocks

The downloader loads the assembly directly into memory without writing it to disk and executes the first public method in the first public class. It serializes the configuration updated through communication and passes it as a method argument. This also uses fileless execution, evading file-based security products and complicating analysis.

4.3. ClassLibrary4.dll (PureLogs)

4.3.1. System Information Collection

“ClassLibrary4.dll” first deserializes the configuration byte array received as an argument, then collects various details about the local system and assembles them into a single object for external transmission. It collects the following information.

- Version: A hard-coded string identifying the PureLogs version.

- Execution flags: Set from Boolean configuration values and used for internal execution conditions and branching.

- Execution time: Records the current date and time to identify when collection occurred.

- Computer name (MachineName): Retrieves the system name configured in the operating system.

- User and system identifier: Combines hardware information obtained through WMI (BaseBoard SerialNumber, ProcessorId, and Processor Name), applies an MD5 hash, and uses a selected portion as a unique identifier. The username is then appended to produce the final identification string.

- Execution path: Obtains the full path of the currently running malware file.

- Operating system information: Combines the OS name and architecture to identify the system environment.

- Installed antivirus: Queries registered antivirus product names to identify security software.

- Screenshot: Captures the current screen and converts it to a JPEG byte array.

- Clipboard text: Reads text stored in the clipboard.

- CPU and GPU names: Retrieves installed CPU and GPU models to identify the user’s hardware environment and help determine whether it is virtualized.

- Physical memory size: Measures installed RAM capacity in GB.

- Screen resolution: Obtains the current resolution (width × height).

- IPv4 and gateway addresses: Collects the local network address and default gateway information.

- First-run status: Checks whether a registry key at “Software\<고유 식별자>” exists. The unique identifier is the system identifier generated earlier. If the key is absent, the malware considers this its first execution.

[Figure 16] Creating the system information object and configuring key collection fields

The attacker uses this information to analyze the victim’s environment in detail, issue commands suited to it, or conduct tailored attacks. System identifiers, clipboard contents, and screenshots are particularly useful targets for information theft.

4.3.2. Browser Information Collection

After collecting system information, the infostealer asynchronously gathers browser and application credentials, cryptocurrency wallets, and Discord tokens. Each collection routine runs concurrently on a separate thread, and all collected data is ultimately sent externally together with the system information.

[Figure 17] Asynchronous routines for collecting browser, application, cryptocurrency wallet, and Discord information

The browser collection routine uses a predefined list to check whether each browser and its user profile directory (“User Data”) exist. The list includes major browsers such as Chrome, Edge, and Firefox, as well as many Chromium- and Gecko-based derivatives. Browser search paths are stored as hard-coded strings. The targeted browsers are listed below.

By targeting a broad range of 114 browsers, the malware attempts to steal information across diverse user environments. For installed browsers, it searches each profile directory to extract browsing history, login information, session cookies, and other data, then transmits it with the other collected information.

4.3.3. Application Information Collection

The infostealer collects sensitive user data from email clients, FTP tools, messengers, VPNs, download managers, and other applications. It executes dedicated routines for each application, searching configuration files or registry paths for data, then exfiltrates the results with other collected information. Target applications and their collection methods are listed below.

[Table 2] Application-specific data collection methods

4.3.4. Cryptocurrency Wallet Information Collection

To collect data from cryptocurrency wallet applications installed locally, the infostealer searches files and folders using hard-coded paths. It targets either an entire wallet data folder or specific configuration or key files. If present, these are compressed and sent along with other collected information. Targets fall into two categories.

- Entire wallet data folders: Collects and ZIP-compresses all data within the wallet installation path

Qtum, DashCore, Litecoin, Bitcoin, Dogecoin, Coinomi, Armory, Bytecoin, MultiBit, Exodus, Ethereum, Electrum, ElectrumLTC, AtomicWallet, Guarda, WalletWasabi, ElectronCash, Sparrow, IOCoin, PPCoin, BBQCoin, Mincoin, DevCoin, YACoin, Franko, FreiCoin, InfiniteCoin, GoldCoinGLD, Binance, Terracoin, DaedalusMainnet, MyMonero, MyCrypto, Bisq, Bisq_db, Bisq_keys, Zap, Simpleos, Neon, bitmonero, Etherwall

- Individual configuration and key files: Collects and ZIP-compresses specific files within the wallet installation path

Electrum_config, ElectronCash_config, Sparrow_config, AtomicDEX, Binance_wallet_config

These folder and file paths are hard-coded in the malware. Files are collected only if their size does not exceed 60MB. All collected files are compressed in memory and transmitted without being written to disk.

4.3.5. Discord Token and User Information Collection

The infostealer searches the Discord desktop client’s local data folders for user authentication tokens, then uses them to retrieve additional user and server information. This design goes beyond simply stealing information and enables direct access to the victim’s Discord account. It first searches for the “Local Storage\leveldb” subfolder in Discord installation directories at the following paths.

It extracts tokens from “.log” and “.ldb” files in the LevelDB folder using the following regular expressions.

-Standard token: [\\w-]{24}\\.[\\w-]{6}\\.[\\w-]{27}

-MFA token: mfa\\.[\\w-]{84}

After removing duplicate tokens, the infostealer calls the official Discord API to collect the following information.

[Table 3] User and server information collected through the Discord API

For API calls, it inserts the extracted token directly into the “Authorization” header to bypass authentication. Because this impersonates an actual user session, accounts without two-factor authentication can be taken over immediately.

4.3.6. File Discovery and In-Memory Compression

The infostealer searches the local file system, collects files, and ZIP-compresses them in memory for exfiltration. Valid directories are traversed recursively, while individual file paths are added directly to the compression targets. The following directories are excluded because access is risky or unnecessary.

All discovered files are ZIP-compressed in memory. The design avoids creating temporary files on disk and leaving traces, helping evade security products.

4.3.7. Transmission of Collected Information

The infostealer transmits collected information in two stages: first text-based data from browsers, applications, cryptocurrency wallets, and Discord, followed by compressed file-system data. It creates a TCP socket and connects to C2 using the IP (144.172.91.41) and port (8805) provided in its execution arguments. Immediately after connecting, it exchanges specific fixed bytes as a health check to verify the session. It then sends information as follows.

①. Serialize the transmission data

The object to be sent is serialized in Protobuf format and converted to a byte array.

②. Send a packet containing system information

A new object containing system information and the serialized data length is created, serialized again, compressed, and encrypted. The encrypted data length is sent first, followed by the data itself. This allows the recipient to determine the exact total size and divide and process it correctly.

[Figure 18] Sending compressed and encrypted data

③. Send a GUID-based identifier

A GUID string with its hyphens removed is serialized, compressed, encrypted, and sent in the same way.

[Figure 19] Sending the GUID-based identifier

④. Stream the data

The serialized collected data is divided into fixed-size blocks, each containing the GUID identifier and a data index. Each block is compressed and encrypted before sequential transmission, with brief pauses between blocks to improve reliability.

[Figure 20] Streaming collected information in blocks

⑤. Send a transfer-complete packet

Finally, the same GUID is sent once more to notify the server that transmission is complete.

4.3.8. Persistence and Trace Removal

The infostealer uses registry registration, executable copying, and self-deletion to maintain execution in the infected environment.

It first registers a unique identifier derived from system information as a subkey under “HKEY_CURRENT_USER\Software\” to track infection. If the currently running file is not in %WINDIR% or %APPDATA%, it copies itself to %APPDATA% and runs the following PowerShell commands in a hidden window to register an autorun entry.

These commands remove the existing Run entry and register the new path to establish persistence. After copying itself to %APPDATA%, the malware runs the following PowerShell command in a hidden window to delete its original executable.

4.3.9. Payload Download and Execution

The infostealer can download an additional payload from an external server, save it locally, and execute it. It explicitly enables TLS 1.2 for HTTPS communication and downloads an executable from “hxxps://rdmfile.eu/install/PoaZWvOtN6wJ”. The file is saved in %TEMP% under a random name with an “.exe” extension and is immediately executed.

[Figure 21] Downloading and saving an external file over HTTPS

[Figure 22] File downloaded from rdmfile.eu

4.4. VioletClient.exe (Violet RAT)

“VioletClient.exe” uses string obfuscation throughout its code. Key strings such as file paths, registry paths, and execution commands are Base64-encoded and embedded in the code, then decoded at runtime. This is intended to hinder static analysis.

[Figure 23] Code obfuscated with Base64 strings

4.4.1. Preventing Duplicate Execution and Establishing Persistence

The RAT prevents duplicate execution and uses several methods to run automatically after reboot. It first creates a mutex named “tR1utZz9FykzeKjC” and terminates immediately if an instance with the same mutex already exists, preventing simultaneous execution on the same PC.

[Figure 24] Decoding a Base64 string for use as a mutex name to prevent duplicate execution

It then copies the running file to the following two locations to enable automatic execution.

- Startup folder

It copies the file to “%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup” to run automatically when Windows starts.

[Figure 25] Copying the running executable to Startup for automatic execution at boot

- %APPDATA% path

It copies the same file to %APPDATA% and registers its name under the registry key “SOFTWARE\Microsoft\Windows\CurrentVersion\Run”. The malicious file then runs automatically whenever the user logs in.

[Figure 26] Copying the executable to appdata and registering it for autorun in the registry

Combining mutex-based duplicate-execution prevention with Startup-folder and Run-key registration establishes persistence through multiple routes. These techniques are common in malware and improve its ability to survive.

4.4.2. C2 Configuration

The RAT implements two methods of configuring the address used to communicate with C2.

The first dynamically retrieves an IP address and port from an external URL. The second uses static values hard-coded in the malware.

In the external-URL method, WebRequest accesses an attacker-specified web page and parses an “IP:Port” string from the response. The HTTP request uses GET, with the User-Agent manually set to “Mozilla/5.0” to resemble normal browser traffic. The received string is filtered based on spaces and the presence of a colon; if valid, the IP and port are separated and assigned to internal variables.

This allows C2 addresses to be changed without redistributing the malware, supporting evasion and long-term operation. Using services such as Pastebin can make static detection even easier to evade.

[Figure 27] Dynamically configuring C2 by parsing an “IP:Port” string from an external URL

In the analyzed sample, however, a conditional disables the external-URL logic, and the URL field contains “%PasteUrl%”, so the feature does not operate normally. The malware therefore configures C2 statically by decoding hard-coded strings.

[Figure 28] Static C2 configuration: decoding Base64-encoded IP and port strings with the XOR key mOZNSBt

The decoded C2 address is 144.172.91.41 and the port is 7708. The IP is the same as the one used by the infostealer, but the port differs.

4.4.3. C2 Command Processing

The malware creates a separate thread to receive and process server commands, running a continuous communication loop. The loop repeats indefinitely with a random delay of 1–5 seconds per iteration. At the start of each loop, it initializes C2 connection resources and attempts to connect to 144.172.91.41:7708 through a TCP socket.

[Figure 29] Communication thread with an infinite loop

After connecting to C2, the client builds a string containing information about the infected system.

The string contains 13 fields, including HWID, username, OS name and service pack, administrator status, executable filename, installed antivirus, and the presence of a video capture device. Fields are joined with the “<Violet>” delimiter, and the resulting string is AES-encrypted and sent to the server. The encrypted byte-array length is converted to a string and followed by a null character (\0) to form the header. The complete structure is “[length + '\0'][encrypted message body]”.

[Figure 30] Constructing the infected-system information string

The server then sends command data to the client.

Like the system information, commands use the “[length + '\0'][message body]” structure. The malware queues received data and processes it on a separate thread. Each command is a string split by the “<Violet>” delimiter: the first field is the command code, and the remaining fields provide parameters required to execute it.

[Figure 31] Parsing received command strings and processing command codes

There are 119 command codes, with functions grouped as follows.

• File system manipulation: Creating, deleting, renaming, copying, and moving files/folders; dropping and executing arbitrary binaries; and more
• Process/system control: Executing CMD commands, elevating to administrator privileges, monitoring the clipboard, controlling keylogging, and more
• Screen and input control: Taking screenshots, moving the mouse cursor, generating click and keyboard events, and more
• Network and remote control: Flood attacks, ARP spoofing, sniffing, TCP tunneling/reverse shell installation, sending command results to the server, and more
• Local resource dropping and execution: Loading assemblies and invoking methods, dropping and executing PE files, and more
• Information collection and exfiltration: Gathering active window information, encrypting and transmitting system environment data, extracting passwords and emails, and more
• Multimedia control: Playing and stopping audio, generating and sending image thumbnails, and more

This command system is designed to go beyond basic remote control and fully compromise the infected system, posing a high risk of prolonged malicious activity. After executing commands, the malware keeps the socket connected and sends encrypted “PING?” messages approximately every 10–15 seconds to maintain its C2 session.

5. Information Collected and Exfiltrated

6. Conclusion

The malware analyzed in this report is a .NET-based multistage threat comprising a dropper, downloader, infostealer, and RAT, with a combined structure that performs information theft and remote control in sequence. The attacker embeds a malicious URL in an email to entice users into downloading an executable that acts as a dropper. The dropper contains an encrypted downloader DLL, which it decrypts and executes directly in memory without writing to disk. The downloader communicates with C2 to receive an infostealer payload, then decrypts and executes it in memory. The chain through the infostealer uses typical fileless techniques, minimizing infection traces and making detection difficult. The subsequent RAT, however, is saved to disk as a separate executable and explicitly launched in a new process, so the attack is not confined entirely to memory.

Based on its internal string (“v4.0.1.”), collection targets, filenames, and code structure, the infostealer module “ClassLibrary4.dll” is identified as PureLogs Stealer, commercial MaaS (Malware-as-a-Service) malware distributed by PureCoder. It collects system information, browser credentials, email and FTP accounts, cryptocurrency wallets, Discord tokens, clipboard contents, screenshots, local files, and other data, then encrypts and compresses it for C2 transmission. After transmission, autorun registration and self-deletion conceal infection traces and establish persistence.

[Figure 32] Official PureLogs sales page

The subsequent RAT module, “VioletClient.exe”, is identified as the commercial MaaS threat Violet RAT based on the “<Violet>” strings throughout its code, the system information string “Violet v4.5”, and its basic build structure. Its command processing, communication architecture, and string formats also closely resemble the officially distributed Violet RAT version.

[Figure 33] Official Violet RAT sales page

These are independent MaaS malware products with different creators and sales channels. The attacker acquired them separately and combined them into a sequence of information theft followed by remote control. System information, account credentials, and network environment data collected by the infostealer can support subsequent RAT commands, enabling precise control and targeted operations on the victim’s system. With 119 commands, the RAT is an advanced remote-control tool supporting command execution, file manipulation, screen and input control, audio playback, DLL injection, information theft, DoS attacks, and more. Encrypted asynchronous communication enables real-time command reception and ongoing control. This broad command capability extends beyond data collection to active compromise and long-term system control, posing a serious threat to assets.

In conclusion, this case separates payloads by function and combines commercial MaaS malware. The attacker uses obfuscation, in-memory loading, autorun registration, self-deletion, and other evasion techniques. Flexible payload combinations also make future variants and renewed distribution likely. Alongside improving user security awareness, organizations should review defenses against email-based distribution and fileless malware. Intelligence gathering on MaaS sales channels, blocking distribution sites, and monitoring malware communities should be carried out in parallel.

The malware was also identified as “exe.trojan.msil” on the SANDS Lab CTX threat intelligence platform, with associated hashes, C2 IPs, URLs, and other IoCs collected. CTX provides additional information beyond this report, including relationships between malware, attack groups, and associated campaigns, offering useful references for detecting and tracking similar threats.

[Figure 34] Detection results on the SANDS Lab CTX platform

7. Indicators of Compromise

7.1. SHA-256 Hashes

7.2. IP

TCP 144.172.91.41:8805

TCP 144.172.91.41:7708

7.3. URL

hxxp://176.46.157.32/files/5373782173/QvG0bbo.exe

hxxps://rdmfile.eu/install/PoaZWvOtN6wJ