This is Dancho.
As many of you know based on my Conti ransomware coverage which is originally based on my Conti Leaks analysis and attribution research including the reproduction video I recently came across to a very interesting malicious software executable which I obtained as a URL location from my original Conti Leaks research in specific hxxp://www.ottenbourg.com/upload/xml1.exe where using my real time OSINT methodology I quickly attempting to automatically visit and download the associated malicious software executables found as URLs in the original Conti Leaks which I did with a lot of success.
MD5: 8503ea92f4c9941ee3295978729d98ba
SHA-1: d04dfbc5b1335c8408ffb5c58bd966791f748ad3
SHA-256: 1e0215f67fb7b02bc44f33bf6a5b884c3061cbeb38e0150b559635458951fa53
Now here comes the interesting part.
Many of my blog readers who've been following my research here for over a decade are pretty familiar with how I work and the actual process in which I do my research and share actionable intelligence with the community and the rest of my blog readers.
This might really come as a surprise but I set a personal goal for 2026 to do over my best to resume posting high quality and relevant content here sticking to my usual rhythm so I did spend some time actually doing what can be described as my first reverse engineering and with a success of a Conti ransomware malicious software executable which I directly obtained and downloaded based on my data mining and real time OSINT methodology for Conti Leaks.
Now comes the second surprise.
After recently finishing to work on an independent contractor project I took the time and investment and I'm now a proud user of Vector35's Binary Ninja which is also AI empowered thanks to SideKick which is an outstanding news.
So here's what I did for the first time ever in my entire career lifetime which I wanted to share which I'm sure most of my blog readers will find entertaining and will enjoy.
The results of my first real reverse engineering attempt? A novel C2 malicious software data exfiltration tactic in one of Conti ransomware's malicious software executables.
Here's the summary of my reverse engineering analysis which is AI assisted but that was among the primary purposes for getting on board with Vector35's Binary Ninja and SideKick.
Multi-Stage C2 Infrastructure with Dual Communication Channels Analysis Report
Multi-Stage Dropper with Advanced C2 and Evasion Techniques
Malware Name: Conti Malware (Variant: Multi-Stage C2 Dropper)
Analysis Date: 2026-02-24 12:57:58 UTC
Executive Summary:
The malware implements a sophisticated multi-stage C2 system with email and HTTP channels, resource-based payload injection, custom RC4 encryption, and anti-analysis techniques.
Threat Assessment:
Sophistication: High - multi-stage, custom encryption, anti-analysis, dual C2 channels Evasion: Advanced - NUMA detection, resource hiding, no direct network calls Persistence: Long-term - registry-based, legitimate-looking UI
Impact: Critical - covert data exfiltration, command execution, remote control
1.INITIAL OBSERVATIONS
Uses VirtualAllocExNuma with specific NUMA node parameter '64' for payload allocation instead of standard VirtualAlloc. This technique may evade memory scanning tools that don't account for NUMA-specific allocations and complicates forensic analysis of memory dumps.
Binary contains only 13 identified functions despite 396KB size, with entry point at 0x40accb. This extreme disparity strongly indicates the binary is packed, encrypted, or heavily obfuscated. Standard unpacking/deobfuscation techniques should be applied before detailed analysis. Look for stub code, runtime decompression, or virtualization markers.
The RC4-encrypted resource 0x4b60 contains coincidental byte sequences that match image file signatures (0x42 0x4D for BMP, etc.) but are actually part of dialog template structures or padding. These false positives mislead analysts into attempting image extraction and recovery techniques on non-image data. Strict header validation (checking reserved fields, planes count, bits-per-pixel validity, dimension reasonableness, file size bounds, pixel offset validity, DIB header size, and compression type) is essential to distinguish real image files from signature collisions. This obfuscation effect—whether intentional or coincidental—increases analysis effort by creating plausible but invalid extraction targets.
Function sub_406470 loads taskmgr.exe to detect if Task Manager is running, indicating sandbox or analysis environment. This check occurs before resource extraction and payload decryption, allowing the malware to alter behavior or abort execution if analysis tools are detected.
GUI elements are encrypted in resource 0x4b60 to prevent static analysis tools (Resource Hacker, PE Explorer, CFF Explorer) from directly viewing dialog templates and UI strings. The RC4 encryption at sub_402ba0 requires runtime decryption, forcing analysts to either execute the malware or reverse the encryption algorithm. This technique specifically targets resource extraction utilities that cannot decrypt embedded resources.
2.EXECUTION FLOW & INITIALIZATION
2.1Multi-Stage Execution Flow
Stage 1 Entry:
Function: _start (0x40accb)
Description: Entry point initializes runtime, checks OS version, sets up exception handlers
Stage 2 Initialization:
Function: sub_41ce18 (0x41ce18)
Description: Sets error mode (SEM_ALL_ERRORS | 0x8001), initializes application state, extracts module filename
Stage 3 Ui Setup:
Function: sub_418d17 (0x418d17)
Description: Installs Windows hook (WH_JOURNALRECORD) for message interception, initializes UI framework
Stage 4 Payload Injection:
Function: sub_406740 (0x406740)
Description: Main C2 initialization - loads encrypted payload, creates UI controls, establishes C2 channels
2.2Key Execution Chain Details (Hidden Features)
Primary malicious logic entry point identified:
Function at 0x4131fa serves as the actual main/WinMain function where malicious behavior initiates. This function is called from the C runtime initialization stub at 0x40accb with module handle and command line parameters. This is the critical control flow junction for understanding the malware's execution sequence and should be prioritized for detailed analysis before examining individual capability functions.
Referenced Locations: 0x4131fa
Initialization chain establishes application state with error mode:
Function at 0x41ce18 serves as the initialization hub in the execution chain (_start 0x4131fa 0x41a42a 0x41ce18). This function sets error mode and initializes application state with module handle and command line parameters. Understanding this initialization sequence is critical as it establishes the runtime environment before malicious capabilities are invoked.
Referenced Locations: 0x4131fa, 0x41a42a, 0x41ce18
String initialization wrapper with pointer validation:
Function 0x41873f initializes string values with pointer validation logic. It sets destination to a default value at 0x427938, then validates source pointer by checking if (source >> 16) != 0 before processing. This validation pattern suggests defensive programming against null or invalid pointers during string initialization, potentially protecting against malformed input during URL setup or configuration loading.
Referenced Locations: 0x41873f
Hardcoded Tripod URL and email as social engineering props:
Binary contains hardcoded URL 'http://members.tripod.com/~SoftechSoftware/index.html' at 0x427130 and email 'mailto:davide_calabro@yahoo.com' at 0x4069a4. These are configured as clickable hyperlinks in UI dialog created by sub_406740 at 0x406740. URLs are launched via ShellExecuteA (sub_4020b0) and serve as social engineering decoys rather than actual C2 infrastructure.
Referenced Locations: 0x427130, 0x4069cb, 0x406740
Dialog resource creation with specific control IDs:
Function sub_406740 creates a dialog window via CreateDialogIndirectParamA at 0x4195eb with four styled controls having IDs 0x85, 0x86, 0x84, and 0x87. Dialog uses WM_SETFONT (message 0x80) via SendMessageA for font configuration. This structure enables resource extraction tools (Resource Hacker, PE Explorer, CFF Explorer) to recover and analyze the dialog template from the PE file's DIALOG resource section without requiring dynamic execution.
Referenced Locations: 0x406740, 0x4195eb
Dialog template constructed programmatically at runtime:
Dialog creation uses CreateDialogIndirectParamA with a memory-constructed template rather than resource-based loading. The dialog template is built at runtime by sub_406740, which programmatically configures four control structures at offsets 0x18, 0xfe, 0x1e4, and 0x496 with styling parameters. This runtime construction approach allows the malware to dynamically modify UI elements without modifying the PE resource section, complicating static analysis and resource extraction tools.
Referenced Locations: 0x406740, 0x41946f, 0x4195eb
Encrypted GUI dialog template in resource section:
Resource type 0xa (10) with ID 0x4b60 (19296) located in .rsrc section at 0x42d000-0x4662a8 contains encrypted dialog template and UI elements. The encryption obscures dialog structure, control definitions, and associated strings from static resource analysis tools. Decryption via RC4 reveals the complete GUI layout including DLGTEMPLATE structures and control definitions that would otherwise be visible in PE resource sections.
Referenced Locations: 0x4b60, 0x42d000
Resource directory navigation path to encrypted GUI:
Resource type 0xa (ID 0x4b60) is located in the resource directory at offset 0x42d190 within the
.rsrc section base at 0x42d000. The resource entry structure contains offset pointer 0x80000498 that leads to the actual encrypted data. This navigation path (Type 0xa ID 0x4b60 offset 0x80000498) enables direct extraction of the encrypted GUI resource without requiring resource extraction tools, allowing programmatic access to the encrypted payload.
Referenced Locations: 0x42d190, 0x42d000
RC4 decryption algorithm suitable for offline analysis:
The RC4 algorithm implementation at sub_402ba0 is deterministic and can be replicated in any programming language (Python, C, JavaScript, etc.) without requiring binary execution. The hardcoded key eliminates key derivation complexity. Analysts can decrypt the 85,441-byte resource offline using standard RC4 implementations or tools like CyberChef, revealing the complete dialog template and UI strings without executing the malware. This enables safe static analysis of the previously encrypted GUI components.
Referenced Locations: 0x402ba0
Encrypted resource contains embedded image files:
The RC4-encrypted resource 0x4b60 (85,441 bytes) contains embedded image files with standard signatures (JPEG: FF D8 FF, PNG: 89 50 4E 47, BMP: 42 4D, GIF: 47 49 46). These images can be extracted by decrypting the resource with RC4 key '4duH61r1b5q0KTnEEPV1ZBQZigyihN0t9ii' at sub_402ba0, then scanning the decrypted payload for image file headers. This reveals additional malware components or social engineering assets hidden within the encrypted resource section.
Referenced Locations: 0x4b60, 0x402ba0
Format-specific image boundary detection for embedded extraction:
The decrypted RC4 resource contains multiple image formats requiring different boundary detection methods: PNG uses IEND chunk signature (49 45 4E 44 AE 42 60 82), JPEG uses FFD9 end-of-image marker, GIF uses 0x3B trailer byte, and BMP uses header-encoded size field. Implementing format-specific extraction logic prevents false positives from signature collisions and ensures complete recovery of all embedded images. This is critical for reliable programmatic extraction of the visual assets hidden in resource 0x4b60.
Referenced Locations: 0x4b60, 0x402ba0
Complete BMP image files with valid headers in encrypted resource: Analysis of the decrypted RC4 payload reveals BMP files with complete, valid headers including signature verification, file size fields, pixel data offsets, DIB header information (width, height,
bits-per-pixel, compression type), and plane counts. Each BMP structure is self-contained with proper header fields that allow reliable extraction without requiring external image format knowledge. The presence of multiple BMPs suggests the resource contains a collection of visual assets (likely UI graphics or social engineering imagery) embedded within the encrypted GUI resource section.
Referenced Locations: 0x4b60, 0x402ba0
Incomplete encrypted resource causes BMP truncation artifacts:
If the encrypted resource 0x4b60 is truncated in the binary file (fewer bytes than the size field declares), RC4 decryption will produce incomplete BMP files. The decrypted payload will end prematurely, cutting off image pixel data and producing invalid BMP structures. This manifests as BMP files with correct headers but incomplete pixel data sections. Verify resource completeness by comparing actual bytes read against the size field in IMAGE_RESOURCE_DATA_ENTRY before decryption. If incomplete, the binary itself may be corrupted or intentionally stripped during distribution.
Referenced Locations: 0x4b60, 0x402ba0
Programmatic resource extraction with bounds checking and diagnostics:
Develop resource extraction script that: (1) Reads .rsrc section bounds (start, end), (2) Navigates PE resource directory to locate type 0xa, ID 0x4b60, (3) Extracts RVA and declared size from IMAGE_RESOURCE_DATA_ENTRY, (4) Calculates actual address using offset formula: actual_address = rsrc_base + (RVA - 0x2d000), (5) Validates address is within .rsrc bounds, (6) Calculates available bytes: available = rsrc_end - actual_address, (7) Reads min(available, declared_size) bytes, (8) Logs diagnostic info including available vs. declared size discrepancy, (9) Passes actual bytes read to RC4 decryption. This diagnostic approach reveals whether binary is truncated or corrupted.
Referenced Locations: 0x42d000, 0x4b60, 0x402ba0
Dual-source resource size validation methodology:
Implement three-level resource size validation: (1) Read declared size from IMAGE_RESOURCE_DATA_ENTRY size field, (2) Read RawSize from PE .rsrc section header,
(3) Calculate available bytes from file end minus RawOffset. Compare all three values. If declared_size > RawSize, the resource is truncated at file level. If RawSize > available_bytes, the file itself is incomplete. Log all three values with discrepancies clearly marked. This multi-level approach reveals whether truncation occurred during binary creation, distribution, or analysis tool processing.
Referenced Locations: 0x42d000, 0x4b60
Lenient RC4 decryption with partial payload support:
The RC4 implementation at sub_402ba0 can successfully decrypt truncated or incomplete encrypted payloads. Rather than requiring exactly 85,441 bytes, pass the actual number of bytes available to the decryption function. The PRGA algorithm will process whatever bytes are provided and produce corresponding plaintext output. This enables recovery of partial BMP files and dialog structures even when the resource is truncated in the binary file. Document the actual bytes decrypted versus declared size to identify truncation artifacts.
Referenced Locations: 0x4b60, 0x402ba0
Partial BMP recovery from truncated encrypted payload:
Truncated BMPs in resource 0x4b60 can be salvaged by extracting complete scanlines and reconstructing valid BMP headers with adjusted dimensions. For each truncated BMP: (1) read the original width, height, bits-per-pixel, and pixel_offset from the header, (2) calculate row_size accounting for 4-byte padding alignment, (3) determine how many complete rows fit in available data, (4) create a new valid BMP with reduced height equal to complete_rows, (5) preserve all complete pixel data and discard only the incomplete final row. This recovery technique yields viewable images from otherwise unusable truncated files, enabling analysis of embedded graphics despite resource corruption.
Referenced Locations: 0x4b60, 0x402ba0
Decrypted resource contains dialog templates, not BMP images:
The RC4-decrypted resource 0x4b60 contains dialog template structures (DLGTEMPLATE) and UI resource data, not embedded BMP image files. False positive 'BM' signatures (0x42 0x4D) found during initial analysis are coincidental byte sequences within dialog data, not image file headers. The 85,441-byte decrypted payload should be analyzed for DLGTEMPLATE structures (style field at offset 0, extended style at +4, control count at +8, dimensions at +10-18) and embedded strings rather than image file signatures. This indicates the encrypted resource contains programmatically-constructed dialog definitions and UI strings.
Referenced Locations: 0x4b60, 0x402ba0
Binary contains no valid embedded BMP image files:
Comprehensive binary-wide search for BMP signatures (0x42 0x4D) with strict header validation reveals no valid BMP image files in the entire binary. Previous 'BMP' detections were false positives from coincidental byte sequences in encrypted resource 0x4b60. Valid BMP headers require: reserved fields = 0, planes = 1, bits-per-pixel in [1,4,8,16,24,32], dimensions < 10000 pixels, file size < 100MB, pixel offset within file bounds, DIB header size in [40,52,56,108,124], compression in [0-6]. The encrypted resource contains dialog templates and UI strings only, not image files. This clarifies that resource 0x4b60 is purely GUI-related without embedded graphics assets.
Referenced Locations: 0x42d000
2.3System Interaction During Initialization/Execution
Runtime initialization and cleanup function chain:
Entry point at 0x40accb invokes a sequence of initialization functions (0x40ce40, 0x40c8fc, 0x40dfc3) before calling main logic at 0x4131fa, followed by cleanup functions (0x40b490, 0x40d9bb) during exit. These functions handle environment setup, Windows version detection, and command line argument processing. Understanding this initialization chain is essential for identifying any pre-execution setup that affects malware behavior or anti-analysis techniques.
Referenced Locations: 0x40ce40, 0x40c8fc, 0x40dfc3, 0x40b490, 0x40d9bb
Multi-stage process execution with registry fallback mechanism:
Function at 0x408980 implements sophisticated process execution with two-stage fallback: primary method uses ShellExecuteA with 'open' verb; if that fails, queries HKEY_CLASSES_ROOT.htm\shell\open\command registry key to retrieve file association handler, then executes via WinExec. This technique bypasses execution restrictions by leveraging system file associations when direct execution is blocked. The registry query specifically targets HTML file handlers.
Referenced Locations: 0x408980
Three-stage URL execution with registry fallback for HTML handlers:
Function 0x408980 implements sophisticated URL launching with fallback chain: Stage 1 attempts direct ShellExecuteA; if that fails (result 32), Stage 2 queries HKEY_CLASSES_ROOT for .htm file association; Stage 3 retrieves the command from .htm\shell\open\command registry key; Stage 4 parses the command by removing '%1' or "%1" placeholders, appends the URL, and executes via WinExec. This technique leverages legitimate file associations to bypass execution restrictions when direct ShellExecute fails.
Referenced Locations: 0x408980
3.PAYLOAD DELIVERY & ANTI-ANALYSIS
3.1 Payload Delivery Mechanism
3.1.1 Resource Extraction:
Function: sub_406470
Resource Type: 0x4b60 | Resource ID: 0xa
Extracts embedded payload from PE resources using FindResourceA/LoadResource
3.1.2Payload Decryption (Overview):
Algorithm: RC4-variant stream cipher
Function: sub_402ba0
Custom RC4 with 85,441-byte state array (0x14dc1), uses KSA and PRGA for decryption
Key: 4duH61r1b5q0KTnEEPV1ZBQZigyihN0t9ii
Key Length: 35
State Size: 85441
3.1.3Payload Injection:
Method: NUMA-aware memory allocation in current process
Allocation: VirtualAllocExNuma with PAGE_EXECUTE_READ protection
Execution: Direct function pointer call to injected code
3.2Anti-Analysis Techniques
Sandbox Check: Attempts to load taskmgr.exe to detect VM/sandbox environments
Minimal function count indicates packing or obfuscation: Binary contains only 13 identified functions despite 396KB size, with entry point at 0x40accb. This extreme disparity strongly indicates the binary is packed, encrypted, or heavily obfuscated. Standard unpacking/deobfuscation techniques should be applied before detailed analysis. Look for stub code, runtime decompression, or virtualization markers.
NUMA-aware memory allocation for evasion: Uses VirtualAllocExNuma with specific NUMA node parameter '64' for payload allocation instead of standard VirtualAlloc. This technique may evade memory scanning tools that don't account for NUMA-specific allocations and complicates forensic analysis of memory dumps.
Anti-Analysis Behavior: Silently fails if anti-analysis checks detect hostile environment
NUMA Detection: Dynamically resolves VirtualAllocExNuma from kernel32.dll
Resource encryption to evade static analysis: GUI elements are encrypted in resource 0x4b60 to prevent static analysis tools (Resource Hacker, PE Explorer, CFF Explorer) from directly viewing dialog templates and UI strings. The RC4 encryption at sub_402ba0 requires runtime decryption, forcing analysts to either execute the malware or reverse the encryption algorithm. This technique specifically targets resource extraction utilities that cannot decrypt embedded resources.
Task Manager detection for sandbox/analysis evasion: Function sub_406470 loads taskmgr.exe to detect if Task Manager is running, indicating sandbox or analysis environment. This check occurs before resource extraction and payload decryption, allowing the malware to alter behavior or abort execution if analysis tools are detected.
False positive image signatures in encrypted resource complicate analysis: The RC4-encrypted resource 0x4b60 contains coincidental byte sequences that match image file signatures (0x42 0x4D for BMP, etc.) but are actually part of dialog template structures or padding. These false positives mislead analysts into attempting image extraction and recovery techniques on non-image data. Strict header validation (checking reserved fields, planes count, bits-per-pixel validity, dimension reasonableness, file size bounds, pixel offset validity, DIB header size, and compression type) is essential to distinguish real image files from signature collisions. This obfuscation effect—whether intentional or coincidental—increases analysis effort by creating plausible but invalid extraction targets.
4. C2 INFRASTRUCTURE & COMMUNICATION
4.1 C2 Servers
Type: HTTP
URL: hxxp://members.tripod.com/~SoftechSoftware/index.html
Purpose: Primary web-based C2 channel
Implementation: ShellExecute-based browser invocation
Type: EMAIL
Address: mailto:davide_calabro[.]yahoo.com Purpose: Secondary email-based exfiltration channel Implementation: ShellExecute with mailto protocol
4.2 C2 UI Framework & Deception
4.2.1 Hyperlink Controls:
Function: sub_41873f (0x41873f)
Target: mailto:davide_calabro[.]yahoo.com
Description: Email exfiltration hyperlink embedded in UI
Function: sub_41873f (0x41873f)
Target: hxxp://members.tripod.com/~SoftechSoftware/index.html
Description: Web C2 hyperlink embedded in UI
4.2.2 Status Indicators: Function: sub_408c80 (0x408c80) Color: 0xff3737
Creates gradient-filled bitmaps (bright red) for status visualization, 8 different patterns for different states
4.2.3 Icon Signaling: Function: sub_401200 (0x401200) Icon IDs: 0x84, 0x85, 0x86, 0x87
Loads custom icons likely representing: connection status, data transfer, command execution, errors
4.3 C2 Communication Details
4.3.1 Activation Mechanism:
Function: sub_4020b0 (0x4020b0)
Trigger: User clicks hyperlink in UI (offset +0x144 contains URL)
Action: ShellExecuteA with 'open' verb and SW_SHOWMAXIMIZED flag
4.3.2 Communication Protocol:
Type: Browser-based and email-based
Stealth Characteristics: No direct network API calls (socket/WinINet/WinHTTP)
Advantage: Blends with legitimate user browsing activity, evades network-based behavioral detection
4.3.3 Shell Execution & Fallback:
Function: sub_408980 (0x408980)
Description: Executes URLs via ShellExecuteA, falls back to registry-based .htm handler if initial execution fails
Fallback Mechanism: Queries HKEY_CLASSES_ROOT.htm\shell\open\command and uses WinExec
4.4 Data Flow - URL Handling & Structure
URL storage offsets in initialization structure:
URLs are stored at specific offsets within a structure initialized at 0x406740: mailto endpoint at offset 0x57c, C2 server URL at offset 0x5af, clickable hyperlink target at offset 0x144, and alternative URL storage at offset 0x58. Additional structure fields include window handle at 0x1c, success flag at 0x4c, state flag at 0x13c, and toggle state at 0x140. These offsets are consistently referenced across URL handling functions and represent the primary data flow mechanism for network targets.
Referenced Locations: 0x406740, 0x4020b0, 0x4080d0
Encrypted resource extraction via PE resource directory:
The encrypted resource 0x4b60 can be extracted by parsing the PE resource directory structure starting at 0x42d000. The resource directory entry at 0x42d190 contains the ID 0x4b60 and an offset pointer (0x80000498) to an IMAGE_RESOURCE_DATA_ENTRY structure. This structure contains the RVA and size of the actual encrypted data. The RVA must be converted to a file offset using the .rsrc section's VirtualAddress and PointerToRawData values to locate the encrypted bytes in the binary file.
Referenced Locations: 0x4b60, 0x42d000, 0x42d190
Resource data entry offset calculation from section base:
The IMAGE_RESOURCE_DATA_ENTRY for resource type 0xa, ID 0x4b60 is located at offset 0x498 from the .rsrc section base (0x42d000). This offset points directly to the RVA and size fields of the encrypted resource data. The RVA must be converted to file offset using the section's VirtualAddress (0x2d000) and PointerToRawData values via the formula: file_offset = RVA - section_VirtualAddress + section_PointerToRawData. This calculation is essential for programmatic extraction of the encrypted payload without using standard resource extraction tools.
Referenced Locations: 0x42d000, 0x498
Resource data entry structure reading from .rsrc section:
The IMAGE_RESOURCE_DATA_ENTRY for encrypted resource 0x4b60 is located at offset 0x498 from the .rsrc section base (0x42d000), yielding address 0x42d498. This 16-byte structure contains the RVA (4 bytes at offset 0) and size (4 bytes at offset 4). Reading this structure directly from the binary view requires proper address calculation: data_entry_offset = rsrc_section.start + 0x498. The RVA value must then be converted to an actual address using either image base offset (RVA + 0x400000) or section-relative calculation (RVA - section_VirtualAddress + rsrc_section.start) depending on the binary view's address space mapping.
Referenced Locations: 0x42d000, 0x42d498
Resource directory navigation requires proper offset calculation:
The resource data entry for ID 0x4b60 is NOT at fixed offset 0x42d498. Instead, navigate the PE resource directory structure: read root directory at rsrc_section.start, parse entries to find type 0xa, then navigate to its subdirectory, find ID 0x4b60 entry, navigate to language directory, and finally read the IMAGE_RESOURCE_DATA_ENTRY structure. The data entry offset is obtained from the language directory entry (without the high bit set, unlike subdirectory pointers which have 0x80000000 set). This multi-level navigation is essential for reliable resource extraction.
Referenced Locations: 0x42d000
Multi-level PE resource directory traversal path:
Resource extraction requires traversing: (1) Root directory at rsrc_section.start to find type 0xa entry, (2) Type 0xa subdirectory to find ID 0x4b60 entry, (3) ID 0x4b60 subdirectory (language directory) to find language entry, (4) IMAGE_RESOURCE_DATA_ENTRY at the offset specified by language entry. Each level is a separate directory structure with its own header (16 bytes) and entries (8 bytes each). The number of entries is read from bytes 14-16 of each directory header. This hierarchical structure must be traversed sequentially; direct offset calculations will fail.
Referenced Locations: 0x42d000
Resource extraction and RC4 decryption execution flow:
Function sub_406470 orchestrates resource extraction: (1) Locates encrypted resource ID 0x4b60 in PE resource directory, (2) Allocates memory via VirtualAllocExNuma with NUMA node 64, (3) Reads encrypted bytes from resource section, (4) Calls sub_402ba0 with encrypted data and hardcoded key '4duH61r1b5q0KTnEEPV1ZBQZigyihN0t9ii', (5) Returns decrypted payload in allocated memory. The decrypted output contains dialog template structures and UI strings that were previously encrypted. This flow must complete before any GUI rendering occurs.
Referenced Locations: 0x406470, 0x402ba0, 0x4b60
Complete resource extraction pipeline for image recovery:
The resource extraction flow at sub_406470 decrypts resource 0x4b60 via RC4 (sub_402ba0) into memory allocated by VirtualAllocExNuma. The decrypted 85,441-byte payload contains both dialog templates and embedded image files. By scanning the decrypted buffer for image file signatures (JPEG/PNG/BMP/GIF headers), analysts can programmatically extract and save individual images without requiring manual binary parsing. This enables recovery of all visual assets embedded in the encrypted resource.
Referenced Locations: 0x406470, 0x402ba0, 0x4b60
BMP file size extraction from header for complete recovery:
BMP files encode their complete size in the file header at offset 2-5 as a 4-byte little-endian integer. When extracting BMP images from the decrypted RC4 resource, read this size field via struct.unpack('<I', data[offset+2:offset+6])[0] to determine the exact number of bytes to extract. This prevents truncation that occurs when using fixed-size extraction or scanning for the next image signature. The size field is mandatory in BMP headers and provides reliable boundaries for multi-image extraction from the 85,441-byte decrypted payload.
Referenced Locations: 0x402ba0
Multiple BMP images embedded in decrypted RC4 resource:
The decrypted RC4 resource (0x4b60) contains multiple BMP image files with standard 'BM' signature (0x42 0x4D). Each BMP includes a complete file header with file size encoded at offset 2-5 as little-endian 4-byte integer. The payload contains sequential BMP structures that can be extracted by reading the file size field from each BMP header and extracting exactly that many bytes. This enables programmatic extraction of all embedded images without manual boundary detection or signature scanning.
Referenced Locations: 0x4b60, 0x402ba0
BMP header fields enable reliable image boundary detection:
Each BMP in the decrypted resource includes critical header fields at fixed offsets: file size at bytes 2-5, pixel data offset at bytes 10-13, image dimensions at bytes 18-25, and bits-per-pixel at bytes 28-29. These fields allow analysts to programmatically determine exact image boundaries and extract complete images without truncation. The file size field is the primary boundary marker—reading this value and extracting exactly that many bytes from the BMP signature position yields a complete, valid image file suitable for analysis or recovery.
Referenced Locations: 0x4b60
Resource size field may not reflect actual encrypted data length:
The IMAGE_RESOURCE_DATA_ENTRY size field (read from offset 0x4 in the data entry structure) indicates 85,441 bytes for resource 0x4b60, but actual encrypted payload in the binary may be truncated or incomplete. When extracting the resource programmatically, verify the actual bytes available at the RVA location match the declared size. If encrypted data is shorter than the size field indicates, the resource extraction is incomplete and BMP files will be truncated. This suggests either the PE resource section is corrupted, the size field is incorrect, or the binary view is not reading the full resource data.
Referenced Locations: 0x42d000, 0x4b60
Resource truncation detection and available data validation:
When extracting resource 0x4b60, the declared size in IMAGE_RESOURCE_DATA_ENTRY (85,441 bytes) may exceed actual bytes available in the .rsrc section. Calculate available bytes as: available = rsrc_section.end - actual_address. If available < declared_size, the resource is truncated. This truncation causes RC4 decryption to produce incomplete BMP files with valid headers but cut-off pixel data. Always validate actual_bytes_read against declared size before decryption to detect binary corruption or intentional stripping. Log discrepancies as: truncation_bytes = declared_size - available_bytes.
Referenced Locations: 0x42d000, 0x4b60
Physical resource truncation confirmed in binary file:
The encrypted resource 0x4b60 is physically truncated in the binary file. The PE header declares 85,441 bytes in IMAGE_RESOURCE_DATA_ENTRY, but the actual raw data in the .rsrc section is shorter. This truncation occurs at the file level, not just in memory views. Verify actual bytes available by reading the .rsrc section header's RawSize field (file size) versus the declared size field. If RawSize < declared size, the resource is incomplete and RC4 decryption will produce truncated output. This indicates either intentional binary stripping during distribution or file corruption during transmission.
Referenced Locations: 0x42d000
Resource extraction requires lenient truncation handling:
When extracting encrypted resource 0x4b60, strict validation against declared size (85,441 bytes) may fail if the binary file contains fewer actual bytes. Instead of rejecting truncated resources, implement lenient extraction that reads all available bytes from the resource location up to the .rsrc section boundary, then passes the actual byte count to RC4 decryption. This approach recovers partial payloads and reveals what data is actually present rather than failing silently. Log both declared size and actual bytes read for diagnostic purposes.
Referenced Locations: 0x42d000, 0x4b60
BMP image extraction from truncated decrypted payload:
When the decrypted RC4 resource is truncated, BMP files may be incomplete but still contain valid headers and partial pixel data. Extract BMPs by scanning for 'BM' signature (0x42 0x4D), reading the file size field at offset 2-5, then extracting exactly that many bytes. If the declared file size exceeds available decrypted data, extract only the available bytes—this produces truncated but valid BMP headers suitable for analysis. Incomplete BMPs reveal the truncation point and indicate how much of the original payload was recovered.
Referenced Locations: 0x4b60
BMP truncation recovery via height adjustment:
When encrypted resource 0x4b60 is truncated, incomplete BMPs can be partially recovered by recalculating the image height based on available pixel data. Calculate row_size = ((width * bpp + 31) // 32) * 4 (with padding), then complete_rows = available_pixel_bytes / row_size. Create a valid but reduced-height BMP by: (1) copying the original header, (2) updating the height field (offset 22) to complete_rows, (3) updating file size field (offset 2) to header_size + (complete_rows * row_size), (4) updating image size field (offset 34) to complete_rows * row_size. This produces a valid, viewable BMP containing all complete scanlines, discarding only the partial final row.
Referenced Locations: 0x4b60, 0x402ba0
BMP header field modification for truncation correction:
Correct truncated BMP files by modifying three header fields: (1) File size at offset 2-5 (4-byte little-endian): set to header_size + (complete_rows * row_size), (2) Height at offset 22-25 (4-byte signed little-endian): set to complete_rows (preserve sign of original height for top-down vs. bottom-up orientation), (3) Image size at offset 34-37 (4-byte little-endian): set to complete_rows * row_size (can be 0 for uncompressed, but should match actual pixel data). These modifications create internally-consistent BMP headers that accurately describe the recovered pixel data, allowing standard image viewers to display the salvaged portions.
Referenced Locations: 0x4b60
Decrypted payload analysis requires string and structure extraction: Analyze the decrypted RC4 resource by extracting ASCII strings (minimum 4 characters, bytes 0x20-0x7E) and Unicode strings (UTF-16LE format with null bytes between characters). These
strings represent dialog captions, control labels, and UI text. Additionally, scan for DLGTEMPLATE structure patterns: check for valid style flags (0x80000000 for WS_POPUP, 0x00C00000 for WS_CAPTION), control count values less than 100, and dimension values between 0-2000. This structural analysis reveals the dialog layout and UI organization without requiring image extraction.
Referenced Locations: 0x4b60, 0x402ba0
RC4-decrypted resource contains only dialog structures, no images: The 85,441-byte RC4-encrypted resource 0x4b60 decrypts to dialog template data and UI strings exclusively. No valid image file signatures (BMP, PNG, JPEG, GIF) exist in the decrypted payload
when validated against strict format specifications. The resource should be analyzed for DLGTEMPLATE structures (checking style flags, control counts, dimensions) and embedded text strings rather than image extraction. This indicates the encrypted resource is purely programmatic UI definition data, not a container for visual assets. Analysts should focus on parsing dialog control definitions and string resources from the decrypted output.
Referenced Locations: 0x4b60, 0x402ba0
4.5 Network Protocol Specifics
5.CRYPTOGRAPHIC ANALYSIS
5.1 Payload Decryption (RC4 Variant)
Algorithm: RC4-variant stream cipher
Function: sub_402ba0
Custom RC4 with 85,441-byte state array (0x14dc1), uses KSA and PRGA for decryption
Key: 4duH61r1b5q0KTnEEPV1ZBQZigyihN0t9ii
Key Length: 35 bytes
State Array Size: 85441 bytes
5.2 Encryption Keys
Primary Key: 4duH61r1b5q0KTnEEPV1ZBQZigyihN0t9ii
Secondary Key: tnCcNAH4
Key Location: 0x427124
Buffer Size: 8192 | Alignment: 64
5.3Algorithm Specifics & Caveats
RC4 key scheduling and PRGA state management for decryption:
RC4 decryption requires two distinct phases: (1) Key Scheduling Algorithm (KSA) initializes a 256-byte S-box by iterating through indices 0-255, accumulating key material modulo key length, and swapping S-box entries based on cumulative sum; (2) Pseudo-Random Generation Algorithm (PRGA) maintains separate i and j indices that increment and swap S-box entries for each byte, with output K = S[(S[i] + S[j]) % 256]. Both phases must maintain state across the entire 85,441-byte payload. The hardcoded key '4duH61r1b5q0KTnEEPV1ZBQZigyihN0t9ii' is used in KSA initialization, making offline decryption feasible without runtime execution.
Referenced Locations: 0x402ba0
BMP scanline padding calculation for truncation recovery:
BMP pixel data is organized in scanlines with mandatory 4-byte alignment padding. Calculate actual row size as: row_size = ((width * bits_per_pixel + 31) // 32) * 4. This formula accounts for bit-level width, rounds up to nearest 4-byte boundary, then multiplies by 4. For example, a 100-pixel 8-bit image has row_size = ((100 * 8 + 31) // 32) * 4 = 128 bytes per row (not 100). This calculation is essential for determining how many complete scanlines fit in truncated pixel data and for reconstructing valid BMP files with correct height values.
Referenced Locations: 0x4b60
BMP signature false positives in binary data analysis:
The byte sequence 0x42 0x4D ('BM' in ASCII) can appear coincidentally in non-image binary data, particularly in dialog templates and string resources. Initial analysis incorrectly identified these as BMP image signatures, leading to invalid dimension calculations (1.7 billion bytes, negative widths, 37468 bits per pixel). When analyzing decrypted binary payloads, validate potential image signatures by checking complete header structures (file size field at offset 2-5, pixel data offset at offset 10-13, DIB header at offset 14) rather than relying solely on signature bytes. This prevents misidentification of dialog data as image files.
Referenced Locations: 0x4b60
5.4 Additional Cryptographic Findings
RC4 encryption key hardcoded in binary:
Resource ID 0x4b60 (type 0xa) containing encrypted GUI elements uses RC4 stream cipher with hardcoded key '4duH61r1b5q0KTnEEPV1ZBQZigyihN0t9ii'. The RC4 implementation is located at sub_402ba0. This static key allows direct decryption of the encrypted payload without runtime key derivation, making the encryption primarily an evasion technique rather than security measure.
Referenced Locations: 0x402ba0, 0x4b60
RC4 implementation with 256-byte S-box key scheduling:
The RC4 cipher implementation at sub_402ba0 uses standard key scheduling algorithm (KSA) to initialize a 256-byte substitution box (S-box) from the passphrase. The algorithm iterates through all
256 values, performing byte swaps based on cumulative key material. This implementation is vulnerable to known RC4 weaknesses (biased output distribution), but the hardcoded key makes decryption straightforward for analysis. The S-box initialization is the critical first step before pseudo-random generation (PRGA) for stream cipher output.
Referenced Locations: 0x402ba0
RC4 pseudo-random generation algorithm (PRGA) implementation:
After S-box initialization, the RC4 PRGA at sub_402ba0 generates keystream bytes by maintaining two indices (i, j) that swap S-box entries and extract output bytes via K = S[(S[i] + S[j]) % 256]. Each encrypted byte is XORed with the corresponding keystream byte. This is the decryption mechanism: decrypted_byte = encrypted_byte XOR K. The algorithm maintains state across all 85,441 bytes of the encrypted resource, making partial decryption impossible without processing from the beginning.
Referenced Locations: 0x402ba0
RC4 decryption with truncated payload handling:
RC4 PRGA at sub_402ba0 maintains state across the entire encrypted payload. If the payload is truncated (fewer bytes than declared), the S-box state will be incomplete when decryption ends. This produces incomplete BMP structures: headers decrypt correctly but pixel data sections are cut short. When decrypting truncated resources, the output will be valid up to the truncation point but subsequent BMP files in the payload will be missing or malformed. Always verify payload completeness before decryption by comparing actual bytes read against declared size in IMAGE_RESOURCE_DATA_ENTRY.
Referenced Locations: 0x402ba0, 0x4b60
6. COMMAND & CONTROL (C2) COMMAND EXECUTION
6.1 Dialog-Based Command Handler
Function: sub_4199e4 (0x4199e4)
Dialog Item ID: 0xe146
Retrieves dialog control and calls vtable function at offset 0x84 for command processing
6.2 Internal Command Message Routing
Mechanism: Windows message passing (SendMessageA) for internal C2 coordination
Functions: sub_4173d0, sub_417d10
Messages Intercepted: 0x30 (WM_SETFONT), 0x80 (WM_SETICON)
7. PERSISTENCE & SYSTEM INTERACTION
7.1 Persistence Mechanisms
Likely Location: HKCU\Software\Microsoft\Windows\CurrentVersion\Run
File Operations: Dynamically constructs paths with .exe extension, uses wide-character strings (LoadLibraryExW)
Registry Access APIs/Locations:
••0x41cd3e
••0x408710
••RegQueryValueExA
••RegOpenKeyExA
••0x41cdd2
••0x41b410
7.2 Core Malware Behaviors
Registry manipulation for persistence or configuration:
Multiple functions implement registry operations including RegCreateKey and RegSetValue patterns. Functions at 0x41cdd2, 0x408710, 0x41cd3e, and 0x41b410 handle registry key creation and value manipulation. This capability is commonly used for malware persistence, configuration storage, or system modification. Analysis should focus on which registry hives are targeted and what values are written.
Referenced Locations: 0x41cdd2, 0x408710, 0x41cd3e, 0x41b410
Process and file execution capability:
Function at 0x408980 implements ShellExecute-like behavior for launching external processes and files. This is a core malware capability used for executing payloads, launching secondary stages, or running system commands. Determine what processes/files are executed and whether execution is conditional or triggered by specific events.
Referenced Locations: 0x408980
Fake legitimate application GUI with red button styling:
Malware creates dialog UI in sub_406740 with multiple controls styled to appear legitimate. Configures button color red (0xff3737) and sets up message handlers for window interaction. This GUI serves as deception layer to make dropper appear as legitimate software with support contact information.
Referenced Locations: 0x406740
Programmatic control styling with hardcoded red color values:
Four UI controls (IDs 0x85, 0x86, 0x84, 0x87) are styled programmatically via sub_408c80 with hardcoded red color value 0xff3737 and dimension parameters (4, 8, 0x14, 5). Each control is registered via sub_401200 after styling. This programmatic approach to UI styling, rather than resource-based styling, allows dynamic modification of appearance and makes the controls harder to identify through static resource analysis.
Referenced Locations: 0x406740, 0x408c80, 0x401200
7.3 Additional System Interactions
Multi-fallback URL launching mechanism:
Function sub_4020b0 uses ShellExecuteA to open URLs with SW_SHOWMAXIMIZED flag. Function sub_408980 implements fallback chain: if ShellExecute fails, attempts registry-based browser launching, then falls back to WinExec. This ensures URLs are opened regardless of system configuration or missing default handlers.
Referenced Locations: 0x4020b0, 0x408980
Font configuration via WM_SETFONT message dispatch:
Dialog font is configured by sending WM_SETFONT message (0x80) via SendMessageA with parameters (hWnd, 0x80, 1, arg1[0x17]) and (hWnd, 0x80, 0, arg1[0x17]). The font handle is stored at offset 0x17 in the dialog structure. This message-based font configuration allows runtime font switching and is applied after control creation, enabling dynamic UI appearance modification.
Referenced Locations: 0x406740
Binary Ninja API for RVA to file offset conversion:
When extracting resources programmatically in Binary Ninja, use bv.get_data_offset_for_address(rva) to convert RVA to file address. If this returns None, fall back to manual calculation: file_offset = RVA - section_VirtualAddress + rsrc_section.start. This dual approach handles both mapped and unmapped address spaces, ensuring reliable resource extraction regardless of binary view configuration.
Referenced Locations: 0x42d000
Fallback RVA-to-address conversion for resource extraction:
When extracting encrypted resources programmatically, use dual-method RVA conversion to handle different binary view configurations. First attempt: convert RVA to actual address via image base offset (RVA + 0x400000). If this returns 0 bytes, fall back to section-relative calculation: file_offset = RVA - 0x2d000 + rsrc_section.start. This dual approach accounts for whether the binary view maps addresses relative to image base or section base, ensuring reliable resource data extraction regardless of analysis tool configuration.
Referenced Locations: 0x42d000
Resource directory entry structure parsing with bit flag handling:
When parsing PE resource directory entries, the 4-byte offset field uses a high bit (0x80000000) to indicate whether the entry points to a subdirectory (bit set) or a data entry (bit clear). Subdirectory pointers must be masked with 0x7FFFFFFF before use. Data entry offsets do NOT have this bit set. This distinction is critical: type and ID directory entries use the high bit flag, but language directory entries pointing to IMAGE_RESOURCE_DATA_ENTRY structures do not. Failure to handle this correctly results in reading from wrong offsets.
Referenced Locations: 0x42d000
XOR-based stream cipher decryption operation:
RC4 decryption uses XOR operation: each encrypted byte is combined with the corresponding keystream byte via XOR (^). The operation is symmetric: encryption and decryption use identical algorithms. To decrypt programmatically, iterate through encrypted bytes, generate keystream bytes via PRGA, and XOR each pair. The result is the plaintext dialog template. This XOR operation is the final step in the decryption pipeline and produces human-readable dialog structures and strings.
Referenced Locations: 0x402ba0
Dual-method resource extraction with size validation:
When extracting resource 0x4b60 programmatically, after reading the size field from IMAGE_RESOURCE_DATA_ENTRY, verify the actual bytes retrieved match the declared size. Implement validation: if Method 1 (RVA + 0x400000) returns fewer bytes than the size field indicates, immediately fall back to Method 2 (RVA - 0x2d000 + rsrc_section.start). If Method 2 also returns incomplete data, log the discrepancy (bytes_read vs. size_field) as this indicates resource corruption or binary truncation. This validation prevents silent data loss and ensures complete RC4 decryption of the 85,441-byte payload.
Referenced Locations: 0x42d000, 0x4b60
Resource extraction with truncation handling and fallback sizing: Implement resource extraction with automatic truncation detection: (1) Read IMAGE_RESOURCE_DATA_ENTRY to get RVA and declared size, (2) Calculate actual_address =
resource_base + (RVA - 0x2d000), (3) Check bounds: available = rsrc_section.end - actual_address, (4) If available < declared_size, use actual_size = available and log truncation warning, (5) Read actual_size bytes from actual_address, (6) Pass actual_size (not declared size) to RC4 decryption. This prevents silent data loss and ensures RC4 state machine processes only available encrypted bytes.
Referenced Locations: 0x42d000, 0x4b60
PE section header parsing for raw file size verification:
To detect physical resource truncation, parse the PE section header for .rsrc: read RawSize field (offset +16 in section header, 4-byte little-endian) which indicates actual bytes in the file, and RawOffset field (offset +20, 4-byte little-endian) which indicates file position. Compare RawSize against the declared size in IMAGE_RESOURCE_DATA_ENTRY. If RawSize is smaller, the resource is truncated at the file level. This verification must occur before attempting resource extraction to avoid silent data loss during RC4 decryption.
Referenced Locations: 0x42d000
PE header navigation for section header extraction:
To locate .rsrc section header: (1) Read PE offset from DOS header at file offset 0x3c (4-byte little-endian), (2) Read number of sections from PE+6 (2-byte little-endian), (3) Read optional header size from PE+20 (2-byte little-endian), (4) Calculate section headers start: PE+24+optional_header_size, (5) Iterate through section headers (40 bytes each), reading section name (8 bytes), VirtualSize (4 bytes at +8), VirtualAddress (4 bytes at +12), RawSize (4 bytes at
+16), RawOffset (4 bytes at +20). This parsing reveals actual file-level resource dimensions independent of PE virtual address space.
Referenced Locations: 0x42d000
Programmatic resource extraction via raw file parsing:
Extract encrypted resources by reading the binary file as raw bytes rather than relying on binary view APIs. Parse PE header (offset 0x3c), locate .rsrc section header in section table, read RawOffset and RawSize fields, then navigate resource directory structure from the raw file offset. This direct file-based approach bypasses binary view address mapping issues and provides accurate byte counts. Calculate resource data location as: file_offset = (RVA - rsrc_virtual_addr) + rsrc_raw_offset, then read min(available_bytes, declared_size) from that location.
Referenced Locations: 0x42d000
8. STEALTH & EVASION TECHNIQUES
No Direct Network Apis: Uses ShellExecute instead of socket/WinINet APIs
Ui Based Deception: Appears as legitimate application with clickable links
Legitimate Infrastructure: Abuses Tripod hosting and Yahoo email services
Error Suppression: SetErrorMode(SEM_ALL_ERRORS | 0x8001) to hide error dialogs
Asynchronous Communication: User-initiated C2 connections blend with normal browsing
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
