APT�C�26 �Lazarus) is a highly active advanced persistent group �APT) known for its sophisticated and covert attack methods and techniques. The group has a wide range of activities with goals ranging from cyber espionage for gathering intelligence, custom ransomware attacks for financial gains and causing cyber sabotage. The group is known for a wide range of highly sophsiticated and well-known attacks that have caused massive damage and got a notable recognition. These attacks reflect the huge amount of resources and high technical capabilites the group posses. In this research I wanna present a case study that I conducted on a new division of the Lazarus group, which was discovered and documented by Microsoft Threat Intelligence Center . The group is tracked as Moonstone Sleet (formerly Strom-1789�. Moonstone Sleet is a slightly new division of the massive Lazarus group, that is known for a few operations that were conducted hand-by-hand with other North Korean threat actor affiliates inculding . It uses many tried-and-true techniques that were used by other North Korean threat actors while using many of these techniques to conduct coordinated attacks targeting a wide range of companies for financial and espionage objectives, the group has shifted to its own infrastructure and attack methods the most notable of which is using trojanized software that was distributed through fake social media profiles, establishing itself a distinct and separate division.

Phase: Initial Access

• Technique: Supply Chain Compromise via Trojanized Software
• Procedure: The attacker uses fake social media profiles to distribute trojanized versions of legitimate software to gain access to target systems.

Phase: Execution

• Technique: Custom Backdoor Deployment
• Procedure: The threat actor installs a custom backdoor for control over compromised systems, likely involving custom scripts or executable payloads specific to the attack.

Phase: Persistence

• Technique: Legitimate Software Abuse
• Procedure: Utilizes persistent mechanisms within the trojanized software to maintain access to the compromised systems.

Phase: Defense Evasion

• Technique: Obfuscation and Encryption
• Procedure: Employs obfuscation and encryption methods to hide the presence of malicious software and evade detection.

Phase: Credential Access

• Technique: Credential Dumping
• Inference: Likely utilizes tools akin to Mimikatz or similar to extract user credentials from compromised systems.

Phase: Lateral Movement

• Technique: Use of Legitimate Credentials
• Procedure: Moves laterally through networks using legitimate credentials, possibly gathered from credential dumping activities.

Phase: Collection

• Technique: Data Exfiltration
• Procedure: Collects and exfiltrates data relevant to espionage or financial gain objectives, possibly through encrypted channels to avoid detection.

Phase: Impact

• Technique: Ransomware Deployment
• Procedure: Deploys custom ransomware to target systems to disrupt operations and demand ransom payments.

We are gonna take a look at the whole infection chain of an attack that was linked to The Moonstone Sleet group, which involved the usage of a trojanized PuTTY installer and was first documented by . The whole point is to show the consistent usage of trojanized software and code reuse across different attacks linked to the MoonStone Sleet group. Microsoft observed in early August 2023 that Moonstone Sleet was delivering a trojanized version of PuTTY, an open-source terminal emulator through a variety of platforms including Linkedin, and Telegram. The threat actor will send the target a zip archive containing two files: a trojanized PuTTY installer and a text file containing an IP address and password to use. The trojanized version triggers the infection upon the user entering the password provided, by simply checking the user's entered password against a hardcoded password, thereby assuring that only the targeted individuals who entered the intended password will be infected. The heavy and consistent use of the relatively uncommon stream cipher HC-256 for encryption and decryption has been observed. In our case, the next stage payload is decrypted using a hardcoded 32-byte HC�256 key. After decryption, the data is decompressed before being mapped to memory.

Phase: Initial Access

• Technique: Trojanized Software Delivery
• Procedure: The attacker delivers a zip archive via LinkedIn or Telegram containing a trojanized PuTTY installer and a text file with an IP address and password.

Phase: Execution

• Technique: Input Triggered Execution
• Procedure: The trojanized PuTTY installer checks the user-entered password against a hardcoded value. Execution of the malicious payload occurs if the correct password is entered.

Phase: Decryption

• Technique: Decrypting Payload
• Procedure: Decrypts the next stage payload using a hardcoded 32-byte HC-256 key.

Phase: Payload Deployment

• Technique: Memory Injection
• Procedure: After decryption, the data is decompressed and mapped to memory for execution.

After successfully decrypting and decompressing the next stage DLL, it employs a traditional yet effective DLL loading mechanism. Rather than allocating committed and RWX (read-write-execute) memory directly which may raise some red flags, the mapping process consists of four steps: 1. Allocate memory with size equal to the image, reserved, and set to PAGE_READWRITE. This can be done either at the original PE �Portable Executable) image base or the system's preferred address. 2. Commit the previously allocated memory, then copy the headers and sections of the payload into it. 3. Perform relocation fixups for any hardcoded addresses, populate the Import Address Table �IAT�, and apply the appropriate section permissions. 4. Call the DLL's entry point, passing a unique wide string that will be used and carried through the subsequent stages. The in-memory mapped DLL functions as an installer module that writes the next stage module, referred to as SplitLoader , to disk. The name likely comes from the fact that the loader is divided into two components. The first component is decrypted using HC-256 , then decompressed, and subsequently written to %APPDATA%.. \Local\Microsoft\Windows\usrgroup.dat .

Phase: Defense Evasion

• Technique: In-Memory Execution via DLL Loading
• Procedure:
• Allocate memory for the DLL with PAGE_READWRITE.
• Copy headers and sections into the allocated memory.
• Perform relocation fixups, populate the Import Address Table (IAT), and adjust section permissions.
• Execute the DLL's entry point with a unique wide string for further stages.

Phase: Execution and Persistence

• Technique: Writing Payload to Disk
• Procedure:
• The installer module writes the next stage module (SplitLoader) to %APPDATA%\..\Local\Microsoft\Windows\usrgroup.dat.
• Use of HC-256 for decryption and decompression before writing the file.

This structured flow allows a red team to emulate the tactics and procedures used by the threat actor effectively.

The execution of the first part DLL� ) was setup in a very special and dependent way such that the next part is only parsed and decrypted properly if the usrgroup.dat's export was executed with the proper arguments L"%APPDATA%\..\Local\Microsoft\Windows\ \usrgroup.dat, LoadDllW %APPDATA%\..\Local\Microsoft\Windows\ \Explorer\thumbcache_512.db \"zjWy\" 4701" . This is what we can call a DLL checksum to enforce the execution of the DLL only when the intended arguments are passed and prevent it from running in an automated analysis environment or a sandbox. This is a common theme or technique that was observed being heavily used in later attacks linked to the Moonstone sleet. The provided argument serves the path of the next part of the loader, the first 4 bytes of the XOR decryption key that will be used to decrypt the next stage embedded inside , and lastly the same magic wide string which will prove useful in the next stage. The process begins by attempting to obtain a file handle for thumbcache_512.db and then parsing the file to extract the necessary information for the next stage. First, it reads the size of the encrypted and compressed next stage, which is represented by the second set of four bytes from the beginning of the file (the initial four bytes are not relevant). Next, it reads a four-byte magic value to verify the integrity of thumbcache_512.db .

Phase: Execution and Anti-Analysis

• Technique: DLL Loading with Argument Verification
• Procedure: The DLL usrgroup.dat is executed with specific arguments to ensure it only loads in a legitimate environment.
• Command: LoadDllW "%APPDATA%\..\Local\Microsoft\Windows\usrgroup.dat" "%APPDATA%\..\Local\Microsoft\Windows\Explorer\thumbcache_512.db" "zjWy" 4701
• Details: This command passes the path of the loader, the decryption key for the next stage, and a verification string. It ensures that the DLL only runs when the correct arguments are provided, serving as an anti-analysis measure.

Phase: Decryption and Execution

• Technique: XOR Decryption of Next Stage
• Procedure: Parse thumbcache_512.db to read the size of the next stage and a magic value for integrity checks.
• Details: The file is opened to extract necessary information, such as the encrypted stage size and magic value, before decrypting and executing the next stage.

This structured procedure reflects the attacker’s method of ensuring controlled execution and preventing automated analysis interference.

The second part of the loader is saved to %APPDATA%.. \Local\Microsoft\Windows\Explorer\thumbcache_512.db . Before executing the first part , which will decrypt, decompress, and execute the next part of the loader( ), it will set up persistence by first creating a scheduled task using COM ITaskScheduler , and then it creates an entry USBCheck under HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run .

Phase: Execution

• Technique: Decryption and Execution of Payload
• Procedure: The first part of the loader decrypts, decompresses, and executes the next part of the loader stored in %APPDATA%\Local\Microsoft\Windows\Explorer\thumbcache_512.db.

Phase: Persistence

• Technique: Scheduled Task Creation via COM ITaskScheduler

• Procedure: The loader sets up persistence by creating a scheduled task using the COM ITaskScheduler interface.

• Technique: Registry Run Key

• Procedure: The loader creates an entry USBCheck under HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run to ensure execution upon user login.

After acquiring the size of the embedded payload and performing a sanity check on the magic value, the process continues by reading the payload along with an additional 28 bytes �0x1C) that follow the payload. From this, only the first four bytes are utilized. These four bytes are combined with the previously mentioned four-byte value "zJWy" to create an 8-byte XOR key, which will be used to decrypt the payload. Finally, the payload is decrypted using the 8-byte key assembled as described. It is then decompressed using zlib and mapped into memory in the same way previously explained to enhance its chances of not being detected. After calling DLLMain, which is the DLL entry point function, the execution of the DLL is properly initialized. It then enumerates the exported functions' names table, searching for the exported function named "GetWindowSizedW" to finally call. This Python script can parse , extracting, decrypting, and decompressing the next stage.

Phase: Execution

• Technique: Payload Decryption and Loading
• Procedure: The attacker reads the payload alongside 28 additional bytes, using the first four bytes combined with "zJWy" to create an 8-byte XOR key. This key decrypts the payload, which is then decompressed using zlib. The payload is mapped into memory, and DLLMain is called to initialize execution.

Phase: Execution

• Technique: Exported Function Enumeration
• Procedure: The attacker enumerates the exported functions' names table in the DLL, searching for the function named GetWindowSizedW to execute it.

Phase: Script Execution

• Technique: Automated Payload Processing
• Procedure: A Python script is used to parse, extract, decrypt, and decompress the next stage payload. This automation facilitates the continuation of the attack by handling complex decryption and decompression steps without detection.

import sys import zlib def decrypt_payload(enc_payload: bytes, full_xor_key: bytes) -> bytes: """XOR decrypts the payload using the extracted key.""" dec_payload = bytearray(enc_payload) xor_key = full_xor_key[:8] print(f"used key: {xor_key.hex()}") print(f"used key length: {len(xor_key)}") key_len = len(xor_key) for i in range(len(enc_payload)): dec_payload[i] ^= xor_key[i % key_len] # Cycle through the key return bytes(dec_payload) def main(): if len(sys.argv) < 2: print(f"Usage: {sys.argv[0]} ") sys.exit(1) file_path = sys.argv[1] first_dword = b"zjWy" # Ensure this is 4 bytes full_xor_key = [first_dword] # Start with the known first DWORD decompressed_payload_data_bytes = bytes() with open(file_path, "rb") as f: # Read payload size (seek to offset 4 and read exactly 4 bytes) f.seek(4) size_bytes = f.read(4) size_int = int.from_bytes(size_bytes, "little") print(f"Payload size: {hex(size_int)}") f.seek(4, 1) # Skip 4-byte magic # Read the encrypted payload payload_data = f.read(size_int) print(f"We are at offset: {hex(f.tell())}") # Read remaining 7 DWORDs (4 bytes each) for _ in range(7): dword = f.read(4) if len(dword) < 4: print("Warning: Unexpected EOF while reading XOR key!") break full_xor_key.append(dword) xor_key = b"".join(full_xor_key) print(f"Extracted XOR Key: {xor_key.hex()}")

Phase: Execution

• Technique: File Decryption and Execution
• Tool / Script: Custom Python Script
• Procedure:
• Command: python decrypt_script.py <path_to_encrypted_next_stage>
  • Decrypts an encrypted payload using a hardcoded first DWORD zjWy and a key derived from subsequent DWORDs.
  • Utilizes XOR decryption for the payload and dynamically forms the XOR key from the file being processed.

Phase: Defense Evasion

• Technique: Payload Compression and Encryption
• Procedure:
• Encrypted payload is compressed using zlib and then decrypted using a dynamically generated XOR key.
• The script seeks the payload size and offset within the file, manages reading extra bytes beyond the primary payload for variable key construction.

Optional Phase: Post-Exploitation Planning

• Technique: Flexible Key Construction
• Procedure:
• The script incorporates a mechanism to handle unexpected end-of-file conditions or incomplete key data, facilitating robustness in payload decryption.

Decrypt the payload

    decrypted_payload_data_bytes = decrypt_payload(payload_data, xor_key)
    decrypted_payload_data_bytes = decrypted_payload_data_bytes[:len(decrypted_pa
    decompressed_payload_data_bytes = zlib.decompress(decrypted_payload_data_byte
    print("Decrypted (first 20 bytes):", decompressed_payload_data_bytes[:20])
# Save decrypted payload
with open("payload.dec", "wb") as out:
    out.write(decompressed_payload_data_bytes)
print("Decrypted payload saved as: payload.dec")

if name == "main": main() This stage is the one before the last, where communication with the command and control �C2) server occurs. It begins by generating a 16-byte unique identifier, which will be used to authenticate with the C2 server. Once the C2 confirms the authenticity of the client, the final payload can be retrieved. The unique identifier is constructed by converting the DLL checksum to ASCII, appending "64," and adding ten random characters.

Phase: Defense Evasion

• Technique: Payload Decryption
• Procedure: The threat actor uses a custom function to decrypt the payload:
• Step 1: Decrypt the payload using an XOR key.
• Step 2: Compress the decrypted payload with zlib.
• Step 3: Extract the initial 20 bytes for testing.

Phase: Execution

• Technique: Execution of Decompressed Payload
• Procedure: Once decompressed, the payload is saved to a file:
• Command: Decompressed data is written to payload.dec.

Phase: Command and Control

• Technique: Create Unique Identifier
• Procedure: Generate a unique 16-byte identifier to authenticate with the C2 server:
• Step 1: Convert the DLL checksum to ASCII.
• Step 2: Append "64" to the checksum.
• Step 3: Add ten random characters to the end.

No explicit command lines were provided, but the described behaviors are inferred based on the report details.

It's important to note that Moonstone sleet obscures the final payload, which rarely changes. This is done using a multi-stage loader setup, where each stage triggers the next. To ensure proper execution, a DLL checksum is implemented, preventing it from running in automated analysis environments. In our case, the DLL checksum is utilized to create the Bot ID, which confirms the authenticity of the client and ensures that the payload is only accessed by an authentic client. The 16-byte identifier and the current system time and date is base64 encoded and added as part of a very large string of bytes, that will be sent to the Comamnd and Control(C2) server to autheticate Unfortunately, at the time of this writing, the C2 server is no longer operational, so we're unable to demonstrate how the HTTP POST is formatted. However, I found an excellent report that I will link in the references, which illustrates the network traffic and the structure of the request. After confirming a successful connection by checking the returned status code, the system proceeds to read the available data from the C2 server. The data received is decoded using a non-standard scheme before processing it.

Phase: Initial Access

• Technique: Multi-stage Loader
• Procedure: A multi-stage loader executes sequential stages, each activating the subsequent stage. A DLL checksum is implemented to avoid running in automated analysis environments, ensuring only authentic clients can proceed.

Phase: Execution

• Technique: Dynamic Library Checksum
• Procedure: DLL checksum is used to generate a Bot ID that validates the client, ensuring access only to an authentic user.

Phase: Command and Control

• Technique: C2 Server Authentication via Encoded Data
• Procedure:
• A 16-byte identifier combined with the current system time and date is base64 encoded.
• This data is included in a large byte string sent to the C2 server for authentication.
• Connection success is verified by checking the returned status code.
• Data from the C2 server is then decoded using a non-standard scheme for further processing.

After successful mapping to memory, the DLL entry point is called for proper DLL initialization, and then the targeted export function is called. In a recent research published by the 360 Threat Research Institute, we observed the consistent use of both legitimate and trojanized software. In our case study, we focused on a trojanized version of PuTTY, while the other research analyzed the infection chain of another trojanized legitimate software called IPMsg. This comparison reveals that both attacks share significant similarities at the code level, and they employ the same tactics, techniques, and procedures �TTPs� as well as a multi-stage setup to obscure the final payload. Therefore, it is clear that both attacks were initiated by the same Lazarus group. • blockchain-newtech[.]com �C2 server) • f59035192098e44b86c4648a0de4078edbe80352260276f4755d15d354f 5fc58 �PuTTY installer) • fcb687685f71615c83e9af26087e6036d7dd52a91339ef5c58d3150fd402a 586 �SplitLoader installer | Dropper) • 00433ebf3b21c1c055d4ab8a599d3e84f03b328496236b54e56042cef21 46b1c �SplitLoader first part usrgroup.dat) • d65e05c961107c787310c4f369034b096f9484c328b43140d0eb90820c8 33f9f �SplitLoader second part thumbcache_512.db) • 63fb47c3b4693409ebadf8a5179141af5cf45a46d1e98e5f763ca0d7d64fb 17c �Trojan downloader)

Phase: Initial Access

• Technique: Supply Chain Compromise
• Procedure: A trojanized version of legitimate software, specifically PuTTY, is used to deliver the initial payload.

Phase: Execution

• Technique: DLL Side-Loading
• Procedure: After mapping the DLL to memory, the DLL entry point is called for initialization, followed by invoking the targeted export function.

Phase: Persistence

• Technique: Multi-Stage Loader (SplitLoader)
• Procedure:
• Components Used:
  • Part 1: usrgroup.dat
  • Part 2: thumbcache_512.db

Phase: Command and Control

• Technique: C2 Communication
• Procedure: The compromised software communicates with a C2 server likely hosted at a domain such as blockchain-newtech[.]com.

Phase: Impact

• Technique: Trojan Downloader Deployment
• Procedure: A trojan downloader is deployed as part of the multi-stage infection chain to obscure and execute the final payload.

The decoded data is divided into five parts, separated by the "|" symbol. The data in these five parts respectively represent: the maximum size �KB) of the subsequent DLL execution result transmitted to C2 each time, the length of the encrypted payload that will be received next, the DLL export function name , the DLL checksum similar to the above, and the MD5 hash value of the payload. Next, the payload is received from the C2 server and is MD5 hashed to verify the integrity of the received payload before proceeding with decryption and execution. After verifying its integrity, the payload DLL is decrypted again using a hardcoded HC�256 32-byte key, decompressed, and then reflectively loaded into memory.

Phase: Command and Control (C2) Interaction

• Technique: Data Encoding and Transmission

• Procedure: Data is divided into five parts separated by the "|" symbol. This structure represents:

  1. Maximum size (KB) of the subsequent DLL execution result transmitted to C2.
  2. Length of the encrypted payload to be received.
  3. DLL export function name.
  4. DLL checksum.
  5. MD5 hash value of the payload.

• Technique: Integrity Verification

• Procedure: The payload is received from the C2 server and MD5 hashed to verify its integrity before decryption.

• Technique: Payload Decryption and Loading

• Procedure: After verifying integrity, the payload DLL is decrypted using a hardcoded HC-256 32-byte key, decompressed, and reflectively loaded into memory.

Model: gemini-2.0-flash

Okay, here's an extraction of the TTPs from the report, focusing on the procedures that a red team could emulate:

Phase: Initial Access

• Technique: Spearphishing via Trojanized Software
• Procedure: Distribute a zip archive containing a trojanized PuTTY installer and a text file containing an IP address and password to use.
• Note: The trojanized version triggers the infection upon the user entering the password provided. The provided password is checked against a hardcoded password.

Phase: Execution

• Technique: HC-256 Payload Decryption

• Procedure: Use a hardcoded 32-byte HC-256 key to decrypt a payload.

• Technique: DLL Reflective Loading

• Procedure: Load a DLL into memory via a custom loader. The loading process involves allocating memory equal to the image size, committing the memory, copying headers and sections of the payload, performing relocation fixups, populating the Import Address Table (IAT), and applying section permissions.
• Note: A unique wide string is passed as an argument to the DLL's entry point.

Phase: Persistence

• Technique: Scheduled Task Creation (via COM)

• Procedure: Create a scheduled task using COM to establish persistence.

• Technique: Registry Run Key Persistence

• Procedure: Add an entry to HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run to execute a program on startup.

Phase: Payload Delivery and Execution

• Technique: Second Stage Loader Execution (SplitLoader)

• Procedure:

  1. Decrypt the first stage of SplitLoader using HC-256.
  2. Decompress the first stage of SplitLoader.
  3. Write the second stage (thumbcache_512.db) to disk at %APPDATA%..\Local\Microsoft\Windows\Explorer\thumbcache_512.db.
  4. First 4 bytes from the first loader are XORed with the next stage loader, creating an 8 byte XOR key
  5. thumbcache_512.db is then decrypted with XOR key

• Technique: Exported Function Execution (DLL Checksum)

• Procedure:

  1. Parse and decrypt thumbcache_512.db if executed with the proper arguments: L"%APPDATA%\..\Local\Microsoft\Windows\usrgroup.dat, LoadDllW %APPDATA%\..\Local\Microsoft\Windows\Explorer\thumbcache_512.db \"zjWy\" 4701".
  2. Obtain an executable file handler
  3. Parse the file and extract the necessary information for the next stage
  4. Find the target export function and call it.
  5. The process is called with magic string "4701"

• Technique: Dynamic Function Resolution and Execution

• Procedure: Enumerate a DLL's export table, search for a specific function name ("GetWindowSizedW"), and execute that function.

Phase: Post-Execution and Communication

• Technique: Unique Identifier Generation

• Procedure: Convert the DLL checksum of the previously executed DLL to ASCII, append "64," and then add ten random characters.

• Technique: Base64 Encoding

• Procedure: Encode the 16-byte identifier, the current system time, and date using Base64 encoding.

• Technique: Custom Data Encoding

• Procedure: Use a custom algorithm for decoding data received from the C2. Replace spaces with "+". The decoded data is split into five parts separated by the "|" symbol: maximum DLL execution result size, encrypted payload length, DLL export function name, DLL checksum, MD5 hash value.

Phase: Final Payload

• Technique: Final Payload Execution
• Procedure: Use MD5 hash to verify the integrity of the received payload before proceeding with decryption and execution, using hardcoded HC-256 32-byte key. Then the payload is decompressed and reflectively loaded into memory.

Notes:

• The specific commands for COM scheduled task creation and Run key modification were not provided. A red team would need to select appropriate methods for achieving this.
• The format of the data sent to the C2 server, beyond Base64 encoding, is not fully detailed. The report only mentions a "very large string of bytes".

This structured breakdown should assist a red team in emulating key aspects of the Moonstone Sleet attack. Remember to adapt procedures to your specific environment and toolsets.

Model: gemini-2.5-flash-preview-05-20

Here's a structured analysis of the attack activities by Moonstone Sleet, focusing on procedures, techniques, and tools for red team emulation:

Phase: Initial Access

• Technique: Supply Chain Compromise (Trojanized Software)
• Procedure: Moonstone Sleet delivers a trojanized version of PuTTY, an open-source terminal emulator, via platforms like LinkedIn and Telegram. The target receives a zip archive containing the trojanized installer and a text file with an IP address and password.

Phase: Execution

• Technique: User Execution (with Interactive Password Gate)
• Procedure: The trojanized PuTTY installer triggers infection only when the user enters a specific hardcoded password, validating the target.
• Technique: Code Deobfuscation (Decryption and Decompression)
• Procedure: The next stage payload is decrypted using the HC-256 stream cipher with a hardcoded 32-byte key. After decryption, the data is decompressed.
• Tool: HC-256 (Cipher), zlib (Decompression Library)
• Technique: Reflective Code Loading (DLL Loading)
• Procedure: The decrypted and decompressed DLL payload is loaded into memory without writing to disk:
  1. Memory is allocated with PAGE_READWRITE permissions.
  2. DLL headers and sections are copied into the allocated memory.
  3. Relocation fixups are performed, the Import Address Table (IAT) is populated, and appropriate section permissions are applied.
  4. The DLL's entry point is called, passing a unique wide string for subsequent stages.
• Technique: Installer Module Execution
• Procedure: The in-memory mapped DLL functions as an installer, writing subsequent loader components to disk:
  • The first component, usrgroup.dat, is decrypted using HC-256, decompressed, and written to %APPDATA%\..\Local\Microsoft\Windows\.
  • The second component, thumbcache_512.db, is saved to %APPDATA%\..\Local\Microsoft\Windows\Explorer\.
• Technique: Execution Guardrails / Anti-analysis (DLL Argument Check)
• Procedure: The execution of the usrgroup.dat DLL's export function is enforced to only proceed if specific arguments are passed.
• Procedure: The usrgroup.dat DLL's export function LoadDllW is called with the following arguments: L"%APPDATA%\..\Local\Microsoft\Windows\usrgroup.dat, LoadDllW %APPDATA%\..\Local\Microsoft\Windows\Explorer\thumbcache_512.db \"zjWy\" 4701". These arguments contain paths to the loader components, an XOR decryption key segment ("zjWy"), and a magic string ("4701").
• Technique: Inter-DLL Communication (DLL Export Function Call)
• Procedure: The usrgroup.dat DLL calls the GetWindowSizedW export function of the thumbcache_512.db DLL.

Phase: Persistence

• Technique: Scheduled Task
• Tool: COM ITaskScheduler
• Procedure: A scheduled task is created programmatically using COM ITaskScheduler for persistence before executing thumbcache_512.db.
• Technique: Registry Run Keys
• Procedure: A registry entry named USBCheck is created under HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run to point to the executable payload.

Phase: Command and Control

• Technique: Custom Bot ID Generation
• Procedure: A 16-byte unique identifier is generated for C2 authentication by converting the DLL checksum to ASCII, appending "64", and adding ten random characters.
• Technique: Standard Encoding (Base64)
• Procedure: The 16-byte identifier and the current system time/date are base64 encoded and sent to the C2 server for authentication.
• Technique: Custom Cryptographic Protocol (Data Decoding)
• Procedure: Data received from the C2 server is decoded using a non-standard scheme.
• Technique: Data Parsing
• Procedure: The decoded C2 response data is divided into five parts using the "|" symbol, containing information such as maximum execution result size, encrypted payload length, DLL export function name, DLL checksum, and MD5 hash of the payload.
• Technique: Data Integrity Check (MD5 Hashing)
• Procedure: The received payload from the C2 server is MD5 hashed to verify its integrity before decryption and execution.
• Technique: Multi-Stage Execution / Code Deobfuscation
• Procedure: The final payload DLL is decrypted using a hardcoded HC-256 32-byte key, decompressed using zlib, and reflectively loaded into memory.

Phase: Defense Evasion

• Technique: Trojanized Software
• Procedure: Initial delivery relies on distributing a legitimate software (PuTTY) that has been tampered with.
• Technique: Obfuscated Files or Information (Custom Encryption and Compression)
• Procedure: Payloads are encrypted with HC-256 and compressed with zlib at multiple stages to hinder analysis.
• Technique: Reflective Code Loading
• Procedure: DLLs are loaded directly into memory, avoiding writing them to disk as traditional files.
• Technique: Execution Guardrails / Anti-analysis
• Procedure: Malware execution is gated by a hardcoded password check at the initial stage and by specific argument validation for subsequent DLL stages, hindering automated analysis environments.
• Technique: Multi-Stage Payload Delivery
• Procedure: The attack employs a multi-stage loader setup where each stage triggers the next, obscuring the final payload.
• Technique: Custom Cryptographic Protocol
• Procedure: C2 communication uses a non-standard decoding scheme for received data.