Telegram Malware investigated by Forcepoint Security Labs

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 as 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.

GoodSender sends IP, username and password to Telegram C2

The Telegram Bot receiving the information

The operator’s Telegram account

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.

• 4 February 2018 – The Telegram bot goes live
• 18 February 2018 – Threat actor starts incorporating Telegram C2 functionality into RTLBot and shifts the development onto Telegram
  
• 20 February 2018 – Moves his infrastructure away from his personal computer onto AWS (Amazon Web Services)
  Adding additional functionality to RTLBot
• 1 April 2018 – GoodSender is active and sends its first victim information
• June 2018 – Rents another VPS to use as a Telegram proxy
  

  Testing Telegram bot

  
• September 2018 – GoodSender sends its last victim information to date

Attack vector and victims

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

• 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.

Map: Distribution of Victims