name: PowerShell Telegram Bot API Used as Command and Control Channel Analytic
signatureid: WEL-PSH137-RUN
category: 'Command and Control'
threatname: 'Web Service: Bidirectional Communication'
functionality: 'Microsoft Windows Powershell'
description: |
Detects a single PowerShell script block that combines a reference to the Telegram Bot API
domain (api.telegram.org) with at least one Bot API operation used for command-and-control
(getUpdates to poll for operator commands, getFile?file_id= to fetch a staged payload, or
sendMessage?chat_id= to exfiltrate output/beacon status) and a PowerShell HTTP primitive
(Invoke-RestMethod, Invoke-WebRequest, or System.Net.WebClient) used to make the call.
HEAVYGRAM-class tooling uses the Telegram Bot API as a bidirectional channel: getUpdates
polls for attacker-issued commands, sendMessage returns command output or beacon data, and
getFile retrieves staged second-stage content, all over normal HTTPS to a domain that blends
with legitimate traffic and is rarely blocked outright. The three-part requirement (domain +
Bot API verb + HTTP primitive) keys on how the technique is used rather than on any one
operator's token, chat ID, or staging infrastructure, none of which are required for the
channel to work and all of which the operator can rotate freely.
This is a single-event, content-based detection over Microsoft-Windows-PowerShell/Operational
Event ID 4104 (Script Block Logging). It requires Script Block Logging to be enabled
(EnableScriptBlockLogging under the PowerShell ScriptBlockLogging GPO path); the emulation
for this Delta found it disabled by default in the lab and had to enable it before any 4104
evidence could be produced.
reference:
- https://attack.mitre.org/techniques/T1102/002/
- https://attack.mitre.org/techniques/T1071/001/
- https://core.telegram.org/bots/api
- https://connect.securonix.com/threat-research-intelligence-62/heavygram-inside-handala-hack-s-telegram-native-surveillance-backdoor-567
labels:
- attack.command_and_control
- attack.t1102.002
- attack.t1071.001
- HEAVYGRAM
- Telegram C2
logsource:
service: powershell
product: windows
detection:
selection_telegram_domain:
ScriptBlockText|contains: 'api.telegram.org'
selection_bot_api_operation:
ScriptBlockText|contains:
- 'getUpdates'
- 'getFile?file_id='
- 'sendMessage?chat_id='
selection_http_primitive:
ScriptBlockText|contains:
- 'Invoke-RestMethod'
- 'Invoke-WebRequest'
- 'System.Net.WebClient'
condition: selection_telegram_domain and selection_bot_api_operation and selection_http_primitive
criticality: High
saveasthreat: false
violation_summary:
grouping_attribute: 'AccountName'
level2_attribute: 'DeviceHostName'
level2_metadata_attributes:
metadata_attributes: 'ScriptBlockText'TECHNICAL DETAILS
Emulated with a harmless PowerShell PoC using a
conspicuously dummy, unregistered bot token. The single script block called, in order:
Invoke-RestMethod -Uri 'https://api.telegram.org/bot<dummy>/getUpdates' ...
Invoke-WebRequest -Uri 'https://api.telegram.org/bot<dummy>/getFile?file_id=DUMMY_FILE_ID_NOT_REAL' ...
(New-Object System.Net.WebClient).DownloadString('https://api.telegram.org/bot<dummy>/sendMessage?chat_id=000000000')
Each call was expected to fail (invalid token -> HTTP 401, or an egress drop at the range's
Palo Alto firewall) and did fail; this is by design and irrelevant to the detection, because
both Script Block Logging (4104) and Sysmon DNS Query (EID 22) fire on the attempt, not on a
successful response. The DNS resolution for api.telegram.org happened from powershell.exe
(C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe), confirmed via Sysmon EID 22
QueryName/Image fields read directly from the guest's own event log immediately before
collection.
Lab prerequisite check performed before emulation: Sysmon EID 22 (DnsQuery rule, onmatch:
exclude, api.telegram.org not in the exclude list) was already enabled. PowerShell Script
Block Logging was NOT enabled (no EnableScriptBlockLogging value under
HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging) and was enabled via
registry for this run, functionally re-verified against a live 4104 event both before and
after a range revert to the clean snapshot (the revert removes the registry change, so it was
re-applied and re-verified post-revert, before truncating the collector).
Post-collection verification used evidence_grep against the archived flat-file copies before
citation. The PowerShell member contained exactly one api.telegram.org match: Event ID 4104
with the Bot API operations and HTTP primitives in ScriptBlockText. The Sysmon member contained
five lines matching api.telegram.org, including one Event ID 22 with QueryName
api.telegram.org and powershell.exe as the resolving image; the other matches were supporting
process/file telemetry carrying the command text. evidence_extract then produced focused
copies containing one PowerShell line (1,131 bytes) and five Sysmon lines (10,520 bytes), and
the ATD URLs above point to those extracts rather than the full raw collector members.
False Positives:
- Legitimate internal tooling that intentionally relays through Telegram (rare, and should
be excluded by accountname/host once identified rather than by weakening this rule).
- Security research or red-team scripts exercising the Telegram Bot API from PowerShell.
Policy building walkthrough can be found in this previous post: