AN1656: Analytic 1656
The user can view a list of device administrators and applications that have registered Accessibility services in device settings. Applications that register an Accessibility service or request device administrator permissions should be scrutinized further for malicious behavior. Application vetting services can look for applications that request permissions to Accessibility services or application overlay. Monitor for API calls that are related to GooglePlayServices.
Analyst context for executives and security teams
This analytic is about validating whether Android apps have high-risk administrative or Accessibility-related privileges that can change the security posture of a device. For leaders, the practical issue is not simply that a permission exists; it is whether the organization can identify which mobile apps have privileged control paths, decide whether those apps are approved, and produce evidence during an incident or audit.
Executive priority
Prioritize this where Android devices are part of the business environment, especially for managed mobility, bring-your-own-device programs, or roles with access to sensitive systems. The decision value is confirming that mobile governance, app vetting, and SOC visibility can surface applications requesting Accessibility services, device administrator permissions, application overlay capability, or Google Play Services-related API activity for review. This supports incident triage, mobile security policy enforcement, and compliance evidence around privileged mobile access.
Technical view
SOC, mobile security, and IR teams should validate visibility into Android device settings and app permission state for device administrators and registered Accessibility services. Application vetting workflows should flag apps requesting Accessibility services or application overlay permissions for further review. Where telemetry exists, teams should also assess monitoring for API calls related to Google Play Services. Because no ATT&CK tactic or formal detection logic is supplied, this should be treated as a validation and review analytic rather than a complete detection rule.
Likely telemetry
- Android device administrator status and registered device admin applications
- Android Accessibility service registration and enabled-state records
- Application permission manifests and app vetting results
- Application overlay permission requests or grants
- Mobile device management or enterprise mobility management inventory, if deployed
Detection direction
- Confirm that Android fleet visibility includes the list of device administrators and applications with registered or enabled Accessibility services.
- Tune review workflows to distinguish approved enterprise accessibility, device management, or assistive applications from unknown, newly installed, or policy-violating apps.
- Use app vetting to flag Accessibility service and overlay permission requests before approval or deployment.
- Correlate privileged mobile permissions with device ownership, user role, app source, install time, and enterprise approval status to reduce false positives.
- Validate whether Google Play Services-related API monitoring is actually collected and usable; do not assume coverage from endpoint or MDM enrollment alone.
Mitigation priorities
- Establish an approved baseline for Android apps allowed to use device administrator, Accessibility service, or overlay capabilities.
- Require app vetting for mobile applications requesting these privileges before enterprise approval.
- Use mobile management controls, where available, to inventory and review privileged Android app permissions.
- Create incident response procedures for reviewing and removing unauthorized privileged mobile apps.
- Maintain audit evidence showing periodic review of Android privileged app permissions and exceptions.
Analyst notes and limits
The supplied object is a mobile ATT&CK detection analytic for Android with no tactic mapping, no formal detection field, and no relationship context. Its strongest use is as a control-validation prompt: can the organization see, review, and govern Android apps with device administrator, Accessibility, overlay, or Google Play Services-related behaviors?
This take is limited to the official STIX fields and external reference provided. It does not establish maliciousness by itself, does not identify a specific technique relationship, and does not prove detection coverage. Local device management, app inventory, and mobile telemetry are required to determine applicability and effectiveness.
Analytic 1656
The user can view a list of device administrators and applications that have registered Accessibility services in device settings. Applications that register an Accessibility service or request device administrator permissions should be scrutinized further for malicious behavior. Application vetting services can look for applications that request permissions to Accessibility services or application overlay. Monitor for API calls that are related to GooglePlayServices.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 945798710956… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1656Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.