Owing to how the Bot API works, all past bot messages can be replayed by an adversary capable of intercepting and decrypting HTTPS traffic. In practice, this can give the adversary the full history of all messages sent or received by the target bot. This often includes messages between regular human users as bots frequently share a group chat with them.

Gaining access to Telegram C2 messages

Telegram uses its in-house MTProto encryption for securing messages between regular users as it (justifiably) sees TLS as not secure enough on its own for an encrypted messaging application.

Unfortunately, this does not apply in the case of programs which use the Telegram Bot API as messages sent this way are only protected by the HTTPS layer. To make matters worse, any adversary capable of gaining a few key pieces of information transmitted in every message can not only snoop on messages in transit but can recover the full messaging history of the target bot.

One of these key pieces of information is the bot API token, which is embedded in all messages (as well as in the binary of any program – malware or legitimate – using the Telegram Bot API). It is thus trivial for an adversary performing MiTM on the target’s HTTPS connection to obtain this data.

The other crucial piece of the puzzle is a randomly generated Telegram chat_id. In the case of individual chats this is the user's own unique ID, whereas group chats get their own chat_id generated upon creation. However, this information is also sent in any Bot API request as the bot needs to know to which user and/or group chat to send the information.

Equipped with these pieces of information, there are a number of methods that can be called from the Telegram Bot API. In our case, the forwardMessage() method is particularly useful, as it allows any message from any chat a given bot has access to be forwarded to an arbitrary Telegram user. To do this we need the API token and the ‘source’ chat_id (either extracted from previous messages sent by the bot or, in the case of malware, from the binary itself) – along with the ‘target’ chat_id (which is our own user id) and finally the message id we would like to forward.

Fortunately for us, message_id’s grow incrementally from 0, so a simple Python script can forward all messages that have ever been sent to a Telegram chat that the bot is currently part of.

One particular piece of malware proved to be an excellent case study of why this is dangerous, with the threat actor clearly not having the necessary separation between their testing/development and operational environments. This meant that we could track their first steps towards creating and deploying the malware (see the Activity Timeline below) all the way through to current campaigns in the form of communications to and from both victims and test machines.

In an extraordinarily poor display of operational security, one of these test machines appears to have been the actor’s own, revealing both his IP address and a host of other sensitive personal information.

Not-so-GoodSender

The piece of malware in question is a fairly simple .NET malware the operator dubbed ‘GoodSender’ and uses Telegram as C2. It operates in a rather simple way: once the malware is dropped it creates a new administrator user and enables remote desktop as well as making sure it's not blocked by the firewall. The username for the new admin user is static, but the password is randomly generated.

All of this information (the username, password, and IP address of the victim) is sent to the operator through the Telegram network, thus providing the operator with access to the victim’s computer through RDP.

Figure 1 - The code in GoodSender that builds the Telegram Bot URL

Figure 2 - The profile screen of the Telegram Bot

Activity Timeline, Threat Actor, and Victims

The actor initially used the Telegram bot in question for a different piece of malware he was developing. This earlier malware was called ‘RTLBot’, and over the course of a few months he added a number of additional features before abandoning its development in favour of the ‘GoodSender’ the malware described above.

The details of timeline below and the screenshots included were retrieved from the malware's historical C2 communications, and demonstrate the ability to use the method described to retrieve the historical messages from a Telegram channel.

4 February 2018 – The Telegram bot goes live.
18 February 2018 – The actor starts incorporating Telegram C2 functionality into RTLBot and shifts the development onto Telegram.
20 February 2018 – The actor moves his infrastructure away from his personal computer onto AWS (Amazon Web Services).
1 April 2018 – GoodSender is active and sends its first victim information.
6 June 2018 – The first indication that the actor has rented another VPS to use as a Telegram proxy.
5 July 2018 – GoodSender sends its last real victim information to date.
29 September 2018 – GoodSender sends its last test victim information to date.

On 23 November 2018 the actor incorporated the same bot API key and C2 channel into a tool that appears to collect images from Instagram accounts. Given the frequent naming of elements as test (e.g. testbot in Figure 3 below), it seems likely that this channel is used for testing bots before changing the API key and channel to 'production' values.

Figure 3 - A screenshot, apparently of the author's development machine, uploaded to the Telegram channel by the bot

Figure 4 - Another screenshot of the author's development environment showing the new proxy first observed on 6 June 2018

While we found no definitive answer to what attack vector the actor must have used to drop the malware, a number of clues indicate that he used the EternalBlue exploit to drop his malware on unpatched machines.

He makes heavy use of the free EternalBlue vulnerability scanner called ‘EternalBlues’;
He has a list of scanned US and Vietnamese IPs that were vulnerable to EternalBlue he then used to infect a few of his victims.

Based on our telemetry, GoodSender has infected at least 120 victims, predominantly in the US.

Figure 5 - A red-hot/blue-cold heatmap of GoodSender victims based on GeoIP information

Figure 6 - Bar graph of victims based on GeoIP information

Summary

In our case study this particular technique for replaying messages was used to uncover a threat actor, but it could very well be used against legitimate applications employing the Telegram Bot API.

Even though Telegram is advertised as a ‘secure messaging application’ and uses an encryption scheme with higher theoretical assurances than TLS during normal chats, bots use traditional TLS to encrypt data in transit. Thus, an attacker in MitM position with capability to decrypt TLS could gain access to the bot token as well as the chat_id leading to a full compromise of not just the current communication but all previous communication to which the bot was party as well.

As such, Forcepoint Security Labs recommend all users avoiding using Telegram bots as well as avoiding channels and groups with a bot.

Forcepoint has informed Telegram of this vulnerability.

Forcepoint customers are protected against the GoodSender malware in our case study at the following stages of attack:

Stage 5 (Dropper File) – Malicious files are prevented from being downloaded.

IOCs (GoodSender)

943eceb00ea52948c30deab1d5824ffcf2fd1cec

While Forcepoint uses reasonable efforts to include accurate and up-to-date information, we make no warranties or representations as to the accuracy of the content and assume no liability or responsibility for any error or omission in the content. The information is provided AS IS, without representation or warranty, express or implied and is subject to change without notice. This is not professional advice and users rely on this information at their own risk. Forcepoint assumes no liability for the use of this information.

Forcepoint Data Security Cloud

Forcepoint DSPM + DDR

Forcepoint DLP

Forcepoint Web Security

Forcepoint Cloud App Security

Risk-Adaptive Protection

Forcepoint Email Security

Data Classification

Salud

Servicios Financieros

Sector Público

DLP for Healthcare

Proteja el uso de la IA generativa

Proteja los datos en ChatGPT

How to Protect Your Data Everywhere

Vea nuestro software de Data Detection & Response (DDR) en acción

Blogs

Webcasts

Podcasts

Informes de analistas

Historias de clientes

Biblioteca de recursos

Capacitación y certificaciones

Cyber EDU

GUÍA

La Guía Práctica para Ejecutivos sobre Data Loss Prevention

GUÍA

Forcepoint AI Mesh

INFORME DE ANALISTAS

Gartner: 2025 Market Guide for Data Loss Prevention

RISK ASSESSMENT

Get Free Data Risk Assessment for OneDrive

Nuestro enfoque

Nuestros Clientes

Forcepoint vs. Netskope

Forcepoint vs. Palo Alto Networks

Forcepoint vs. Zscaler

Acerca de nosotros

Sala de Prensa

Trabaje con nosotros

Comuníquese con Nosotros

Forcepoint Trust Hub

VAKIFBANK fortalece la postura de seguridad y la elaboración de informes de cumplimiento

Eczacıbaı Holding extiende la seguridad a la nube para proteger al personal remoto

Communisis moderniza su Forcepoint DLP con Risk-Adaptive Protection

X-Labs

Predicciones de Ciberseguridad de Forcepoint para el 2020

X-Labs

Get insight, analysis & news straight to your inbox

Analizando Bots de Telegram