How to use a Telegram token

In the following article I talk about some approaches to mitigate the damage from a criminal attack. I am not sure if what I am talking about is legal in all countries, so do your research first. Or use a VPS in Russia 😀

Telegram is one of the main tools used by criminals to receive stolen information through various types of attacks, including of course phishing sites.

Below I outline some simple actions we can take to mitigate Telegram bot-based attacks. But first let’s see how to use a token.

For this post I will use a token identified in these hours within a kit distributed on different domains:

• psyclum.org
• lwonsio.org
• peyssc.org
• katjrig.org
• katjriv.org
• sorajfm.org
• niondin.org

Analyzing the deployment methods of the kit, we can see how the criminal registered the various domains and only after several days installed the kit. This in an attempt to avoid being intercepted. Fortunately, Matrix also manages these situations 🙂

Let’s move on to the kit, as always it’s a piece of junk written in PHP. Inside we find the Telegram bot token to which stolen credentials are sent to unwary users.

Now let’s move on to the main topic of this article: we have a token, what do we do with it? First, let’s study. Here is the documentation on how to use bots: https://core.telegram.org/bots/api

Using VS Code and the amazing “REST Client” extension we can query bots and use it to mitigate criminal action.
First, using the “getMe” method I check if the token is active. The 200 return code and the Json in response indicate that the token is active and therefore ready to receive information from clients, including the phishing site itself.

When the unwary user enters their credentials into the phishing site, it sends the information to the Telegram bot. Two things can happen here: if there is a registered webhook, the information is sent to the resource indicated as the webhook, otherwise the information is kept in the bot’s message queue to be consumed via the “getUpdates” method.

Using the “getWebhookInfo” method we check the bot status and the possible presence of a webhook. In this case the webhook is not registered and therefore we must use the “getUpdates” method to download any messages present in the queue.

By calling the “getUpdates” method we see that there are no messages in the queue. If there were any, our call would have returned them to us by deleting them from the queue.

As mentioned, we have several ways to handle this situation. The first is to register a resource of our own as a webhook that will then receive the stolen information, allowing us to act promptly. For example, you could implement an alert system for the user to warn him that his credentials have been stolen and perhaps even deactivate his account and credit cards. As an alternative to registering your own webhook, you can implement a polling mechanism to download the stolen information, removing it from the criminal’s reach, and use it to mitigate the threat: as mentioned above, you can block the account, warn the user, and explain to them that they need to be careful.

Another approach is token deletion. I personally don’t like this approach because it prevents us from intercepting compromised accounts and therefore deprives us of the ability to act on users.