New 2CLoader malware fools sandboxes to deliver stealers

Published

A new malware loader that checks whether a human is moving the mouse before it unpacks its cargo is being used to push credential-stealing malware, researchers at Zscaler ThreatLabz report. The loader, which ThreatLabz tracks as 2CLoader and first identified in August 2026, has mainly delivered the Vidar and Remus information stealers, along with the XWorm remote access trojan.

Loaders are the delivery vans of cybercrime: they get onto a machine, stay quiet, and hand over to whatever payload the operator wants to deploy. Stealers such as Vidar and Remus then harvest credentials that feed later attacks, which is why a new, well-built loader matters beyond its own code. The analysis was written by ThreatLabz security researcher Muhammed Irfan V A.

Built to decide whether it is being watched

2CLoader runs a two-tier anti-virtualization test. Some findings end the run immediately: a hypervisor identifying as VMware, VirtualBox, KVM, Xen, Parallels or QEMU (Microsoft Hyper-V is explicitly allowed), or blocklisted modules, processes, MAC address prefixes and registry keys. Otherwise it scores the machine on signals a real PC tends to have, such as more than 25 running processes, at least 2 GB of memory, a 40 GB disk, more than three minutes of uptime, recently opened files and a cursor that moves. A score below 8 means it exits without decrypting its payload.

It sidesteps the hooks that endpoint security products place on Windows functions by making indirect system calls with the Hell's Gate technique, and it can check for debuggers and wait for a mouse click or an Enter keypress. With one option enabled, it hooks around 20 Windows APIs in its own process to return randomized but correctly formatted usernames, computer names, volume serial numbers and registry values, and to scramble the last two octets of any IPv4 address in downloaded data. ThreatLabz says the exact purpose is unclear but may be to confuse malware sandboxes.

A payload locked to the loader's own code

The encrypted payload sits in a PE resource. 2CLoader peels off two XOR layers, then derives its AES-256-GCM key from a SHA-256 hash of its own first executable section. With its timing check enabled, a run that looks emulated produces a deliberately wrong key. Depending on configuration, it runs the payload in memory as a .NET assembly, maps it into its own process, or injects it into a suspended dllhost.exe. Persistence options include the Run and RunOnce registry keys, the Startup folder and a scheduled task, all using the name SecurityHealthService.exe, the same name as a legitimate Windows process. It reports to its server with XOR-encrypted JSON sent in HTTP POST requests.

Hunt for the fake SecurityHealthService.exe

Defenders should look for Run, RunOnce or scheduled-task entries named SecurityHealthService.exe that point to unusual paths, lock files matching %TEMP%\aw_*.lk, and outbound POST requests to /api/beacon. ThreatLabz has published a payload decryption script and its anti-VM blocklist on GitHub, and detects the loader as Win64.Loader.2CLoader. Vidar has been a regular in our coverage, most recently when Vidar began changing its disguise with every build.

Indicators (defanged):

Almost every behavior described here is a switch in the loader's configuration, so two 2CLoader samples can look quite different at runtime. The constants, like the persistence name and the beacon path, are the more durable things to hunt for.

This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.

Detection coverage

Read the full analysis on IntelFusions