Detecting Telegram Bot API C2 in Enterprise Networks

Background

MITRE ATT&CK T1102 (Web Service) covers adversary abuse of third-party cloud services as command-and-control channels. Telegram’s Bot API is one of the most commonly abused services in this category. Malware families leveraging Telegram for C2 include Ares RAT, TelePowerBot, AsyncRAT variants, and as of July 2026, TELESHIM — the first-stage implant in a documented East Asia-linked APT campaign targeting Middle East government networks (Zscaler ThreatLabz, July 2026).

The reason actors choose Telegram is obvious: traffic to api.telegram.org is TLS-encrypted, comes from Telegram’s own CDN, and is operationally indistinguishable from a legitimate user running the Telegram desktop or web client. Traditional C2 detection relies on identifying anomalous domains, unusual ASNs, or beaconing cadence to unfamiliar infrastructure — none of these signals appear when C2 runs through Telegram.

Detection must instead focus on the following:

• Process-to-network relationship (what process is making the API call?)
• Volume and timing patterns of API requests
• API endpoints and response patterns specific to Bot API polling
• Absence of corresponding user-facing Telegram client processes

What Telegram Bot API C2 Looks Like

A malware controller interacting with a bot polls the getUpdates endpoint on a regular interval. The implant receives commands as Telegram messages delivered to the bot, and sends output via sendMessage or file upload APIs.

Key API endpoints used by malicious bots:

Network characteristics:

• Host: api.telegram.org
• TLS on port 443
• Regular interval polling (variable by family; typically 5–60 seconds)
• Response bodies are JSON containing ok: true and result arrays
• Large or frequent POST requests from the same endpoint suggest data exfiltration

Detection Logic

Network Layer — Proxy or DNS Telemetry

Sigma Rule: High-Frequency Polling of Telegram Bot API

title: High-Frequency Telegram Bot API Polling (Potential C2)
id: b7e3f1a2-8d4c-4e5f-a9b1-c2d3e4f5a6b7
status: experimental
description: Detects frequent polling of the Telegram Bot API endpoint consistent with malware C2 behaviour
references:
  - https://attack.mitre.org/techniques/T1102/
author: SOC Analyst Hub
date: 2026/07/29
tags:
  - attack.command_and_control
  - attack.t1102
logsource:
  category: proxy
detection:
  selection:
    cs-host: 'api.telegram.org'
    cs-uri-query|startswith: '/bot'
    cs-uri-query|contains: '/getUpdates'
  condition: selection | count() by c-ip > 10
  timeframe: 5m
falsepositives:
  - Legitimate Telegram bot integrations (notify or chatops pipelines)
  - Internal developer tooling that interacts with Telegram bots
level: medium

KQL (Microsoft Sentinel / Defender for Endpoint — Network Events)

// Detect high-frequency Telegram Bot API polling
DeviceNetworkEvents
| where RemoteUrl has "api.telegram.org"
| where RemoteUrl matches regex @"/bot[^/]+/getUpdates"
| summarize RequestCount = count(), 
            FirstSeen = min(Timestamp), 
            LastSeen = max(Timestamp) 
            by DeviceName, InitiatingProcessFileName, InitiatingProcessId, RemoteUrl
| where RequestCount > 10
| project Timestamp = LastSeen, DeviceName, InitiatingProcessFileName, RequestCount, RemoteUrl
| sort by RequestCount desc

Splunk SPL (Proxy Log Source)

index=proxy_logs dest_host="api.telegram.org" uri_path="/bot*getUpdates"
| bin _time span=5m
| stats count AS request_count BY src_ip, _time
| where request_count > 10
| eval alert="High-frequency Telegram Bot API polling - potential C2"
| table _time, src_ip, request_count, alert

Endpoint Layer — Process-Network Anomaly

The most reliable signal is a process making Telegram API calls that is not the Telegram client. On Windows, the legitimate Telegram Desktop process is Telegram.exe. On Linux/macOS it is telegram-desktop or the corresponding application bundle process.

KQL: Non-Telegram Process Connecting to Telegram API

// Flag processes connecting to Telegram API that are not the Telegram client
DeviceNetworkEvents
| where RemoteUrl has "api.telegram.org"
| where InitiatingProcessFileName !in~ ("Telegram.exe", "telegram-desktop", "Updater.exe")
| where InitiatingProcessFileName !endswith "telegram"
| project Timestamp, DeviceName, InitiatingProcessFileName, 
          InitiatingProcessFolderPath, InitiatingProcessCommandLine, 
          RemoteUrl, RemotePort
| sort by Timestamp desc

Sigma Rule: Non-Telegram Process Connecting to Telegram Bot API

title: Non-Telegram Process Connecting to Telegram Bot API
id: c4a7b2d1-9e5f-4b3a-8c2d-f1e2a3b4c5d6
status: experimental
description: Detects processes other than the Telegram client establishing connections to api.telegram.org/bot endpoints, indicating potential C2 usage
author: SOC Analyst Hub
date: 2026/07/29
tags:
  - attack.command_and_control
  - attack.t1102
logsource:
  product: windows
  category: network_connection
detection:
  selection_telegram_api:
    DestinationHostname: 'api.telegram.org'
    DestinationPort: 443
  filter_legitimate_client:
    Image|endswith:
      - '\Telegram.exe'
      - '\Updater.exe'
  condition: selection_telegram_api and not filter_legitimate_client
falsepositives:
  - Legitimate applications that use Telegram Bot API for notifications
  - Development tools testing bot integrations
level: high

Identifying Bot Token Patterns

When proxy or TLS inspection logs capture URL paths (not encrypted payload), the bot token appears directly in the API path: /bot{numeric_token}/endpoint. The token format is {10-digit-number}:{35-character-alphanumeric-string}. Any URL matching /bot\d{9,10}:[A-Za-z0-9_-]{35}/ in proxy logs is a Telegram Bot API call.

Splunk: Extract and Inventory Bot Tokens from Proxy Logs

index=proxy_logs dest_host="api.telegram.org"
| rex field=uri_path "/bot(?P<bot_token>\d{8,12}:[A-Za-z0-9_\-]{30,40})/"
| stats count AS call_count, 
        values(uri_path) AS endpoints_used, 
        values(src_ip) AS source_ips 
        BY bot_token
| where call_count > 5
| table bot_token, call_count, endpoints_used, source_ips

Inventorying tokens observed from your network lets you identify unknown bot tokens (not belonging to any approved integration) and flag them for investigation.

APT Indicators: TELESHIM Specifics

The July 2026 TELESHIM campaign (Zscaler ThreatLabz) provides additional context for hunting specifically for this family. TELESHIM is a 32-bit C++ DLL loaded via DLL sideloading from an ASUS-signed binary (RegSchdTask.exe) hosting a malicious DLL (AsTaskSched.dll).

Endpoint indicators for TELESHIM pre-C2:

// Hunt for ASUS binary sideloading DLLs outside known paths
DeviceImageLoadEvents
| where InitiatingProcessFileName =~ "RegSchdTask.exe"
| where FolderPath !startswith @"C:\Program Files\ASUS"
| where FolderPath !startswith @"C:\Program Files (x86)\ASUS"
| project Timestamp, DeviceName, InitiatingProcessFolderPath, 
          FileName, FolderPath, InitiatingProcessSHA256
| sort by Timestamp desc

// Hunt for AsTaskSched.dll specifically
DeviceImageLoadEvents
| where FileName =~ "AsTaskSched.dll"
| project Timestamp, DeviceName, FolderPath, SHA256, InitiatingProcessFileName

Reducing False Positives

Telegram Bot API usage is legitimate in many enterprise environments — ChatOps integrations, monitoring alert bots, and internal notification pipelines all make API calls matching the detection patterns above. Reduce false positives by:

1. Maintaining a bot token allowlist. Capture all bot tokens used by approved integrations. Detections for unknown tokens are high confidence.
2. Scoping by source asset type. Workstations and employee laptops should not be running server-side Telegram bot integrations. API calls from workstation-class assets are higher signal than calls from server infrastructure.
3. Checking for corresponding client process. If Telegram.exe is running and also making API calls, the traffic may be legitimate. If no client is running and API calls are occurring, the signal is stronger.
4. Volume thresholds. A single API call to /getUpdates may not be meaningful. Sustained polling (10+ calls per 5 minutes) is characteristic of a C2 polling loop.

Recommended Response Actions

When a Telegram Bot API C2 alert fires and cannot be attributed to a known approved integration:

1. Isolate the source host from the network pending investigation.
2. Capture the bot token from proxy logs. Bot tokens can be used to query Telegram’s API and retrieve message history if not yet deleted by the operator. Report the token to Telegram security for takedown ([email protected]).
3. Collect memory from the affected process before termination. TELESHIM and similar families run as DLLs in sideloaded processes; memory capture preserves the decrypted implant for analysis.
4. Review parent process to identify the sideloading chain and locate the malicious DLL on disk.
5. Search for lateral movement indicators — Telegram C2 implants are typically deployed post-initial-access and may not be the only foothold.