DPRK’s Playbook: Kimsuky’s HttpTroy and Lazarus’s New BLINDINGCAN Variant

In recent weeks, our Threat Labs researchers have uncovered two new toolsets that show just how adaptive the DPRK’s operations have become. Kimsuky, known for its espionage-style campaigns, deployed a new backdoor we’ve named HttpTroy, while Lazarus introduced an upgraded version of its BLINDINGCAN remote access tool. 

Both attacks reveal the same underlying pattern: stealthy code and layered obfuscation. In this post, we’ll break down how these tools work, what they target and what defenders can learn from the latest moves inside the DPRK playbook. 

Inside DPRK’s Latest Campaigns: How Kimsuky and Lazarus Refine Their Playbook 

The Kimsuky attack targeted a single victim in KR and started with a ZIP file that looked like a VPN invoice, then quietly installed tools that let attackers move files, take screenshots and run commands. The chain has three steps: a small dropper, a loader called MemLoad, and the final backdoor, named “HttpTroy”. We see several signs that possibly tie this activity to Kimsuky: the Korean language lure, an AhnLab-style scheduled task name and command patterns seen in past Kimsuky work.  

The Lazarus attack targeted two victims in CA and was caught in the middle of the attack chain, where we observed a new version of the Comebacker malware leading to a new variant of their BLINDINGCAN remote access tool.  

We’ll explain how these attacks work in plain terms, why North Korea-aligned groups use these tricks, and simple steps you can take to avoid similar threats. 

Quick takeaways for readers: do not open any attachments you did not expect, treat .scr files as programs not documents and keep your security software on and updated. 

Diving into the Kimsuky attack: MemLoad and HttpTroy 

The Initial dropper 

While the exact delivery mechanism remains unknown, telemetry indicates that the samples was obtained via an internet download, packaged within a ZIP archive named “250908_A_HK이노션_SecuwaySSL VPN Manager U100S 100user_견적서”. Given the nature of the filename, it is highly probable that the archive was distributed through a phishing email. 

Contained within the archive is a “.scr” file bearing the same name. Execution of this file initiates the entire infection chain. 

This initial sample is a lightweight GO binary containing 3 embedded files. These files are decrypted using a simple XOR operation with the key “0x39”, then written to disk and executed. To maintain user deception, the binary displays a PDF document as a decoy, displaying a fake bill for VPN services, while simultaneously registering the next stage backdoor as a COM server using “regsvr32.exe”. See below an image of the decoy PDF and the decompiled code that decrypts it. 

Stage 1 backdoor: Memload_V3 

The first backdoor, internally identified as Memload_V3 (“Memload_V3.dll”), performs 2 primary functions: 

1. Re-registering the “AhnlabUpdate” scheduled task 

Using COM interfaces instantiated via the Windows API “CoCreateInstance”, the backdoor re-creates a scheduled task named “AhnlabUpdate”, targeting one of the more prevalent anti-virus software in the Korean region to avoid suspicions. This task is configured to execute the current DLL silently using the command “regsvr32.exe /s <CURRENT_FILENAME>”. The task is then set to repeat every minute, using the “PT1M” repetition pattern. 

2. Decrypting and executing the final payload 

After establishing persistence, Memload_V3 proceeds to decrypt the third file dropped by the initial sample. The decryption algorithm used is RC4, and once decrypted, the payload is loaded directly into memory. Execution is then triggered via its exported function named “hello”.

Final payload: HttpTroy backdoor 

The final stage of the attack chain is a highly obfuscated backdoor, internally named HttpTroy (“httptroy_dll.dll”). This component grants the attackers full control over the compromised system, offering a wide range of capabilities: 

• File upload and download
• Screenshot capture and exfiltration
• Command execution with elevated privileges
• Loading an executable in memory
• Reverse shell
• Process termination and trace removal 

HttpTroy employs multiple layers of obfuscation to hinder analysis and detection. API calls are concealed using custom hashing techniques, while strings are obfuscated through a combination of XOR operations and SIMD instructions. 

Notably, the backdoor avoids reusing API hashes and strings. Instead, it dynamically reconstructs them during runtime using varied combinations of arithmetic and logical operations, further complicating static analysis. 

The HttpTroy backdoor communicates with its command-and-control server exclusively via HTTP POST requests. All transmitted data (both commands and responses) is obfuscated using a two-step process: XOR encryption with the key 0x56, followed by Base64 encoding. Each query to the C2 has a specific ID and is followed by buffers of interest, all formatted in a single special string. Commands received from the server follow a simple structure: “<command> <parameters>”. 

After executing a command, the backdoor reports the result to the C2 using ID 2: 

• ok - Successful execution
• fail - Execution failed
• connect ok - Successful reverse shell connection 

To request a new command from the C2, the backdoor sends a query with ID 1. 

Below, you can see an example flow of a command in decompiled code, together with the decryption flow of a response from the server for the “down” command: 

Indicators of compromise 

SCR file: e19ce3bd1cbd980082d3c55a4ac1eb3af4d9e7adf108afb1861372f9c7fe0b76 

Memload_V3: 20e0db1d2ad90bc46c7074c2cc116c2c08a8183f3ac6f357e7ebee0c7cc02596 

HttpTroy: 10c3b3ab2e9cb618fc938028c9295ad5bdb1d836b8f07d65c0d3036dbc18bbb4 

C2: hxxp[://]load[.]auraria[.]org/index[.]php 

User-agent (wide-string): Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36 

Mutexes: 

a:fnjiuygredfgbbgfcvhutrv 

u:fnjiuygredfgbbgfcvhutrv 

Analysis of the Lazarus Attack: the comeback of Comebacker and the new BLINDINGCAN variant 

Comebacker, yet again 

During routine threat monitoring, our team identified a sample indicative of a new variant of the previously documented Comebacker malware, which is attributed to the Lazarus APT group. While our telemetry captures the infection chain from this stage onward, the initial access vector remains unclear. However, based on the absence of any exploited vulnerabilities, we assess with moderate confidence that the initial compromise likely originated from a phishing email. 

We observed two closely related instances of the Comebacker malware: 

• A DLL variant located at “C:\ProgramData\comms.bin” (internally named “NetSvcInst_v1_Rundll32.dll”, using the exported function “InfoHook”)
• An EXE variant located at “C:\ProgramData\Comms\ssh.bin” 

The DLL sample appears to have been executed via a Windows service, whereas the EXE variant was launched through cmd.exe, suggesting a different execution context. 

Despite their differing formats, both variants share identical functionality. Their primary objectives include: 

• Validating execution via a specific command-line parameter
• Decrypting embedded payloads
• Configuring registry entries
• Deploying the next-stage payload as a service 

The dropper's behavior can be summarized in the following stages: 

1. Dynamic function resolution 

Prior to payload execution, the malware dynamically resolves API functions from system DLLs. This is achieved by XOR-decrypting hardcoded strings using a PRNG-like stream.

2. Parameter validation 

Execution is gated by the presence of specific command-line arguments. The DLL variant expects "up45V3FR9ee9", while the EXE variant requires "760H33ls9L5S". If the parameters are incorrect, the malware terminates. 

3. Service name selection 

The malware enumerates the “REG_MULTI_SZ” entries under “HKLM\ SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost\netsvcs”, identifying service names that are listed but not yet registered under “HKLM\ SYSTEM\CurrentControlSet\Services”. A random candidate is then selected and reused as both the service name and the name of the service DLL. 

For some of the string decryption processes, it uses the HC256 stream cipher, while for others it uses RC4. 

4. Timestamp logging 

The malware writes the current local time to “C:\Windows\system32\AppxProvision.xml” using the format “[%04d-%02d-%02d %02d:%02d:%02d] %s\n”, appending the chosen service name. It then modifies the file’s attributes to mimic those of win32k.sys.

5. Payload deployment and configuration 

The embedded PE file is decrypted using HC256, then decompressed via zlib, and written into a decoy file in the current directory named “kjepl.xml”. To obfuscate its true size, random data is appended at the end. The file is then moved via “cmd.exe” to “C:\Windows\system32\<SERVICE_NAME>.dll”, and its attributes are altered similarly to the timestamp file, but this time it mimics “cmd.exe”. 

Subsequently, the embedded configuration is decrypted using HC256, re-encrypted using RC4 and stored as a binary blob in the registry under  “HKLM\SYSTEM\ControlSet001\Services\kbddes\GUID”. The configuration includes potential C2 addresses, the path to cmd.exe, the path to the dropped DLL, %TEMP%, and a special integrity-check value. 

6. Service execution 

Finally, the malware registers and starts a service using the randomly selected name, thereby initiating the next stage of the attack. 

Second stage: Compcat_v1.dll 

Both observed variants of the Comebacker dropper deploy the same service binary, internally named “Compcat_v1.dll”. This component serves a singular purpose: it acts as a wrapper for the final payload. 

Upon execution, it decrypts an embedded PE file using the HC256 stream cipher. The decrypted data is then decompressed using the miniz library, a lightweight zlib-compatible implementation. The resulting PE is loaded directly into memory, employing a technique similar to that used by the aforementioned MemLoad sample. 

Once the payload is successfully mapped into memory, the malware invokes the exported function “OPENSLL_NONPIC”, thereby initiating the execution of the final stage. 

Final payload: new variant of BLINDINGCAN 

As the final payload, the attackers employed a new variant of their BLINDINGCAN remote access tool, improved with additional cryptographic elements and more capabilities. Internally named “T_DLL64.dll”, it acts as a complete suite for attackers, offering them the possibility to perform any action they desire. 

The backdoor has 2 operating modes, which are dictated by the parameter passed to the main function: 

• 13398 – config stored in a file
• 13399 – config stored in registry 

Apart from the “OPENSSL_NONPIC” export, this sample exports another function, called “MemLoad”, which uses the other operating mode (13398). 

The malware’s execution begins by dynamically loading APIs, using the same techniques as in the previous cases. It then moves on to loading the configuration, picking a C2 at random and attempting to connect to it. 

Next, it attempts to authenticate itself within the chosen C2 by sending a “GET” request with the integrity-check value from the config, followed by 4 random uppercase letters. This newly obtained value is then shifted with a random offset between 0 and 9 (which is appended at the end of the buffer), XOR-encrypted with 0xC6 and Base64-encoded before being sent. To add to the authenticity of the request, the malware also sends additional buffers of key-value pairs filled with random values. 

If the authentication succeeds, it proceeds to generate RSA-2048 keys for encryption. The public key is then sent to the C2 in a similar fashion. The same operations regarding the config integrity-check value are performed, and their value represents the beginning of the data. Following that, the values 23, 0, and the size of the public key are appended before the public key (separated by spaces), then encrypted with HC256 and the same XOR + Base64 combo as before. Similar randomness is added after, and the request is sent as such. 

From the response, the malware obtains some RSA-encrypted values, that are then decrypted and will serve in future communications as key and IV for encryption via the EVP interface. 

Due to the functions used in the structure that contains the “evp_cipher_st” struct for the encryption functions, we conclude that the encryption used is AES-128-CBC. 

Subsequently, the malware enters its main command loop, constantly communicating with the C2 and executing the commands of the attackers. 

The communication pattern to the C2 is now as follows: 

1. Join by space 2 per-command specific values and the size of the data to be sent
2. First parameter is the command ID

3. Second parameter represents the status of the command

   1 – Success sending regular chunk (for streamed buffers – typically 100KB chunks)

   2 – Error

   3 – Success sending end chunk (if the buffers are not streamed, this value is used)

4. Append the data and AES-128-CBC encrypt everything
5. String-shift the same config token + 4 random letters by a random value (0-9) appended at the end, then XOR+Base64 encode it
6. Compute MD5 of the encrypted payload and append the encrypted data after the hash, then XOR+Base64 encode it
7. Build the base request data as “<RANDOM_2_LETTERS>=<XOR+BASE64(SHIFTED_TOKEN || 4_RANDOM_LETTERS) || SHIFT_OFFSET>&<RANDOM_4_LETTERS>=<RANDOM_4_OR_5_LETTERS>&<RANDOM_5_LETTERS>=<XOR+BASE64(MD5 || ENCRYPTED_DATA)>”
8. Append a random amount of random key-value pairs after the base data 

In similar fashion, responses are XOR + Base64 decoded, integrity-checked using MD5, and AES-128-CBC decrypted in case of a match. 

Continuing, we will describe the functionalities of the RAT: 

• Command ID 1
  • Exfiltrate file, starting from an offset and compressing it
  • Input: <SRC_PATH>|<OFFSET>
  • Chunked
• Command ID 2
  • Downloads a file from the C2
  • Input: <DEST_PATH>|<SIZE_OF_DATA_BLOCK>|<BYTES_TO_WRITE
  • Chunked
• Command ID 3
  • Copies a file to %TEMP% and exfiltrates it from there
  • Input: <SRC_PATH>|<OFFSET>
  • Chunked
• Command ID 4
  • Securely delete a file by overwriting it and renaming it multiple times
  • Input: <FILE_PATH>
  • Not chunked
• Command ID 5
  • Changes a file’s attributes to mimic another file
  • <DEST_PATH>|<SRC_PATH>
  • Not chunked
• Command ID 6
  • Recursively traverses all sub-directories and files from a given path, also reporting their size
  • Input: <SRC_DIR_PATH>
  • Not chunked
• Command ID 7
  • Traverses the entire file system, listing the empty space from drives, files and their attributes
  • Chunked
• Command ID 8
  • Gathers data from the victim computer, such as locale info, computer name, OS version, MAC address, network adapters, CPU architecture, OEM code page
  • Not chunked
• Command ID 9
  • Runs a command-line via CreateProcessW
  • Input: <CMDLINE>
  • Not chunked
• Command ID 10
  • Runs a command-line in a given session via CreateProcessAsUserW
  • Input: <CMDLINE>|<SESSION_ID>
  • Not chunked
• Command ID 11
  • Lists active processes (provides EXE name, full image path, PID, PPID, SID, user and creation time)
  • Chunked
• Command ID 12
  • Kills a process
  • Input: <PROCESS_ID>
  • Not chunked
• Command ID 13
  • Keep alive request
  • Not chunked
• Command ID 14
  • Sleeps for a given period, checking for early wake conditions such as new drives or sessions every 5 seconds
  • Input: <SLEEP_DURATION>
  • Not chunked
• Command ID 15
  • Hibernate for a given period, checking for early wake conditions every minute
  • Input: <HIBERNATION_DURATION>
  • Not chunked
• Command ID 16
  • Updates the config from the binary’s current config
  • Not chunked
• Command ID 17
  • Send the current config from the binary to the C2
  • Not chunked
• Command ID 18
  • Removes traces, securely deletes itself and terminates itself
  • Not chunked
• Command ID 19
  • Test TCP connection to a given IP address
  • Input: <IP>:<PORT> <TIMEOUT>
  • Not chunked
• Command ID 20
  • Runs cmd.exe with the provided command line and reports back the output
  • Input: <COMMAND_LINE>
  • Chunked
• Command ID 21
  • Changes the current working directory
  • Input: <DIR_PATH>
  • Not chunked
• Command ID 22
  • Obtains the current working directory
  • Not chunked
• Command ID 23
  • Updates encryption keys with new values
  • Not chunked
• Command ID 24
  • Takes a screenshot and sends it to the C2
  • Chunked
• Command ID 25
  • Enumerate or take a photo from the available video capture devices using COM interfaces; in the case of GETPIC, the resulting buffer is compressed
  • Input: <GETLIST> or <GETPIC> <INDEX>
  • Not chunked
• Command ID 26
  • Runs a PE file in memory
  • Input: <SIZE>|<EXPORT_NAME>|<ARGUMENT>|<MD5_OF_PE>
  • Chunked
• Command ID 27
  • Updates the config with data from the C2
  • Input: <NEW_CONFIG_BYTES>
  • Not chunked 

Indicators of compromise 

new Comebacker variants: 509fb00b9d6eaa74f54a3d1f092a161a095e5132d80cc9cc95c184d4e258525b  

b5eae8de6f5445e06b99eb8b0927f9abb9031519d772969bd13a7a0fb43ec067   

Service binary: 368769df7d319371073f33c29ad0097fbe48e805630cf961b6f00ab2ccddbb4c  

new BLINDINGCAN: c60587964a93b650f3442589b05e9010a262b927d9b60065afd8091ada7799fe 

C2s:  

hxxp[://]166[.]88[.]11[.]10/upload/check.asp 

hxxps[://]tronracing[.]com/upload/check.asp 

hxxp[://]23[.]27[.]140[.]49/Onenote/index.asp 

Conclusion 

Kimsuky and Lazarus continue to sharpen their tools, showing that DPRK-linked actors aren’t just maintaining their arsenals, they’re reinventing them. These campaigns demonstrate a well-structured and multi-stage infection chain, leveraging obfuscated payloads and stealthy persistence mechanisms. From the initial stages to the final backdoors, each component is designed to evade detection, maintain access and provide extensive control over the compromised system. The use of custom encryption, dynamic API resolution and COM-based task registration/services exploitation highlights the groups’ continued evolution and technical sophistication. Monitoring for these indicators and behaviors is essential for early detection and mitigation of such threats. 

By tracking every line of code and every new variant, we help surface the patterns that keep defenders one step ahead. Awareness, collaboration, and constant vigilance are what turn technical insights into real-world protection — and that’s where Gen Threat Labs and our global intelligence network can make a difference.