A newly documented Android backdoor dubbed Keenadu demonstrates how dangerous preinstalled malware and supply chain attacks have become for the mobile ecosystem. According to researchers at Kaspersky, Keenadu is distributed through factory firmware images, system applications, and even official app stores such as Google Play, meaning users can purchase a brand‑new device that is already compromised before first boot.
Scale of the Keenadu Android Infection and Affected Regions
As of February 2026, Kaspersky’s telemetry recorded more than 13,000 Android devices infected with the Keenadu backdoor. The highest concentration of affected devices is observed in Russia, Japan, Germany, Brazil, and the Netherlands. For a modular infrastructure‑level backdoor, this figure is significant but likely not the upper limit, suggesting that the campaign is still active and potentially expanding.
How Keenadu Uses a Supply Chain Attack on Android Firmware
The defining trait of Keenadu is its use of a supply chain attack—compromising software during development or distribution rather than on individual devices after purchase. Researchers reconstructed the infection chain using the tablet Alldocube iPlay 50 mini Pro (T811M) as an example.
In this case, a malicious static library called libVndxUtils.a was added directly into the firmware’s source code repository and linked to the core system library libandroid_runtime.so. As a result, the crucial Zygote process—responsible for spawning every Android app process—became infected. Because all applications are forked from Zygote, the backdoor’s code is injected into the address space of every running app, effectively undermining Android’s application isolation model.
Importantly, the compromised firmware images were properly signed by the manufacturer. Subsequent over‑the‑air updates for affected models also carried the Keenadu implant, including versions released after public disclosure of the issue. This is a classic sign of a deeply compromised supply chain, where the vendor’s build pipeline or third‑party components are tainted—sometimes without the OEM’s knowledge.
Beyond Firmware: System Apps and Official App Stores
Keenadu is not limited to Alldocube devices and is associated with a broader campaign targeting multiple Android OEMs. In some cases, the backdoor is integrated not into libandroid_runtime.so, but into separate system applications. The malware has also been identified in applications distributed via alternative app catalogs, Google Play, and Xiaomi GetApps, indicating a multi‑vector distribution strategy.
Another notable feature is that Keenadu does not activate when the device’s interface language or time zone suggests use in mainland China. Such geo‑ and language‑based filters are a recurring pattern in financially motivated threat campaigns seeking to avoid scrutiny from local regulators and law enforcement.
Technical Architecture: AKServer, AKClient, and Full Device Control
Keenadu implements a client–server architecture inside the Android operating system. The server‑side component, AKServer, runs within the highly privileged system_server process, while the client module, AKClient, is injected into all other apps via the compromised Zygote process. This design provides the operators with near‑total control over the device.
Documented capabilities of Keenadu include:
— Granting or revoking permissions for any application;
— Collecting detailed device information (IMEI, MAC address, model, OS version);
— Accessing location data and other sensitive information;
— Managing the installation, update, and execution of APK files.
Newer Android versions use install sessions and stricter permission models to limit abuse by third‑party apps. Code analysis indicates that Keenadu is explicitly engineered to bypass these protections, including mechanisms around dangerous permissions and the Accessibility (special access) APIs frequently exploited in fraud and account‑takeover schemes.
Monetization: Ad Fraud, Traffic Hijacking, and Biometric Risk
The primary monetization vector for Keenadu appears to be advertising fraud. The backdoor can silently interact with ad components, simulate clicks and app installs, and generate fake but seemingly legitimate ad traffic, inflating revenue streams for the operators at the expense of advertisers and ad networks.
A dedicated module targeting the Chrome browser intercepts user search queries—including those made in incognito mode—and can replace the configured search engine. This enables traffic redirection, phishing, and additional fraudulent monetization through affiliate or low‑quality search providers.
Another loader is specifically tuned for apps such as Amazon, SHEIN, and Temu. User complaints indicate that it can add products to shopping carts without the owner’s knowledge, enabling covert purchases or manipulation of engagement metrics on e‑commerce platforms.
Particularly concerning is the discovery of Keenadu within a system facial recognition application. In such a scenario, attackers might gain access to users’ biometric templates. Unlike passwords, biometric data cannot be changed, which makes its theft vastly more damaging in the long term.
Links Between Keenadu, Triada, BADBOX, and Vo1d
Code analysis reveals connections between Keenadu and other high‑profile Android botnets, including Triada, BADBOX, and Vo1d. There are documented instances where the BADBOX platform downloaded one of Keenadu’s modules, and side‑by‑side code comparison shows noticeable overlaps, even though each family maintains distinct architecture and infrastructure.
This suggests that Keenadu’s authors may have borrowed concepts and code fragments from BADBOX and related projects, gradually building their own versatile platform for large‑scale Android compromise. Similar code reuse across malware families has been observed in earlier Android supply chain cases, reinforcing the view that an interconnected ecosystem of developers underpins such threats.
User Impact, Google Play Infections, and Removal Challenges
Keenadu’s reach extends into the official Google Play store. Researchers identified several infected “smart camera” applications with a combined download count exceeding 300,000 installs. While these apps have reportedly been removed, their presence highlights the difficulty of detecting sophisticated supply chain malware during standard application vetting.
Manufacturers and platforms affected by Keenadu have been notified, but fully remediating such incidents is complex and time‑consuming. It often requires reviewing build pipelines, auditing third‑party libraries, and strengthening firmware signing and validation processes.
For end users, removing Keenadu with standard Android tools is virtually impossible. On modern devices, the system partition that contains libandroid_runtime.so is mounted read‑only, preventing conventional uninstallation. Realistic options are limited to installing a known‑clean official firmware image—if one exists—or manually reflashing the device with a trusted ROM. Until a clean firmware is applied, experts recommend avoiding sensitive activities such as online banking, payments, and handling of corporate accounts on suspected devices.
Keenadu underscores that preinstalled Android malware and supply chain attacks remain among the most serious threats to mobile security. Users should favor reputable device vendors, keep firmware up to date, use well‑maintained mobile security solutions, and treat sudden app installations, intrusive advertising, or unexplained account activity as red flags requiring a full security check. For manufacturers and ecosystem providers, the incident is a clear signal to harden the software supply chain—by auditing external code, enforcing strict verification before firmware signing, and continuously monitoring for anomalous behavior in shipped devices—to prevent future backdoors from being delivered straight out of the box.
