• In late October 2024, the Cleafy TIR team discovered and analysed a new Android Remote Access Trojan (RAT). Upon investigation, traces of this threat were found dating back to June 2024. However, as of this writing, no connections to any known malware families have been identified. Consequently, the team has classified this new threat under the name DroidBot, based on a domain name leveraged by this malware.
• DroidBot is a modern RAT that combines hidden VNC and overlay attack techniques with spyware-like capabilities, such as keylogging and user interface monitoring. Moreover, it leverages dual-channel communication, transmitting outbound data through MQTT and receiving inbound commands via HTTPS, providing enhanced operation flexibility and resilience.
• At the time of writing, DroidBot targets 77 distinct entities, including banking institutions, cryptocurrency exchanges, and national organisations. Active campaigns have been observed in countries such as the United Kingdom, Italy, France, Spain, and Portugal, indicating a potential expansion into Latin America.
  Inconsistencies observed across multiple samples indicate that this malware is still under active development. These inconsistencies include placeholder functions, such as root checks, different levels of obfuscation, and multi-stage unpacking. Such variations suggest ongoing efforts to enhance the malware’s effectiveness and tailor it to specific environments.
• The information retrieved within malware samples (e.g., debug strings, configuration files, etc.) makes us assume that most of its developers are Turkish speakers. This observation reflects, at least partially, the efforts to adapt tactics for broader geographical impact.

DroidBot is an advanced Android Remote Access Trojan (RAT) that combines classic hidden VNC and overlay capabilities with features often associated with spyware. It includes a keylogger and monitoring routines that enable the interception of user interactions, making it a powerful tool for surveillance and credential theft. A distinctive characteristic of DroidBot is its dual-channel communication mechanism: outbound data from infected devices is transmitted using the MQTT protocol, while inbound commands, such as overlay target specifications, are received over HTTPS. This separation enhances its operational flexibility and resilience.
At the time of analysis, 77 distinct targets have been identified, including banking institutions, cryptocurrency exchanges, and national organisations, underscoring its potential for widespread impact. Notably, the threat actor behind DroidBot has been linked to Turkey, reflecting a broader trend of adapting tactics and geographical focus.

Analysis of DroidBot samples has also revealed its Malware-as-a-Service (MaaS) infrastructure, with 17 distinct affiliate groups identified, each assigned unique identifiers. Interestingly, multiple affiliates were found to be communicating over the same MQTT server, suggesting that some groups may collaborate or participate in demonstration sessions showcasing the malware’s capabilities.

Moreover, DroidBot appears to be under active development. Some functions, such as root checks, exist as placeholders and are not yet properly implemented, while other features vary between samples (e.g., obfuscation, emulator checks, multi-stage unpacking). These inconsistencies suggest ongoing refinement to enhance functionality or adapt to specific environments. Despite these developmental signs, the malware has already demonstrated its potential, successfully targeting users in the United Kingdom, Italy, France, Spain, and Portugal, with indications of expansion into linguistically similar Latin American regions.
The combination of advanced surveillance features, dual-channel communication, a diverse target list, and an active MaaS infrastructure highlights DroidBot’s sophistication and adaptability. As it evolves, this malware poses an escalating threat to financial institutions, government entities, and other high-value targets across multiple regions.

The following table represents a summary of the TTP behind DroidBot campaigns:

Malicious App Overview

To lure victims into downloading and installing DroidBot, the TAs leverage common decoys frequently observed in banking malware distribution campaigns. In this case, the malware is disguised as generic security applications, Google services, or popular banking apps.

Like most modern Android banking malware, DroidBot relies heavily on abusing Accessibility Services to carry out its malicious functions. These services are typically requested during the initial stages of installation, as shown in the Figure above. DroidBot appears to have been developed using the B4A framework, a popular framework for native Android applications. It’s important to note that B4A  is widely used in malware developed by Brazilian TAs, such as the Brata family and its known variant CopyBara.

DroidBot offers a range of functionalities commonly found in modern Android banking malware, including:

• SMS Interception: The malware monitors incoming SMS messages, often used by financial institutions to deliver transaction authentication numbers (TANs), allowing attackers to bypass two-factor authentication mechanisms.
• Key-Logging: By exploiting Accessibility Services, DroidBot captures sensitive information displayed on the screen or entered by the user, such as login credentials, personal data, or account balances.
• Overlay Attack: This approach involves displaying a fake login page over the legitimate banking application once the victim opens it to intercept valid credentials.
• VNC-Like Routine: DroidBot periodically takes screenshots of the victim’s device, providing threat actors with continuous visual data that offers a real-time overview of the device's activity.
• Screen Interaction: Leveraging the full potential of Accessibility Services, DroidBot enables remote control of the infected device. This includes executing commands to simulate user interactions such as tapping buttons, filling out forms, and navigating through applications, effectively allowing attackers to operate the device as if they were physically present.

This report will not provide an in-depth analysis of these functionalities, as they are standard features across most modern banking trojans. Moreover, our analysis did not reveal any noteworthy innovations in their implementation. Instead, the following sections will focus on some unique and intriguing aspects uncovered during our investigation.

Exploring C2 Communication

The DroidBot banking trojan employs an unconventional Command-and-Control (C2) communication method, leveraging the MQTT (Message Queuing Telemetry Transport) protocol. This lightweight and efficient protocol, traditionally used in IoT and real-time messaging systems, enables DroidBot to achieve seamless data exfiltration from infected devices.

The choice of MQTT is particularly noteworthy because its use among Android malware remains relatively rare. The TA strategic decision facilitates efficient communication and enhances the malware's ability to evade detection. By adopting a protocol not commonly associated with malicious activities, the operators behind DroidBot can stay under the radar of conventional security measures.

DroidBot’s utilisation of MQTT reflects a growing trend in the malware landscape. Recent examples of Android banking trojans adopting this protocol include Copybara and BRATA/AmexTroll. Originally active in Latin America, these families have recently expanded their operations to Europe, demonstrating such techniques' increasing versatility and geographical spread.

DroidBot dynamically retrieves the MQTT broker's address from a remote resource to ensure resilience and mitigate takedowns. Specifically, the malware utilises a hardcoded domain within its source code to request an HTTP to a designated endpoint. This endpoint, /GETM5662, returns the broker's address.

In earlier versions of DroidBot, this address was delivered in plain text, as shown in the previous image. However, the TAs have recently adapted their techniques to enhance resilience and stealth. In the latest samples, the response containing the broker's address is first encrypted and then encoded in Base64 before being delivered to the malware. Once received, the malware decodes and decrypts the address, which is used to establish a connection to the MQTT broker.

The MQTT broker used by DroidBot is organised into specific topics that categorise the types of communication exchanged between the infected devices and the C2 infrastructure. These topics function as logical channels, each dedicated to a specific type of data or instruction, ensuring a structured and efficient flow of information. For readers unfamiliar with the MQTT protocol, topics are hierarchical strings that organise and route messages between publishers (senders) and subscribers (receivers). A topic acts as an "address" within the broker, determining where a message should be delivered. In the following image, you can see a snippet from DroidBot’s decompiled code, which reveals some of the hardcoded topics utilised by the malware.

By compartmentalising communications in this way, the malware simplifies data handling and ensures a degree of modularity, potentially making it easier to adapt or expand its capabilities in future updates. In fact, during our analysis, we also identified several topics that do not appear to be actively used by the malware at this time. These include applicationlog, pinsave, and injectionlog.

These unused topics suggest that the TAs may have planned additional functionalities or reserved these channels for future updates. This further highlights the evolving nature of DroidBot and its potential for expanded malicious capabilities over time.

To secure its communications with the MQTT broker, DroidBot employs an encryption routine that obfuscates the transmitted data, making it challenging to intercept or analyse without reverse engineering. The process for constructing the communication flow is outlined in the following Figure:

In details:

• Serialisation: The clear-text message is first serialised into a byte array using UTF-8 encoding.
• Encryption via XOR: The serialised byte array is passed through an XOR-based encryption routine. As shown in the code snippet, the encryption key is derived using a predefined pattern (PO0000000000000000000L), which is dynamically resized to match the length of the message. Each byte of the message is XORed with the corresponding byte of the repeated pattern, resulting in an encrypted array.
• Compression (zlib): The encrypted byte array is further compressed using the zlib compression algorithm.
• Transmission via MQTT: The resulting message is then published to the broker via MQTT.

Below is a simplified version of the decryptor code:

Exploring C2 Communication

DroidBot introduces a custom decryption routine to decrypt embedded strings that contain information about the C2 server and credentials for successfully connecting to the MQTT broker. The decryption routine is pretty straightforward. However, it relies on four parameters that depend on the package name, the version and name, and an integer.

This reflects an effort to make string decryption less straightforward. However, once a collection of samples has been gathered, an application parser will still be needed to extract all relevant information.

Analysing the sample, a keyword that captured our attention was injection. It was possible to read through the developers' posts on underground forums that DroidBot was equipped with an ATS (Automatic Transfer System) module that allows the app to perform a completely automated fraud against a target. However, exploring the MQTT messages and collecting injection information made it impossible to observe a proper ATS engine. We can’t exclude that that information is stored on the server and could be sent over “candidate” bots.

Target Countries

Investigating the TAs' infrastructure also enabled us to obtain the list of financial institutions targeted by these campaigns. Analysing the nationality of the users of these institutions reveals a particular in the European area with a focus on four nations: France, Italy, Spain, and Turkey.

The same results also emerge from analysing a file in the malware called security.html, which contains a security page warning users that “The application cannot be uninstalled for security reasons”. Within the code, we can see that this information is customised for 4 main languages: English, Italian, Spanish, and Turkish.

Further investigation of the MQTT client revealed a significant number of infected French users, confirming France as one of the campaign's targets.

Malware-as-a-Service (MaaS) is a business model in the cybercrime world where malware authors offer their malicious software and services to other cybercriminals. This model operates similarly to legitimate Software-as-a-Service (SaaS) platforms, where customers can subscribe to a service and access software without developing or maintaining it themselves. The malware's creators develop and maintain the malicious software while providing it to "affiliates" or "botnet operators" who pay for access.

By examining DroidBot Command-and-Control (C2) infrastructures and malware configurations, evidence emerged suggesting the existence of a private MaaS network. This network operates with a sophisticated structure, enabling "affiliates" or "botnet operators" to access DroidBot and its advanced capabilities.

Affiliates, Forums, and Offerings

Our analysts successfully retrieved the initial post from a prominent Russian-speaking hacking forum, where the purported authors introduced their MaaS offering. This post, dated October 12, 2024, provides critical insights employed by the creators of DroidBot.

According to this post, we can extract the following information:

• “Allegedly” experienced malware developer: the user claims to have written the bot from scratch, signalling advanced malware development skills and experience in the field. However, the forum account used to create this post has no reputation or history within the forum, and its registration dates back only a few months. This discrepancy could raise questions about the claimed expertise and experience.
• Comprehensive MaaS Offering: The service package includes a crypter (used to obfuscate malware) and server access, indicating the infrastructure to support affiliates in evading detection and running operations smoothly.
• Powerful Android features, including hVNC, allow remote control of infected devices while keeping them hidden from the victim. ATS (Automated Transfer System) is also included, but we found nothing related to the ATS routine or similar approaches during our investigation.
• No restrictions against CIS countries, which could suggest that the authors do not originate from the CIS region.

In the same forum post, the author included details of a Telegram channel for those interested in joining the group as affiliates. This channel provides additional information about DroidBot's features and the monthly subscription price of $3000. The Threat Actors frequently share screenshots of specific details within the Command-and-Control (C2) panel, offering potential affiliates a glimpse of its capabilities.

Sharing screenshots with affiliates or potential members is common, especially within private groups. However, there is always a risk of unintentionally revealing sensitive information. In one particular instance, a shared screenshot inadvertently included the date, time, and weather information, which can be crucial in tracing the operators' origins.

The operating system language was set to Turkish, and the weather details matched conditions in certain regions of Turkey on that specific day, such as the capital city of Ankara.

Another compelling insight gathered from the Telegram channel, which further links the group to Turkey, is the publication of a specific link on November 22, 2024. The link's message simply stated, "Problem with server," as shown in the screenshot below.

The link directs to an alert issued by TR-CERT Usom (https://www.usom.gov.tr/), the Computer Emergency Response Team of the Republic of Türkiye. In this alert, as seen in the screenshot, one of the primary domains used by the group (dr0id[.]best) has been flagged as malicious and identified as a potential threat to the financial sector.

The domain dr0id[.]best presented some interesting data when we analyzed the associated infrastructure and its DNS-related data. According to the related subdomains found and the malware configurations extracted from multiple samples, this domain seems potentially associated with a private MaaS operation (Malware-as-a-Service).

We reconstructed the following list of 17 affiliates/botnets, reported on the “IOCs Appendix”.

A closer look into one botnet

Our analysts successfully intercepted traffic from a specific botnet associated with DroidBot on an active MQTT broker, which remained operational for several days. Leveraging the MQTT protocol’s real-time nature, we could access and decrypt the live stream of botnet communications. This allowed us to extract valuable insights and statistics regarding the botnet's size and geographical distribution.

Below, we present key metrics derived from this analysis:

DroidBot C2 panel

Our analysts obtained visibility into the associated C2 web panel where TAs can manage their botnet. The following page, for example, provides the TAs with a simple interface for interacting with a specific infected device, giving the ability to:  

• Collecting valid banking credentials via injections (Overlay Attack).
• Interact with phone calls by forcing the hang-out or redirecting a specific call to a different number.
• Remote access to the device via VNC capabilities (with the support of a “blank-screen” for masquerading the malicious activities).
• Sending fake push notifications
• Retrieve data (e.g., SMS messages, data intercepted via keylogger) and more.

The C2 panel also includes a builder. A builder is a tool attackers use to generate customized malware versions automatically. It allows modification of key settings, like the command-and-control (C2) server or specific features, to create unique malware builds.

The builder is especially valuable in a MaaS operation because it allows multiple affiliates to create personalized malware builds. Affiliates can adjust configurations, adding flexibility in distribution while keeping their attacks unique. This significantly boosts the scalability and reach of the malware, as each affiliate can generate distinct versions, making detection and defense more difficult for intelligence teams.

The malware presented here may not shine from a technical standpoint, as it is quite similar to known malware families. However, what really stands out is its operational model, which closely resembles a Malware-as-a-Service (MaaS) scheme—something not commonly seen in this type of threat. If we recall significant cases such as Sharkbot, Copybara, or the more recent Toxic Panda, the infrastructure, code, and campaign planning were all handled "in-house." Droidbot, on the other hand, introduces a well-known but not widely spread paradigm in the mobile threat landscape. As mentioned earlier, while the technical difficulties are not so high, the real point of concern lies in this new model of distribution and affiliation, which would elevate the monitoring of the attack surface to a whole new level. This could be a critical point, as changing the scale of such an important data set could significantly increase the cognitive load. If not efficiently supported by a real-time monitoring system, this could severely overwhelm anti-fraud teams within financial institutions.

Appendix

IOCs

DroidBot sample:

C2 servers:

Affiliated/botnet:

Malware Target Apps

‍

Meet the authors:

Simone Mattia

Alessandro Strino

Federico Valentini