TELESHIM Beacons Through Telegram, Rides an ASUS Signature In, and Won't Decrypt on Your Analysis Box

Zscaler ThreatLabz published a technical analysis today of a campaign against Middle East government entities using three previously unreported malware families: TELESHIM, MIXEDKEY, and BINDCLOAK.

We had none of it. Zero corpus hits on all three names, zero on the C2 domain, zero on every hash. This is their find, they are the primary source, and the indicators below are theirs — we are carrying them into a free feed so smaller defenders can block them, not claiming them.

All ten indicators are ingested at confidence 85-90, source tag manual-batch-teleshim if you want to audit exactly what we took. The C2 domain is live in domains.csv now.

The nine hashes are not in hashes.csv yet, and finding out why is the second story in this post. Details at the bottom — it is a bug in our own feed, it has been there a while, and we would rather tell you than quietly fix it.

The chain

A ZIP arrives carrying an ISO. The lure documents are diplomatic and energy-sector: Cooperation protocol for the exploration of petroleum and gas, and Agreement on the Establishment of Common Border Offices. Both in English, both aimed squarely at the kind of ministry that would plausibly receive them.

Mounting the ISO gives the victim a legitimate, validly signed ASUS binary — RegSchdTask.exe — which sideloads a malicious AsTaskSched.dll. That DLL is TELESHIM, a 32-bit C++ first-stage backdoor that persists via scheduled tasks.

TELESHIM runs recon, then stages the second half: a legitimate GoPro binary sideloads pthreadVC2.dll, which is MIXEDKEY, a reflective PE loader. MIXEDKEY decrypts and loads BINDCLOAK, the 64-bit final implant, which beacons to cert.hypersnet[.]com.

Two signed vendor binaries, two sideloads, three families, one domain at the end of it.

Three things here are worth your attention

1. The C2 is Telegram's Bot API.

TELESHIM embeds bot tokens and chat identifiers in obfuscated code and polls the Telegram Bot API over HTTPS. There is no attacker-controlled C2 domain in the first stage. There is nothing to sinkhole, nothing to add to a domain blocklist, and nothing that looks unusual in a proxy log — it is HTTPS to api.telegram.org, an endpoint that exists on almost every corporate network already because somebody's monitoring bot uses it.

We have written about the general shape before — the on-chain dead-drop class, where a loader pulls its second stage from a blockchain address. Same logic, different substrate: put the C2 somewhere that cannot be taken down and cannot be blocked without collateral damage. Blockchain is takedown-proof. Telegram is takedown-slow and block-expensive. Both defeat the indicator, so both force you to detect on behaviour.

2. MIXEDKEY uses environmental keying tied to the volume serial number.

The final payload is encrypted with a key derived from the target machine's volume serial number. On any host that is not the intended victim, BINDCLOAK does not decrypt. Pull the sample into your sandbox and you get a loader that runs, fails, and tells you nothing.

This is the anti-analysis technique that actually matters, and it is worth separating from the noise around it. TELESHIM also does hypervisor detection via CPUID and RAM validation through WMI — standard, well-understood, and defeated by any competent analyst. Environmental keying is different in kind. It does not detect your sandbox; it makes the payload cryptographically unavailable anywhere except the one machine it was built for. You cannot fix that with a better VM. If you did not capture the sample on the victim host, you do not have the final implant, and neither does your vendor.

Which is exactly why the shared indicator matters more than usual here. Nobody is going to independently reverse BINDCLOAK from a sample pulled off VirusTotal.

3. The obfuscation is compiler-grade, and the build is fresh.

Control-flow flattening, mixed boolean arithmetic, and opaque predicates — that combination is a deliberate toolchain choice, not a packer someone bought. The TELESHIM DLL was compiled as recently as July 2026. This is current, maintained tradecraft, not something recycled from an old kit.

On attribution — read what ThreatLabz actually wrote

ThreatLabz assesses with moderate-to-high confidence that the actor operates out of East Asia, based on IP geolocation and system locale. They explicitly do not attribute this to any known APT group.

We are going to hold that line exactly where they put it. IP geolocation and system locale are among the softest signals in attribution — both are trivially spoofable, and locale in particular tells you about a build machine, not a person. A regional assessment is not a country, and a country is not a group.

The temptation with an East-Asia-to-Middle-East government campaign is to fill in the blank, and there is a name most people would reach for. Don't. When a research team with the samples in hand declines to name an actor, the correct move for everyone downstream is to decline as well. We have been wrong in this exact direction before, and the correction cost more than the caution would have.

Note also that this lands on the targeting side of our standing Iran/Gulf watch, not the actor side. The victims are Middle East government entities. The operator, per the only people who have looked at the samples, appears to be someone else entirely.

What to do

Block cert.hypersnet[.]com and the nine hashes. They are in our free feed now — no signup needed for the CSVs, and if you already pull our list you have them.

Do not try to block Telegram as your control. You will break legitimate tooling and you will not stop this. Instead, alert on the combination: a process making Telegram Bot API calls that is not a known, approved bot. api.telegram.org traffic from a sideloaded DLL inside a signed vendor binary is the anomaly — the destination alone is not.

Hunt for the sideload pattern, because it outlives these hashes. A legitimate signed executable loading a DLL from a non-standard path is the reusable detection. Specifically: RegSchdTask.exe loading AsTaskSched.dll, and any GoPro binary loading pthreadVC2.dll, from anywhere other than their installed program directories. That logic survives a recompile; the hashes will not.

Treat mounted ISO and IMG files from email as high-suspicion. The ISO-in-ZIP delivery exists to defeat mark-of-the-web propagation. If your users have no business reason to mount disk images from email — and most do not — block it at the gateway. That one control kills the entire initial-access stage of this campaign.

Check your scheduled tasks. TELESHIM persists there. It is unglamorous, it is where a lot of things live, and almost nobody audits it.

The second story: we found a hole in our own feed while filling it

We ingest campaign indicators with a verified writer — it does a real write, waits for the task, then reads the record back by primary key. It reported 10 of 10 verified. Good.

Then we checked the actual customer-facing artifact, because a write landing in a database is not the same as a defender being able to pull it. The C2 domain was in domains.csv. Zero of the nine hashes were in hashes.csv.

The cause: hashes.csv builds its query with a type filter listing filehash-md5, filehash-sha256, filehash-sha1, sha256, md5, and sha1. It does not list hash — the plain type our own documented ingest path accepts and writes. The STIX bundle endpoints filter correctly and do include hash, which is why nothing looked wrong from the API side.

So the count of affected records is not nine. It is 5,037.

Every hand-curated hash we have ever ingested — the campaign batches, the ones a human looked at and attributed and wrote a description for, the highest-confidence material we own — has been present in the corpus, present in the STIX bundle, and absent from the CSV. And the CSV is precisely the artifact a two-person team pulls with one request, because they are not running a TAXII client.

The most curated part of our feed was missing from the surface that matters most to the people we built it for.

The fix is one term added to one filter. It is written and pending deploy; we do not ship to production without an explicit confirmation step, and that is the correct trade even when the change is trivial. Once it lands, those 5,037 hashes — including these nine — appear in hashes.csv on the next pull.

Two things worth saying plainly about how this was found. First, it was caught by checking the consumer-facing output rather than the write receipt. The write receipt was honest and green; the product was still broken. Verifying the write is necessary and it was not sufficient. Second, nothing alerted on it. A feed that silently omits a category does not look empty — it looks like a feed. There is no denominator that would have made 5,037 missing hashes feel wrong, which is exactly why you have to go and look.

The honest position

We are following on this one. Zscaler found it, Zscaler reversed it, and Sudeep Singh's team wrote it up in the kind of detail that lets everyone else act. Our contribution is distribution: taking indicators that are published in a vendor blog and putting them somewhere a two-person IT team at a regional government agency can pull with a single request and no procurement cycle.

That is a smaller claim than "we caught it," and it is the true one. This is Part 1 of their series; when Part 2 lands with more indicators, those go into the feed too.

We are 95 percent confident that Telegram-as-C2 keeps growing through the rest of the year, because the economics are unarguable: free infrastructure, TLS by default, a destination nobody can afford to block, and an API that is trivially scriptable. The remaining five percent is the chance Telegram starts aggressively policing bot-token abuse at scale. They have the telemetry to do it. Whether they want to is a different question.

Credit to Zscaler ThreatLabz and Sudeep Singh for the research and for publishing complete indicators rather than a teaser.

Free IP, domain, hash, and malicious-package blocklists at analytics.dugganusa.com.

---

Her name was Renee Nicole Good.

His name was Alex Jeffery Pretti.