UPDATE — BINDCLOAK unpacked: a modular C++ backdoor that routes every DLL load through RtlQueueWorkItem to keep LoadLibraryW off unbacked memory, assessed high-confidence an OctLurk variant
UPDATE · originally covered TELESHIM / MIXEDKEY / BINDCLOAK — DLL side-loading under a legitimate vendor binary, Telegram-API C2 and volume-serial environmental keying against government networks (2026-07-26)
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.
BINDCLOAK is a 64-bit modular backdoor written in C++ that uses a complex message routing mechanism to manage the C2 communication channel.
When resolving imports, each DLL is loaded via RtlQueueWorkItem with LoadLibraryW and the DLL name as arguments to evade EDRs since LoadLibraryW calls from unbacked executable memory regions are considered highly suspicious by EDRs.
ThreatLabz assesses with high-confidence that BINDCLOAK is a variant of OctLurk.
the new campaign we identified in July 2026 highlights a notable expansion of operations to target the Middle East with a key focus on the energy vertical.
ATT&CK mapping
6 techniques mapped from the cited reporting · MITRE ATT&CK v19.2
Privilege Escalation TA0004
T1134.001Access Token Manipulation: Token Impersonation/Theft
Adversaries may duplicate then impersonate another user's existing token to escalate privileges and bypass access controls. For example, an adversary can duplicate an existing token using `DuplicateToken` or `DuplicateTokenEx`. The token can then be used with `ImpersonateLoggedOnUser` to allow the calling thread to impersonate a logged on user's security context, or with `SetThreadToken` to assign the impersonated token to a thread.
T1134.003Access Token Manipulation: Make and Impersonate Token
Adversaries may make new tokens and impersonate users to escalate privileges and bypass access controls. For example, if an adversary has a username and password but the user is not logged onto the system the adversary can then create a logon session for the user using the `LogonUser` function. The function will return a copy of the new session's access token and the adversary can use `SetThreadToken` to assign the token to a thread.
Stealth TA0005
T1134.001Access Token Manipulation: Token Impersonation/Theft
Adversaries may duplicate then impersonate another user's existing token to escalate privileges and bypass access controls. For example, an adversary can duplicate an existing token using `DuplicateToken` or `DuplicateTokenEx`. The token can then be used with `ImpersonateLoggedOnUser` to allow the calling thread to impersonate a logged on user's security context, or with `SetThreadToken` to assign the impersonated token to a thread.
T1134.003Access Token Manipulation: Make and Impersonate Token
Adversaries may make new tokens and impersonate users to escalate privileges and bypass access controls. For example, if an adversary has a username and password but the user is not logged onto the system the adversary can then create a logon session for the user using the `LogonUser` function. The function will return a copy of the new session's access token and the adversary can use `SetThreadToken` to assign the token to a thread.
T1620Reflective Code Loading
Adversaries may reflectively load code into a process in order to conceal the execution of malicious payloads. Reflective loading involves allocating then executing payloads directly within the memory of the process, vice creating a thread or process backed by a file path on disk (e.g., Shared Modules).
Discovery TA0007
T1057Process Discovery
Adversaries may attempt to get information about running processes on a system. Information obtained could be used to gain an understanding of common software/applications running on systems within the network. Administrator or otherwise elevated access may provide better process details. Adversaries may use the information from Process Discovery during automated discovery to shape follow-on behaviors, including whether or not the adversary fully infects the target and/or attempts specific actions.
Command and Control TA0011
T1095Non-Application Layer Protocol
Adversaries may use an OSI non-application layer protocol for communication between host and C2 server or among infected hosts within a network. The list of possible protocols is extensive. Specific examples include use of network layer protocols, such as the Internet Control Message Protocol (ICMP), transport layer protocols, such as the User Datagram Protocol (UDP), session layer protocols, such as Socket Secure (SOCKS), as well as redirected/tunneled protocols, such as Serial over LAN (SOL).
T1132.002Data Encoding: Non-Standard Encoding
Adversaries may encode data with a non-standard data encoding system to make the content of command and control traffic more difficult to detect. Command and control (C2) information can be encoded using a non-standard data encoding system that diverges from existing protocol specifications. Non-standard data encoding schemes may be based on or related to standard data encoding schemes, such as a modified Base64 encoding for the message body of an HTTP request.
Update chain
AI-generated · no human review · this permalink is the shareable record for the finding · verify operationally critical claims against the linked primary source.