In July 2026, Zscaler ThreatLabz observed new activity by a threat actor with links to East Asia targeting government entities in the Middle East. During analysis, ThreatLabz captured post-compromise activity and uncovered previously undocumented malware tooling, including TELESHIM, MIXEDKEY, and BINDCLOAK. The campaign used a multi-stage attack chain to establish and maintain access on infected systems, with TELESHIM abusing the Telegram API for command-and-control (C2) communication to blend in with legitimate internet traffic.
This blog post (Part 1) explores the technical details of the multi-stage attack chain, focusing on TELESHIM, MIXEDKEY, and the post-compromise activity observed during the campaign. A follow-up post (Part 2) will provide a detailed technical analysis of the BINDCLOAK C2 implant.
In the following sections, ThreatLabz provides a technical analysis of the campaign, detailing the malware tooling it leverages and the post-compromise activity.
The attack chain begins with an ISO file containing a legitimate RegSchdTask.exe file from ASUSTek that sideloads a malicious DLL named AsTaskSched.dll. The figure below illustrates the campaign’s attack flow used to distribute TELESHIM, MIXEDKEY, and BINDCLOAK.
Figure 1: Multi-stage attack chain leading to the deployment of BINDCLOAK.
TELESHIM is a 32-bit C++ Windows DLL that is used in the first stage of the attack. ThreatLabz identified three unique instances of TELESHIM. While two of these instances were compiled in 2025, the variant used in this campaign was compiled in July 2026. This variant introduced heavy code obfuscation techniques as well as encrypted strings.
When the DllMain is invoked, the code locates the base address of the host executable and installs the following 7-byte hook at offset 0x1394 as shown below.
Figure 2: 7-byte hook at offset 0x1394.
Before installing the hook, DllMain calls VirtualProtect to mark this memory region as writable and restores the original protection after writing the hook. The offset 0x1394 is hardcoded, indicating that the attacker reverse-engineered the legitimate host application to identify an instruction executed early on during its normal initialization. When the host executable reaches that point in its startup, the trampoline fires and execution enters the implant's main payload. By redirecting execution via an installed hook, the code is executed in the context of the host executable to evade security tools.
TELESHIM checks for the presence of a mutex named ----WebKitFormBoundary7MA4YWxkTrZu0g on the victim’s machine to ensure only a single instance of the malware is running at any given time.
All strings relevant to the malicious activity are stored encrypted in the binary. Below are two string decryption variants.
In this variant, each string has its own dedicated CFF-obfuscated decryption function. The XOR key and ciphertext are stored contiguously in a single .rdata blob. Every function is structurally identical; only the decryption key length and plaintext length operands change.
In this variant, each string is first Base64-decoded and then decrypted using the following 44-byte rolling XOR key.
This string decryption algorithm is also used to protect the network communication, which is discussed in more detail later.
TELESHIM uses multiple anti-analysis techniques to evade automated analysis environments and hinder static reverse engineering.
TELESHIM delays execution by performing intense I/O file activity using a function that writes and reads back ~1 MB of randomly generated data to %TEMP%\CVR9EEA.tmp in a loop of 1000 iterations, generating roughly 1 GB of total disk I/O per invocation. This is likely to stall the execution in emulated, virtual, and analysis environments.
The anti-analysis check calls the CPUID instruction with EAX=1 and checks bit 31 of the ECX register to detect the presence of a hypervisor. Since all major hypervisors set this bit, it can be used to detect virtualization-based analysis environments. If bit 31 of ECX is set, execution terminates.
TELESHIM leverages Windows Management Instrumentation (WMI) to execute the following WMI query to check RAM speed.
In a virtualization environment, this command usually returns either 0 or an undefined value. If the return value is 0 or cannot be parsed, then the execution terminates. The WMI query string itself is stored encrypted using string decryption method 2.
TELESHIM uses CFF and complex MBA expressions to deter reverse engineering. The figure below shows the CPUID-based anti-analysis technique leveraging MBA expressions.
Figure 3: MBA expressions used to obfuscate the CPUID hypervisor bit check in TELESHIM.
Similar MBA expressions are used in other critical sections of the code, such as string decryption.
TELESHIM creates a directory at C:\programdata\shimgen_Data\ for staging payloads. The legitimate executable ( RegSchdTask.exe ) is copied to this path as shimgen.exe and the malicious DLL is copied to this path as AsTaskSched.dll .
TELESHIM creates a scheduled task named shimgen that runs every 6 minutes and executes the binary from C:\programdata\shimgen_Data\shimgen.exe .
TELESHIM abuses the Telegram API for C2 communication, a technique used to blend in with legitimate internet traffic. The hostname api.telegram.org , the Telegram bot token, and the chat ID are stored encrypted and encoded in the binary using string encryption method 2. These values are decrypted at runtime to enable C2 communication.
The GetAdaptersInfo API is used to retrieve the infected machine's MAC address, which uniquely identifies the machine to the C2 server.
In the phase, TELESHIM enters a polling loop by sending HTTP GET requests to the following URL to fetch updates: .
Each HTTP GET request uses the hardcoded User-Agent below to impersonate web browser traffic:
The JSON response from the Telegram server is parsed using the nlohmann::json library written in C++ to extract the relevant fields.
The message.chat.id field parsed from the JSON response is validated against the hardcoded chat_id in the binary to prevent hijacking.
There are two C2 message types supported by TELESHIM that are processed with different handlers, which include the following:
At the time of analysis, ThreatLabz captured post-compromise activity from the C2 operator, including system, user, and network reconnaissance commands, along with the deployment of -stage payloads. Most of the activity took place between July 7, 2026 and July 9, 2026. Using the original timestamps at which the threat actor issued the C2 commands, ThreatLabz performed a timing analysis and observed that all C2 commands were executed only between 4 AM UTC and 12 PM UTC, with a heavy concentration between 7 AM and 11 AM UTC. The figure below shows the time-series plot.
Figure 4: Time plot of C2 commands executed by the TELESHIM threat actor.
The table below summarizes some of the C2 commands executed by the threat actor.
System reconnaissance
net user tasklist hostname
Discover information current users, list of running processes, and the hostname of the infected machine.
Network reconnaissance
Discover information the system's network configuration and active network connections.
dir c:\Users\ \desktop
dir c:\Users\ \Downloads
dir C:\ProgramData\Crypto\DSS\
dir C:\ProgramData\Lenovo
dir C:\ProgramData\Intel
Retrieve a list of files in key directories to gain intel, choose an appropriate staging directory, and validate successful deployment of stage payloads.
schtasks /create /f /sc minute /mo 10 /tn "Feedback" /tr "C:\ProgramData\Intel\winProAlertService.exe"
Create a scheduled task that runs every 10 minutes to execute the stage.
schtasks /Query /TN Feedback /v
Verify the scheduled task installation.
Network connection verification
ping cert.hypersnet[.]com -n 1
ping ssl.blsouqs[.]com -n 2
ping contacts.ftabnews[.]com -n 2
Verifies network connectivity
Table 1: Post-compromise commands executed by the TELESHIM threat actor.
For each infected machine, the threat actor enumerated the directories under the path C:\ProgramData\ to choose an appropriate staging directory. The following -stage payloads were then deployed to the staging directory.
On each infected machine, the threat actor created the directory C:\ProgramData\Crypto\DSS\ and dropped the final encrypted C2 implant named C99F29AC08454855B3D538960BB2F34F.PCPKEY . The directory name and the file extension were carefully chosen by the threat actor to impersonate files related to Microsoft’s Platform Crypto Provider (PCP) in order to appear benign.
Once all the -stage payloads were dropped, the threat actor created a scheduled task named Feedback that runs every 10 minutes and launches the legitimate binary, which sideloads the malicious DLL named pthreadVC2.dll present alongside in the same directory. ThreatLabz named this stage loader MIXEDKEY.
MIXEDKEY is a Windows 64-bit DLL whose main purpose is to decrypt the contents of C99F29AC08454855B3D538960BB2F34F.PCPKEY , and reflectively load it.
Similar to the TELESHIM backdoor, MIXEDKEY heavily uses MBA operations to generate junk instructions and opaque predicates, bloating the size of the binary and deterring reverse engineering.
Unlike TELESHIM, MIXEDKEY constructs decrypted strings at runtime by computing each byte using MBA expressions over hardcoded values in the .data section. These bytes are written out of order to a buffer to assemble the final string. To compute a single byte, MIXEDKEY executes approximately ~1,000 instructions.
The final payload is encrypted using two layers of XOR encryption. The second layer of encryption uses environmental keying. The threat actor used the volume serial number of the victim's machine to derive a key to encrypt the payload before deploying it. This ensures the payload decrypts and executes only on the intended target and complicates decryption by analysts who do not have the correct volume serial number.
MIXEDKEY decrypts the payload and reflectively loads it using the following steps:
Finally, MIXEDKEY reflectively loads the PE file and invokes its export function to continue the stage of the attack chain.
The final payload is a 64-bit C2 implant written in C++ that ThreatLabz tracks as BINDCLOAK . It beacons to the C2 server at cert.hypersnet[.]com . A detailed technical analysis of BINDCLOAK will be shared in a follow-up blog post.
During our analysis of the post-compromise activity, ThreatLabz observed high-confidence indicators revealing the threat actor’s public IP address and the system locale configured on their Windows server. 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. At this stage, ThreatLabz is not attributing this activity to any known APT group. We will update our attribution as more evidence emerges.
In this campaign, a threat actor targeted government entities in the Middle East using a multi-stage attack chain with previously undocumented malware tooling including, TELESHIM, MIXEDKEY, and BINDCLOAK. The activity also reflects broader trends such as EDR evasion, blending in with legitimate internet traffic through abuse of trusted platforms, and the use of code-obfuscation techniques such as MBA and CFF to hinder reverse engineering.
This post (Part 1) focused on the attack chain, TELESHIM, MIXEDKEY, and post-compromise activity; a follow-up post (Part 2) will provide a detailed technical analysis of the BINDCLOAK C2 implant.
Zscaler’s multilayered cloud security platform detects indicators related to this campaign at various levels.
97124a93766be732e8fef5a56a5346a2
C1f16e31ae71372ee45fa6fd6927c7b887a4e3f2
789fd11285642861190dc074c1e9a5957073f1a2afebd5160f9cc907f7f320bd
Cooperation protocol for the exploration of petroleum and gas (English).zip
ZIP archive containing the ISO image
68926e6c958562deaae35de3d9f59de3
Ccb2002fe8f5cc1f511d52309625b52d1c507421
c84542ac30cbe9bb8bd648bad323c37801023bf9451c1c0990452466e084340f
Cooperation protocol for the exploration of petroleum and gas (English).img
087499849115eb28c4364581d2b28d09
86ee99f293a30720bcc898a4a8e391f93fb9be95
32529043d15e9111ba284f1d8a9e4b3f58e071c6b69c8f271d4d02feacd44e66
Agreement_on_the_Establishment_of_Common_Border_Offices_English (1).zip
ZIP archive containing the ISO image
B776eb638fbb535708fb92b12fcc1731
2377c47cfde148c2140faa7105628174f9c4d56d
db11ff3f37a8b2aa25c480871504b886a6364167ecb501eacf7345f6bbf9582b
Agreement on the Establishment of Common Border Offices (English).img
7cbc51ada1a4aec88660ec32c408114b
F46c01a5be2e08e36d4ec3302a8650a6ed25ec14
5c2fe953da53da66fbcbb3be0fd6b63907c10714c337f287b2fc258857bbff6d
3f60d53a2b5737d77e058d9e33cbe9eb
1099bf51e53bd5fb32401edb4e0be841d8486b19
cac1f37beaa814461f7709a073aeec468c74e5d70f7d693a9e367ece4a3a78be
28b47bdf16d7af6f8ec21218eac9145a
Fee6806c96f87bf1e240a2eb6fd7e045101d58d3
0637069c7052118fd5c0f1113541bdd35e5f71cd9689f2516045da152c6fa8d9
78a4f8574830bf7fbaf63d7da09be2b8
Ee287d6a09295502ab2407aec336f9f0d8477d68
3b3eaea783fd6dab90f0408274bf8a9c49adbdc70c0efd70658d65b0e1684a3f
MIXEDKEY reflective PE loader
7a14a99d70d42d3f7bf72f843185fc07
577b1cc894636f4ac5ad670b0079b9b7ade137c3
3b0c658ebaa2bae80af97f390b9b2bb20a2f815eb584b2251255e84da4fa669d
Descargo de responsabilidad: Esta entrada de blog ha sido creada por Zscaler con fines únicamente informativos y se proporciona "tal cual" sin ninguna garantía de exactitud, integridad o fiabilidad. Zscaler no asume ninguna responsabilidad por cualquier error u omisión o por cualquier acción tomada en base a la información proporcionada. Cualquier sitio web de terceros o recursos vinculados en esta entrada del blog se proporcionan solo por conveniencia, y Zscaler no es responsable de su contenido o prácticas. Todo el contenido está sujeto a cambios sin previo aviso. Al acceder a este blog, usted acepta estos términos y reconoce su exclusiva responsabilidad de verificar y utilizar la información según convenga a sus necesidades.
Al enviar el formulario, acepta nuestra política de privacidad .
The full story
This article is one source in a clustered incident — the cluster page carries the summary, timeline and every other outlet covering it.
