Man in the Malware: Intercepting Adversarial Communications

Man in the Malware: Intercepting Adversarial Communications

Speakers: Ben Folland

Conference: DEF CON 33

YouTube: https://www.youtube.com/watch?v=lv-hua5b_9s

Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/Ben%20Folland%20-%20Man-in-the-Malware%20Intercepting%20Adversarial%20Communications.pdf

Overview

Ben Folland's DEF CON 33 talk presents a threat intelligence methodology for intercepting malware communications—specifically, the C2 (command and control) channels and data exfiltration pipelines of info-stealers and other commodity malware that use platforms like Telegram as their backend. By analyzing the operational security failures of threat actors who configure their malware bots with hardcoded or extractable credentials, defenders can not only detect infections but actively monitor, intercept, and counter adversarial operations.

The talk walks through the anatomy of info-stealer malware, why Telegram became a dominant C2 channel for commodity actors, how to extract bot tokens and chat IDs from malware samples, and a detailed case study where Folland's team at Huntress intercepted a threat actor's Telegram-based exfiltration channel and gathered significant intelligence about the actor's operations, victims, and infrastructure—all from the attacker's own OPSEC failures.

Background

▶ Watch: Introduction: researching Telegram-based C2 infrastructure for info-stealers (2:17)

The Info-Stealer Ecosystem

Info-stealers are a category of malware designed to harvest credentials, cookies, cryptocurrency wallets, browser history, and sensitive files from infected machines and transmit them to an attacker-controlled collection point. The market for info-stealers has exploded in recent years, with Malware-as-a-Service (MaaS) offerings like Redline, Raccoon, Vidar, and Lumma available for subscription on criminal forums. These stealers are sold with web-based administration panels—but a growing number of low-tier operators use Telegram bots as a simpler alternative.

Telegram as a C2 Platform

Telegram's bot API provides a free, reliable, and abuse-resistant (from the attacker's perspective) mechanism for receiving data. A Telegram bot is created with a token—a string like BOTID:SECRETTOKEN—that allows HTTP requests to the Telegram API to send and receive messages in a designated chat or channel. For info-stealers, this works as follows:

1. The malware runs on a victim machine, harvests credentials and data.
2. The data is compressed and sent as a message or file attachment to a Telegram bot using the bot's token.
3. The bot delivers the data to a Telegram channel or chat that the attacker controls.

The appeal for attackers: no server to maintain, resilient global infrastructure, and exfiltrated data is delivered directly to their Telegram client. The security failure: the bot token is embedded in the malware sample, and with it, anyone—including a defender—can interact with the bot.

Key Findings

▶ Watch: OPSEC failures: systematic mistakes in threat actor operational security (7:12)

Bot tokens in malware are extractable and reusable. Folland demonstrates that the majority of Telegram-C2-enabled malware embeds the bot token either in plaintext or in a trivially decoded form (base64, simple XOR). Static analysis of a malware sample yields the token. That token is then usable by anyone to call the Telegram Bot API.

Defenders can enumerate victims using the bot API. The Telegram Bot API endpoint getUpdates returns recent messages sent to the bot—messages that contain stolen credential dumps from all recent victims. By polling getUpdates with an extracted token, a defender can:

• Enumerate all recent victims (by the exfiltrated data they sent).
• Identify the scope of an ongoing campaign.
• Recover stolen data to notify affected parties.

The chat ID reveals the attacker's Telegram profile. The destination chat ID (where the bot delivers data) is also embedded in the malware or extractable from API responses. While Telegram does not expose personal information via the chat ID alone, in many cases the attacker's username, profile picture, and linked channels are visible—providing threat intelligence about the actor.

Attackers frequently reuse tokens across campaigns. Rather than generating a new bot token for each malware build, many low-tier actors reuse the same token. This means that a single extracted token can provide visibility into months of exfiltrated data across multiple victim organizations.

OPSEC failures cascade. The case study demonstrates that a single Telegram token, once extracted, led to: victim enumeration, actor identification, infrastructure mapping (domains, IPs used in payloads), and secondary actor account discovery through message metadata.

Technical Deep Dive

▶ Watch: Man-in-the-malware: intercepting and logging all C2 communications (14:52)

Malware Sample Analysis

Folland's workflow for extracting Telegram credentials from a malware sample:

1. Static analysis: Load the sample in a tool like FLOSS (FireEye Labs Obfuscated String Solver) or manually in a disassembler (Ghidra, Binary Ninja, IDA). Search for strings matching the Telegram bot token pattern: a numeric ID followed by a colon and a 35-46 character alphanumeric/underscore/hyphen string.

1. If obfuscated: Identify the decryption routine (commonly simple XOR with a single-byte key, or base64 decoding) and extract the plaintext token.

1. Dynamic analysis: Run the sample in a sandbox with HTTP/HTTPS logging. Observe the outbound request to api.telegram.org/bot{TOKEN}/sendDocument or similar endpoints. The token is visible in the URL path.

Telegram Bot API Abuse

Once the token is extracted, the attacker's bot becomes accessible to the analyst. Key API calls:

• GET https://api.telegram.org/bot{TOKEN}/getMe — Verify the token is valid and retrieve the bot's username.
• GET https://api.telegram.org/bot{TOKEN}/getUpdates — Retrieve up to 100 pending messages. Each message contains the payload sent by a victim machine—typically a zip archive with credential dumps, browser cookies, and system information.
• GET https://api.telegram.org/bot{TOKEN}/getUpdates?offset=-1 — Get the most recent message. Incrementing the offset iterates through history.

The getUpdates endpoint returns a JSON array of Update objects, each containing a message with a from field (the bot itself, since it's forwarding), a chat with the destination chat ID, and document or text attachments. The chat ID of the attacker's channel is exposed in each update.

Victim Enumeration from Exfiltrated Data

Each "update" received via getUpdates typically contains an archive (ZIP or RAR) containing:

• A passwords.txt with browser-saved credentials.
• A cookies.txt with session cookies.
• System information (hostname, Windows version, installed software).
• Crypto wallet files if present.

From these archives, defenders can identify victim organizations, the usernames/hostnames of compromised machines, and the timing of infections. In the case study, the team was able to identify compromised organizations and issue notifications.

The Case Study: Threat Actor Interception

Folland describes a specific engagement where a Huntress client's machine was infected with an info-stealer using a Telegram-based exfiltration pipeline. Upon extracting the bot token from the sample:

1. getUpdates returned 87 messages—87 separate victim machines had exfiltrated data to this bot.
2. The attacker's Telegram channel was identified from the chat ID. The channel was public and contained the actor's Telegram username.
3. The actor's profile linked to a criminal marketplace forum account with a history of selling stolen credentials and RDP access.
4. The malware payloads linked from the actor's posts contained a consistent infrastructure pattern (same hosting provider, same domain registration pattern).
5. The exfiltrated data allowed identification and notification of multiple victim organizations, including several outside the original client relationship.

Throughout the operation, the attacker had no indication their bot was being monitored by a defender—getUpdates queries are indistinguishable from the malware's own outbound requests.

Disruption Techniques

Beyond passive monitoring, Folland discusses techniques for actively disrupting the attacker's operations:

• Message deletion: The Telegram Bot API allows bots to delete messages they have sent. A defender controlling the bot token can delete exfiltrated data before the attacker retrieves it. This denies the attacker the stolen credentials while the defender can still analyze the victim metadata.
• Bot disabling via abuse report: Armed with specific evidence of abuse, Telegram's abuse reporting channel for bot tokens can disable the bot. The attacker must generate a new token and rebuild malware.
• Controlled degradation: The defender can acknowledge specific messages (marking them as read in getUpdates) so the attacker's polling returns empty—a "ghost bot" from the attacker's perspective.

Demo / Proof of Concept

▶ Watch: Attribution technique: OPSEC failures enable threat actor identification (20:14)

The talk demonstrates:

• Token extraction from a real malware sample using FLOSS and Ghidra.
• getUpdates query returning victim data from the attacker's bot, shown as JSON output.
• Victim archive contents with credentials and system info (redacted PII), illustrating the intelligence value.
• Attacker profile pivot from chat ID to Telegram username to forum identity to infrastructure.
• Message deletion via the Bot API, showing the attacker's view of an empty bot after the defender deletes pending messages.

Defensive Implications

▶ Watch: Infrastructure mapping: linking bot token to attacker's broader crime operations (33:44)

For incident responders:

• When analyzing a Telegram-C2-enabled malware sample, extract the bot token as a primary indicator and query getUpdates immediately—the window during which victim data is in the bot's message queue is time-limited.
• Use the victim enumeration capability to scope the campaign and notify other affected organizations.
• Report the bot token to Telegram's abuse team promptly.

For threat intelligence teams:

• Telegram bot tokens extracted from malware samples are high-value intelligence artifacts. Maintain a repository and correlate tokens across campaigns to identify actor infrastructure reuse.
• Chat IDs and actor usernames provide actor attribution trails that can be cross-referenced with underground forum profiles.

For defenders and blue teams:

• Monitor for outbound DNS queries to api.telegram.org from workstations—legitimate user activity rarely requires programmatic Telegram API access from a business machine.
• Network-level blocking of api.telegram.org will disrupt Telegram-based C2, at the cost of blocking legitimate Telegram app access.

For malware developers (adversarial perspective the talk documents): Hardcoding bot tokens in malware is an operational security failure. Defenders have been exploiting this for years. More sophisticated actors use server-side token management where the token is retrieved from an authenticated API call at runtime, making static extraction insufficient.

Key Takeaways

1. Telegram bot tokens embedded in malware provide defenders with the same access to the bot that the attacker has—including full visibility into all exfiltrated data.
2. OPSEC failures by commodity threat actors are systematic: reused tokens, public attacker channels, and predictable infrastructure patterns enable significant intelligence collection.
3. Proactive interception of malware C2 channels can enable victim notification across entire campaigns, not just the initial incident.
4. The Telegram Bot API can be used both for defensive intelligence gathering and for active disruption of an attacker's exfiltration pipeline.
5. Threat actors using Telegram as a free, convenient C2 platform are trading operational security for convenience—a trade that informed defenders can exploit.

About the Speaker(s)

▶ Watch: Live demo: watching threat actor troubleshoot their own malware in real time (38:17)

Ben Folland (online handle: PolygonBen) is a threat analyst at Huntress, working in the UK team. His background is in threat hunting and malware analysis, with a focus on commodity malware and the criminal ecosystems that produce and distribute it. This was his first DEF CON talk and only his second time in the United States. He credited Huntress with enabling the research and providing the environment to develop the techniques presented. He describes himself as a "blue teamer" who, through this work, found himself operating in traditionally offensive-adjacent territory—exploiting attacker infrastructure against its creators.