New 2CLoader Malware Uses Anti-VM and API Hooking to Deliver Vidar and Remus Stealers

A new Windows malware loader, tracked as 2CLoader, that combines extensive anti-analysis logic, indirect system calls, API tampering, and flexible in-memory execution to deliver Vidar and Remus information stealers.

Researchers also observed the loader distributing XWorm RAT, indicating that its operators can use the framework to deploy multiple payload families.

Its layered design makes it a notable addition to the expanding loader ecosystem used to deploy credential-stealing malware and remote-access tools.

2CLoader begins by decrypting internal strings through an inline XOR routine, then initializes indirect system calls for several sensitive Windows Native APIs, including NtProtectVirtualMemory, NtUnmapViewOfSection, NtQueryInformationProcess, NtDelayExecution, NtSetContextThread, and NtGetContextThread.

The malware uses the Hell’s Gate technique to extract system service numbers from a clean ntdll.dll image mapped from disk.

It then locates syscall; ret gadgets in the in-memory ntdll executable sections, allowing it to invoke kernel services without directly calling potentially hooked API exports.

This approach is intended to bypass inline API monitoring commonly used by endpoint detection and response products.

If the indirect syscall setup fails, 2CLoader falls back to resolving the same functions through GetProcAddress.

Its anti-VM logic includes a hard-fail path and a score-based environment assessment.

The hard-fail checks inspect CPUID hypervisor indicators, virtual-machine vendor identifiers, VM-related modules, processes, MAC prefixes, and registry artifacts associated with VMware, VirtualBox, KVM, Xen, Parallels, QEMU, and Wine. Microsoft Hyper-V is explicitly allowed.

The score-based component evaluates system realism by checking process count, processor count, RAM, disk capacity, uptime, display resolution, recent-file activity, cursor movement, and host naming.

A host that scores below eight is treated as an analysis environment and the loader exits before payload decryption.

It also uses IsDebuggerPresent, CheckRemoteDebuggerPresent, and timing checks to identify debugging activity.

2CLoader can install inline trampoline hooks in Windows APIs after decrypting its payload. These hooks modify data returned to applications or malware running within the process, potentially complicating sandbox analysis and downstream payload behavior.

Zscaler ThreatLabz said in a report shared with GBhackers, 2CLoader is designed to survive analysis, evade endpoint detection, and deliver encrypted payloads only after determining that an infected host is a genuine victim system.

2CLoader Malware

The hooks target APIs including InternetReadFile, WinHttpReadData, RegQueryValueEx, GetUserName, GetComputerName, GetVolumeInformation, and GetEnvironmentVariable.

The opt_flag and fl fields control how 2CLoader executes the payload. Each field can contain multiple values combined with a bitwise OR operation. 

For example, the malware can alter the last two octets of IPv4 addresses received from network APIs, replace usernames with values such as “admin” or “gamer,” generate DESKTOP-prefixed hostnames, spoof GUIDs, and return fabricated system-manufacturer information.

This environment spoofing is particularly unusual because it preserves expected data formats rather than simply blocking API calls.

The technique could mislead security tools, sandboxes, or follow-on malware that relies on host-identification data.

2CLoader stores its configuration and encrypted payload inside a PE resource. The embedded data is protected with two rolling XOR stages followed by AES-GCM encryption.

The AES-256 key is derived from the SHA-256 hash of the loader’s first executable section, usually .text, then modified using configuration-specific XOR seed values.

The decrypted resource can contain a final payload, an optional dropped executable, and an optional MessageBoxW message. The primary payload may also be compressed with Xpress Huffman.

ThreatLabz released a Python payload-decryption utility to support defenders and malware analysts investigating 2CLoader samples.

Depending on its configuration, 2CLoader can execute .NET payloads directly from memory using CLR hosting, manually map PE files through LoadPE, or use RunPE process hollowing-style execution.

The RunPE path creates a suspended target process defaulting to dllhost.exe maps a malicious SEC_IMAGE section, redirects the primary thread to the payload entry point, and resumes execution.

The loader supports persistence through Registry Run and RunOnce keys, the Startup folder, scheduled tasks, the Windows Load value, and UserInitMprLogonScript.

It communicates with command-and-control infrastructure through HTTP POST requests containing XOR-encrypted JSON registration and execution-status messages.

Organizations should prioritize behavior-based detections for indirect syscalls, suspicious ntdll mapping, API trampoline hooks, anomalous scheduled-task creation, and process injection into legitimate Windows binaries.

Defenders should also monitor for the credential-theft impact associated with Vidar and Remus, rather than relying solely on payload-specific signatures.

IOCs

URL	Description
https://aware-cr1[.]com/api/beacon	2CLoader C2
http://62.60.226[.]185/t0907.exe	2CLoader ITW URL

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC