BINDCLOAK Backdoor Linked to OctLurk Hits Middle East Governments

A newly documented Windows backdoor, BINDCLOAK, is giving defenders a fresh look at how an East Asia-linked espionage actor is quietly expanding its reach from Central Asia into Middle Eastern government networks.

Zscaler ThreatLabz, in Part 2 of a two-part investigation, has tied the tool directly to OctLurk, a backdoor Kaspersky exposed in Central Asia campaigns through overlapping code, matching C2 message formats, and shared infrastructure.

BINDCLOAK doesn’t arrive as a standalone file. It’s the third stage of a chain that starts with the TELESHIM backdoor and the MIXEDKEY loader, which decrypts BINDCLOAK using a key derived from the victim machine’s volume serial number and reflectively loads it straight into memory, never touching disk as a standalone binary.

BINDCLOAK Backdoor Linked

The analyzed DLL sample (MD5: 7a14a99d70d42d3f7bf72f843185fc07) exports two disguised functions, curl_easy_escape and mn_dcode, with MIXEDKEY invoking the former to kick off execution.

Once running, BINDCLOAK generates a 4-byte host identifier by summing the ASCII values of the computer name and adding it to the volume serial number a lightweight but effective way to fingerprint each victim for tracking across the C2 channel.

The backdoor’s design is genuinely modular: a C2 module and a command module form the core, while additional plugin DLLs can be pushed down and reflectively loaded on demand via the INIT_PLUGIN_MODULE command.

Eleven C2 commands give operators granular control, but the most alarming cluster targets Windows access tokens. COLLECT_USER_TOKEN authenticates with stolen credentials via LogonUserW and retains the resulting handle; GET_STATUS then enumerates running processes and their token privileges using WTSEnumerateProcessesW and OpenProcessToken, effectively mapping which processes are worth hijacking to escalate privileges.

“What stands out about BINDCLOAK isn’t any single capability it’s the discipline. Every module is gated behind token checks, every plugin is loaded through an EDR-aware path, and the C2 protocol itself is layered like an onion.

This isn’t malware built to survive a single campaign; it’s infrastructure built to be reused, retooled, and quietly redeployed against a new region once the last one gets burned.”

BINDCLOAK’s communication with its C2 server is where the “previously undocumented” label earns its keep. Every message, including the initial beacon that carries the OS version, hostname, username, and local IP address, follows a 28-byte header structure with fields for source, destination, flags, and sequencing, mirroring the exact beacon format used by OctLurk.

Encryption runs in layers: the payload is zlib-compressed, XORed with a hardcoded 105-byte rolling key strikingly similar to OctLurk’s, then XORed again with a random 83-byte key sent in cleartext so the server can reverse the process, and finally padded with random junk bytes to obscure size patterns.

Rather than calling LoadLibraryW directly from unbacked, RWX-permissioned memory a red flag for most EDR products BINDCLOAK’s plugin loader routes the call through RtlQueueWorkItem, letting a worker thread perform the load and breaking the suspicious call-stack pattern that detection engines watch for.

ThreatLabz’s confidence in linking BINDCLOAK to OctLurk rests on more than code similarity. The C2 domain cert.hypersnet[.]com shares an identical SSL certificate (serial 59fe1ef7707fe497d89f34505222862f) with OctLurk’s known C2, about.blsouqs[.]com, and the actor was observed pinging both alongside a third domain, contacts.ftabnews[.]com.

Combined with consistent use of the Tucows registrar, Njalla name servers, and ASN 14956, this points to one operator running parallel campaigns, one against Central Asian government and healthcare targets since early 2025, and a newer one launched in July 2026 against Middle East government entities, with a notable focus on the energy sector.

For defenders, the takeaway is straightforward: BINDCLOAK’s modular, memory-resident design and layered C2 encryption make signature-based detection unreliable, so hunting should focus on token-manipulation behavior, RtlQueueWorkItem-triggered library loads, and TLS connections to the flagged infrastructure.