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

Keenadu is a firmware-level Android backdoor embedded into libandroid_runtime.so and some system apps during the firmware build phase, which injects into the Zygote process to load malicious modules into every app and expose a binder-based malicious system service. The platform delivers encrypted modular payloads (clickers, loaders, monetizers, spyware) via HTTP-based C2 infrastructure and shows links to other large Android botnets including BADBOX and Triada. #Keenadu #BADBOX

Keypoints

Keenadu is a pre-installed backdoor found in firmware for multiple tablet vendors (discovered in Alldocube iPlay 50 mini Pro and other devices) and was integrated during the firmware build phase via a malicious static library (libVndxUtils.a).
The malware is loaded from /system/lib[64]/libandroid_runtime.so and injects into the Android Zygote process so a copy of the backdoor runs in the address space of every app launched on the device.
Keenadu uses a client-server binder architecture (AKClient/AKServer) to provide attackers with powerful capabilities including arbitrary DEX loading, granting/revoking app permissions, geolocation retrieval, and device info exfiltration.
The backdoor retrieves encrypted C2 addresses, reports device metadata (model, IMEI, MAC, OS), and downloads signed, AES-encrypted modular payloads that perform ad fraud, install monetization, credential theft, and other actions.
Payloads observed include loaders targeting storefront apps (Amazon, SHEIN, Temu), clickers (Nova/Phantom), a Chrome module that hijacks searches and exfiltrates queries, monetization modules in launcher, and a Google Play module that harvests the advertising ID.
Keenadu components were also found embedded directly in system apps (face recognition service, launcher, ad SDKs) and distributed via modified apps on third-party stores and even Google Play, indicating multiple distribution vectors.
Telemetry shows links between Keenadu, BADBOX, Triada and Vo1d (shared code, downloader relationships and overlapping C2 infrastructure), and 13,715 users were observed encountering Keenadu or its modules worldwide.

MITRE Techniques

[T1195 ] Supply Chain Compromise – Keenadu was integrated into firmware during the build phase via a malicious static library and source-tree inclusion (‘we believe that Keenadu was integrated into Android device firmware as the result of a supply chain attack.’).
[T1055 ] Process Injection – the backdoor injects into the Zygote process so a copy is loaded into every app’s address space (‘the malware injected itself into the Zygote process’).
[T1547 ] Boot or Logon Autostart Execution – malicious calls were inserted into println_native in libandroid_runtime.so so the dropper runs in every app at startup (‘the attacker inserted a call to this function directly into the implementation of the println_native method.’).
[T1105 ] Ingress Tool Transfer – operators deliver modular payloads and APKs from attacker-controlled CDNs (Amazon/AWS and other storage) to infected devices (‘The attacker’s server delivers information about the payloads as an object array… Each object contains a download link for the payload’).
[T1071 ] Application Layer Protocol – C2 communication and data exfiltration use HTTP POST/GET to specific paths (e.g., /ak/api/pts/v4 and /ota/api/tasks/v3) to send encrypted device metadata and retrieve payload configs (‘the encrypted data is sent to the C2 server via a POST request to the path /ak/api/pts/v4.’).
[T1082 ] System Information Discovery – the backdoor collects device metadata such as model, IMEI, MAC address and OS version before reporting to C2 (‘the Trojan collects victim device metadata, such as the model, IMEI, MAC address, and OS version’).
[T1056 ] Input Capture – a Chrome module monitors the url_bar and exfiltrates search queries and intercepts search submissions (‘All search queries entered by the user into the url_bar field are exfiltrated to the attackers’ server.’).
[T1036 ] Masquerading – the malicious dependency was disguised as a legitimate vendor component (“vndx”) in the firmware source to hide its presence (‘the attacker most likely attempted to disguise the malicious libandroid_runtime.so dependency as a supposedly legitimate “vndx” component’).

Indicators of Compromise

[File hash ] Examples of malicious binaries and modules found in firmware and apps – libVndxUtils.a MD5: ca98ae7ab25ce144927a46b7fee6bd21, Keenadu loader MD5: 4c4ca7a2a25dbe15a4a39c11cfef2fb2, and other module hashes (e.g., f0184f6955479d631ea4b1ea0f38a35d) and more.
[IP address ] C2 infrastructure and resolving addresses observed in telemetry – 67.198.232.4, 67.198.232.187 (C2 resolution for keepgo123[.]com / gsonx[.]com), and additional addresses such as 110.34.191.81.
[Domain ] Command-and-control and CDN domains used by operators – keepgo123[.]com, gsonx[.]com (observed in C2 and firmware DNS queries), and other domains like zcnewy[.]com and multiple CDN/storage hosts.
[File path / library ] Infected system libraries and firmware files – /system/lib/libandroid_runtime.so and /system/lib64/libandroid_runtime.so (dropper injection point), and static library libVndxUtils.a used during build.
[Package name ] Targeted or infected Android packages and system apps used for persistence or payload injection – com.android.chrome (Chrome module), com.android.launcher3 (install monetization), com.amazon.mShop.android.shopping (loader target), and system services like com.aiworks.faceidservice.