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.
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:
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:
For instance, an application with OEM 1 permissions could potentially:
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
Together, these permissions could allow the app to:
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:
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
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.
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.
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:
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 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.
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.
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.
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
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:
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.