Request pricing
En
    Request pricing

    Login

      Attack techniques overview

      Malicious accessibility services

      Accessibility services are a set of native features on the Android OS developed to assist and enhance the experience of users with disabilities.

      However, these powerful features can be abused to introduce security risks. An accessibility service process has the unique ability to interfere with the UI of other apps; this breaks the application sandbox principle, an important security feature designed to prevent applications from reading and modifying other applications. Malware developers are well aware of, and take advantage of, the possibilities of Android accessibility services.

      Malicious accessibility services work by inspecting the events generated on the device, which allows them to track which application is being executed at any moment, what text is being entered, and what the screen layout looks like. We have seen this information being used in three distinct ways:

      • Triggering actions at a specific moment, e.g. when a particular view is shown on the screen.
      • Capturing sensitive information (keyloggers).
      • Performing a number of actions without the user's knowledge or consent. Namely, self-granting permissions or elevating privileges to become a device admin app; as well as obstructing any action from the user that could threaten entail danger for the malware’s operation, such as permission or privilege revocation, uninstallation, etc.

      Defense techniques overview

      --- title: Spying on and spoofing users' data with malicious a11y services --- graph TD all[All malware attacks] --> steal_screen click all href "/mobile-app-security-research-center/malware/overview" "Malware overview" steal_screen[Spy on users' screen] steal_screen --> a11y[Malicious accessibility service] a11y --> a11y_api34{API Level?} a11y_api34 -- Android 14+ (API Level ≥ 34) --> sads([accessibilityDataSensitive ⭐]) a11y_api34 -- All versions --> a11y_api_all(Solution options) a11y_api_all --> a11y_delegate([AccessibilityDelegate]) a11y_api_all --> a11y_filtering(Accessibility service filtering) a11y_api_all --> biometric([Biometric authentication]) a11y_filtering --> a11y_allowlist([Accessibility service allow-listing ⭐]) a11y_filtering --> a11y_deviceadmin([Verifying device admin ⭐]) a11y_filtering --> a11y_sideload([Verifying sideloaded ⭐]) a11y_filtering --> a11y_system([Verifying system flag]) style sads fill:lightgreen style a11y_delegate fill:lightgreen style a11y_allowlist fill:lightgreen style a11y_deviceadmin fill:lightgreen style a11y_sideload fill:lightgreen style a11y_system fill:lightgreen style biometric fill:lightgreen click a11y_allowlist href "/mobile-app-security-research-center/malware/accessibility-services-allowlisting" "Simple allowlisting" click a11y_deviceadmin href "/mobile-app-security-research-center/malware/device-admin-accessibility" "Checking device admin" click a11y_sideload href "/mobile-app-security-research-center/malware/side-loaded-accessibility" "Checking side-loaded" click a11y_system href "/mobile-app-security-research-center/malware/non-system-accessibility-services" "Checking system" click sads href "/mobile-app-security-research-center/malware/accessibility-data-sensitive" "AccessibilityDataSensitive" click biometric href "/mobile-app-security-research-center/malware/biometric-authentication" "Biometric authentication" click a11y_delegate href "/mobile-app-security-research-center/malware/accessibility-delegates" "Accessibility delegates"

      Recommended defense tactics

      Defending against malicious accessibility services is not easy, because limiting functionality of accessibility services may impact the user experience of anyone relying on accessibility services to use the device.

      Therefore, we recommend implementing a multi-front defense strategy that collectively protects against malicious accessibility services while reducing the probability of mistakingly restricting the user experience to a minimum.

      For example:

      1. On Android ≥ 14 (API Level ≥ 34), use the accessibilityDataSensitive API.
      2. On Android < 14 (API Level < 34), use:
        1. Allowlisting.
        2. Sideloaded check (Extension of allowlisting).
        3. Device admin check (Extension of allowlisting).

      Check the side bar on the left to find more details about each technique.

      Guardsquare

      Table of contents