2026-07-26 · view entry permalink →
TELESHIM / MIXEDKEY / BINDCLOAK, DLL side-loading under a legitimate vendor binary, Telegram-API C2 and volume-serial environmental keying against government networks
The victims here are government entities in the Middle East, not Europe, and the actor is assessed as East-Asian, so the reason this matters to a Swiss or European government defender is the tradecraft, which is aimed at exactly their target class and combines three techniques that each defeat a different common control. Zscaler ThreatLabz "observed new activity by a threat actor with links to East Asia targeting government entities in the Middle East", assessing attribution "with moderate-to-high confidence" on the basis of "the geolocation of the IP address, the configured system locale, and active operational hours matching regional working timeframes" (Zscaler ThreatLabz, 2026-07-20), a hedge worth carrying as stated rather than hardening into a country attribution.
Initial execution comes from an ISO containing a legitimate ASUSTek executable, RegSchdTask.exe, which side-loads a malicious library named AsTaskSched.dll; at the staging step the legitimate executable is copied to its working path under the name shimgen.exe (Zscaler ThreatLabz, 2026-07-20). The first code to run therefore executes under a legitimate vendor binary rather than an attacker-authored one, so controls that key on the executable's identity or reputation see a known-good file. The first-stage TELESHIM backdoor persists through scheduled tasks and, rather than contacting dedicated infrastructure, "abuses the Telegram API for C2 communication, a technique used to blend in with legitimate internet traffic", which means the egress destination is a mainstream service that many organisations either allow outright or cannot block without business friction, and domain- or reputation-based egress control gives no signal. TELESHIM and the MIXEDKEY reflective loader carry heavy obfuscation (control-flow flattening, mixed boolean arithmetic, opaque predicates), and the final BINDCLOAK implant is decrypted only with a key derived from the victim machine's volume serial number, so the payload cannot be detonated on any machine other than the intended one.
Triage: the ASUSTek executable is a legitimate vendor file, and DLL side-loading of this kind produces process telemetry that looks legitimate, so the discriminators are location and provenance rather than the executable's identity. Look for that vendor executable running from a mounted-image path or a user-writable directory instead of its installed application tree, loading a same-directory DLL, on a host with no corresponding ASUS software installed; a scheduled task created shortly afterwards under that lineage raises it further. For the C2 leg, traffic to the Telegram Bot API from a server or from a workstation whose user has no Telegram client installed is the reviewable case; Telegram traffic from staff endpoints that legitimately run the app is noise, and the discriminator is the absence of the client, or a non-browser, non-Telegram process making the connection.
ThreatLabz observed new activity by a threat actor with links to East Asia targeting government entities in the Middle East.
TELESHIM abuses the Telegram API for C2 communication, a technique used to blend in with legitimate internet traffic.
Based on the geolocation of the IP address, the configured system locale, and active operational hours matching regional working timeframes, ThreatLabz assesses with moderate-to-high confidence that the threat actor is operating out of East Asia.
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.
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.