Telegram Is Now a C2 Channel Your EDR Probably Isn't Watching
Telegram Is Now a C2 Channel Your EDR Probably Isn't Watching
Most enterprise security teams treat Telegram as a consumer messaging app — something to block at the web filter and move on. That assumption is operationally dangerous. Telegram's Bot API, combined with its encrypted transport and legitimate CDN infrastructure, makes it one of the most effective command-and-control channels available to threat actors today — and one of the least likely to trigger alerts in a default Microsoft Defender for Endpoint configuration.
Why Telegram's Architecture Makes C2 Detection Hard
Telegram's design choices that make it appealing to developers are the same ones that make it attractive to attackers.
The Telegram Bot API operates over HTTPS to api.telegram.org — a domain with a valid TLS certificate, a clean reputation score, and consistent uptime. Bots poll for commands using long-polling GET requests or receive them via webhook. Exfiltrated data travels as bot messages or file uploads. From a network sensor's perspective, this traffic is indistinguishable from a developer's CI/CD pipeline posting build notifications to a team channel.
The core detection problem: Telegram C2 doesn't require a custom domain, a self-signed certificate, or unusual port usage. It rides entirely on infrastructure that most enterprise allow-lists treat as trusted.
The Bot API's authentication model is a single bearer token embedded in the URL path: https://api.telegram.org/bot<TOKEN>/getUpdates. This token is the only differentiator between a legitimate bot and a C2 implant. Without decrypting and parsing HTTPS request paths at the proxy layer, you cannot distinguish them by URL structure alone at the network edge.
Telegram also offers MTProto — its native encrypted protocol — for client-to-client communication. MTProto operates on TCP port 443 or 5222, uses its own encryption layer beneath TLS, and is specifically designed to resist traffic analysis. Malware using the full Telegram client library (not just the Bot API) gets MTProto's obfuscation for free.
---
The Compliance Gap Between 'EDR Deployed' and 'EDR Actually Detecting This'
Deploying Microsoft Defender for Endpoint does not automatically close the Telegram C2 detection gap. This distinction matters enormously under SOC 2 Type II, ISO 27001:2022, and HIPAA audit scopes.
SOC 2's CC6.8 control requires that organizations detect and respond to unauthorized software and communication channels. ISO 27001:2022 Annex A 8.16 mandates monitoring of network activity for anomalous behavior. HIPAA's Security Rule (45 CFR §164.312(b)) requires audit controls that record and examine activity in systems containing ePHI.
If Telegram traffic is neither monitored nor restricted, and a threat actor exfiltrates data through a Telegram bot running on an endpoint inside your environment, none of these controls are satisfied — even if your EDR console shows full device coverage. The audit finding isn't "EDR was missing." The finding is "the EDR was present but the monitoring scope did not include this exfiltration vector."
This is the gap that matters. Coverage metrics don't reflect detection scope.
---
Mapping the Attack Chain: How Telegram C2 Actually Works in Practice
Understanding the mechanics is prerequisite to building detection logic. A typical Telegram-based C2 chain follows this pattern:
Stage 1 — Implant delivery. The malware arrives via phishing, trojanized software, or a supply chain compromise. The implant binary contains a hardcoded Telegram Bot API token and a target chat ID.
Stage 2 — Beacon establishment. On execution, the implant calls https://api.telegram.org/bot<TOKEN>/getUpdates on a polling interval — often between 30 and 300 seconds. This is the C2 check-in. Commands are delivered as messages in the bot's inbox.
Stage 3 — Command execution. The operator sends commands as Telegram messages to the bot. The implant parses the message text, executes the command locally, and sends output back via sendMessage or sendDocument.
Stage 4 — Exfiltration. Files are uploaded using sendDocument. Telegram supports files up to 2GB per upload. Credential dumps, database exports, and configuration files all fit comfortably within this limit.
Stage 5 — Persistence. Many variants register a scheduled task or registry run key to survive reboots. The C2 channel itself requires no persistent network connection — polling resumes after any interruption.
The entire chain uses only outbound HTTPS on port 443 to a legitimate CDN-backed domain. No inbound connections. No unusual ports. No self-signed certificates.
---
Building Detection Logic in Microsoft Defender and Sentinel
Default Defender for Endpoint rules do not flag api.telegram.org connections. You need custom detection rules. The following KQL queries are written for Microsoft Sentinel with the Defender for Endpoint data connector enabled, and for Defender XDR Advanced Hunting.
Detecting Telegram Bot API Polling Behavior
This query identifies processes making repeated HTTPS connections to api.telegram.org at short intervals — the behavioral signature of bot polling.
// Sentinel / Defender XDR Advanced Hunting
// Detects repeated outbound connections to api.telegram.org
// Threshold: 5+ connections within a 10-minute window from a single process
DeviceNetworkEvents
| where TimeGenerated > ago(24h)
| where RemoteUrl has "api.telegram.org"
or RemoteIP in (
// Telegram API IP ranges (as of September 2026 — validate against current Telegram ASN)
"149.154.160.0/20",
"91.108.4.0/22"
)
| summarize
ConnectionCount = count(),
FirstSeen = min(TimeGenerated),
LastSeen = max(TimeGenerated),
ProcessList = make_set(InitiatingProcessFileName),
CommandLines = make_set(InitiatingProcessCommandLine)
by DeviceId, DeviceName, InitiatingProcessFileName, bin(TimeGenerated, 10m)
| where ConnectionCount >= 5
| project
DeviceName,
InitiatingProcessFileName,
ConnectionCount,
FirstSeen,
LastSeen,
CommandLines
| order by ConnectionCount descDetecting Telegram API Token Patterns in Process Command Lines
Telegram Bot tokens follow a predictable format: a numeric bot ID, a colon, and a 35-character alphanumeric string. This query scans process command lines and PowerShell script blocks for that pattern.
// Sentinel — DeviceProcessEvents + DeviceEvents
// Detects Telegram Bot API token patterns in process execution telemetry
let TelegramTokenPattern = @"\d{8,10}:[A-Za-z0-9_-]{35}";
union DeviceProcessEvents, DeviceEvents
| where TimeGenerated > ago(7d)
| where ProcessCommandLine matches regex TelegramTokenPattern
or AdditionalFields has "api.telegram.org"
| project
TimeGenerated,
DeviceName,
AccountName,
FileName,
ProcessCommandLine,
InitiatingProcessFileName,
InitiatingProcessCommandLine
| order by TimeGenerated descDetecting Suspicious File Uploads via Telegram sendDocument
This query looks for network connections to api.telegram.org that are initiated within 60 seconds of a file read event on sensitive paths — a behavioral indicator of staged exfiltration.
// Sentinel — correlates file access with Telegram network activity
// Flags potential exfiltration staging behavior
let SensitivePaths = dynamic([
"C:\\Users\\",
"C:\\ProgramData\\",
"C:\\Windows\\System32\\config\\"
]);
let TelegramConnections = DeviceNetworkEvents
| where TimeGenerated > ago(24h)
| where RemoteUrl has "api.telegram.org"
| project DeviceId, NetworkEventTime = TimeGenerated;
DeviceFileEvents
| where TimeGenerated > ago(24h)
| where ActionType == "FileRead"
| where FolderPath has_any (SensitivePaths)
| where FileName endswith ".db"
or FileName endswith ".kdbx"
or FileName endswith ".pfx"
or FileName endswith ".csv"
| join kind=inner TelegramConnections on DeviceId
| where abs(datetime_diff('second', TimeGenerated, NetworkEventTime)) <= 60
| project
TimeGenerated,
DeviceName = DeviceId,
FileName,
FolderPath,
NetworkEventTime,
TimeDeltaSeconds = datetime_diff('second', TimeGenerated, NetworkEventTime)
| order by TimeGenerated desc---
Restricting Telegram at the Intune and Network Layer
Detection alone is insufficient. You need enforcement controls that reduce the attack surface before a detection fires.
Intune Application Control via WDAC
Windows Defender Application Control (WDAC) policies deployed through Intune can block the Telegram desktop client binary without requiring a third-party application control solution. The relevant publisher rule targets the Telegram FZ-LLC certificate.
For environments where Telegram is not an approved business application, deploy a WDAC supplemental policy that denies execution of any binary signed by Telegram's publisher certificate. This is managed through the Endpoint Security > Application Control blade in Intune, using a custom OMA-URI policy with your compiled WDAC XML.
For environments where Telegram is partially approved (e.g., specific teams use it for vendor communication), scope the WDAC deny rule to device groups that exclude those teams, and enforce a Conditional Access policy requiring compliant device status before allowing api.telegram.org traffic through your proxy.
DNS-Layer Blocking via Intune-Deployed DNS Policy
Use Intune's Settings Catalog to configure Windows DNS Client settings, or deploy a custom PowerShell script to enforce DNS-over-HTTPS to a resolver that supports category-based blocking (e.g., Cloudflare Gateway or Microsoft's own DNS filtering via Defender for Endpoint's network protection).
$HostsPath = "C:\Windows\System32\drivers\etc\hosts"
$BlockedDomains = @(
"api.telegram.org",
"web.telegram.org",
"desktop.telegram.org",
"updates.tdesktop.com"
)
foreach ($Domain in $BlockedDomains) {
$Entry = "0.0.0.0`t$Domain"
$Existing = Get-Content $HostsPath | Where-Object { $_ -match [regex]::Escape($Domain) }
if (-not $Existing) {
Add-Content -Path $HostsPath -Value $Entry
Write-Output "Blocked: $Domain"
} else {
Write-Output "Already present: $Domain"
}
}Important: Hosts file blocking is trivially bypassed by malware that uses hardcoded IP addresses or DoH. Treat this as a defense-in-depth layer, not a primary control. Your primary enforcement should be at the proxy or DNS resolver level with TLS inspection enabled.
Conditional Access and Defender for Cloud Apps
If your organization uses Microsoft Defender for Cloud Apps (formerly MCAS), add Telegram to the Cloud App Catalog as an unsanctioned application. This triggers block policies at the proxy level for managed devices routing through the Defender for Endpoint network protection stack.
For managed devices, enable Defender for Endpoint's network protection in block mode via Intune's Endpoint Security profile. This enforces SmartScreen and custom indicator blocks at the kernel level, before traffic reaches the network stack — making it significantly harder for userland malware to bypass.
---
Governance Controls That Actually Close the Audit Finding
The compliance gap described earlier requires procedural controls alongside technical ones.
First, add api.telegram.org and Telegram's IP ranges to your named locations in Entra ID Conditional Access — not to block authentication, but to create a signal that can be correlated in Sentinel when a managed device accesses these ranges outside of approved application groups.
Second, document Telegram's classification in your data flow inventory required under ISO 27001:2022 Annex A 5.14. If Telegram is used for any business communication, it must appear in the inventory with its data classification, approved use cases, and monitoring status. If it is not approved, the inventory must reflect that it is blocked and monitored for bypass attempts.
Third, create a Sentinel Analytics Rule from the KQL queries above and map them to the MITRE ATT&CK framework: specifically T1071.001 (Application Layer Protocol: Web Protocols) and T1567.002 (Exfiltration Over Web Service: Exfiltration to Cloud Storage). This mapping is what auditors look for when validating that your monitoring scope covers known exfiltration techniques — not just that alerts exist.
Fourth, schedule a quarterly review of your Defender for Endpoint custom detection rules to validate that Telegram's IP ranges and API endpoints haven't changed. Telegram periodically adds CDN nodes. A static IP block list degrades over time without maintenance.
---
Final Thoughts
The Telegram C2 problem is a specific instance of a broader architectural reality: threat actors route C2 traffic through legitimate, high-reputation infrastructure precisely because enterprise security tooling is tuned to trust it. Telegram is effective as a C2 channel not because it's sophisticated, but because it's boring — it looks like normal developer traffic, and most EDR configurations never challenge that assumption.
The remediation path is not "block all messaging apps." That approach fails operationally and misses the actual threat vector, which is the Bot API, not the consumer client. The path is precise: deploy KQL detection rules that identify polling behavior and token patterns, enforce network protection in block mode, add Telegram to your unsanctioned app catalog in Defender for Cloud Apps, and close the audit gap by mapping your detections to MITRE ATT&CK T1071.001 and T1567.002.
Every control described in this article is deployable today using Microsoft-native tooling. No third-party agents. No additional licensing beyond what most enterprise M365 E5 tenants already hold. The gap isn't a product gap — it's a configuration gap. Close it deliberately.
---
