The binary implements a multi-stage bootstrap and staged execution pattern centered at the entrypoint _start (0x402610). _start calls sub_4010e0 to resolve API pointers, loads resources 0x68 and 0x69 (RT_RCDATA) and converts one resource with MultiByteToWideChar. The sequence of setup and control functions includes sub_402bf0() (decodes and executes embedded commands via sub_402b60), sub_4032a0() (bulk decode and registration of obfuscated strings and enumeration triggers), sub_407fa0(), sub_4025b0(), sub_408bd0(), sub_408c10(), and sub_408c50() (system info, worker-pool initialization, worker creation and shutdown). Discovery and staging proceed via sub_4024b0(&i_3) and sub_402990(&i_2) for network target discovery. There is a producer-consumer pipeline implemented with globals such as data_40ce9c (dispatcher/queue), enqueue functions sub_408ca0 and sub_4025c0, and worker creation (sub_408c10) with handles tracked in data_40cea0. The design does not show privilege separation; all actions occur in a single process with multiple threads.

Resource-based configuration and embedded payloads are loaded at initialization: _start (0x402610) calls FindResourceA, SizeofResource, LoadResource, LockResource to access resources 0x68 and 0x69 and converts data with MultiByteToWideChar before handing it to sub_4032a0 and sub_402bf0. No direct evidence of registry Run keys, scheduled tasks, Windows services, plist/systemd units, or other explicit persistent autostart artifacts was found in the analyzed functions. However, sub_402bf0 decodes and executes arbitrary command strings via sub_402b60 (which calls CreateProcessA), so persistence could be implemented by those decoded commands; the decoded command texts were not included in the analyzed subset and remain unknown.

No explicit persistence vectors (registry Run keys, scheduled tasks, services, startup folders) were observed in the analyzed functions. The capability to execute decoded commands (sub_402bf0 -> sub_402b60 using CreateProcessA with CREATE_NO_WINDOW) creates a likely mechanism by which the binary could implement persistence, but the specific decoded commands were not available to confirm persistence actions. No UAC bypass or token-stealing routines were identified in the inspected functions.

The binary uses two-tier obfuscation for static strings and embedded data: a 128-bit SIMD/XMM XOR using data_4099d0 implemented in sub_401000 and a trailing-byte single-byte XOR with 0x99. sub_401000 performs 16-byte lane XORs and per-byte XOR for tails. sub_4010e0 dynamically reconstructs module and API names at runtime, calling GetModuleHandleA, LoadLibraryA, and GetProcAddress to populate API pointers in global data_40c*. sub_4032a0 decodes dozens/hundreds of data regions (e.g., regions at 0x40b5d4, 0x40ac60) with this primitive. The import table in the binary metadata is empty, consistent with the runtime import resolution design. No packer header was conclusively identified, but the obfuscation and empty import table emulate manual packing/self-unpacking behavior.

Anti-analysis techniques observed are largely obfuscation-based: empty import table with runtime GetProcAddress resolution (sub_4010e0), and encrypted/obfuscated strings decoded only at runtime (sub_401000, sub_4032a0). No explicit VM or sandbox detection (e.g., IsDebuggerPresent, timing checks, known VM artifacts) or debugger-compromised exits were observed in the examined functions. The primary evasion technique is import/string obfuscation rather than explicit environment detection in the functions analyzed.

sub_401000 (0x401000) is a SIMD-assisted deobfuscator that applies a 128-bit XOR with data_4099d0 and a trailing per-byte XOR 0x99. sub_4010e0 (0x4010e0) performs dynamic API resolution and sets initialization flags in data_40cdcc. _start (0x402610) orchestrates initialization, resource loading, and calls to sub_402bf0, sub_4032a0, sub_408bd0, and network/discovery functions. sub_402bf0 decodes many embedded commands and executes them via sub_402b60 (0x402b60), which calls CreateProcessA with CREATE_NO_WINDOW and waits for completion. sub_4032a0 decodes bulk data and triggers enumeration/search behavior using tokens like data_409794. Network discovery is implemented by sub_402990 (0x402990) enumerating local IPs and spawning worker threads (sub_402900) which call sub_402800 to enumerate SMB shares using a resolved enumerator pointer in data_40cdf0. File staging and traversal are performed by sub_407fe0 (0x407fe0), which excludes system directories and enqueues candidate files via sub_408ca0. Worker pool lifecycle is managed by sub_408bd0, sub_408c10 (0x408c10), and sub_408c50 (0x408c50). Per-file contexts are prepared in sub_408480 and processed by worker threads running thread_main (0x408830).

Observed capabilities focus on local network enumeration rather than external C2: sub_402990 enumerates local IP addresses (calls InetNtopW via resolved pointers), sub_4024b0 and sub_402800 enumerate servers and SMB shares (building UNC paths via wsprintfW/lstrcatW) and queue UNC targets for processing. There is no direct evidence in the analyzed functions of outbound C2 channels (no socket creation, no HTTP(S) client code, no DNS beacons) although sub_4032a0 and sub_402bf0 decode many strings that could include network endpoints used outside the analyzed subset. The observed network logic aligns with lateral discovery and propagation across SMB.

The binary collects system information (calls to GetNativeSystemInfo referenced in _start and sub_402bf0) and builds lists of network and filesystem targets. It reads user files discovered by sub_407fe0, processes them in chunked loops (thread_main calling functions like the resolved data_40cdb0/data_40cd94/data_40cdc8 helpers), and writes modified content back to disk before renaming files with the .CONTI extension. Ransom notes HOW_TO_DECRYPT.txt are created per directory. No evidence in the inspected functions shows automatic exfiltration of file contents; however, executed decoded commands could implement exfiltration.

Obfuscation uses weak XOR primitives (sub_401000 with data_4099d0 and 0x99). Operational cryptography uses CryptoAPI via the Microsoft Enhanced RSA and AES Cryptographic Provider string acquisition in thread_main (0x408830), implying RSA and AES operations. The worker loop performs chunked read/encrypt/write operations (data_40cdb0, data_40cd94, data_40cdc8) in thread_main, and files are then renamed to append .CONTI. No explicit private keys or key-exchange endpoints were found in the analyzed functions; key generation, wrapping, or storage locations are not visible in this subset and remain to be located.

No code paths were identified that harvest OS credential stores (LSASS, browser vaults, or SAM) in the analyzed functions. The SMB/share enumeration may access network shares using credentials available to the process (implicit network access), but how credentials are obtained or whether credential reuse/stealing is attempted is not shown in the inspected code.

High-confidence destructive capabilities are present: encryption-like modification of user files via chunked transforms and renaming to .CONTI (thread_main), and creation of per-directory ransom notes HOW_TO_DECRYPT.txt (sub_407fe0). No evidence of additional destructive actions such as Volume Shadow Copy deletion, MBR overwrite, or backup disabling was found in the analyzed functions, though decoded commands executed by sub_402bf0 could implement such steps.

The binary shows moderate-to-high engineering quality: a well-structured multi-threaded design with a synchronized producer-consumer queue (data_40ce9c), careful worker lifecycle management (sub_408bd0, sub_408c10, sub_408c50), and fallback handling for file sharing/lock errors when opening files (sub_408480 using alternative strategies via data_40cda8, data_40cda0, data_40cdf8). Error checking and cleanup exist in resource paths. The deliberate obfuscation increases analysis difficulty but does not indicate sloppiness; rather, it indicates purposeful hardening.

The binary targets Microsoft Windows: heavy use of Win32 APIs (GetModuleHandleA, GetProcAddress, CreateProcessA, CreateThread, MoveFileW, MultiByteToWideChar), CryptoAPI provider strings, STARTUPINFOA/PROCESS_INFORMATION usage, critical sections, and wide-string (W) APIs for filesystem and UNC path operations. Worker and network code rely on Windows-specific enumerators and SMB UNC creation routines. Calling conventions and APIs indicate a native Windows PE executable.