Analysis of attack activities of Moonstone sleet a division of APT-C-26 (Lazarus) group

APT-C-26 (Lazarus)

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 MSTIC. 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 Diamond sleet.

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.

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 MSTIC.

The whole point is to show the consistent usage of trojanized software and code reuse across different attacks linked to the MoonStone Sleet group.

Analysis of attack activities

1.Trojanized PuTTY analysis

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.

DLL Reflective Loading

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.

2.Analysis of SplitLoader Installer

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.

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(thumbcache_512.db), 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.

3.Analysis of usrgroup.dat(First part of SplitLoader)

The execution of the first part DLL(usrgroup.dat) was setup in a very special and dependent way such that the next part thumbcache_512.db 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 thumbcache_512.db, and lastly the same magic wide string "4701" 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.

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 thumbcache_512.db, extracting, decrypting, and decompressing the next stage.

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]} <path_to_encrypted_next_stage>")
        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()}")

        # Decrypt the payload
        decrypted_payload_data_bytes = decrypt_payload(payload_data, xor_key)
        decrypted_payload_data_bytes = decrypted_payload_data_bytes[:len(decrypted_payload_data_bytes) - 0x108]
        decompressed_payload_data_bytes = zlib.decompress(decrypted_payload_data_bytes)
        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()

4.Trojan loader analysis

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.

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.

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.

After successful mapping to memory, the DLL entry point is called for proper DLL initialization, and then the targeted export function is called.

5.Attibution analysis

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.

6.IOCs

• blockchain-newtech[.]com (C2 server)

• f59035192098e44b86c4648a0de4078edbe80352260276f4755d15d354f5fc58 (PuTTY installer)

• fcb687685f71615c83e9af26087e6036d7dd52a91339ef5c58d3150fd402a586 (SplitLoader installer | Dropper)

• 00433ebf3b21c1c055d4ab8a599d3e84f03b328496236b54e56042cef2146b1c (SplitLoader first part usrgroup.dat)

• d65e05c961107c787310c4f369034b096f9484c328b43140d0eb90820c833f9f (SplitLoader second part thumbcache_512.db)

• 63fb47c3b4693409ebadf8a5179141af5cf45a46d1e98e5f763ca0d7d64fb17c (Trojan downloader)

7. References

• https://mp.weixin.qq.com/s?__biz=MzUyMjk4NzExMA==&mid=2247505438&idx=1&sn=cf1947c7af6581f4a66460ae6d14dc2f

• https://lazarus.day/media/post/files/2023/11/13/2023-11-10_%E1%84%89%E1%85%A1%E1%86%BC%E1%84%89%E1%85%A6_%E1%84%87%E1%85%AE%E1%86%AB%E1%84%89%E1%85%A5%E1%86%A8_%E1%84%87%E1%85%A9%E1%84%80%E1%85%A9%E1%84%89%E1%85%A5%E1%84%8B%E1%85%A1%E1%86%A8%E1%84%89%E1%85%A5%E1%86%BC%E1%84%8F%E1%85%A9%E1%84%83%E1%85%B3%E1%84%85%E1%85%A9_%E1%84%83%E1%85%AE%E1%86%AB%E1%84%80%E1%85%A1%E1%86%B8%E1%84%92%E1%85%A1%E1%86%AB_Putty.pdf

• https://www.microsoft.com/en-us/security/blog/2024/05/28/moonstone-sleet-emerges-as-new-north-korean-threat-actor-with-new-bag-of-tricks/