Zscaler ThreatLabz published its second BINDCLOAK report on August 3. The disclosure connects campaign context to the token sequence defenders can hunt. BINDCLOAK is a modular Windows backdoor that can collect user tokens, inspect process tokens, and start malware modules under a different security identity. Zscaler describes the actor as “targeting government entities in the Middle East” and says the July campaign had “a key focus on the energy vertical.” Its first report lists diplomatic and energy-themed lures, including an archive posed as a petroleum-and-gas cooperation protocol.
The new analysis does not describe a Windows vulnerability, a vendor-remediated product flaw, or a fresh path into every endpoint. It describes what the operator can do after BINDCLOAK is running. Zscaler dates most observed post-compromise activity to July 7 through July 9, 2026, and assesses with high confidence that BINDCLOAK is an OctLurk variant based on code similarities and overlapping command infrastructure. The implant can test credentials with LogonUserW, retain successful token handles, inspect running processes for reusable token rights, duplicate a chosen token with DuplicateTokenEx, and pass that security context to built-in or downloaded modules.
Modules inherit another identity
Windows uses access tokens to represent the security context attached to a user or process. BINDCLOAK turns those tokens into a routing choice for its modular backdoor. Its command module supports three linked operations: collect a user token, return the status of available users and processes, then start another module with a chosen token.
The COLLECT_USER_TOKEN command receives a domain, username, and password from the command server. BINDCLOAK calls LogonUserW; when authentication succeeds, it keeps the resulting token handle. This acquires a token from supplied credentials. A separate cleanup command clears the stored user-token list.
The GET_STATUS command maps the other route. It enumerates running processes with WTSEnumerateProcessesW, obtains account names and domains, and checks whether a process token exposes TOKEN_QUERY, TOKEN_DUPLICATE, and TOKEN_ASSIGN_PRIMARY. That inventory lets the operator choose a process whose security context could give a module more authority than the implant currently has.
Figure details
BINDCLOAK reaches a reusable Windows identity by one of two paths. The user path supplies a domain, username, and password to LogonUserW and retains the successful token handle. The process path enumerates running processes and checks whether their tokens can be queried, duplicated, and assigned as primary tokens. A start-module command selects a retained user token or a process ID, DuplicateTokenEx creates a usable copy, and ImpersonateLoggedOnUser lets a built-in or reflectively loaded plugin module execute in that security context.
START_MODULE_WITH_USER_TOKEN duplicates a retained user-token handle. It requests a primary token through DuplicateTokenEx. START_MODULE_WITH_PROCESS_TOKEN applies the same operation to the token for a supplied process ID. BINDCLOAK can then call ImpersonateLoggedOnUser, allowing the selected module function to run with that identity.
That separation is operationally useful to the attacker. The malware’s network and command layer can remain in one process while a specific task runs with the authority of a more privileged account or service. ThreatLabz says the implant has built-in command-and-control and command modules, and can accept additional plugin DLLs from its server. The INIT_PLUGIN_MODULE command reflectively loads a plugin into memory allocated with read, write, and execute permissions but does not run it. A later module command invokes the plugin’s core function, optionally under a supplied higher-privileged token.
Hunt for the full token sequence
Any single API in this chain can appear in legitimate administration, security software, services, or sign-in flows. Correlate the complete sequence across token access, impersonation, and execution. MITRE’s token-impersonation detection strategy recommends correlating token duplication or impersonation APIs with suspicious process execution and changes in privilege context.
Start with endpoint telemetry that records process creation, access-token activity, cross-process handle access, image loading, memory protection changes, and network connections. Look for an unusual process that enumerates many processes, opens their tokens, calls DuplicateTokenEx, then performs work or spawns activity under a different user, domain, session, or integrity context. Give extra weight to sequences involving ImpersonateLoggedOnUser, executable private memory, or DLL content that is present in memory without a normal file-backed image load.
Correlate that behavior with the sample and infrastructure published by ThreatLabz: MD5 7a14a99d70d42d3f7bf72f843185fc07, SHA-1 577b1cc894636f4ac5ad670b0079b9b7ade137c3, SHA-256 3b0c658ebaa2bae80af97f390b9b2bb20a2f815eb584b2251255e84da4fa669d, and TLS beacon cert.hypersnet[.]com. The attribution record also lists about.blsouqs[.]com, ssl.blsouqs[.]com, contacts.ftabnews[.]com, the apex domain ftabnews[.]com as likely actor infrastructure and potential command-and-control, certificate serial 59fe1ef7707fe497d89f34505222862f, and common name 107.175.172[.]40. These are campaign pivots. The token workflow remains necessary because hashes and infrastructure can change.
Scope the campaign without overstating attribution
The reported victim class is narrow.
ThreatLabz’s first report traced BINDCLOAK through TELESHIM and MIXEDKEY. The chain begins with DLL sideloading, uses Telegram for an earlier command channel, and derives part of the final payload’s decryption key from the target’s volume serial number. Zscaler assesses the operator is from East Asia with moderate-to-high confidence. It does not assign the activity to a named group or country.
Government entities in the Middle East are the reported victim class. Zscaler separately describes energy as a key targeting focus and supports that characterization with diplomatic and energy-themed lure material. That does not establish a separately counted set of energy-company victims. ThreatLabz stops short of naming the operator. The public record does not show a broad campaign across the general Windows population, and the token behavior alone does not identify initial access or prove attribution.
Account for token context
Context makes the sequence testable.
Preserve volatile process, handle, token, session, memory, and connection evidence before containment removes it. Identify credentials supplied to LogonUserW, processes with reusable tokens, the represented accounts, and activity after duplication or impersonation.
Contain the endpoint and rotate every credential shown to have been supplied, captured, or reused. Rebuild from a trusted image when module or memory state cannot be accounted for. Block the published infrastructure and hunt the sample fleetwide, while treating a clean hash search as one negative finding.
Confirm the security context for each supplied credential, duplicated process token, impersonated account, loaded module, child process, outbound connection, and follow-on authentication event.
The expected result is no unexplained sequence that duplicates a token, changes security context, runs a module, and contacts BINDCLOAK infrastructure.
BINDCLOAK’s useful trick is borrowing context, so the host is not the whole incident. A duplicated token gives a module the selected identity on the host. The incident scope follows that identity into later authentication or service activity defenders can verify. The strongest ending names the security contexts the malware touched; anything less is a rebuilt workstation with identities still carrying the unanswered part of the compromise.