Geost botnet downfall

Introduction

As we have already seen in another blog post, OPSEC is not just for everyday users. It applies to everyone. Malware developers and botnet operators are no exception. Because they engage in highly sensitive and illegal activities, and face severe consequences if caught, they must maintain flawless OPSEC. In this article, we will see that even individuals with the expertise to develop and operate advanced malware and botnets can make critical mistakes that lead to their downfall. Today, we will examine the Geost botnet and how its operators were exposed.

What is Geost Botnet ?

First of all, if you're not familiar with what a botnet is, I highly encourage you to read this article, which provides a detailed explanation.

Before delving into the details of the Geost botnet, it's important to first understand what HtBot is. HtBot is a type of malware that turns infected devices into unwilling proxies, enabling attackers to remotely control them and use them for malicious activities, such as stealing data or spreading additional malware. It has been linked to several cybercriminal operations, including the Geost banking botnet, which specifically targeted Russian banks.

The Geost botnet, which operated through HtBot, consisted of a large number of APK Android applications, ranging from fake social networks to banking and photo services, that installed malware on Android devices. Once the malware was installed, it allowed the botnet administrators to access personal data from victims, particularly SMS messages, including those sent by their banks. The malware was capable of directly interacting with the web services of five banks in Eastern Europe.

In essence, the objective of the Geost botnet was to infect individuals' Android devices in order to gain access to their bank accounts. The malware in question was used to access millions of euros held in bank accounts across Eastern Europe and Russia, compromising more than 800,000 victims. Through this malware, the botnet administrators were able to collect victims' information via a centralized control panel, which provided details such as account balances.

What caused their downfall ?

The answer to this question is simple: they failed to maintain proper OPSEC. However, the number and scale of their mistakes deserve closer examination. Let us begin with the error that first led researchers to uncover their existence.

Using HtBot

The first mistake made by the creators of Geost was relying on HtBot. HtBot operates by turning victims' devices into proxies to route traffic. This means that if a researcher manages to deliberately infect a device with the malware in a controlled environment, they can monitor the traffic passing through it. That is precisely what the researchers did. By analyzing traffic from an infected device, they identified unusual patterns. In particular, a significant amount of unencrypted data was being routed through the device, prompting them to investigate its destination.

Choosing to rely on HtBot was a matter of convenience for the Geost administrators, as it allowed them to use an existing infrastructure without having to manage their own architecture. However, as is often the case with OPSEC, convenience does not necessarily mean security. By prioritizing simplicity, they increased their exposure. Operating their own carefully secured proxy infrastructure might have made their activities far less detectable.

To put it simply, as shown in the image above, a proxy sits between your computer and the internet. If no one else has access to that proxy, the traffic passing through it cannot easily be monitored. However, if the proxy is controlled by a researcher, because the infected device itself is routing the traffic, then that researcher can observe everything passing through it.

Do not encrypt data

Encryption is a fundamental principle of OPSEC. Anyone concerned with operational security understands that data should be encrypted to ensure it remains unreadable if intercepted. However, the Geost administrators chose not to encrypt the data they were collecting and transmitting. Combined with the fact that this data was routed through devices controlled by researchers, this oversight gave investigators full access to unencrypted information, allowing them to see exactly what was being transferred.

If they had encrypted the data, the researchers might still have noticed that large volumes of information were being transmitted, but they would not have been able to determine its content.

To put it simply, this decision is comparable to asking Person A to pass your secret to Person B while hoping that Person A will not learn the secret in the process. It is an extremely reckless and illogical approach. It is often surprising to see that individuals capable of developing and managing sophisticated criminal operations can overlook such fundamental precautions.

The lack of encryption had consequences beyond simply revealing what data the administrators were collecting. It also allowed the researchers to intercept and analyze the administrators' connections to their C&C server.

In this instance, we can see that a Geost administrator attempted to connect to the C&C server from a Windows device, with the domain wgg4ggefwg.ru. Furthermore, because different administrators used different devices, the responses to these connection attempts varied, allowing the researchers to gather information about the number of administrators and the software they were using.

Finally, the researchers were able to intercept the administrators' password when they connected to the C&C server, granting full access to their operations. Additionally, because the login interface, which required only a password and no username, was displayed in both Russian and English, the researchers inferred that these were the two languages used by the botmasters.

Using Skype

Later in their investigation, researchers discovered that the botmasters were using Skype to communicate with one another. This was a major OPSEC failure for several reasons. First, using Skype for sensitive activities requires trusting a large corporation to protect your communications. Skype is owned by an American company, while the botnet operators were based in Russia. Given that the U.S. government conducts extensive surveillance on Russia, and vice versa, and that American companies often cooperate with government requests without restriction, Skype was one of the most insecure choices they could have made.

As shown in this image, Skype is a Microsoft product.

By using Skype, the Geost group engaged in group chats without any guarantees regarding the OPSEC practices of their participants. As a result, some chat logs were uploaded to the internet, likely by one of the group members (though it's unclear whether it was intentional), and made accessible on a public webpage. The key issue here is that this incident demonstrates that using Skype in an uncontrolled environment can lead to private conversations being exposed.

These chat logs, which contained more than eight months of conversations among 29 different participants, provided researchers with substantial material for OSINT analysis. Through this process, they were able to identify the owner of the chat archive. In addition, they uncovered discussions that included links to the Geost control panel, enabling them to determine who was directly involved in its operation.

As the researchers explained:

"The fact that they shared information from inside the C&C channels, information that requires authenticated access to view (such as the stats.php file), and the fact that they discussed the need to fix related issues, constitutes strong evidence that they possessed internal knowledge and fully understood its purpose. The chat logs contained numerous indications of direct involvement in malware operations, including requests to re-encrypt links after Kaspersky detected them."

The use of Skype, an insufficiently secure communication platform for such activities, led to yet another OPSEC failure. In some instances, members of the Geost group used their real names in messages and shared sensitive information, including credentials, wallet IDs, and even credit card numbers. With this information, researchers were able to trace them to an online forum where they were advertising their services.

This represents a critical OPSEC error. The group members failed to fully separate their criminal identities from their real-world identities, allowing clear connections to be established between the two. For example, reusing the same wallet ID across different contexts created a direct link that significantly increased their exposure.

This principle is a fundamental aspect of OPSEC. When engaging in sensitive activities, you must ensure that they cannot be linked to your real identity, as that is the only identity the legal system can act upon. Governments cannot imprison an online persona, but they can imprison the individual behind it, often with relatively little effort once a connection has been established.

Using the same protection service multiple times

The final OPSEC mistake made by the Geost botmasters involved repeatedly relying on the same protection service. At first glance, this may seem reasonable, if you trust a service, why not use it consistently? However, this approach carries a significant risk.

If an investigator or adversary manages to compromise or monitor that service, and you depend on it across multiple aspects of your operation, they can replicate their monitoring efforts each time it is used. This creates a single point of failure, substantially increasing your overall exposure.

It is comparable to building an organization in which the same individual is placed in charge of every department: marketing, support, IT, and sales. As long as this person remains trustworthy, everything appears to function smoothly. However, if a competitor approaches them one day and offers a substantial sum in exchange for confidential information, the consequences could be catastrophic. Because all responsibilities were concentrated in a single individual, every secret within the organization would suddenly be exposed.

What could have been done better ?

Now that we have examined the mistakes made by the Geost group and their consequences, let us consider what could be done to avoid such issues.

Running their own proxy

First and foremost, selecting a secure and properly managed proxy infrastructure is essential. In practice, there are only two viable approaches.

The first option is to rely on a proxy service provided by a third party AND to ensure it is being used anonymously like how we did in this other tutorial. The main advantage of this approach is convenience: it reduces the workload associated with maintaining the infrastructure and generally ensures stable performance. However, the drawbacks are significant. You must place trust in an external organization that may cooperate with authorities, and you have no way of knowing whether the provider is already under surveillance.

The second option is to operate your own proxy infrastructure by anonymously renting VPSes and running the proxies on them. The primary advantage is full control: you manage its configuration, security measures, and overall operation in alignment with your OPSEC requirements. Another important advantage of operating your own proxy infrastructure is that it allows you to monitor it directly. By maintaining full control, you may be better positioned to detect unusual activity or signs that someone is attempting to monitor or compromise the system.

In my view, operating your own proxy infrastructure is generally the preferable option for several reasons. First, it provides complete visibility into how the system functions and how it is administered. While building and maintaining such infrastructure requires time and effort, any investment in OPSEC-related measures is worthwhile, as it is ultimately intended to protect you and your activities. If the process demands skills you do not yet possess, it can also serve as an opportunity to develop new competencies, which is always beneficial in the long term.

Secondly, running your own proxy helps ensure that all your security measures function cohesively, reducing the risk that one misconfiguration undermines another. For example, if your objective is to block requests originating from a specific location, but your proxy is not configured correctly to enforce this rule, you may unknowingly expose yourself to unnecessary risk. Direct control significantly reduces the likelihood of such oversights.

Using encrypted chat service

As we have seen, the Geost botmasters relied on Skype for their communications, a decision that created multiple vulnerabilities and ultimately contributed to their identification. Using a properly secured and encrypted messaging system could have significantly reduced that risk. However, the number of truly reliable options is limited.

Many messaging platforms promote themselves on the basis of encryption and anonymity. Telegram and Signal, for example, are widely known for these claims. But are they suitable for highly sensitive activities? The answer is more nuanced than it may appear. While such platforms implement encryption, they remain centralized services that can be compelled to comply with legal requests within their jurisdictions. When you rely on a third-party service to manage encryption infrastructure, you inherently depend on its policies, technical design, and legal environment. Furthermore, as private companies, they are subject to financial and regulatory pressures, which can influence how they respond to government demands.**

This again highlights a core OPSEC principle: whenever a third party controls critical elements of your security, especially encryption keys or metadata, you are ultimately placing a degree of trust in that entity.

Fortunately, there are solutions designed to provide secure and encrypted communications without relying on a centralized third party. One such option is SimpleX. Several detailed blog posts and guides are available like this one that explain how to configure SimpleX properly to maximize its security and privacy features.

Using a good password manager

There is another important point worth mentioning. Although it did not directly determine the outcome for the Geost botmasters, it could have reduced their exposure while using Skype. As we have seen, they shared credentials through their messaging platform, which is extremely poor security practice. However, even if they had used a more secure solution such as SimpleX, this would still not have been an appropriate method.

When it comes to credentials, it is essential to use a dedicated password manager for secure storage and controlled sharing. Sensitive authentication data should never be exchanged casually through chat platforms, regardless of the level of encryption those platforms claim to provide.

An excellent solution for managing credentials is KeePass. It enables you to store and organize your passwords securely in a controlled environment. I strongly encourage you to consult the following blog post, which explains how to configure and use it properly to maximize its security benefits.

Securing the infrastructure at different levels

This is a key concept in OPSEC: securing infrastructure at multiple levels. To illustrate this, let's use the example of a medieval castle and its defense strategies. First, imagine a castle that relies entirely on a single defense, its front gate. The gate is incredibly strong and fortified, and the entire security system is based on this one point of defense. Now, what would happen in the event of an assault?

In such a scenario, while the defending knights concentrate their efforts on protecting the main gate against a small attacking force, they could be surrounded by other enemies scaling the walls or entering through a rear gate. In other words, even if the front gate is strong and well defended, the threat can emerge from other, less protected points.

Now, let us consider what would happen if the castle were protected at multiple levels.

In this case, a multi-layered defense would be significantly stronger. Traps and archers positioned along the perimeter would greatly reduce the number of attackers and provide early warning of the enemy's strategy. This would allow the knights within the castle to organize their response more effectively, greatly increasing their chances of repelling the assault.

More importantly, each layer relies on different defensive measures. This means that attackers must adapt to a variety of obstacles rather than applying the same strategy at every stage. Such diversity in defenses significantly increases the complexity and cost of a successful attack.

The same principle applies to securing infrastructure. It must be protected at every level, with varied and complementary security measures. The goal is not only to strengthen your overall OPSEC posture, but also to increase the time, effort, and resources required for an attacker to succeed. By doing so, you gain valuable time to detect suspicious activity, receive alerts, and adapt your defenses accordingly. In many cases, the added complexity alone can discourage adversaries from pursuing the attack further.

Conclusion

As we have seen, the Geost botmasters made numerous mistakes that ultimately led to their downfall. Many of these errors could have been avoided with a more disciplined and rigorous approach to OPSEC. The key lesson is that, regardless of the nature of the sensitive activities involved, OPSEC must be treated as a priority. Before engaging in any action that could expose you to risk, you must ensure that your security measures are thoroughly planned, properly implemented, and consistently maintained.

Resources such as the OPSEC Bible provide detailed guidance and tutorials that can help prevent the types of mistakes discussed here. As emphasized in previous articles, OPSEC is an all-or-nothing discipline: a single oversight or moment of carelessness can compromise an entire operation.

Suggest changes

Crabmeat

2026-02-12

Donate XMR to the author:
89aWkJ8yabjWTDYcHYhS3ZCrNZiwurptzRZsEpuBLFpJgUfAK2aj74CPDSNZDRnRqeKNGTgrsi9LwGJiaQBQP4Yg5YtJw2U