Built a functional C2 implant using Telegram's Bot API as a covert communication channel, then configured network-level detection to identify the attack pattern.
Overview
This lab explores how attackers abuse legitimate third-party infrastructure to evade detection. By using Telegram as a C2 channel, outbound traffic blends in with normal HTTPS traffic to api.telegram.org, a domain rarely blocked in corporate environments. The lab covers both the offensive implementation and the defensive detection angle.
Architecture
- pfSense as the network gateway with NAT and port forwarding
- Isolated victim network (10.10.20.0/24) on a dedicated virtual bridge
- Windows 10 victim VM, domain-independent, simulates a compromised endpoint
- Python C2 agent on the victim, using Telegram long-polling (getUpdates) for command retrieval
- Suricata IDS on pfSense for network-level traffic inspection
How it works
The agent runs silently on the victim, polling Telegram every 30 seconds for new commands. The attacker sends commands via a private Telegram bot (e.g. /cmd whoami); the agent executes them via cmd.exe and returns output via sendMessage. No dedicated C2 server is required. Telegram's infrastructure acts as the relay.
Offensive capabilities demonstrated
- Remote command execution via subprocess + cmd.exe
- Chat ID filtering to prevent unauthorized bot access
- Pull-based architecture: victim initiates outbound, no inbound firewall rules required
Defensive detection
- Suricata rules deployed on pfSense to detect periodic polling to api.telegram.org
- Detection logic targets beaconing patterns: repetitive HTTPS connections at regular intervals from non-user hosts
Why this matters
This attack pattern (HTTPS to legitimate platforms as C2) is actively used in the wild by AsyncRAT variants, TA505, and others. Understanding it at the implementation level is the foundation for writing effective detection rules and tuning SIEM alerts that aren't fooled by "it's just HTTPS."