Executive Summary This analysis represents the second instalment in a comprehensive examination of the KorPlug malware family. Previous reporting detailed the initial loading vector utilising DLL side-loading techniques against legitimate utilities to achieve code execution. The second-stage payload executes via a designated entry point function. Static analysis of the binary reveals that the Initialise function, invoked by the preceding loader stage, exhibits an anomalous Control Flow Graph (CFG) structure. Reverse-engineering efforts targeting this function present significant analytical challenges due to implemented obfuscation mechanisms. Both static disassembly and dynamic analysis methodologies encounter substantial impediments when attempting to enumerate the function's operational logic. The following technical analysis, with the file-details in Table #1, documents the methodologies employed to circumvent the identified obfuscation techniques and extract actionable intelligence regarding KorPlug's second-stage execution capabilities. Table #1. Details of malicious DLL Technical Breakdown Flashback to Stage-3 Analysis of the terminal phase detailed in Part 1 reveals that despite the decoded payload maintaining standard DLL file structure, execution occurs through non-conventional loading mechanisms.  The sample implements shellcode-style execution via the EnumSystemGeoID API function call. The payload's initial byte sequence contains redirect instructions that divert execution flow directly to the Initialize function, circumventing standard Windows DLL loading procedures and associated security mechanisms. Static analysis of the binary within disassembly environments reveals that the Initialize function exhibits a complex and extensive Control Flow Graph (CFG) structure. This report documents the methodologies employed to transform the obfuscated CFG representation into a comprehensible format suitable for reverse engineering analysis, while maintaining the integrity of the original execution logic and operational behaviour. O-LLVM The observed CFG structure and block segmentation patterns are consistent with O-LLVM [1] implementation characteristics. O-LLVM represents a modified iteration of the LLVM compiler infrastructure [2] that incorporates code obfuscation capabilities. This toolset is commonly deployed to impede reverse engineering and static analysis efforts across various threat vectors, including malware campaigns, digital rights management systems, and software protection schemes. O-LLVM implements three primary obfuscation methodologies: Control Flow Flattening: Transforms function control flow structures into flattened switch-based dispatch mechanisms, obscuring conventional conditional logic and iterative constructs. Bogus Control Flow: Introduces spurious conditional branches and unreachable code segments designed to mislead disassembly tools and analytical processes. Instruction Substitution: Replaces straightforward instruction sequences with functionally equivalent but syntactically complex alternatives to defeat signature-based detection mechanisms. O-LLVM operates on LLVM's Intermediate Representation (IR) layer, enabling language-agnostic obfuscation across any codebase compiled through Clang or LLVM-based toolchains. The resulting binary complexity substantially increases reverse-engineering difficulty. Analysis efforts included evaluation of multiple publicly available deobfuscation tools and documented methodologies. Testing revealed that existing solutions did not successfully process the sample without significant modification. In RevEng.AI’s assessment of publicly-available tooling, MODeflattener [3] demonstrated the highest compatibility potential, with associated documentation [4] providing foundational reference material for the techniques detailed in this analysis. Control Flow Graph Component Analysis Effective deobfuscation of the target function requires systematic identification and categorisation of individual components within the Control Flow Graph (CFG). O-LLVM obfuscation implementations assign specific operational roles to distinct basic block types. The following analysis examines the functional classification of these block categories to establish the foundation for subsequent deobfuscation procedures. The pre-dispatcher block represents the most readily identifiable component within the obfuscated CFG structure. This block exhibits a characteristic high predecessor count relative to other basic blocks within the function. Analysis reveals that the pre-dispatcher typically contains minimal operational logic, consisting primarily of an unconditional jump instruction directing execution flow to the initial dispatcher block. The first dispatcher block initiates the computational logic responsible for determining subsequent execution paths within the obfuscated function. This block operates through manipulation of a designated control variable, referenced as the state variable within control flow flattening implementations. Individual basic blocks within the obfuscated structure assign discrete values to this state variable. The dispatcher and backbone components subsequently utilise these assigned values to perform calculated branch operations, determining the target basic block for continued execution flow. The dispatcher block initiates execution immediately following initial state variable assignment. The opening instruction within this block performs additional manipulation of the state variable (observed as [esp+9Ch+var_8C] within the analysed sample) to commence the resolution process for determining the current state value and directing execution to the corresponding target block. Subsequent blocks contain the core operational logic intended for execution by the malware sample. These backbone blocks demonstrate consistent instruction patterns utilising JMP, MOV, SUB, and JZ operations.  These instructions function collectively to manipulate and evaluate the state variable contents, facilitating calculated jumps to appropriate successor blocks within the execution sequence. This instruction sequence architecture serves as the foundational mechanism governing execution flow control throughout the obfuscated function. The relevant blocks constitute the critical components containing the sample's core operational functionality.  These blocks house the primary behavioural logic and executable actions that fulfil the malware's intended objectives. Irrespective of the specific malicious capabilities implemented by the threat actor, the fundamental operational code responsible for achieving the malware's design goals resides within these relevant block structures. Not all critical blocks within the obfuscated structure maintain the pre-dispatcher as a successor block. The terminal block, which denotes function completion, contains no successor relationships. This architectural variation does not compromise execution integrity, as proper resolution of state variable logic and backbone comparison mechanisms ensures natural progression to the terminal block without disrupting established control flow patterns. Within relevant blocks, state variable manipulation represents the primary mechanism governing execution flow transitions. Analysis of the sample reveals that state variable assignment operations consistently occur at the conclusion of each relevant block. These relevant blocks can be categorised into two distinct operational types based on their state assignment methodology. Simple Assignment Blocks implement direct state variable assignment through hardcoded value placement utilising MOV instructions. Conditional Assignment Blocks incorporate decision logic where subsequent state values depend on evaluated conditions, enabling selection between two possible state values. This conditional pattern typically manifests through the following instruction sequence: MOV eax, value1; MOV ecx, value2; CMOVZ ecx, eax; MOV [state variable], ecx.  Through systematic manipulation of state variable values at the conclusion of each relevant block that transitions back to the pre-dispatcher, the sample enforces a predetermined execution sequence and ensures processing of functional components in a specified order.  This obfuscation technique, while maintaining logical execution flow integrity, generates a significantly more complex CFG structure compared to conventional compilation output. The resulting architectural complexity substantially impedes manual analysis efforts within standard SRE tooling. Deobfuscation Implementation Methodology With comprehensive understanding of the Control Flow Graph components established, analysts can develop automated deobfuscation tools utilising any programming language or framework capable of CFG analysis and structural pattern recognition. The primary objective involves systematic mapping of all potential state variable values assigned within simple and conditional relevant blocks, followed by determination of actual jump targets processed by backbone block logic. The deobfuscation procedure requires enumeration of state variable assignments across all relevant blocks and correlation of these values with backbone block comparison operations to identify legitimate execution paths.  Upon completion of this mapping process, the deobfuscation tool can implement binary patching operations to redirect each relevant block's execution flow directly to its intended successor relevant block, effectively bypassing the obfuscated dispatcher mechanism. This process includes removal of operational code within backbone blocks and the first dispatcher, restoring the function to its original, unobfuscated control flow structure. Following successful mapping of execution paths, the deobfuscation process requires patching each relevant block to implement direct jumps to the subsequent relevant block within the legitimate execution sequence.  The following implementation utilises Python in conjunction with the angr binary analysis framework to automate the deobfuscation process.  Angr provides comprehensive capabilities for extracting critical components from individual basic blocks, enabling systematic identification and classification of the structural elements detailed in the preceding analysis. The implementation iterates through identified relevant blocks to catalog their operational characteristics, classifying each block as either simple or conditional type based on state variable assignment methodology. The analysis process records the specific values assigned to the state variable at the conclusion of each block's execution sequence. Analysis must also account for a specialised category designated as tail blocks. While tail blocks technically qualify as relevant blocks due to their direct predecessor relationship with the pre-dispatcher, they contain no substantive operational logic. These blocks typically consist of a single JMP instruction directing execution to the pre-dispatcher component. During the binary patching phase–which will be covered in more detail further in this report–tail blocks are classified and processed as backbone components, requiring removal from the execution logic. This treatment is appropriate as tail blocks neither manipulate the state variable nor contribute meaningful functionality to the CFG structure, serving only as transitional elements within the obfuscated architecture. With state variable values enumerated and cataloged for each relevant block, the subsequent analysis phase requires identification of corresponding jump operations within the backbone block structures.  With comprehensive state variable to jump target correlation established, the final implementation phase involves systematic patching of the binary to eliminate obfuscated control flow mechanisms. This process replaces existing state variable manipulation operations and jumps to the pre-dispatcher with direct jump instructions targeting the appropriate successor relevant blocks. For conditional execution flows, the patching procedure may require insertion of conditional jump instructions followed by unconditional jump operations, depending on the specific branching logic requirements. Attention must be maintained regarding instruction size variations during the patching process. Original instruction sequences, such as MOV [state variable], value; JMP pre-dispatcher, typically consume 13 bytes of binary space.  Direct JMP instruction replacements may require only 5 bytes, creating a size differential that must be addressed to preserve binary integrity. The remaining byte space must be populated with NOP (no operation) instructions to maintain proper binary alignment and prevent execution of unintended instruction sequences that could compromise deobfuscation effectiveness. The concluding phase involves systematic removal of backbone blocks, dispatcher components, and tail blocks from the binary's execution flow. This elimination process produces a simplified binary structure that accurately represents the underlying operational logic of the original, unobfuscated code.  Conclusion  This methodology demonstrates effective analysis and deobfuscation capabilities against heavily flattened control flow structures generated by O-LLVM obfuscation implementations.  Through systematic identification of obfuscation architectural components, classification of relevant block types, and reconstruction of original execution logic via targeted binary patching, analysts can achieve significantly improved visibility into the malware's core operational behaviour. While this implementation was developed for analysis of the specific KorPlug sample, the underlying methodology provides a framework adaptable to similar obfuscation schemes through appropriate modifications. This approach parallels adaptation strategies employed with existing tools such as MODeflattener, enabling broader application across O-LLVM obfuscated threat samples with suitable technical adjustments to accommodate implementation variations. As documented in the initial assessment phase, MODeflattener failed to process the analysed sample without modification. Manual intervention involving direct specification of missing basic block addresses and corresponding state variable transition updates enabled successful tool operation for this particular instance. However, these modifications represent sample-specific adaptations that do not provide generalised compatibility across other O-LLVM obfuscated binaries. The complete Python implementation utilising the angr binary analysis framework[5], including comprehensive reference materials and supporting documentation, is accessible through the resources provided in the footnote citations. IOCs  Footnotes  [1] The LLVM Compiler Infrastructure - https://llvm.org/  [2] O-LLVM Wiki - https://github.com/obfuscator-llvm/obfuscator/wiki  [3] MODeflattener GitHub Repository - https://github.com/mrT4ntr4/MODeflattener  [4] mrT4ntr4's MODeflattener Post - https://mrt4ntr4.github.io/MODeflattener/  [5] Github link to the code. 

Executive Summary In late May 2025, RevEng.AI identified a new sample of KorPlug (a.k.a Hodur) - a well-known Remote Access Trojan (RAT) frequently leveraged in targeted cyber-espionage campaigns - uploaded to a third-party file-scanning platform. This report is the first in a three-part series detailing a malware campaign involving KorPlug. This is the first of three reports describing a KorPlug campaign, detailing a three-stage malware-execution chain. The observed campaign detailed in this Part 1 of reporting employs a multi-stage execution chain designed to evade detection: Initial Access begins with a seemingly benign Microsoft Installer (MSI) file. Execution involves DLL sideloading alongside deobfuscation of a payload file on disk– by abusing a legitimate, signed Canon Inc. executable. Execution of a malicious payload, culminates in a memory-only deployment of KorPlug, using non-standard Windows callback APIs to execute the final stage RevEng.AI assesses with high confidence that this activity is attributable to an China-nexus threat actor based on: Code Similarity Analysis: Large-scale static analysis performed by RevEngAI’s proprietary engine revealed significant code-level overlaps with previously documented KorPlug variants. Infrastructure and Tooling Overlap: Strong alignment with KorPlug infrastructure and techniques observed in previous China-attributed operations [7]. Use of Trusted Signed Binaries: The abuse of a Canon Inc. signed executable for DLL hijacking mirrors tradecraft seen in earlier campaigns attributed to Chinese threat actors, specifically MUSTANG PANDA (a.k.a. Proofpoint: TA416, PwC: Red Delta, or PAN: PKPLUG). Analysis Highlights  Stage 1 - MSI File The initial stage of the execution chain is a Microsoft System Installer (MSI) file with an unspecific name (SHA-256: 2e888ffd9d7ab1a210b4165f4f2aa34b1e42e7c4eed79dd9c9f310659c59f10d). An MSI file is a structured database used by Windows Installer to manage the installation, maintenance and removal of software. This file was first seen on a third-party scanning service on 16 April 2025 [8]. Figure 2: Files contained within the MSI file Analysis of the MSI within the CustomAction and InstallExecuteSequence tables reveals further insight into the initial installation logic of KorPlug. In the sample examined by RevEng.AI, a custom action named FovFancUbFDD is defined that is configured to launch an executable file cnmpaui.exe (SHA-256: 2e888ffd9d7ab1a210b4165f4f2aa34b1e42e7c4eed79dd9c9f310659c59f10d) within %LOCALAPPDATA%. The command-line: %LOCALAPPDATA%\ZDYmiFz\cnmpaui.exe is configured to be used. Stage 2 - Execution of Malicious Hijacked DLL The legitimate, signed executable (cnmpaui.exe) executed under the MSI installer, signed by Canon Inc (serial: 20 A9 47 94 7E 70 33 91 C3 00 8B 62 66 06 FA 8F) is a printer utility used for Canon devices. Although the signature has expired (30/12/2020 - 23:59:59), Windows does not mark the signature as invalid – a design choice by Microsoft. The flawed implementation of blindly loading another application-related DLL, cnmpaui.dll (SHA-256: c1124deb209ed291a98c7185bee26946beec7161d4f22519902f80393ffca660) – which allows for DLL hijacking – is relatively straightforward.  Towards the end of the entrypoint within the executable, it exhibits a common pattern involving the dynamic loading of the DLL file, the resolution of exported function MaintenanceAppStart using GetProcAddress, and the subsequent execution of the retrieved function pointer with three parameters.  The use of DLL hijacking in this context allows the malicious DLL bundled within the KorPlug execution pipeline to be executed under the context of a signed process. This is a common technique frequently used by threat-actors to abuse legitimate executables as means of evading detection on a host. Stage 3 - KorPlug DLL Loader The malicious hijacked DLL named cnmpaui.dll, SHA-256: c1124deb209ed291a98c7185bee26946beec7161d4f22519902f80393ffca660, is signed with a bogus, invalid signature masquerading as the legitimate executable’s signer–Canon Inc. This can be observed below in Figure 4. The DLL file only contains two exports: DllMain and MaintenanceAppStart. MaintenanceAppStart contains the malicious functionality of the DLL loader in this instance, which – as previously discussed – is executed by the loading executable.  The first function called within the MaintenanceAppStart function is located at 0x10001000, referred in the pseudocode here as get_function_pointers [1].  Upon initialisation, the function searches for Windows API functions by precomputed hashes and stores their resolved addresses in the Thread Environment Block (TEB) – using Thread Local Storage (TLS). This is a common evasion tactic designed to avoid direct API references appearing in the Import Address Table (IAT).  To aid in this resolution, it calls a helper function located at 0x10001F90, referred within Figure 5 as get_function_by_hash [2]. The functions that are resolved are primarily memory management system-call APIs. Further analysis of the MaintenanceAppStart function reveals a typical setup for Windows event-driven applications, although without a message loop. Examining the function flow, we can identify that the Windows Procedure function. By calling a ShowWindow function in MaintenanceAppStart, a message with the ID 0x18 is sent to the message queue to be interpreted by WinProc. This function will forward all messages that do not have the ID 0x18 to NtdllDefWindowProc_W.   However, if the message ID matches the expected one (0x18), it triggers the creation of a new thread via CreateThread [3], passing the function located at 0x10001C60 as the target function: The function first proceeds by calling itself recursively. During this process, it invokes GetModuleFileNameW [4] to retrieve the path of the current executable, extracts the directory, and appends the string _\cmplog.dat, a file also present in the MSI package and which appears to be obfuscated.  Next, it checks for the existence of this file using the CreateFileW [5] API. If the file is found successfully, the execution continues by calling the final key function in this sample, located at 0x10001490, renamed to load_and_execute [6]. This function is responsible for allocating memory and reading the contents of the file, as well as allocating additional memory to hold the decrypted version of the next stage in the execution chain.  Finally, to load KorPlug, this sub-stage makes use of the EnumSystemGeoID API. At first glance, one might assume that the next stage is a shellcode rather than a PE file, but that assumption would be incorrect. In reality, the first bytes of the PE file are shellcode, effectively invoking the first function of the next stage. An extract of the first 22-bytes in the shellcode used for the execution of the DLL can be observed below, which has been highlighted with a colour-key: This loading phase ultimately leads to the execution of KorPlug. This will be analysed in the next part of this series. Assessment  RevEng.AI assesses this activity to a currently unnamed China-nexus threat actor based on comprehensive analysis of observed Tactics, Techniques, and Procedures (TTPs) that demonstrate strong alignment with established patterns documented in open-source intelligence reporting – specifically the code overlap with known KorPlug builds, use of DLL hijacking, and tooling overlap. This attribution assessment reflects behavioural consistencies and modus operandi of China-nexus actors. RevEng.AI does not currently have enough evidence to corroborate these findings to known activity from a named China-nexus actor. Conclusion  The first stage of this KorPlug execution chain showcases a structured and multi-layered approach designed to evade detection and ensure successful payload delivery. From the use of a seemingly benign MSI installer to the strategic abuse of DLL side-loading and dynamic API resolution, each step in the chain demonstrates a clear intent to blend into legitimate system activity. The reliance on obfuscated payloads, memory-only execution, and signature misuse further reinforces the sophistication behind the operation. How RevEng.AI Can Help RevEng.AI's advanced analysis capabilities provide unparalleled insights into complex malware. Our ability to deconstruct intricate infection chains, identify hidden tactics, and attribute activity to specific threat actors empowers security teams to: Gain deeper threat intelligence: Understand the "how" and "why" behind sophisticated attacks. Strengthen defensive postures: Proactively adjust security controls based on real-world threat actor methodologies. Improve incident response: Quickly and accurately identify compromised systems and eradicate threats. For more information you can request a Demo of the RevEng.AI platform. MITRE ATT&CK® Mapping  Indicators Of Compromise (IOCs)  Footnotes [1] korplug_get_function_pointers function in KorPlug [2] korplug_get_function_by_hash function in KorPlug [3] CreateThread function (processthreadsapi.h) - https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createthread [4] GetModuleFileNameA function (libloaderapi.h) - https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-getmodulefilenamea [5] CreateFileW function (fileapi.h) - https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilew [6] korplug_load_and_execute function in KorPlug [7] https://www.welivesecurity.com/2022/03/23/mustang-panda-hodur-old-tricks-new-korplug-variant/ [8] https://www.virustotal.com/gui/file/2e888ffd9d7ab1a210b4165f4f2aa34b1e42e7c4eed79dd9c9f310659c59f10d/details

Reverse engineering malware often feels like solving a puzzle where half the pieces are hidden. Among the most common obstacles analysts face is string obfuscation—a technique where malware authors encrypt or encode strings to evade detection and frustrate analysis. This anti-analysis technique appears in virtually every modern malware family, turning what should be straightforward analysis into hours of tedious manual work. In this post, RevEng.AI will explore two approaches to dealing with this form of obfuscation. Firstly, we will demonstrate how to build an IDAPython script that automatically decodes obfuscated strings and renames associated variables using StealC V1 (the predecessor to StealC V2) as our case study. Second, we will showcase how RevEng.AI can expedite this process to dramatically accelerate reverse engineering workflows, freeing up analysts to focus on understanding the malware's actual behaviour. The sample analysed can be accessed here. The Case for Automation Before diving into the technical details, let's understand why automating string decoding is crucial for efficient malware analysis: Time Efficiency: Each obfuscated string requires multiple manual steps: identifying the decoding logic, extracting arguments, and performing the decoding. When dealing with hundreds of strings, this becomes prohibitively time-consuming. Accuracy: Manual analysis is prone to human error. It's easy to miscalculate offsets, incorrectly extract values, or make transcription mistakes that lead to incorrect conclusions about the malware's functionality. Pattern Recognition: Most malware families use a single decoding function throughout their codebase. Once you've identified the pattern, automation can apply it consistently across the entire binary. Focus on What Matters: By automating routine tasks, analysts can dedicate their cognitive resources to understanding the malware's core functionality, network behavior, and potential impact. Understanding StealC V1's Obfuscation When analysing the sample, the following function came across as being of particular interest. It takes a large number of encoded strings and passes them into the function at 0x45c0. We can see the decompiled output of 0x45c0 using the RevEng.AI AI Decompiler below: From this, we can see that StealC V1 employs a straightforward XOR-based string obfuscation technique. The decoding routine is elegantly simple, accepting three parameters via the stack: Key buffer - The XOR key used for decryption Encrypted buffer - The obfuscated string data Length - The size of the string to decode The C implementation resembles: While the algorithm is basic, manually decoding hundreds of strings using this method would be exhausting. Building the IDAPython Automation Script Let's break down our automation approach into four logical components: 1. Locating All Decoder Calls First, we need to find every location where the decodeString function is called: This function leverages IDA's cross-reference capabilities to identify every call instruction targeting our decoder function, giving us a comprehensive list of decoding sites. 2. Extracting Stack Arguments Before each call to decodeString, the malware pushes three arguments onto the stack. We need to backtrack from the call instruction to collect these values: Additionally, we track where the return value is stored after the call: 3. Implementing the Decoder With the extracted parameters, we can reimplement the XOR decoding logic in Python: To ensure variable names remain valid in IDA, we sanitize the decoded strings using regular expressions, removing any non-alphanumeric characters that could cause issues. 4. Automated Variable Renaming The final step renames variables in the Hex-Rays decompiler view to reflect their decoded values: When name collisions occur (multiple variables decoding to the same string), we append a counter to maintain uniqueness while preserving the meaningful connection to the decoded content. Results and Impact Running this script on a StealC V1 sample transforms the analysis experience: Immediate Context: Variables like var_4C become str_kernel32_dll, instantly revealing their purpose Revealed Infrastructure: Command and control servers, file paths, and registry keys become visible Behavioral Insights: API names and system commands expose the malware's capabilities Time Savings: Hours of manual work compressed into seconds of automated processing RevEng.AI Community RevEng.AI users analysing variants of StealC can now benefit from our internal analysis by matching pre-reverse engineered symbol data between the malware variants. To do so, simply match all functions using a RevEng.AI plugin for your SRE tool and set the filter to limit to the sample above. Alternatively, use our Web UI and then export a PDB or ELF debug file. Doing so will match functions using BinNet AI between the samples and merge any debug information. Conclusion Automating string decoding transforms malware analysis from a tedious manual process into an efficient, scalable workflow. Automation frees us to focus on that narrative rather than getting lost in the mechanics of decoding. By investing time in building automation scripts, we not only accelerate individual analyses but create reusable tools that benefit future investigations. Detection YARA Rule YARAI Alternatively, RevEng.AI users can detect StealC variants based on a BinNet AI summary of the sample. This looks at the intent and behaviour of code contained in the malware and finds similar samples uploaded to the platform. For example, the StealC binary referenced in this blog post is most similar to the following files: