TI-2026-063C — The Documented Technique: Telegram C2 as MITRE T1102.002, and How to Catch It

Classification: HIGH · Forensic threat intelligence · Detection engineering · Published 2026-07-07 · Series: The Trusted Channel

The implant in TI-2026-063A is not novel to the world — it is a live, Linux/IoT-flavoured instance of a technique the security industry named and catalogued years ago. That is good news for defenders: a documented technique has documented detections. This part places the honeypot capture in its published context — a decade of Telegram-API abuse, an ATT&CK sub-technique, and ready-made SIGMA rules sitting in our own OSINT library — and turns them into a concrete detection stack keyed to the exact behaviours 063A exhibited.

1. The Technique Has a Name

Abusing a legitimate web service for bidirectional command-and-control is MITRE ATT&CK T1102.002 — Web Service: Bidirectional Communication. The Telegram Bot API is the textbook example: the malware both receives instructions and returns results through api.telegram.org, so there is no attacker-controlled endpoint in the traffic at all. 063A is a clean specimen — getUpdates inbound, sendMessage outbound — but the lineage is long:

063A is the piece these lists were missing on our sensor: the minimal POSIX-sh / IoT variant of the same idea. The technique migrated from Windows RATs and Android trojans down to a 25-line shell script that runs on a router. Same ATT&CK cell, new low end of the market.

2. The Detections Already Exist

Our OSINT library holds published SIGMA rules for precisely this behaviour — three complementary vantage points, all tagged attack.command-and-control / attack.exfiltration / attack.t1102.002:

• DNS — Telegram Bot API Request (net_dns_susp_telegram_api.yml): flags DNS queries resolving api.telegram.org. On a server that has no reason to use Telegram, the lookup itself is the alert.
• Process → network — Suspicious Non-Browser Network Communication With Telegram API (net_connection_win_domain_telegram_api_non_browser_access.yml): a non-browser process talking to api.telegram.org. Chrome/Edge reaching Telegram is normal; a random binary — or wget/curl in a shell loop — is not.
• Proxy / TLS — Telegram API Access (proxy_telegram_api.yml): requests to the Telegram API without the legitimate Telegram User-Agent. 063A's wget/curl calls carry no Telegram UA — they trip this directly.

These are field-tested rules (Nextron/Florian Roth lineage) already in the corpus. The contribution of this dossier is to bind them to the live capture: 063A would fire the DNS rule (the box resolves api.telegram.org), the non-browser rule (a /tmp/.a.sh shell loop, not a browser), and the proxy rule (no Telegram UA) — three independent detections on one implant.

3. A Detection Stack Keyed to 063A

Layering the generic technique-detections with 063A's specific artefacts gives a defence-in-depth stack, cheapest and broadest first:

No single layer is sufficient against a trusted-service channel — the destination is legitimate and the payload is TLS — which is exactly why the stack matters. The egress allow-list is the only layer that blocks rather than merely alerts, and it is the one most organisations omit because "it's just Telegram."

4. Why This Is Hard, Honestly

The uncomfortable truth of T1102.002 is that the strongest single control — block api.telegram.org — is unavailable to anyone who legitimately uses Telegram on the monitored network. For those environments the defence degrades to detection, and detection of a TLS channel to a trusted host is inherently probabilistic: you are hunting for a non-browser process, an absent User-Agent, an unusual server making the lookup — signals of anomaly, not signatures of malice. This is why the technique persists across a decade of RATs, stealers and now shell implants: it is cheap to build and structurally expensive to detect. The honest posture is layered detection plus aggressive egress control everywhere Telegram is not a business requirement — not a single silver bullet, because there isn't one.

5. Alternative Interpretation

Steelman: "If the technique is a decade old and MITRE-catalogued with public SIGMA rules, a dossier adds nothing — this is a literature review, not intelligence."

Why it earns its place:

• It closes the loop between capture and canon. 063A is a live specimen; this part proves it is the documented TTP (not a novelty to over-claim) and hands defenders the specific rules that fire on it. Intelligence is not only new actors — it is correctly situating what you caught, so responders act on established detections instead of reinventing them.
• It fills a real gap in the family. The published corpus of Telegram-C2 is Windows- and Android-heavy. Documenting the IoT/POSIX-sh variant on a live sensor extends the technique's known surface downward to embedded devices — where egress control and endpoint telemetry are weakest.
• It is honest about difficulty. Rather than promise a block, it states plainly that trusted-service C2 is structurally hard and prescribes layered detection + scoped egress. That calibration is itself the value.

What is not claimed: that 063A is linked to TeleRAT/Small Sieve/DeerStealer (it is not — those are cited as lineage, not attribution), or that any single detection is decisive. Confidence: HIGH — the technique's documentation, ATT&CK mapping, and applicable SIGMA rules are established fact; the honeypot capture is a confirmed instance that trips all three rule vantage points.

6. Defense Response

• Scope an egress allow-list to api.telegram.org. On every host and segment where Telegram is not a business requirement, deny it outbound. This is the one control that blocks the C2/exfil rather than alerting after the fact.
• Deploy the three SIGMA vantage points. DNS (api.telegram.org resolution), process (non-browser → Telegram API), and proxy/TLS (Telegram API without the Telegram UA). Together they catch the technique regardless of the specific malware or OS.
• Hunt bot tokens at rest. Telegram bot tokens match a stable regex (\d{8,10}:[A-Za-z0-9_-]{35}). Scan .env, config.*, and source repositories for them; a hardcoded token in a place it should not be is both a detection and an incident.
• Instrument the endpoint for the sh-implant shape. Alert on hidden /tmp/*.sh launched via nohup, the base64-decoder fallback chain in shell history, and wget/curl loops to api.telegram.org. Pair with the network HASSH tell (7be2ba0c… + root/root) from 063A.
• When you find a bot, report it. Detection ends the incident on your host; a Telegram abuse report (abuse@telegram.org) ends the operation by banning the bot for every victim.

7. Investigation Metadata

Cristian Lișneanu · shuffle-on.com · Threat Intelligence