Zscaler ThreatLabz disclosed a previously undocumented malware campaign in which an East Asia-linked threat actor deployed three new malware families against government entities in the Middle East, routing command-and-control traffic exclusively through the Telegram API to blend with legitimate network traffic.
TELESHIM, MIXEDKEY, and BINDCLOAK — A Three-Stage Implant Architecture
The campaign operates through a sequenced three-component implant chain, with each family serving a distinct role. TELESHIM is a 32-bit Windows backdoor functioning as the initial-stage payload. It uses heavy obfuscation — string encryption, control flow flattening, and mixed boolean arithmetic — to frustrate static analysis. TELESHIM also includes anti-analysis logic that detects virtualization environments, terminating execution when sandbox conditions are present to protect the subsequent implant stages from automated detonation and detection.
ISO File Delivery and DLL Sideloading Bypass Application Allow-Listing
Initial access relies on an ISO file containing a legitimate Windows executable, RegSchdTask.exe. The threat actor achieves code execution through DLL sideloading, placing rogue DLLs alongside the legitimate binary so that the trusted process loads attacker-controlled code. This technique bypasses application allow-listing controls that block unknown executables by piggybacking on a recognized and permitted binary. Once TELESHIM is active on the host, it retrieves and executes the second-stage loader.
MIXEDKEY Reflective Loading and BINDCLOAK’s Volume Serial Number Encryption
MIXEDKEY serves as the second-stage bridge component. As a reflective loader, it decrypts and executes subsequent payloads entirely in memory, without writing stage-two code to disk. This limits the forensic artifacts available to incident responders and reduces the likelihood of detection by endpoint tools that monitor file writes. BINDCLOAK, the campaign’s final payload, is a 64-bit C++ implant that provides persistent remote access and supports download-and-execute commands. Its encryption is locked behind two XOR layers keyed to the victim machine’s volume serial number — a form of environmental keying that prevents decryption of captured payload files off the compromised host, since the decryption requires that specific machine’s hardware identifier.
How TELESHIM Routes C2 Communications Through Telegram’s API
TELESHIM communicates exclusively through the Telegram API for command-and-control. The choice to use Telegram rather than conventional C2 infrastructure is deliberate: Telegram traffic is encrypted in transit, generated in large volumes on enterprise networks that permit the application, and indistinguishable at the packet level from legitimate user activity. Network defenses that rely on blocking connections to known malicious IP ranges or flagging anomalous domain lookups will generate no alert from TELESHIM’s Telegram-based C2 channel. The architecture forces defenders to detect the implant through behavioral signals on the host rather than network traffic analysis.
Zscaler ThreatLabz observed post-compromise activity in the campaign concentrated in the 7-to-11 a.m. UTC time window — a range consistent with standard working hours in East Asia — during a multi-day observation period in early July.
Attribution Assessment and Targeting Profile
Attribution is assessed with moderate-to-high confidence as East Asia-linked, but Zscaler ThreatLabz has not assigned the campaign to a named APT group. The combination of government-sector targeting in the Middle East, Telegram C2, and the environmental keying of BINDCLOAK’s encryption distinguish this operation from lower-sophistication campaigns and point toward an actor with specific intelligence collection objectives against state institutions.
The BINDCLOAK keying technique carries an additional strategic benefit for the operator: even if a compromised endpoint is fully imaged during incident response and the BINDCLOAK payload is extracted, the payload cannot be decrypted or fully analyzed without access to the specific machine’s volume serial number. This slows forensic attribution, complicates threat intelligence sharing, and enables continued operations even after payload samples are submitted to analysis platforms — since the submitted sample is undecryptable without the hardware identifier from the victim host.
