2CLoader: A New Malware Loader Delivering Vidar and Remus

The following sections analyze 2CLoader’s core features and cover malware delivery trends associated with the loader.

String encryption

Important strings in 2CLoader are decrypted at runtime using an inlined bitwise XOR operation applied to global values. The key in the analyzed sample is 0x37.

Indirect system calls

For the Nt* APIs listed below, 2CLoader prefers indirect system calls to evade inline API hooks commonly used by security software for detection.

• NtProtectVirtualMemory 
• NtUnmapViewOfSection 
• NtQueryInformationProcess 
• NtDelayExecution 
• NtSetContextThread 
• NtGetContextThread

2CLoader uses the Hell’s Gate technique to perform indirect system calls. The loader maps a fresh copy of ntdll from disk, retrieves the export addresses of the APIs listed above, and checks whether each stub begins with one of the following two patterns.

4C 8B D1    mov r10, rcx
B8 xx xx xx xx  mov eax, ssn

or

F3 0F 1E FA    endbr64          # CET-prefixed variant
4C 8B D1       mov r10, rcx
B8 xx xx xx xx mov eax, ssn

If the stub matches one of these patterns, 2CLoader extracts and stores the 4-byte syscall ID. The loader also walks the Process Environment Block (PEB) to obtain the in-memory module base of ntdll.dll and scans executable sections for the syscall gadget (0F 05 C3 which maps to syscall, ret). 2CLoader stores the six syscall gadget addresses in global variables for later use when performing indirect system calls.

If indirect system call initialization fails, a fallback mechanism resolves the six APIs listed above using GetProcAddress and stores the resulting export addresses in global variables.

Loader configuration

2CLoader stores its configuration and encrypted payload as a Portable Executable (PE) resource. The resource has the following structure:

[final payload] [optional payload dropped] [optional message shown using MessageBoxW] [configuration]

The configuration occupies the last 0xDC bytes of the resource and begins with the 4-byte magic value 2C 3D 4E 5F. The configuration uses the following structure:

 struct 2cloader_config
{
uint32_t magic; // Magic bytes 2C 3D 4E 5F.
uint32_t fl; // Payload execution options, explained in later sections. Sent in the registration message.
uint32_t payload_size_before_decompression; // Final payload size before decompression.
uint32_t aes_gcm_nonce_size; // AES-GCM nonce length used for final payload decryption.
uint32_t aes_gcm_tag_size; // AES-GCM tag length used for final payload decryption.
uint8_t aes_gcm_nonce[0xC]; // AES-GCM nonce for the final encrypted payload.
uint8_t aes_gcm_tag[0x10]; // AES-GCM authentication tag for the final encrypted payload.
uint8_t sha256_seed_xor2[0x10]; // Bitwise XOR applied to bytes 0x00-0x0F of the 32-byte AES key seed.
uint8_t sha256_seed_xor1[0x10]; // Bitwise XOR applied to bytes 0x10-0x1F of the 32-byte AES key seed.
uint32_t sum_of_bytes_checksum; // Byte-sum checksum used to validate the derived AES-256 key.
uint32_t persistence_option; // Persistence options, explained in later sections.
uint32_t opt_flag; // Customizable options flag (anti-VM, anti-debug, etc.). Explained in later sections.
uint32_t optional_payload_dropped_size; // Size of the additional payload to be dropped.
uint32_t messageboxw_message_size; // Size of the appended MessageBox caption/text block.
uint8_t xor_add_after_rolling_xor; // Per-byte increment used in the second XOR stage.
uint8_t xor_key_after_rolling_xor; // Initial constant used in the second XOR stage.
uint8_t rolling_xor_seed; // Seed for the first rolling XOR layer.
uint8_t unk_67; // Not used anywhere; set to zero.
uint32_t sleeptime; // Malware sleep time in milliseconds (ms) before payload decryption.
uint8_t ID[0x10]; // ID used in the start message.
char target_executable_name_used_in_injection[0x40]; // Target executable names used for injection.
uint32_t bt; // Sent in the registration message with the key name bt. Not used elsewhere.
char pn[0x10]; // Sent in the registration message with key name pn. Contains a file name such as default.exe or build_tbuild.exe. Not used elsewhere.
uint32_t unk_D0; // Not used anywhere; set to zero.
uint32_t scheduled_tasks_trigger_interval_hours; // Scheduled task trigger interval in hours.
uint32_t decompressed_buffersize_of_payload; // Final payload size after decompression.
};

Payload decryption

2CLoader first decrypts the resource body (excluding the last 0xDC bytes) using a rolling XOR driven by the rolling_xor_seed from the configuration. Each byte is XOR’ed with a value that starts with the rolling_xor_seed and is incremented by one for each subsequent byte. After that, the loader applies a second XOR layer using the xor_key_after_rolling_xor (from the configuration) as the initial value and xor_add_after_rolling_xor as the per-byte increment. This produces the AES-GCM ciphertext that the loader uses in the next stage.

2CLoader then derives the AES key from its own image. The loader calculates the SHA256 of the first executable section in memory, usually .text, and uses that 32-byte digest as the base key material. The first half of that digest is XOR’ed with the sha256_seed_xor2 field and the second half is XOR’ed with sha256_seed_xor1. The resulting 32-byte buffer is the AES key, which is validated using sum_of_bytes_checksum. If the checksum matches, the loader uses aes_gcm_nonce and aes_gcm_tag to perform AES-GCM decryption of the transformed resource body.

In the final step, 2CLoader treats the AES plaintext as three concatenated parts. The first part is the final payload, the second part is an optional dropped payload of size optional_payload_dropped_size, and the third part is an optional MessageBoxW block of size messageboxw_message_size. Only the first payload is decompressed, and only when decompressed_buffersize_of_payload is nonzero. Decompression uses Xpress Huffman and expands the first part from payload_size_before_decompression to decompressed_buffersize_of_payload, while the second and third parts are left unchanged. The payload decryption script is available in the ThreatLabz GitHub repository.

ANALYST NOTE: If the 0x1 flag in opt_flag is enabled, 2CLoader also performs a timing-based check after calculating the SHA256 digest. It runs an arithmetic operation in a loop 3,000,000 times. If this loop completes in fewer than 2,000,000 CPU cycles, all 32 bytes of the SHA256 digest are XOR’ed with 0xFF. This is intended to mislead emulators by producing an incorrect key seed.

Custom options flag (opt_flag)

The opt_flag configuration value controls which custom options 2CLoader enables. Multiple options can be combined using a bitwise OR operation. The supported values and their behavior are listed in the table below.

Table 1: Supported opt_flag values and their functions in 2CLoader.

Anti-VM detection

The anti-VM logic uses two decision models. The first is a hard-fail path, in which a single condition is enough to classify the victim machine as a VM. The second is a score-based path, in which 2CLoader builds a score from multiple checks. If any hard-fail check triggers or the final score is below 8, the loader exits before decrypting the payload.

• Hard-fail checks: 2CLoader first performs a CPUID-based (EAX = 1) virtualization check. If the hypervisor bit is not set, this check passes immediately. If the hypervisor bit is set, the malware queries the hypervisor vendor with CPUID EAX=0x40000000. VMware, VirtualBox, KVM, Xen, Parallels, and QEMU TCG are blocklisted; Microsoft Hyper-V is explicitly allowed. The malware also checks loaded modules, running process names, VM-related MAC address prefixes, and registry keys associated with VirtualBox, VMware, and Wine against a blocklist. For registry keys, it checks whether a key exists and contains subkeys or values. If any of these checks match, the anti-VM check fails. A timing check also causes failure if the anti-VM checks take more than 200 ms.
• Score-based checks: If 2CLoader passes the hard-fail stage, it proceeds to a score-based environment check. The base score is 5. The malware adds one point for each of the following conditions:
  • The current process count is above 25. 
  • The logical processor count is at least 2. 
  • Total physical memory is at least 2 GB. 
  • Total disk size is at least 40 GB. 
  • System uptime is greater than 3 minutes. 
  • ProcessDebugPort is 0. 
  • %APPDATA%\Microsoft\Windows\Recent\* contains at least 2 files. 
  • Screen resolution is larger than 800 x 600.
  • The current username does not match the blocklist. 
  • The computer name does not match the blocklist. 
  • The cursor position changes within 500 ms.

2CLoader continues checking even if the score has reached 8. A final score of 8 or higher causes 2CLoader to treat the system as a physical machine.

The complete blocklist is available in the ThreatLabz GitHub repository.

Persistence

Persistence for 2CLoader is controlled by the persistence_option field in the configuration. The loader can enable multiple persistence methods simultaneously by combining the flags using a bitwise OR operation. In all cases, the persistence entry points to the current malware file path. The supported values and their corresponding persistence methods are listed in the table below.

Table 2: Supported persistence_option values and their corresponding persistence methods in 2CLoader.

Inline trampoline hooks

After payload decryption, if the 0x400 flag in opt_flag is enabled, 2CLoader sets inline trampoline hooks on a set of Windows API functions in the current process. In the analyzed sample, there are around 20 such hooks, but only a few important ones are discussed here. The common pattern is that the original API entry point is patched to redirect execution through a malware-controlled trampoline, allowing the loader to modify the returned data.

These hooks perform two functions: network data tampering where API return buffers are scanned and modified, and environment spoofing, where values related to host identity, such as username, computer name, volume serial number, registry data, or environment variables, are replaced with random, but properly formatted values. The replacement data is crafted to preserve the expected structure of the original value. The table below shows the hooked APIs and their behavior.

Table 3: Windows APIs hooked by 2CLoader and the behavior of their hooks.

The goal of environment spoofing is to provide fake system information about the victim’s system while still matching the format expected by the API call. The exact intention behind these hooks is not clear, but may they may have been designed to confuse malware sandboxes.

Payload execution options

The opt_flag and fl fields control how 2CLoader executes the payload. Each field can contain multiple values combined with a bitwise OR operation. Before executing the final payload, 2CLoader processes two optional blobs appended after the final payload in the decrypted buffer. The first optional blob is treated as an additional PE file. If present, the loader writes it to a temporary .exe file, launches it, and if execution succeeds, schedules it for deletion on reboot. If the 0x80 flag in opt_flag is set, the loader spoofs explorer.exe as the parent process (parent process ID, or PPID, spoofing) and enables SeDebugPrivilege for the new process. The second optional blob contains the caption followed by the message text, separated by a null terminator. If neither of the bits in the 0x6 mask is set in fl and the 0x20 flag in opt_flag is not set, the loader displays the message box in the current thread before continuing. Otherwise, it copies the message block to heap memory and displays it from a helper thread so execution can continue asynchronously.

If the 0x2 flag in fl is set, the payload is treated as a managed .NET assembly and executed directly from memory via Common Language Runtime (CLR) hosting. In this mode, the loader loads mscoree.dll, initializes the CLR, creates a SAFEARRAY from the payload bytes, loads the assembly from memory, and invokes its entry point. If the 0x2 flag in fl is not set but the 0x4 flag is set, the loader forces the RunPE path. The figure below shows how the loader selects the execution method based on fl.

When neither the 0x2 nor the 0x4 flag in fl is set, 2CLoader enters the next branch. Here, the loader switches between LoadPE and RunPE based on the 0x20 flag in opt_flag. When this flag is not set, it tries LoadPE first and falls back to RunPE if that fails. When the flag is set, it tries RunPE first and falls back to LoadPE if needed. The LoadPE path is an in-process manual PE loader that maps the payload into the current process, fixes relocations and imports, updates PEB->ImageBaseAddress to the base address of the mapped payload, spoofs the command line to svchost.exe, and starts the payload in a new thread.

The RunPE path creates a suspended process, using the target image specified in the configuration field target_executable_name_used_in_injection that defaults to dllhost.exe. The loader first creates a temporary file, immediately marks it as DeletePending via NtSetInformationFile(FileDispositionInformation), and writes the payload to this file. The file handle is then passed to NtCreateSection with the SEC_IMAGE allocation attribute, creating an image section from the payload. That SEC_IMAGE section is mapped into the suspended target process, the remote PEB->ImageBaseAddress is updated to the base address of the newly mapped section, the suspended primary thread is redirected to the payload entry point, and execution is resumed.

The RunPE path supports both x64 and x86 payloads. For x64 payloads, if the 0x400 flag in opt_flag is set, the loader performs an additional step before the payload entry point is reached. In this mode, hooks are placed inside the remote process on WinHttpReadData and InternetReadFile. The purpose of these hooks is to scan received data for IPv4 addresses and replace the last two octets with random but valid decimal values while preserving the IPv4 format.

Network communication

2CLoader uses HTTP for command-and-control (C2) communication. The C2 URL is encrypted using the same string encryption scheme. Outbound messages are formatted as JSON and then XOR-encrypted before being sent in the body of an HTTP POST request. The XOR key used for network encryption is 4A 7B 3C 1D 8E 5F A0 D1 62 93 24 F5 B6 47 C8 09 E1 72 53 84 35 A6 D7 18 49 FA 0B 6C 9D 2E BF 50.

The first message sent to the C2 server is a registration message. Its keys are listed below:

Table 4: JSON keys used in 2CLoader’s registration message.

Below is an example 2CLoader network communication for a registration message.

POST /api/beacon HTTP/1.1
Connection: Keep-Alive
Content-Type: application/octet-stream
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36
Content-Length: 252
Host: aware-cr1.com

An example POST body (after XOR decryption) is shown below:

{"id":"18c070b8d032336a244440df1115123d","s":"start","ok":1,"t":0,"os":[10,0,19044],"pid":1408,"adm":0,"fl":0,"opt":1152,"cpu":4,"arch":9,"dll":0,"ram":4195,"lc":"en-US","bt":1787666555,"pn":"default.exe","path":"C:/Users/Bruno/Desktop/executable.exe"}

After registration, 2CLoader sends additional event messages to report execution status. These messages are also constructed as JSON and then encrypted using the same XOR-based scheme. The event format is as follows:

{
 "id":[32 hexadecimal characters from ID],
 "s":[event name],
 "ok":[0 or 1],
 "t":[Total malware elapsed time in ms],
 "x":[additional argument for the event],
 "ec":[error code from GetLastError()],
 "pid":[malware process ID]
}

Malware delivery

ThreatLabz identified a number of 2CLoader samples to identify which malware families were being distributed by the loader. ThreatLabz found 2CLoader used to primarily deliver information stealers including Vidar and Remus. The pie chart below illustrates the distribution of the malware families distributed via 2CLoader.

Figure 2: Distribution of malware families delivered by 2CLoader in samples identified by ThreatLabz.

ThreatLabz has developed a Python script to decrypt 2CLoader payloads. The script is available in our GitHub repository.