2CLoader: evasion layer, payload chain and detection points

Source, scope and evidence boundary

ThreatLabz published a technical analysis of 2CLoader and a Python payload-extraction tool on 30 September 2026. This review reads both primary sources against each other: which structure is actually encoded in the tool, which behavioural claims depend exclusively on ThreatLabz sample and telemetry analysis, and which defensive consequences follow?

We did not possess a 2CLoader sample. The companion code was not executed with malware. Runtime behaviour, delivered families and infrastructure therefore remain explicitly attributed to the primary source.

What is supported — and what is missing

The report and companion code form two different evidence layers. The report describes observed samples, execution options and campaign telemetry. The tool implements resource discovery, footer structure and the decryption sequence. Without an original sample, this implementation cannot be replayed here against a concrete build.

The footer is the control plane

The public tool expects exactly 0xDC bytes of configuration at the end of the PE resource. A magic value identifies the footer; size fields separate the main payload, an optional additional file and an optional message. Other fields control persistence, anti-analysis, target process, sleep time and scheduled task.

This matters defensively because the footer links a statically visible structure to later behaviour. A magic value alone would be too brittle for detection; combined with PE-resource placement, plausible size relationships and subsequent process activity it becomes stronger.

80def parse_footer(footer_bytes: bytes) -> configfooter:
81
82    if struct.unpack_from("<I", footer_bytes, 0)[0] != FOOTER_MAGIC:
83        fail()
84
85    dwords = struct.unpack("<55I", footer_bytes)
86    return configfooter(
87        magic=dwords[0],
88        fl=dwords[1],
89        final_payload_size=dwords[2],
90        aes_gcm_nonce_size=dwords[3],
91        aes_gcm_tag_size=dwords[4],
92        aes_gcm_nonce=footer_bytes[0x14:0x20],
93        aes_gcm_tag=footer_bytes[0x20:0x30],
94        sha256_seed_xor2=footer_bytes[0x30:0x40],
95        sha256_seed_xor1=footer_bytes[0x40:0x50],
96        sum_of_bytes_checksum=dwords[20],
97        persistence=dwords[21],
98        opt_flag=dwords[22],
99        optional_payload_size=dwords[23],
100        optional_message_size=dwords[24],
101        xor_add_after_rolling_xor=footer_bytes[0x64],
102        xor_key_after_rolling_xor=footer_bytes[0x65],
103        rolling_xor_seed=footer_bytes[0x66],
104        unk_67=footer_bytes[0x67],
105        sleeptime=dwords[26],
106        beacon_id=footer_bytes[0x6C:0x7C],
107        target_executable_name_used_in_injection=footer_bytes[0x7C:0xBC],
108        bt=dwords[47],
109        pn=footer_bytes[0xC0:0xD0],
110        unk_D0=dwords[52],
111        scheduled_tasks_trigger_interval_hours=dwords[53],
112        decompressed_buffer_size=dwords[54],
113    )

From resource to three outputs

The documented processing path is fixed: locate the resource, apply rolling XOR, apply a second XOR stage, derive a key from configuration and code hash, perform authenticated AES-GCM decryption and optionally decompress Xpress Huffman. Only then are the main payload, optional extra file and message block separated.

AES-GCM does not protect the victim here; it protects the embedded payload from simple static extraction. The authentication tag also creates a hard validation step: incorrect key derivation or altered data breaks the chain.

316def extract_decode_and_write(pe_path: str | Path, out_dir: str | Path):
317    resource = find_footer_resource(pe_path)
318    footer = resource["footer"]
319    out_dir = Path(out_dir)
320    out_dir.mkdir(parents=True, exist_ok=True)
321
322    section_sha256_seed = compute_section_sha256_seed(pe_path)
323    stage1 = decode_resource_stage(resource["body"], footer.rolling_xor_seed)
324    stage2 = xor_decrypt_payload(bytearray(stage1), footer.xor_add_after_rolling_xor, footer.xor_key_after_rolling_xor)
325    aes_key = generate_aes_key(footer, section_sha256_seed)
326    aes_plaintext = aes_gcm_decrypt(stage2, footer, aes_key)
327    final_buffer = decompress_final_payload(aes_plaintext, footer)
328    main_payload, dropped_payload, message_block = split_body_parts(final_buffer, footer)

Anti-analysis reaches into key derivation

ThreatLabz describes VM, debugger, timing and user-activity checks. Most importantly, one timing check is coupled to decryption: it can alter the intermediate SHA-256 value and thereby produce an incorrect AES key. This does not require a separate visible exit; it makes the payload chain fail cryptographically.

ThreatLabz also reports indirect system calls and inline trampolines intended to influence what user-mode security products and the delivered payload observe. Their runtime effect was not measured independently here.

Three execution paths, multiple persistence paths

The primary report describes in-memory .NET execution, manual LoadPE in the loader process and RunPE in a suspended target process. Configuration flags can control fallbacks between the native paths. An optional second dropped file and decoy message may be added.

Persistence can use Run, RunOnce, the Startup folder, scheduled tasks, the Load registry value or UserInitMprLogonScript. For defenders, the useful signal is not one method alone but the sequence of new autorun configuration, suspicious process start or manipulation and subsequent beacon traffic.

Detection: correlate structure and behaviour

A defensible model should connect three layers. First, static structure: a PE resource with the matching footer magic, plausible size relationships and option fields. Second, host behaviour: new persistence followed by process manipulation or in-memory CLR loading. Third, network: a timely HTTP POST from a newly started, unexpected process.

The Sigma example below is a defensive correlation model for one high-signal persistence branch. It was not validated with a Sigma engine here and must be adapted to product fields, legitimate software distribution and local naming conventions.

1title: 2CLoader-style scheduled task persistence candidate
2status: experimental
3logsource:
4  product: windows
5  category: process_creation
6detection:
7  task_tool:
8    Image|endswith: '\\schtasks.exe'
9    CommandLine|contains|all:
10      - '/create'
11      - '/sc'
12      - 'onlogon'
13  suspicious_name:
14    CommandLine|contains: 'SecurityHealthService.exe'
15  condition: task_tool and suspicious_name
16falsepositives:
17  - Legitimate software using the same filename or task pattern
18level: medium

Payload use is not developer attribution

ThreatLabz observed 2CLoader primarily delivering Vidar and Remus, with XWorm also present. This describes delivery relationships in the reviewed campaigns. It does not establish common authorship of loader and payloads, nor that every future 2CLoader build delivers the same families.

Likewise, filenames, message text, target process or individual C2 indicators do not establish operator identity. This report therefore makes no actor attribution.

What this source review supports

The report and official decryptor agree on the core structural claims: footer size and magic, three-part resource, staged decryption, code-bound key derivation and optional decompression. The primary source adds anti-analysis, persistence, execution options and campaign observations.

What is not established is first-party replay against a sample. This review therefore assesses architecture and defensive consequences, not the functionality of a specific sample or completeness across variants.

Review limits

• This report is an independent technical interpretation of public primary sources, not first-party malware-sample reverse engineering.
• The published decryptor was reviewed and hash-bound but was neither executed nor functionally verified without a malware input.
• Payload families and infrastructure observed by ThreatLabz do not attribute every 2CLoader build.