Forcepoint - Telegram encrypted messaging service as a C2 infrastructure for malware

At Forcepoint Security Labs we are always looking at the methods threat actors use to circumvent existing protections. One such investigation saw us looking into the usage of the Telegram encrypted messaging service as a Command and Control (C2) infrastructure for malware.

Malware that uses Telegram as a C2 channel typically uses the Telegram Bot API for communications. In the course of an investigation into one piece of malware, we discovered a significant flaw in the way Telegram handles messages sent through its Bot API.

Due 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 within TLS traffic for securing messages between regular users like it (justifiably) see 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 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 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.