Divide and conquer: how the new Keenadu backdoor exposed links between major Android botnets

Kaspersky experts have uncovered Keenadu, a sophisticated new backdoor targeting tablet firmware as well as system-level and Google Play apps. They also revealed connections between the world's most prolific Android botnets.

Divide and conquer: how the new Keenadu backdoor exposed links between major Android botnets

17 Feb 2026

minute read

Table of Contents

• Malicious dropper in libandroid_runtime.so

• AKClient architecture
• AKServer architecture

• How Keenadu compromised libandroid_runtime.so
• Keenadu backdoor modules

• Keenadu loader
• Clicker loader
• Google Chrome module
• The Nova (Phantom) clicker
• Install monetization
• Google Play module

• Other Keenadu distribution vectors

• System apps
• Loading via other backdoors
• Modifications of popular apps
• Google Play

• The Fantastic Four: how Triada, BADBOX, Vo1d, and Keenadu are connected
• Victims
• Recommendations

• If the libandroid_runtime.so library is infected
• If one of the system apps is infected
• If an infected app has been installed on the device

• Conclusion
• Indicators of compromise

In April 2025, we reported on a then-new iteration of the Triada backdoor that had compromised the firmware of counterfeit Android devices sold across major marketplaces. The malware was deployed to the system partitions and hooked into Zygote – the parent process for all Android apps – to infect any app on the device. This allowed the Trojan to exfiltrate credentials from messaging apps and social media platforms, among other things.

This discovery prompted us to dive deeper, looking for other Android firmware-level threats. Our investigation uncovered a new backdoor, dubbed Keenadu, which mirrored Triada’s behavior by embedding itself into the firmware to compromise every app launched on the device. Keenadu proved to have a significant footprint; following its initial detection, we saw a surge in support requests from our users seeking further information about the threat. This report aims to address most of the questions and provide details on this new threat.

Our findings can be summarized as follows:

• We discovered a new backdoor, which we dubbed Keenadu, in the firmware of devices belonging to several brands. The infection occurred during the firmware build phase, where a malicious static library was linked with libandroid_runtime.so. Once active on the device, the malware injected itself into the Zygote process, similarly to Triada. In several instances, the compromised firmware was delivered with an OTA update.

• A copy of the backdoor is loaded into the address space of every app upon launch. The malware is a multi-stage loader granting its operators the unrestricted ability to control the victim’s device remotely.

• We successfully intercepted the payloads retrieved by Keenadu. Depending on the targeted app, these modules hijack the search engine in the browser, monetize new app installs, and stealthily interact with ad elements.

• One specific payload identified during our research was also found embedded in numerous standalone apps distributed via third-party repositories, as well as official storefronts like Google Play and Xiaomi GetApps.

• In certain firmware builds, Keenadu was integrated directly into critical system utilities, including the facial recognition service, the launcher app, and others.

• Our investigation established a link between some of the most prolific Android botnets: Triada, BADBOX, Vo1d, and Keenadu.

The complete Keenadu infection chain looks like this:

[Full infection diagram]

Full infection diagram

Kaspersky solutions detect the threats described below with the following verdicts:

HEUR:Backdoor.AndroidOS.Keenadu.*

HEUR:Trojan-Downloader.AndroidOS.Keenadu.*

HEUR:Trojan-Clicker.AndroidOS.Keenadu.*

HEUR:Trojan-Spy.AndroidOS.Keenadu.*

HEUR:Trojan.AndroidOS.Keenadu.*

HEUR:Trojan-Dropper.AndroidOS.Gegu.*

Malicious dropper in libandroid_runtime.so

At the very beginning of the investigation, our attention was drawn to suspicious libraries located at /system/lib/libandroid_runtime.so and /system/lib64/libandroid_runtime.so – we will use the shorthand /system/lib[64]/ to denote these two directories. The library exists in the original Android source. Specifically, it defines the println_native native method for the android.util.Log class. Apps utilize this method to write to the logcat system log. In the suspicious libraries, the implementation of println_native differed from the legitimate version by the call of a single function:

[Call to the suspicious function]

Call to the suspicious function

The suspicious function decrypted data from the library body using RC4 and wrote it to /data/dalvik-cache/arm[64]/system@framework@vndx_10x.jar@classes.jar. The data represents a payload that is loaded via DexClassLoader. The entry point within it is the main method of the com.ak.test.Main class, where “ak” likely refers to the author’s internal name for the malware; this letter combination is also used in other locations throughout the code. In particular, the developers left behind a significant amount of code that writes error messages to the logcat log during the malware’s execution. These messages have the AK_CPP tag.

Payload decryption

The payload checks whether it is running within system apps belonging either to Google services or to Sprint or T-Mobile carriers. The latter apps are typically found in specialized device versions that carriers sell at a discount, provided the buyer signs a service contract. The malware aborts its execution if it finds that it’s running within these processes. It also implements a kill switch that terminates its execution if it finds files with specific names in system directories.

Next, the Trojan checks if it is running within the system_server process. This process controls the entire system and possesses maximum privileges; it is launched by the Zygote process when it starts. If the check returns positive, the Trojan creates an instance of the AKServer class; if the code is running in any other process, it creates an instance of the AKClient class instead. It then calls the new object’s virtual method, passing the app process name to it. The class names suggest that the Trojan is built upon a client-server architecture.

[Launching system_server in Zygote]

Launching system_server in Zygote

The system_server process creates and launches various system services with the help of the SystemServiceManager class. These services are based on a client-server architecture, and clients for them are requested within app code by calling the Context.getSystemService method. Communication with the server-side component uses the Android inter-process communication (IPC) primitive, binder. This approach offers numerous security and other benefits. These include, among other things, the ability to restrict certain apps from accessing various system services and their functionality, as well as the presence of abstractions that simplify the use of this access for developers while simultaneously protecting the system from potential vulnerabilities in apps.

The authors of Keenadu designed it in a similar fashion. The core logic is located in the AKServer class, which operates within the system_server process. AKServer essentially represents a malicious system service, while AKClient acts as the interface for accessing AKServer via binder. For convenience, we provide a diagram of the backdoor’s architecture below:

[Keenadu backdoor execution flow]

Keenadu backdoor execution flow

[...]

Original source