Out of the Box and Already Compromised: The Keenadu Android Supply-Chain Backdoor

Aegiron 9 mins0

Overview

In early 2026, security researchers identified a pre-installed Android backdoor embedded directly into the system firmware of several low-cost Android tablet models. The malware has been internally tracked under the name Keenadu.

Unlike typical Android malware that is delivered as a malicious app, Keenadu is embedded inside a core Android runtime library (libandroid_runtime.so). Because this library is loaded early during the Android boot process and is part of the system partition, the malware is active immediately after first boot and cannot be removed by factory reset.

This represents a supply-chain compromise affecting devices before they ever reach end users.

What Is Keenadu

Keenadu is a native Android backdoor implanted at the firmware level. Its placement inside the Android runtime allows it to:

  • Execute with system-level privileges
  • Hook core Android APIs used by nearly all apps
  • Operate without user interaction or visible UI
  • Survive device resets and standard user remediation steps

Because it is not an APK and does not rely on Android’s permission model, it bypasses many mobile security controls and traditional antivirus detection.

Technical Placement and Architecture

Affected Component

  • File name: libandroid_runtime.so
  • Location:
    • /system/lib/libandroid_runtime.so (32-bit devices)
    • /system/lib64/libandroid_runtime.so (64-bit devices)

This shared object is part of Android’s core runtime layer, acting as a bridge between the Android framework (Java/Kotlin layer) and native system services.

Why This Is Critical

libandroid_runtime.so is loaded by:

  • zygote
  • system_server
  • Core framework processes

Any malicious code inside this library gains:

  • Early execution during boot
  • Visibility into nearly all app activity
  • The ability to intercept system calls and framework APIs

How Keenadu Works

1. Boot-Time Execution

When the device boots:

  • Android loads libandroid_runtime.so
  • Malicious hooks inside the library are initialized
  • Backdoor logic registers itself silently

This occurs before any user apps run.

2. API Hooking

The malware modifies or intercepts runtime functions to monitor and extract data such as:

  • Device identifiers (IMEI, IMSI, Android ID, serial number)
  • Installed applications list
  • Contacts and call logs
  • SMS metadata (and potentially content)
  • Notifications
  • Files accessed by other apps
  • Clipboard contents
  • Network requests

Because this happens at the runtime level, apps do not need to be malicious themselves.

3. Persistence

The malware resides in the system partition:

  • Factory reset does not remove it
  • User data wipes do not affect it
  • Only a verified firmware reflash or hardware replacement removes it

4. Command-and-Control Communication

Observed behavior indicates:

  • Automatic outbound connections shortly after first boot
  • Known patterns consistent with beaconing behavior
  • Encrypted or obfuscated network traffic
  • Periodic data exfiltration

The exact C2 infrastructure has not been publicly disclosed at the time of discovery.

Impacted Devices

Device Category

  • Low-cost / budget Android tablets
  • Devices shipped with modified Android builds
  • Often sold through:
    • Secondary manufacturers
    • White-label OEMs
    • Resellers bundling custom firmware

Android Version

  • Appears across modern Android builds shipping in 2026
  • Not tied to a single Android version but to specific firmware images

Impacted Industries and Use Cases

High-Risk Sectors

  • Education
    • Student tablets
    • Classroom device programs
  • Retail and Hospitality
    • Point-of-sale tablets
    • Kiosks and guest devices
  • Small and Medium Businesses
    • Cost-driven bulk purchases
  • Healthcare and NGOs
    • Field data collection devices
  • Logistics and Field Operations
    • Inventory and reporting tablets

Why These Are High Risk

  • Devices often handle credentials, internal apps, or sensitive data
  • Network segmentation is frequently weak
  • Firmware integrity is rarely verified during procurement

Data at Risk

Potentially exposed information includes:

  • Corporate email credentials
  • VPN tokens and session data
  • Customer or student personal information
  • Authentication tokens stored by apps
  • Files stored locally or cached by applications
  • Internal network metadata

Because the malware operates below the app layer, any app on the device is potentially exposed, even if it is otherwise secure.

Indicators of Compromise (IOCs)

File-Based Indicators

  • Modified or non-standard checksum for:
    • /system/lib/libandroid_runtime.so
    • /system/lib64/libandroid_runtime.so
  • File timestamps inconsistent with official firmware build dates
  • Binary differences compared to OEM or AOSP reference images

Behavioral Indicators

  • Network connections initiated immediately after first boot
  • Periodic outbound traffic without user activity
  • System processes opening network sockets unexpectedly
  • Runtime behavior inconsistent with stock Android builds

Device-Level Indicators

  • Unexplained battery drain
  • Network activity during idle state
  • Unexpected system calls visible during dynamic analysis

Detection Guidance

Firmware Integrity Validation

  • Extract system image
  • Compute cryptographic hashes
  • Compare against vendor-provided or AOSP reference images
  • Any mismatch should be treated as a compromise

Network Monitoring

  • Monitor newly provisioned tablets for:
    • External connections
    • Unusual domains or IP ranges
    • Encrypted traffic with no clear application source

Mobile Device Management (MDM)

  • Flag devices with modified system partitions
  • Enforce restricted network access for new devices
  • Block unknown outbound destinations by default

Mitigation and Response

Immediate Actions

  • Isolate affected devices from production networks
  • Do not rely on factory reset as remediation
  • Do not enroll suspected devices into corporate MDM

Remediation Options

  1. Verified Firmware Reflash
    • Only if OEM provides a clean, signed image
  2. Device Replacement
    • Recommended if firmware integrity cannot be proven
  3. Procurement Freeze
    • Suspend purchases from affected suppliers

Long-Term Controls

  • Require firmware integrity attestations from vendors
  • Validate system libraries during device onboarding
  • Use network segmentation for mobile endpoints
  • Avoid white-label or unverifiable OEM firmware

Final Takeaway

This incident reinforces a critical reality:
Mobile supply-chain threats are no longer theoretical.

Pre-installed malware:

  • Scales instantly
  • Evades user-level defenses
  • Undermines trust in endpoint security
  • Turns legitimate devices into long-term surveillance platforms

For organizations relying on Android tablets, firmware integrity must now be treated as a core security requirement, not an optional hardening step.

Aegiron

Backed by 11+ years in cybersecurity and incident response, we decode the latest threats shaping today’s digital battlefield. This blog cuts through the noise with clear insights on vulnerabilities, emerging exploits, and the cyber news defenders can’t afford to miss.