The Pure malware family’s origins trace back to March 2021. Initially it was advertised as educational and penetration testing software. However, closer examination shows a different reality.
Evidence suggests these products are frequently employed in malicious campaigns, raising concerns about their true purpose.
In their recent blog post, researchers at ANY.RUN shared an in-depth analysis of the most popular representatives of the Pure malware family: PureCrypter, PureLogs, and PureMiner. Here is an overview of what they found.
The Pure family’s malware deployment typically begins with a loader containing both staged and stage-less payloads. PureCrypter serves as a prime example, utilizing custom encryption algorithms and network communication with high entropy to evade detection.
PureCrypter operates in two variants:
- Staged: Loader decrypts resources containing libraries like Protobuf-net and Costura.
- Stage-less: Protobuf-net deserializes data, forming a configuration with compressed malware. This compressed malware is then decompressed and executed with parameters from the configuration in a separate process.
By obfuscating and encrypting malware, PureCrypter aims to make detection and analysis by security measures more challenging.
Searching for threat information on PureCrypter on Threat Intelligence Lookup revealed hundreds of samples analyzed in the ANY.RUN sandbox.
Button: Speed up threat investigations with TI Lookup by discovering context info related to specific IOCs, TTPs, and artifacts found in command lines, registries, and processes.
Submitting this sample for analysis in ANY.RUN unveiled that it was written in .NET. After execution, the sample downloaded an .mp4 file, which turned out to be a payload with a 3-byte XOR encryption.
Using a custom CyberChef recipe, the file was decrypted, revealing an executable or library beneath the deceptive exterior.
Unlike the staged loader, the stage-less counterpart employs SmartAssembly for protection.
The payload itself resides within a resource, encrypted for added security.
This execution involves two steps:
1) AES decryption: The resource is decrypted using AES with embedded keys.
2) Decompression: Following AES decryption, the resource is decompressed, exposing a .NET Assembly without executable code but containing another encrypted resource.
This second resource undergoes further decryption using 3DES with a different key and initialization vector (IV).
Both staged and stage-less PureCrypter loaders ultimately share the same entry point, suggesting underlying similarities despite their differing encryption approaches. This shared entry point serves as the launching pad for two payload types:
- Third-party malware like AgentTesla.
- PureLogs, PureCrypter’s own malware specializing in data exfiltration.
The initial steps of the AgentTesla payload follow a similar process to the stage-less loader: decrypting and loading a .NET Assembly resource. This decryption employs the same AES (Rijndael) encryption algorithm, suggesting a consistent approach within the PureCrypter framework.
You can view the rest of the AgentTesla deployment process in the original post on ANY.RUN’s blog.
For this article, let’s focus on Pure’s own malware, PureLogs.
PureLogs malware, disguised as a small .NET library, relies on a NET Reactor-protected loader for distribution and communication with its command-and-control (C2) server. Its primary function is data theft, achieved by the library being downloaded and loaded by the loader.
However, communication with the C2 server isn’t straightforward. Analyzing the loading traffic reveals a multi-layered encryption process:
- Encrypted messages: Both the loader’s initial message and the server’s response are encrypted.
- Double encryption: The server’s response undergoes an additional layer of serialization and re-encryption with byte reversal.
- 3DES encryption: The 3DES encryption method is utilized with a key stored within the loader’s resources. This key itself is further secured with an MD5 hash.
- Transmission format: The loader sends the message size (4 bytes) followed by the encrypted data.
This complex encryption scheme aims to obfuscate PureLogs’ communication and hinder analysis efforts. View a complete decryption here.
The server’s response, after initial decryption, undergoes further processing. Like the initial message, it’s deserialized and re-encrypted using 3DES and GZIP compression. However, a final twist awaits: the entire data is reversed byte-by-byte.
As a result, a library responsible for stealing and exfiltrating data is obtained. It’s time to take a closer look at it.
PureLogs: Multifaceted Stealer
PureLogs, a multifunctional stealer, shares similarities with PureCrypter in its use of obfuscation techniques to impede analysis.
The class library features the “PlgCore” class, likely signifying “PureLogsCore.”
This core component receives serialized data from a resource loaded by the loader from the Command & Control (C2) server.
Data collection and encryption:
1) Deserialization and Configuration: The library deserializes the received data and stores it as configuration settings.
2) Extensive Data Gathering: The library iterates through numerous functions, collecting a wide range of data from the infected system, including:
- Browser data and extensions
- Cryptocurrency wallet details
- User information
- Complete PC configuration details
3) Serialization and Encryption: The gathered data is then serialized and encrypted for secure transmission. This involves compression and 3DES encryption using a pre-existing key.
4) Hashing and Transmission: The prepared data undergoes three transmissions:
- The first and last transmissions contain hashes of the actual data for integrity checks.
- The second transmission carries the encrypted data itself, preceded by a 4-byte size indicator.
This multi-step process, involving data collection, encryption, and hashing, aims to obfuscate the stolen information and make its analysis more challenging.
Researchers at ANY.RUN investigating PureLogs and PureCrypter also encountered another sample that shared the same features with other Pure malware. It followed an identical pattern: 4 bytes indicating data length and the transmission of the actual data.
This consistency hinted at a shared communication approach. Further analysis highlighted a common encryption scheme as well, with both employing 3DES and MD5-encrypted keys.
Running the sample with administrative privileges in ANY.RUN exposed its tactic: the malware created a scheduled task for self-persistence and injected itself into legitimate processes.
The proto-buf configuration and strings mentioning XMRIG, a cryptocurrency miner, hinted at the malware’s potential purpose.
To understand the communication flow better, researchers decrypted the network traffic using the retrieved key and found the familiar 3DES encryption with the 4-byte length indicator.
This allowed the researchers to conclude that the Pure malware family also includes a miner.
Try ANY.RUN for free
ANY.RUN is a trusted provider of an interactive malware analysis sandbox that has been at the forefront of cybersecurity innovation for over 7 years.
The service offers fully interactive Windows and Linux virtual machines (VMs) for conducting both quick scanning of suspicious files and links, as well as in-depth investigations.
Try ANY.RUN’s malware sandbox for 14 days at no cost by requesting a trial.