Operation Capsule Vault: RokRAT Attack Chain Analysis Using EMBED_PAYLOAD_v2

◈ Key Findings

• Initial access was carried out through spear-phishing emails disguised as materials for actual academic events and seminars.
• Although the file was disguised as a PDF, it actually delivered a malicious ISO file through a cloud storage link.
• The ISO contained an executable disguised as a PDF document, using the ".pdf", ".pif" extension to induce the user to run it.
• The attack loaded the shellcode payload into memory and injected a RokRAT variant into a process.
• EDR and threat hunting policies should be strengthened to detect correlated ISO and PIF execution behaviors.

1. Overview

Genians Security Center recently identified spear-phishing activity impersonating the distribution of materials for an academic event.

This attack is assessed to be a targeted campaign against individuals working in specific research, policy, and academic fields. It is characterized by sophisticated social engineering that leveraged information from an event that was actually held.

[Figure 1-1] Attack Flow

The threat actor wrote the email by abusing the name of an actual publicly disclosed event and the format used to distribute event materials. The email was structured so that recipients would perceive it as part of normal work or research activity. The email subject and body used a format similar to legitimate event notices and material distribution emails, and the threat actor attempted to increase credibility by disguising the event as one jointly hosted by related organizations.

In particular, this attack was confirmed to have increased its effectiveness by using information from an actual publicly disclosed event, rather than creating a fake event or fabricated document. This approach can be viewed as a representative social engineering technique that lowers the recipient’s suspicion and increases the likelihood of malicious file execution.

Analysis confirmed that the threat actor used a cloud-based file-sharing service to distribute the malicious file and induced the user to execute it by using a filename and format that could be mistaken for a legitimate document. The attack also used a decoy document technique that performed normal document viewing and malicious activity at the same time, making it difficult for the user to recognize the infection.

The malware used in the attack has a multi-stage structure that displays a normal document while executing an additional payload in memory. It was confirmed to perform subsequent malicious activity through process injection. An attempt to evade user recognition and detection by security solutions was also observed by combining a normal file format with an executable file format.

Genians Security Center has named this attack activity "Operation Capsule Vault". This name was derived from the structural characteristics of the PIF executable used in the attack, which stores a normal PDF document and an additional malicious payload together inside the file, then sequentially extracts and uses them during execution.

In particular, the EMBED_PAYLOAD_v2-based structure embeds multiple objects inside a single file and ultimately loads the RokRAT payload into memory to perform subsequent malicious activity. Capsule refers to a container structure that contains various objects inside it, while Vault refers to a storage form that conceals a normal document and malicious components. The operation name reflects these characteristics of the attack chain.

This threat intelligence report focuses on the analysis of the spear-phishing email, social engineering techniques, distribution structure, malicious executable structure, embedded payload, process injection behavior, and major tactics, techniques, and procedures (TTPs). It also provides key indicators of compromise (IoCs) identified during the analysis and EDR detection methods.

This report is not limited to the analysis of a single malicious file. It was prepared based on the full attack chain, including the social engineering technique that abused information from an actual event and the multi-stage payload structure. It is expected to support stronger detection and response capabilities against similar targeted attacks in the future.

2. Threat Analysis 

2-1. Initial Access

Initial access begins through a spear-phishing email. On June 22, 2026, the threat actor sent emails to individuals working in research, policy, and academic fields, disguising them as notices for the distribution of materials from an actual academic event. The content was structured so that recipients would recognize the email as normal work-related material.

[Figure 2-1] Spear-Phishing Email Screen

The email subject and body were written based on actual publicly disclosed event information and used a general notice format for delivering event materials. The content used in the attack was introduced as materials related to the academic conference titled "Why Wonsan-Kalma Tourism Now?", which was held at the Seoul COEX on June 12, 2026.

Wonsan-Kalma is a representative tourism development area on North Korea’s east coast. The threat actor created the decoy document by partially abusing publicly disclosed event information from the actual academic conference, including the event name, topic, and host organization.

In addition, the sender impersonated a separate company in the unification field, disguising the email as a normal business notice. Through this, the threat actor attempted to mislead recipients into mistaking it for official materials related to the actual event and induce them to check the attached file.

To the user, it appears as though a PDF material booklet is attached. In reality, however, a download link to a file uploaded to Dropbox is provided. When the user clicks the item recognized as an attachment, the user is redirected to Dropbox cloud storage, after which an ISO image file is downloaded.

The downloaded ISO file uses a filename similar to that of the seminar material booklet, making it appear to be a normal document. In addition, the ISO contains a file that appears to be a PDF document, inducing the user to execute the file while believing that they are opening the material booklet.

[Figure 2-2] View Inside the ISO Image File

The actual file is an executable disguised as a document format. It is designed to obscure its executable nature by using a PDF-like filename and icon. Notably, the attack was confirmed to abuse the fact that file extensions are not displayed by default in the Windows environment to lower the user’s suspicion.

This method is a social engineering technique that combines actual event information with the normal process of delivering work-related documents. It is used as an initial access method to induce the user to directly execute the malicious file. As a result, the PDF-disguised executable inside the ISO serves as the initial loader for performing subsequent malicious activity.

2-2. Attachment Analysis

The ISO image file used in the attack contains an executable disguised as a PDF document. The name of the file executed by the user follows the same format as a PDF document, but its actual extension was confirmed to be PIF (Program Information File).

A PIF file is a file format used in early Windows environments to configure the execution environment for MS-DOS-based programs. It was originally used to store information such as memory settings, screen mode, and the startup directory when running a program. In modern Windows environments, however, it is treated as an executable file. Because of this characteristic, threat actors have frequently abused PIF files as a means of disguising executables as documents.

In particular, Windows environments may not display extensions for known file types depending on the default settings. In this case, the user may recognize the filename as a PDF document, but in reality, they execute an executable file. The threat actor abuses this user environment to increase the likelihood of malicious file execution.

The PIF file was confirmed to have been created as a multi-stage loader rather than a simple executable. The file contains "dropper_stub.pdb" information and embeds a separate payload, which is extracted during execution before subsequent operations are performed.

• D:\project\pif\pif\x64\Release\dropper_stub.pdb
  
  

Analysis of the file structure found that the executable contains an embedded data area based on the "EMBED_PAYLOAD_v2" string, and this area stores information for multiple payloads. After execution, the program reads itself again, parses the payload table embedded inside the file, and processes each data item sequentially.

[Figure 2-3] EMBED_PAYLOAD_v2 Marker

The payload table identified during the analysis contained a total of two entries. The first entry is a normal PDF document, and the second entry consists of a separate binary payload. The filename length for each entry is declared as 8 bytes.

For reference, the build time (TimeDateStamp) was confirmed to be 2025-10-15 10:43:24 (KST). However, the PDF document embedded in the PIF file uses materials from an actual academic event held in June 2026, creating a time discrepancy between the PIF build time in October 2025 and the creation period of the PDF decoy document.

Accordingly, this build time is highly likely to have been arbitrarily manipulated by the threat actor to interfere with analysis or conceal the actual creation time.

[Figure 2-4] Payload Table

When the normal PDF document is executed, the contents of the actual academic event material booklet are displayed on the screen, leading the user to believe that they have opened a legitimate document. During this process, extraction and execution of the second payload proceed simultaneously in the background, making it difficult for the user to recognize that the malware has already been executed.

In other words, displaying a normal document together is a typical decoy technique used to minimize user suspicion and conceal malicious activity. It combines social engineering with malware execution to reduce the likelihood of detection.

[Figure 2-5] Execution of the Normal Decoy Document

2-3. Shellcode Analysis

As confirmed in the previous section, the second embedded payload included inside the executable is a shellcode binary saved under the filename "yanfirst64.bin". This payload is not an independent executable file. Instead, it is included inside the executable as binary data and is restored into memory during program execution.

After parsing the EMBED_PAYLOAD_v2 payload table, the executable sequentially reads the file size and data of the second entry and loads them into a memory buffer. It then restores the shellcode data into a contiguous memory region. During this process, the shellcode is not created as a separate file on disk and is handled only in memory.

[Figure 2-6] Embedded Shellcode Reading Process

Analysis found that the shellcode does not directly execute the encrypted payload. Instead, it first uses the Call-Pop technique to calculate the XOR key and the starting position of the encrypted data.

The Call-Pop technique uses the return address stored on the stack by the call instruction to identify the location of the currently executing code, then adds a specific offset to calculate the starting position of the data contained inside the program.

This technique is widely used as a position-independent code implementation method that allows internal data to be referenced properly even when the code is loaded at different memory addresses depending on the execution environment.

[Figure 2-7] Shellcode XOR Decoding Process

The analyzed shellcode adds 0x0C to the return address to calculate the start address of the data area where the XOR key is stored. It then uses the XOR key (0x29) stored in the first byte to sequentially decrypt the entire encrypted payload.

After decryption is completed, the payload is mapped into memory and restored into an executable form. The malware then performs process injection.

First, it calls the CreateToolhelp32Snapshot() API to enumerate the list of processes running on the system, then uses Process32NextW() to search for the "explorer.exe" process.

Once the target process is identified, it obtains a process handle through OpenProcess() and calls VirtualAllocEx() to allocate an executable memory region with PAGE_EXECUTE_READWRITE permissions inside "explorer.exe".

The restored payload is then copied to the allocated remote memory region using WriteProcessMemory(). The malware subsequently uses LoadLibraryW() and GetProcAddress() to dynamically obtain the address of RtlCreateUserThread() in ntdll.dll, then creates a remote thread and executes the previously allocated memory region as the start address.

As a result, the malware runs inside "explorer.exe", a legitimate Windows process, without creating a separate process. This is a representative process injection technique that uses a legitimate process to perform malicious activity. It makes it difficult for the user to recognize that a new malicious process has been created and is also used to evade behavior-based detection by some security products.

Analysis confirmed that the payload ultimately executed in the "explorer.exe" process is an x64-based RokRAT variant. It was analyzed to perform subsequent malicious activities, including collecting information from the infected system and communicating with cloud-based command-and-control (C2) infrastructure.

2-4. RokRAT Variant Analysis

Analysis of the final payload executed through process injection confirmed that the malware is a RokRAT variant that operates in an x64 environment. In the main function of the decrypted payload, the malware first initializes the internal environment required for execution and configures the objects needed for C2 communication before conducting full-scale information collection or command execution.

During the initialization process, it generates an internal identifier used for session identification. It also collects the operating system version, computer name, user account, executable file path, and executable file version information, then stores them in an internal structure.

In addition, it generates a system-specific identifier based on SMBIOS (System Management BIOS) and system information, then uses this identifier to configure the execution environment required for cloud-based C2 communication. SMBIOS is a specification designed to provide system hardware and BIOS-related information in a standardized data structure. The malware uses it to collect system-specific information and identify victims.

[Figure 2-8] SMBIOS Check Routine

After the initial environment configuration is completed, the malware initializes cloud objects that support pCloud, Dropbox, and Yandex Cloud services to prepare for C2 communication. During analysis, strings related to the REST APIs of all three cloud services were identified. The execution flow is implemented to initialize each service object and then select an available cloud storage service.

In particular, two OAuth access tokens related to Yandex Cloud are hardcoded inside the malware. The malware is designed to attempt a connection using the first token and, if communication fails, sequentially use the second token. This failover method is assessed to be intended to maintain cloud-based C2 communication using alternate authentication information even when a specific token has been revoked or is unavailable.

As of the time of analysis, the first token was successfully authenticated, while the second token returned an UnauthorizedError, confirming that it is currently unavailable.

The two access tokens were also confirmed to have been used in RokRAT-family attacks publicly disclosed in 2025. The cloud-based C2 structure that simultaneously supports pCloud, Dropbox, and Yandex also matches the characteristics of previously disclosed APT37 RokRAT-family activity.

[Figure 2-9] Yandex Token Key

• y0__xCvwqD6BxiitDUgtK7BqRJKUd5n0zFOnE5JA1vpobhCHkgkZg
• y0__xCgjYyMBxjIhDUgqp2umhIg72AOcJ1RXdfk-fIWhJrHtL7_Iw

After initializing the cloud objects, the malware generates HTTP requests according to the REST API format of each service. In the pCloud upload function, the multipart/form-data format is used, and the Boundary string "--wwjaughalvncjwiajs--" was confirmed to be hardcoded.

This Boundary string is a representative identifier repeatedly observed in previously disclosed RokRAT analysis cases, and it is used in the same way in this variant.

The HTTP request generation routine also includes the Googlebot/2.1 User-Agent string, which is assessed to be used to disguise the traffic as normal search engine traffic.

[Figure 2-10] pCloud Upload Multipart Boundary String

Once the C2 connection is established, the malware requests a command object using the "/Program/<VictimID>" path. The collected information and screen capture data are uploaded using the "/Comment/" path. This shows a structure in which the command reception channel and data upload channel are operated separately.

The received commands are processed through a mixed branching structure that combines ASCII code range comparisons, rather than a simple switch statement. The "0" command disables the screen capture function, while "i" enables it. The "j" and "b" commands reflect command processing completion on the server and then immediately terminate the process.

The "d" command decrypts an obfuscated deletion command and executes it through "cmd.exe". This command uses the first byte of the input string as the decryption key, then extracts only the lower byte at 2-byte intervals from the obfuscated string stored in UTF-16 format.

Each ciphertext byte is decrypted using the cipher_byte - key method, and the decrypted result is sequentially stored in the output buffer.

Therefore, with the key value 0x23, 0x87 - 0x23 = 0x64 is decrypted into the character "d". This performs a cleanup function by deleting malicious files and related traces used in the attack, including ".VBS", ".CMD", ".BAT", and ".LNK" files created in "%APPDATA%" and the Startup folder, thereby removing autorun traces. After executing the deletion command, the malware waits for approximately 10 seconds and then calls ExitProcess() to terminate the process.

[Figure 2-11] Decryption Routine of the "d" Command

The "g" command simply updates the server with the command completion status and returns without performing any additional functions. The "h" command enumerates the system’s logical drives and collects file lists. It uses the GetLogicalDriveStringsA API to identify removable drives, fixed disks, and network drives, then runs the "dir /A /S" command for each drive to create a full file list as "%TEMP%[DriveLetter]_.TMP".

The generated file is then sent to the cloud C2 through the common upload routine. After the transfer is completed, the temporary file is deleted to remove the intermediate artifact created during the collection process.

The "e" command executes operating system commands through "cmd.exe", while the "c" command searches for and collects files from a specified path. The file collection function uses the FindFirstFileW and FindNextFileW APIs to recursively search the specified directory, then converts filenames to uppercase and compares extensions to select target files.

The collection mode supports three options: Normal, All, and user-defined extensions. In user-defined mode, up to 20 extensions separated by semicolons (;) can be specified. In Normal mode, files are selected and collected based on the default extension list hardcoded in the malware: ".XLS", ".DOC", ".PPT", ".TXT", ".M4A", ".AMR", ".PDF", and ".HWP".

[Figure 2-12] File Collection Target Routine

Commands from "1" to "4" operate in a fileless manner. After decrypting and verifying the encrypted payload, the malware allocates executable memory with VirtualAlloc and executes it directly from memory using CreateThread.

In contrast, commands from "5" to "9" create the "%TEMP%\KB400928_doc.exe" path, decrypt and verify the entire payload using a key generated by XORing the first byte of the payload with 0x4D, save the decrypted data as the "KB400928_doc.exe" file, and execute it using ShellExecuteA.

"KB400928_doc.exe" is a filename that has been continuously used in previous RokRAT variants, showing the reuse of the same filename.

The process information collection function operates as an independent information collection routine, separate from the switch-based command system that handles C2 commands. This function uses the CreateToolhelp32Snapshot, Process32NextW, OpenProcess, K32EnumProcessModules, and K32GetModuleFileNameExW APIs to iterate through running processes, collect each process’s PID, process name, and full executable path, and store them in a single buffer.

The code also includes the "360Tray.exe" string, associated with Qihoo 360 Total Security, a Chinese security vendor, along with a wcsicmp() comparison. This matches one of the characteristics continuously observed in previous RokRAT variants. This string is likely to have been inserted to imply a connection to China or to confuse analysis.

[Figure 2-13] "360Tray.exe" String Comparison Routine

Overall, this variant is a RokRAT-family malware that performs a wide range of functions, including initial environment configuration, Victim ID generation, system information collection, cloud-based C2 initialization, separation of command and data channels, screen capture, process and drive information collection, document file collection, memory-based payload execution, and disk-based execution of additional payloads.

In particular, the cloud C2 structure supporting pCloud, Dropbox, and Yandex, the "--wwjaughalvncjwiajs--" Boundary string, and the Yandex OAuth token operation method match representative characteristics repeatedly observed in previously disclosed APT37 RokRAT-family activity.

3. Threat Attribution 

3-1. Correlation Analysis

A lookup of the account information for the Yandex OAuth token used by the malware identified the account "philp.stwart", which was registered on February 20, 2025 (UTC).

The same account was also identified in "Operation Artemis: Analysis of HWP-Based DLL Side Loading Attacks", published on December 22, 2025. Taken together, these findings indicate that the threat actor likely continued to operate the same Yandex cloud account.

[Figure 3-1] Yandex Account Subscriber Information

The key information identified in this threat actor’s attack activity from 2025 to the present is as follows.

• johnson8903013@gmail.com
• 5.180.208[.]57 (US) - Clouvider
• 5.180.208[.]60 (US) - Clouvider
• 89.147.101[.]197 (KR) - Nord VPN
• 89.187.161[.]220 (JP) - Astrill VPN
• 160.238.37[.]95 (KR) - Nord VPN
• 160.238.37[.]100 (KR) - Nord VPN
  
  

The above information represents part of the indicators of compromise identified as being used by the threat actor during spear-phishing attacks and in the establishment and operation of attack infrastructure. It can be used to detect and respond to the same or similar attack activity in the future.

Analysis of the identified IP addresses also found that some of them were exit nodes for commercial VPN services such as NordVPN and Astrill VPN. This indicates that the threat actor likely carried out the attack while hiding the actual origin IP address through VPN services.

[Figure 3-2] IP Information Lookup Screen

In addition, a comparative analysis between the RokRAT sample identified in Operation Artemis, which used an HWP-based DLL side-loading attack technique in 2025, and the “Operation Capsule Vault” variant found a high level of overall code similarity in the internal function call flow, command processing structure, string decryption method, cloud C2 operation method, and implementation of key functions.

[Figure 3-3] RokRAT Similarity Comparison Screen

These analysis results support the possibility that this variant was developed based on the same codebase as existing RokRAT-family malware and was created by reusing existing source code or core modules.

In particular, a high level of code similarity with existing RokRAT variants was found in key components, including the internal function call flow, command processing structure, string decryption method, cloud-based C2 operation method, file collection, and payload execution functions.

However, code similarity alone is not sufficient to conclude that it was created by the same developer or the same threat actor.

Threat attribution should be determined by comprehensively reviewing not only the malware codebase, but also attack infrastructure, operational accounts, cloud C2 configuration, indicators of compromise (IoCs), tactics, techniques, and procedures (TTPs), victimology, campaign correlation, and other cyber threat intelligence (CTI) information.

In this analysis, we comprehensively compared and analyzed the high code similarity with existing RokRAT variants, the cloud-based C2 structure using pCloud, Dropbox, and Yandex, signs of continued use of the same Yandex account, the Yandex OAuth token operation method, code and functional similarities with the RokRAT sample identified in the previous Operation Artemis case, and the identified attack infrastructure and TTPs.

Based on these technical grounds, “Operation Capsule Vault” is assessed as highly likely to have been conducted by the APT37 group.

4. Conclusion

4-1. Threat Analysis Conclusion

This report analyzed the full attack chain of a new targeted attack campaign.

The key characteristic of this attack is its use of an EMBED_PAYLOAD_v2-based multi-stage loader structure. The attack induces the user to execute a file through a spear-phishing email disguised as the distribution of materials from an actual academic event, then embeds both a normal document and a malicious payload inside a PIF executable disguised as a PDF document.

The user believes they are viewing legitimate academic materials, while in the background, embedded payloads are sequentially extracted and, after process injection, RokRAT is ultimately executed in memory.

Genians Security Center named this attack Operation Capsule Vault, reflecting its structural characteristic of storing a normal document and multiple malicious objects together inside a single executable and using them sequentially during execution.

This attack is assessed as a case in which the existing RokRAT family strengthened its detection evasion capabilities by combining social engineering techniques that abuse an actual academic event with an embedded loader structure.

In particular, the structure that stores a normal document and malicious payload together inside a single executable and processes them sequentially in memory is highly likely to continue being used in similar targeted attacks.

Therefore, it is necessary to strengthen not only IoC-based detection, but also behavior-based response capabilities that can correlate and detect the full attack flow, including spear-phishing emails, ISO-based distribution, PIF execution, process execution flow, cloud-based C2 communication, and memory-based payload execution.

4-2. "Genian Insights E"-Based Integrated Response Strategy

This threat consists of a multi-stage attack chain that begins with a spear-phishing email disguised as the distribution of materials from an actual academic event, followed by ISO image distribution through Dropbox, a PIF executable disguised as a PDF document, embedded payload extraction based on EMBED_PAYLOAD_v2, shellcode decryption, process injection into "explorer.exe", and execution of the cloud-based RokRAT payload.

In particular, the user believes they are viewing a normal PDF document, while in the background, embedded payloads are sequentially restored in memory, and RokRAT injected into the "explorer.exe" process communicates with cloud-based C2 infrastructure to collect information and execute remote commands. Because this structure uses both a legitimate process and legitimate cloud services, it is difficult to identify the full attack flow using only file-based or network-based detection.

Therefore, an EDR (Endpoint Detection and Response)-centered integrated response framework is required to visualize the full attack chain, from initial access to ISO image execution, PIF-based loader behavior, cloud C2 communication, and information collection, and to analyze and block threat activity based on correlations between events.

"Genian Insights E" is an integrated endpoint security platform based on a single agent. For multi-stage targeted attacks such as “Operation Capsule Vault”, it provides the following behavior-based detection and response capabilities.

EDR can track and analyze the entire attack process based on behavior. In this case, it can correlate and identify the following key activities.

• Execution of an ISO image file through a spear-phishing email
• Execution of a PIF executable disguised as a PDF document (double-extension trick)
• Cloud-based C2 communication using services such as pCloud, Dropbox, and Yandex
  
  

In particular, Genian Insights E does not simply provide process creation events. It can comprehensively analyze various events, including parent-child process relationships (process tree), command lines, file creation, memory behavior, DLL loading, remote thread creation, process injection, and network connections, enabling full visualization of the attack flow.

[Figure 4-1] Detection of Double-Extension Trick Execution Through EDR

In addition, starting from the PIF file executed inside the ISO image, the XBA (anomaly behavior analysis) detection engine can detect the double-extension technique used by "260612(자료집-내지)동북아-원산갈마해안.pdf.pif", which is disguised as a PDF file.

[Figure 4-2] Detection by Machine Learning

In addition, as a result of comprehensively analyzing various malicious behavior characteristics through the Machine Learning (ML) engine built into EDR, the malicious file is classified as having a very high likelihood of being malicious (ML.High) and is detected as an immediate threat at the initial execution stage.

This enables high-confidence detection of new variants or unknown malware with similar characteristics, regardless of whether they are already known malware. It also allows effective proactive response to targeted attacks that are difficult to identify through signature-based detection alone.

[Figure 4-3] Yandex C2 Connection Attempt

With this behavior-based analysis information, EDR administrators can intuitively trace the full attack chain, from initial access through spear-phishing email to Yandex Cloud C2 communication.

This enables rapid and accurate threat identification, while also allowing comprehensive analysis of the threat actor’s intrusion process and subsequent activities to establish effective response and incident response measures.

In addition, because file creation and network connection information are provided in correlation, threats can be analyzed and handled based on the full attack chain rather than individual events. This also enables more effective detection and response against similar variant attacks.

5. IoC (Indicator of Compromise) 

•  MD5

  e5c9bb3938f2a24e755ee39073fc3aca
  

   

• C2

5.180.208[.]57

5.180.208[.]60

89.147.101[.]197

89.187.161[.]220

160.238.37[.]95

160.238.37[.]100