Overview
Three new malware families. Zero prior documentation. A three-stage infection chain hitting Middle East government networks, built by an actor that hasn’t been publicly attributed to any known APT group. That’s the situation Zscaler ThreatLabz found itself describing in late July 2026 after publishing analysis of a campaign they’d been tracking against government entities in the region.
The toolset is called TELESHIM, MIXEDKEY, and BINDCLOAK — first stage, second stage, and final implant respectively. Together they represent a purpose-built espionage framework: structured around evasion from the initial ISO delivery all the way through to C2 communication, with each stage designed specifically to complicate analysis and ensure the payload only executes where it’s supposed to.
The threat actor behind it is assessed with moderate confidence as East Asia-linked, based on targeting patterns and operational characteristics. Zscaler declined to attribute it to a specific APT group in their Part 1 publication, noting attribution is still developing. What’s clear is the sophistication of the tooling, the deliberateness of the targeting, and the operational security invested in making these tools resilient against both automated and manual analysis.
The Geopolitical Context
Before getting into the malware, the targeting matters. Middle East government entities are a long-standing collection priority for several state-sponsored actors. East Asian intelligence services — particularly China-aligned ones — have sustained interests in Middle Eastern energy policy, arms procurement, diplomatic positioning between regional blocs, and the Gulf states’ increasingly independent foreign policy trajectories.
The region sits at an intersection of several strategic competitions simultaneously: US-China rivalry over Gulf partnerships, Chinese infrastructure investment through Belt and Road, regional states hedging between Western security relationships and Chinese economic ties. Government networks in this environment hold exactly the kind of diplomatic and policy intelligence that foreign intelligence services target.
China-linked actors have been documented targeting Middle Eastern governments before. GopherWhisper, publicly disclosed in April 2026, used similar cloud-service C2 techniques against Mongolian government networks. The TELESHIM campaign shares operational DNA in its emphasis on network-layer evasion through legitimate service abuse, though the tooling is entirely different and attribution to the same cluster has not been confirmed.
Stage 0: Initial Access via ISO and DLL Sideloading
The infection begins with a weaponized ISO file — a delivery format that remains popular among APT actors because ISO mounting behaviour in modern Windows environments bypasses Mark-of-the-Web propagation, reducing the friction between delivery and execution.
Inside the ISO: a legitimate signed binary, RegSchdTask.exe, published by ASUS. The binary is used as a sideloading host. Alongside it sits AsTaskSched.dll, the malicious DLL that TELESHIM is packaged as.
DLL sideloading via legitimate software publisher binaries is a reliable initial access technique. The execution runs under a trusted process identity, which confounds endpoint defences that baseline process reputation and trust the software publisher’s signature. The ASUS binary was likely chosen because it’s plausible in an enterprise context, won’t trigger behavioural alerts on sight, and carries a legitimate code signature.
The ISO format also has a practical benefit: it doesn’t require macros, scripts, or exploitation of document rendering engines. It presents as a volume and relies entirely on user interaction — opening the ISO and running the binary. Phishing lures or spearphishing delivery are the presumed initial vector; ThreatLabz did not disclose specifics of how targets received the ISO.
Stage 1: TELESHIM
TELESHIM is a 32-bit C++ DLL compiled in July 2026 — recent enough that the malware was almost certainly developed specifically for this campaign rather than reused from a prior operation. That’s significant. Purpose-built malware for a targeted campaign suggests investment, confidence that the operation justifies new tooling, and a deliberate decision not to reuse infrastructure that might already be burned.
Three technical features define TELESHIM.
Telegram API C2. TELESHIM communicates with its operator by making API calls to the Telegram messaging service. Command and control traffic blends entirely with legitimate Telegram traffic on the network. From a network monitoring perspective, what you see is TLS-encrypted connections to Telegram’s API endpoints — the same traffic pattern as any employee using Telegram on a work device. Traditional network-based C2 detection looks for anomalies: unusual domains, rare ASNs, high-entropy DNS, beaconing cadence to unfamiliar infrastructure. None of those signals appear when C2 runs through Telegram’s production infrastructure.
This technique — using legitimate cloud services as C2 channels — is increasingly adopted by sophisticated actors. It shifts the defence problem: blocking Telegram entirely to stop the C2 would also block a legitimate messaging tool used by staff. Defenders must either accept the blind spot or invest in deep packet content inspection and API call logging, which most organisations haven’t built.
Anti-virtualisation detection. TELESHIM checks whether it’s running inside a virtualised analysis environment before proceeding. The specific detection methods weren’t fully documented in Part 1, but anti-VM checks in first-stage malware serve a clear purpose: sandbox environments submit files to automated analysis pipelines that run in VMs. A malware sample that detects sandbox execution and does nothing is effectively invisible to automated analysis — it won’t generate behavioural signatures, won’t detonate its payload, and will return inconclusive results. The analyst needs physical hardware or a sufficiently hardened bare-metal environment to get accurate results.
Obfuscation depth. The code-level evasion in TELESHIM is notable. ThreatLabz documented three distinct obfuscation techniques applied simultaneously:
- Control flow flattening (CFF) — the program’s normal execution graph is replaced with a dispatch-based structure where a central switch statement drives transitions between code blocks, making the logical flow of the program extremely difficult to follow in a disassembler.
- Mixed boolean arithmetic (MBA) — arithmetic and logical operations are replaced with semantically equivalent but visually impenetrable sequences of bit manipulation operations. Simple computations become pages of indirection.
- Opaque predicates — code branches are inserted that appear to offer multiple execution paths but always resolve the same way. The effect is additional noise in the control flow graph that hinders automated analysis tools.
The combination of all three simultaneously is a defensive investment that reveals deliberate attention to analyst tradecraft. Each technique individually slows analysis; layering them together substantially raises the cost of understanding what the malware actually does.
Stage 2: MIXEDKEY
TELESHIM’s job is initial persistence and staging. Once it’s established that the execution environment is a real target — not a sandbox, not the wrong machine — MIXEDKEY is deployed as the second stage.
MIXEDKEY uses the same DLL sideloading mechanic as the initial infection, this time with a renamed legitimate binary as the host process. Its primary role is loading and executing BINDCLOAK, the final implant, without BINDCLOAK ever touching disk in its decrypted form.
The mechanism is reflective loading. MIXEDKEY decrypts BINDCLOAK and loads it directly into memory, executing it without going through a file write to disk. Disk writes are logged by endpoint telemetry; in-memory execution leaves a much smaller artifact trail. If the host process is killed and the system is examined post-incident, BINDCLOAK’s decrypted form may not be recoverable from disk.
The decryption key for BINDCLOAK is where the campaign’s most interesting evasion technique appears.
Stage 3: BINDCLOAK and Environmental Keying
BINDCLOAK is the final implant — a 64-bit C++ C2 agent designed for long-term persistent access. It communicates with dedicated infrastructure at cert.hypersnet[.]com, a domain chosen to look plausible in certificate-related network traffic.
What sets BINDCLOAK apart from most implants is how it’s locked. The payload is encrypted with a key derived from the infected machine’s volume serial number. That volume serial number is unique to each installation of Windows on a given piece of hardware. The malware copies distributed to different targets are, in effect, each individually keyed.
The security implication is significant. If a BINDCLOAK binary is extracted from a target system — either by incident responders, by a sandbox, or by sharing through malware repositories like VirusTotal — the binary is cryptographically inert on any machine other than the original target. An analyst examining it on their workstation will see an encrypted blob. The decryption key doesn’t exist in the binary; it has to be computed from the target machine’s hardware. The payload cannot be analysed without either the original victim machine or knowledge of its volume serial number.
This is environmental keying — a technique seen in high-end commercial spyware and sophisticated nation-state tooling, but not commonly in commodity malware. It’s a deliberate choice that trades some operational simplicity (payload distribution requires computing a unique binary per target, or the loader needs the target’s volume serial in advance) for substantially increased resilience against both sandbox detection and post-incident malware analysis.
For defenders: a BINDCLOAK sample obtained from a compromised system is not directly useful for building detections on other networks, because the ciphertext will differ per target. Hunting must focus on the loader stages, on network indicators (the C2 domain and infrastructure), and on behavioural patterns rather than binary signatures.
What the Tooling Reveals About the Operator
The investment visible in this toolset tells a story. Consider what the threat actor chose to build:
Purpose-built, not recycled. TELESHIM was compiled in July 2026. The campaign tooling is fresh. This actor didn’t reuse documented malware that carries existing detection signatures; they built new tools for this operation. That’s resource-intensive, and it suggests either that operational security matters enough to justify the cost, or that the value of the targeted access is sufficient to warrant it.
Multiple layers of analysis resistance. Anti-VM, three-layer code obfuscation, reflective loading, and environmental keying are each individually useful. Implementing all of them together means the operator planned specifically against both automated malware analysis pipelines and manual reverse engineering. This is not opportunistic; this is tradecraft.
C2 through legitimate infrastructure. Telegram API abuse for C2 is an active evasion choice against network monitoring. It requires understanding how defenders look for C2 traffic and designing around those detection models. The operator understands defender capabilities.
Operational precision. Environmental keying limits the blast radius of compromise: if a sample is shared, it doesn’t give defenders a transferable weapon. The operator is thinking about what happens after an incident, not just before.
Together, these choices describe an actor with meaningful resources, an understanding of modern defensive practices, and an interest in sustained access over an extended period. This isn’t a smash-and-grab credential campaign. It’s an intelligence collection operation designed to survive.
Attribution Status
Zscaler’s Part 1 publication attributes the campaign to an East Asia-linked actor but does not name a specific APT group. This is an appropriate level of caution at this stage of investigation: East Asia is not a single actor, and the absence of confirmed OPSEC failures, shared infrastructure, or code overlaps with known clusters means a specific attribution would be speculative.
Several China-linked APT groups have documented history of targeting Middle Eastern government networks, including APT41 (dual-mandate state/criminal), and various clusters associated with Chinese intelligence collection interests in the Gulf. The cloud C2 pattern also appears in GopherWhisper, a group that uses similar techniques against different targets. Whether any of these represent the same operator behind TELESHIM is not established from public reporting.
A Part 2 analysis focused specifically on BINDCLOAK is expected from ThreatLabz. That analysis will likely provide more technical detail on the C2 protocol, network signatures, and any additional indicators that may support or constrain attribution.
Defensive Considerations
Detection focus on the loader stages. BINDCLOAK’s environmental keying means binary-based detection of the final payload is target-specific. Defenders should focus detection efforts on TELESHIM and MIXEDKEY behaviours: ISO delivery, DLL sideloading from uncommon process names, and the specific sideloading pattern (ASUS binary + AsTaskSched.dll naming).
Telegram API traffic monitoring. Where Telegram is not a business application, egress to Telegram’s API endpoints from workstations or servers warrants review. Where it is used legitimately, establishing a baseline of typical API interaction frequency and flagging sustained high-frequency calls from non-user contexts is feasible.
Anti-sandbox environment hardening. TELESHIM’s anti-VM checks mean sandbox analysis pipelines using standard virtual environments may not detonate this family correctly. Malware analysis environments should include bare-metal analysis capability for samples from high-value targeting contexts.
Hunt for sideloading patterns. The use of legitimate signed binaries to sideload malicious DLLs is a persistent technique. EDR-based hunting for process trees where a signed vendor binary loads a DLL from the same directory that is not part of its normal distribution is a general-purpose signal that this campaign, and others using similar techniques, should trigger.
Network indicators. cert.hypersnet[.]com is the confirmed BINDCLOAK C2 domain from Part 1. Block and monitor at the network perimeter.
Closing Assessment
The TELESHIM campaign represents the kind of APT tooling that tends to precede longer-term compromise campaigns rather than quick raids. The investment in evasion, the targeting of government entities, and the design for sustained access through BINDCLOAK all point toward an intelligence collection objective. The operator has resources and sophistication, and they chose Middle East government networks as targets deliberately.
The lack of attribution to a specific group is, in a sense, part of the story. This is an actor that doesn’t want to be known — and they’ve built tooling that actively resists the analysis that would make them known. That resistance is itself a data point about who this is and what they’re protecting.
ThreatLabz’s ongoing Part 2 analysis will add significant detail. Until then, defenders with exposure to the Middle East government sector, or with broader East Asia APT threat models, should treat the indicators from Part 1 as active and prioritise the detection logic described above.