In Android security, privilege escalation extends far beyond conventional exploit techniques. A significant yet often overlooked threat comes from applications that acquire excessive privileges through seemingly legitimate channels. While security teams focus on detecting malicious exploits, applications can gain dangerous levels of system access through legitimate mechanisms like sideloading and OEM (Original Equipment Manufacturer) permissions. This is yet another method employed by attackers as part of their move to a mobile-first attack strategy.
These applications frequently obtain permissions that exceed their functional requirements, creating security vulnerabilities without triggering standard detection systems. For instance, a simple utility app might request permissions for system settings modification, network access, and storage control - each legitimate in isolation, but dangerous in combination. This scenario is particularly common with sideloaded applications that bypass Google Play store security checks and applications that were pre-installed by device manufacturers with elevated privileges.
To fight this security challenge, organizations must implement comprehensive app vetting processes. These processes should systematically analyze permission requests and validate application behavior. This systematic approach helps prevent applications from accumulating excessive privileges that could compromise system security.
This issue has been extensively researched in academic literature too and with the proliferation of 3rd party stores, the sideloading practice has become even more problematic.
Our blog will revisit some examples of abuses of the Android Accessibility API that some OEM apps and sideloaded apps make use of, we will first provide an overview of such vulnerabilities and then delve into specific real-world cases.
Key Points:
1. Understanding Privilege Escalation in Android via OEM permissions
Privilege escalation through OEM permissions represents a significant security concern in Android systems. Device manufacturers often include proprietary permissions that grant applications extensive system access, bypassing Android's standard security model. These permissions, while designed for legitimate system functionality, can be misused by malicious applications.
Consider these real-world examples:
- OEM 1 platform permissions:
- <REDACTED>.permission.<REDACTED>_SECURITY allows applications to modify security policies
- <REDACTED>.permission.<REDACTED>_HW_CONTROL enables hardware-level access
- OEM 2 system permissions:
- <REDACTED>.permission.USE_INTERNAL_GENERAL_API grants access to system-level APIs
- android.permission.INTERACT_ACROSS_USERS_FULL allows cross-user data access
It is difficult to give proper attribution to the above permissions and what they are capable of as their description is vague and hides potential avenues for privilege escalation and misuse.
These permissions can be exploited when:
- A malicious app impersonates a system application
- A legitimate app is compromised and uses inherited OEM permissions
- Third-party apps request and combine multiple OEM permissions for unintended purposes
For instance, an application with OEM 1 permissions could potentially:
- Modify system security settings
- Access secure hardware features
- Override user privacy preferences
- Bypass standard Android permission restrictions
2. App Vetting: A Critical Defense Against Privilege Escalation
App vetting serves as a crucial security measure to identify applications attempting to gain excessive privileges through both legitimate and malicious means. This systematic evaluation process examines applications' permission requests, behaviors, and potential security implications before deployment in enterprise environments.
An all-around vetting solution should look at both static and dynamic permissions, which could be granted via manifest or during the execution of the app.
Manifest declaration:
Code check and request:
For example the above set of permissions is capable of
- SYSTEM_ALERT_WINDOW - Allows drawing overlays over other apps (can be used for clickjacking or to steal information including credentials)
- ACCESSIBILITY_SERVICE - Can monitor user actions and automate interactions (typically used by malware to grant the malicious app further permissions)
- WRITE_SECURE_SETTINGS - Can modify system settings
Together, these permissions could allow the app to:
- Monitor user input using accessibility
- Display fake UI elements with overlays
- Modify system settings without user awareness
Accessibility Services and Restricted Settings
The Accessibility Service is one of the most frequent features that is being exploited by mobile malware to carry out malicious activities.
Android’s Accessibility API is an incredibly powerful tool intended for developers to build apps for users with disabilities. The API lets apps read the contents of the screen and perform inputs on behalf of the user, which are essential functions for screen readers and alternative input systems, and respond to voice commands and convert them into taps on UI controls.
For those with visual impairments the Accessibility API is essential. Unfortunately, these functions are also incredibly useful for malicious apps (Zimperium blogged extensively about applications abusing accessibility services) that want to:
- Reading sensitive information from other apps' screens
- Intercepting and modifying user input
- Automating clicks/interactions without user awareness
- Capturing passwords and authentication tokens
- Injecting fake UI elements
- Performing unauthorized actions in privileged apps or system setting
- Automate the installation of payloads, enabling them to complete the installation process without user interaction
For this reason, Google limited which apps on the Google Play store can use the Accessibility API, and in Android 13, they’re taking things one step further by heavily restricting API access for apps that the user has sideloaded from outside of an official app store. For apps available on Google Play, their use is subject to careful scrutiny by moderators. Google calls this feature "Restricted Settings".
Figure: Restricted Setting
How Android apps can bypass Restricted Settings
App stores typically use the so-called session-based installation method.
This is how texting apps, mail clients, and browsers handle APK installation. Apps installed using this method are considered safe by the system.
For a sideloaded app, installed without using the session-based method, when a user manually downloads an APK and installs it, the Accessibility API settings will be restricted. A sideloaded app can bypass the “Restricted Settings” by using the session-based method to install another malicious app.
Even on the Google Play store, malware infected apps were observed abusing the accessibility services by the usage of drooper apps which facilitates the installation of the malware by circumventing security measures to grant sensitive permissions by using versioning, which refers to uploading a clean version of the app to the Play store to build trust among users and then adding malicious code at a later stage via app updates and by dynamically loading a DEX file payload.
Cleaning with high privilege
Cleaner applications are a good example of apps that have permissions that would allow them to perform powerful actions. Most of the time these permissions are required to fulfill the declared functionality of the app, but in other cases these permissions can be abused.
The Zimperium application vetting process that includes static code inspection, runtime and network communication analysis, identifies those apps as security and privacy risks.
Understanding legitimacy of privileges
Bookkeeping and cleaning apps are often on the verge when observed under the privilege point of view, meaning that they may require extra permissions to accomplish their task, nonetheless it is important to reassure that these privileges are not abused. Also it is possible that the apps may require other permissions that are not essential to their main purpose, like getting and managing accounts, reading calendars, request for packages installation and more.
In our analysis, we found more than a dozen cleaner apps (combining together several million downloads) that display malicious behaviour by abusing permissions expected in a cleaner app. Most of these apps are not available in official stores due to failing to comply with their TOS. Some of these apps logos are shown in the next image:
Let’s perform a deeper analysis on one of these apps. This cleaner app offers the following functionality:
- File Manager
- Uninstall apps
- Manage phone notifications
- Stop unused apps (Automatically hibernate them)
Further analysis shows that this app is a type of dropper which facilitates the installation of the malware by circumventing security measures to grant sensitive permissions. After being installed the app appears to have standard, yet privileged, cleaner activity, engaging buttons on top of system dialogs and force-stopping of foreground running app services that drain the device battery and memory.
After a while, the app dynamically loaded code and configuration from a command-and-control (C2) server. The code and configuration were dynamically loaded as a DEX file loaded by the dalvik.system.InMemoryDexClassLoader
This update altered the accessibility service functionality, enabling it to execute malicious actions such as automatically clicking buttons once it received a configuration from the C2 server. Some of the actions the app can perform afterwards include overlaying banking apps to steal user credentials, intercept SMS messages that could include MFA codes, steal contacts and perform unauthorized transactions. Moreover, this application was found to be part of a known malware campaign that had three iterations: Anatsa, TeaBot and Toddle.
Pre-installed apps
Pre-installed applications are installed on a device before it is sold and cannot be uninstalled by the user; they can only be disabled or hidden.
These apps are included for several reasons: to provide essential user experience features (like phone and messaging), as part of promotional agreements, for user convenience by eliminating the need to search and download, to save users time and data, and to increase app visibility.
Attack through the pre-installed “privileged” application
By design, pre-installed apps possess elevated privileges, enabling them to perform a wider range of actions and access more sensitive device resources compared to third-party apps. This makes them significant targets for privilege escalation attacks.
Pre-installed apps are also susceptible to common security vulnerabilities such as insecure API usage, declared custom permissions, improper authentication and authorization, general software vulnerabilities, and insecure handling of sensitive data. Typically, an Android device comes with tens of pre-installed applications.
App Vetting at pre-installed applications
As OEMs and other technology leaders are updating their pre-installed multiple applications, vulnerabilities are discovered and patched as a part of the endless circle of build-and-fix at the mobile security domain.
In this section we show an example of a security vulnerability at pre-installed applications that our application vetting system and static code inspection analysis identified as a security and privacy high risk.
OEM's Private Folder App
A popular OEM developed an app for the work profile to secure applications and data as a part of a proprietary security and management framework pre-installed on most mobile devices from this OEM. Since it was launched, this application has been installed in hundreds of millions of devices. Moreover, it is still pre-installed in most flagship devices today.
However, this application was vulnerable to a CVE discovered 3 years after its release. The vulnerability is an intent redirection vulnerability, enabling attackers to execute unauthorized privileged actions. Attackers could exploit this vulnerability locally without requiring privileges or user interaction, impacting the confidentiality of affected devices.
Our static code analysis of this APK detects security risks due to vulnerable intent redirection in a public activity using the setResult function, along with an exposed Content Provider that could allow a malicious application to access private data—including contacts, photos, call logs, text messages, and more.
Figure: vulnerable content provider as caused by an intent redirection and a grant URI permission
Figure: an intent redirection in an exposed activity
Lessons Learned – How Can Zimperium Help?
Preventing privilege escalation and securing Android ecosystems against malicious or over-privileged applications requires more than user awareness or reactive patching—it demands proactive, scalable, and intelligent defense mechanisms.
Zimperium offers a robust, enterprise-grade Application Vetting solution that empowers security teams to detect excessive privilege accumulation, pre-installed vulnerabilities, and sideloaded threats before they impact users or devices. Through a combination of static code analysis, dynamic behavioral monitoring, and machine learning-powered risk scoring, Zimperium identifies threats that evade traditional app store checks or basic MDM controls.
Here’s how Zimperium helps organizations stay ahead:
- Static Code Analysis: Detects hardcoded secrets, insecure API usage, intent redirection vulnerabilities, and over-permissive manifest declarations before an app is deployed.
- Dynamic Behavior Analysis: Evaluates runtime behaviors, including dynamic permission requests, network communication patterns, and abuse of services such as Accessibility or overlay permissions.
- Permission Risk Modeling: Automatically flags applications with suspicious combinations of permissions (e.g., SYSTEM_ALERT_WINDOW, BIND_ACCESSIBILITY_SERVICE, and WRITE_SECURE_SETTINGS) that could be used for clickjacking, credential theft, or device control.
- OEM and Pre-installed App Assessment: Analyzes proprietary OEM apps and preloaded software that may contain undocumented permissions, insecure Content Providers, or unpatched CVEs—highlighting risk even when users cannot uninstall the app.
- Sideloaded App Risk Detection: Identifies apps installed from unofficial sources and evaluates their potential to bypass Android’s "Restricted Settings" using session-based installation or dropper techniques.
- Malware detection: Zimperium’s MTD can detect malicious apps once they are installed on the device.
- Continuous Threat Intelligence Integration: Leverages global threat intelligence and real-time malware research to detect evolving techniques and droppers used in campaigns like Anatsa and TeaBot.
Implementing Zimperium's vetting capabilities—either as a pre-release security gate for enterprise apps, a vetting pipeline for BYOD and managed devices, or an assessment tool for pre-installed software—enables organizations to enforce least privilege, prevent lateral movement, and reduce mobile attack surface at scale.
