TELESHIM / MIXEDKEY / BINDCLOAK, DLL side-loading under a legitimate vendor binary, Telegram-API C2 and volume-serial environmental keying against government networks

The earlier entry covered Part 1 of this series, the TELESHIM backdoor and the MIXEDKEY loader, and the environmental keying that ties a payload to the host it infected. Zscaler ThreatLabz has now published Part 2, a teardown of the toolkit's final stage (Zscaler ThreatLabz, 2026-08-03). Two things in it are new rather than restatement: the loading tradecraft, and a targeting expansion.

BINDCLOAK is described as "a 64-bit modular backdoor written in C++ that uses a complex message routing mechanism to manage the C2 communication channel," running two built-in modules alongside plugin DLLs delivered from the command server. The detail worth carrying into detection engineering is how those DLLs get loaded. Plugin modules are reflectively loaded, and when resolving their imports the backdoor queues LoadLibraryW through RtlQueueWorkItem rather than calling it directly; Zscaler is explicit about the reason, which is that a LoadLibraryW call originating from an unbacked executable memory region is exactly what endpoint tooling flags. This is evasion aimed at a specific, widely deployed heuristic: the call still happens, but the thread that makes it belongs to the thread pool rather than to the injected region, so the stack the detection inspects no longer points where it expects.

The rest of the design continues Part 1's environmental-keying theme without repeating it. A four-byte per-victim identifier is derived by summing the ASCII values of the computer name and adding the volume serial number, and travels in every command-and-control message. Traffic is encoded under two layers of XOR and carried over TLS on TCP. Eleven commands are grouped around tokens (collecting user tokens through an authentication call, enumerating processes to decide which tokens are worth taking, and starting modules under either a stolen user token or a duplicated process token) with the remainder covering module lifecycle and one command whose purpose ThreatLabz says it has not determined.

The attribution language matters and is carried exactly as published: ThreatLabz "assesses with high-confidence that BINDCLOAK is a variant of OctLurk." That is an assessment of family relationship, not an identity claim, and OctLurk itself is a family Kaspersky separately documented against Central Asian and Syrian government targets (Kaspersky GReAT, 2026-07-30). The targeting delta is that the July 2026 campaign shows "a notable expansion of operations to target the Middle East with a key focus on the energy vertical."

Detection, telemetry class first. The reflective-loading behaviour surfaces in image-load and thread telemetry rather than on disk: a module load whose initiating thread belongs to the process thread pool while the corresponding executable memory region has no backing file is the shape, and it is precisely the correlation that a stack-based LoadLibraryW heuristic alone will miss. Token activity is the second class, process enumeration immediately followed by token duplication with primary-token assignment rights, then a new module executing under a different user context within the same process. Network telemetry shows TLS over TCP with a fixed short identifier repeated across sessions from the same host. Triage: thread-pool work items and LoadLibraryW are both entirely ordinary in benign software, and legitimate services duplicate tokens routinely; the discriminator is the combination of an unbacked executable region in the same process, a module load initiated from a pool thread, and token duplication following process enumeration; no single element is anomalous alone.