Android banking trojans and spyware routinely ask for device administrator rights, and once granted those rights let them lock the screen, wipe the device and resist uninstall. MITRE ATT&CK for Mobile records this as T1626 Abuse Elevation Control Mechanism, a Privilege Escalation technique with one sub-technique, T1626.001 Device Administrator Permissions. ATT&CK v20 lists it for Android only; device management on iOS runs through Apple's MDM protocol, which is out of scope here. This guide explains how the abuse works, how platform changes since Android 7 limit it, how to detect and remove a rogue device admin, and how to move legitimate management off the legacy API. It is for MDM administrators, mobile security engineers and incident responders. For the wider matrix, see the MITRE ATT&CK for Mobile Guide.
Key takeaways
- Legitimate apps rarely need device admin. ATT&CK's developer guidance (M1013) notes that applications very rarely require administrator permission, so a request is itself a strong signal.
- Abuse is usually paired with accessibility. ATT&CK notes that with Input Injection an app can grant itself admin rights without user input.
- Google has moved management away from this API. Since Android 9 several device admin policies are deprecated, and since Android 10 they throw a
SecurityExceptionfor apps targeting API 29. - Corporate devices should use Android Enterprise. Google recommends work profiles for personal devices and fully managed mode for company-owned devices, which leaves no business reason for a third-party device admin.
- Removal order matters. An active device admin must be deactivated before the app can be uninstalled; plan for malware that fights this step.
How device administrator abuse works
The Device Administration API lets an app enforce policies such as password rules, maximum failed attempts before wipe, inactivity lock time and camera disabling. Per the Android developer documentation, installing an app enforces nothing: the app must send ACTION_ADD_DEVICE_ADMIN, and the user must explicitly approve a system prompt that lists the requested policies. The app's DeviceAdminReceiver must require BIND_DEVICE_ADMIN so only the system can call it.
ATT&CK describes how adversaries use the granted rights:
- Resetting the device password to lock the owner out, which ATT&CK tracks separately as Mobile T1642 Endpoint Denial of Service.
- Factory resetting the device to delete data and traces of the malware.
- Disabling all cameras.
- Making the app harder to uninstall, because an active admin must first be deactivated.
ATT&CK also notes that combined with Mobile T1516 Input Injection, typically through an accessibility service, an app can approve its own admin request without the user touching the prompt.
Procedure examples from ATT&CK
| Software | Behaviour recorded by ATT&CK v20 |
|---|---|
| AbstractEmu (S1061) | Can modify system settings to give itself device administrator privileges |
| Asacub (S0540) | Can request device administrator permissions |
| Crocodilus (S9004) | Can request device administrator permissions |
| Exobot (S0522) | Can request device administrator permissions |
| GPlayed (S0536) | Can request device administrator permissions |
| Hornbill (S1077) and Sunbird (S1082) | Can request device administrator privileges |
| Red Alert 2.0 (S0539) | Can request device administrator permissions |
| XLoader for Android (S0318) | Requests Android Device Administrator access |
The pattern is consistent: banking trojans and surveillanceware request the permission early to secure their foothold. T1626.001 replaced the older Mobile ID T1401, which ATT&CK now marks as revoked.
Platform changes that limit the technique
| Android version | Change | Source |
|---|---|---|
| Android 7 | Changes made abuse of device administrator permissions more difficult (ATT&CK M1006) | MITRE ATT&CK |
| Android 9 (API 28) | USES_POLICY_DISABLE_CAMERA, USES_POLICY_DISABLE_KEYGUARD_FEATURES, USES_POLICY_EXPIRE_PASSWORD and USES_POLICY_LIMIT_PASSWORD are marked deprecated when invoked by a device admin, but still function | Google device admin deprecation notice |
| Android 10 (API 29) | Those four policies throw a SecurityException when invoked by a device admin in apps targeting API 29; wipe and force-lock remain for consumer use cases such as finding a lost device | Google device admin deprecation notice |
The remaining wipe and lock capabilities are exactly the ones malware uses for denial of service and anti-forensics, so the deprecation reduces but does not remove the risk.
Choosing a management model
| Device ownership | Recommended mode (Google) | Effect on T1626 risk |
|---|---|---|
| Personally owned (BYOD) | Work profile (profile owner) | Corporate apps and data sit in a separate profile managed by the EMM; no third-party device admin is needed |
| Company owned | Fully managed device (device owner) | The EMM's device policy controller controls the device; policy can restrict app sources and settings |
| Legacy device admin estate | Phased migration: new devices enrol in the new mode, existing ones stay until refreshed | Moving to fully managed requires a factory reset, so plan it with the hardware cycle |
Small organisations without an EMM should at least make sure no app other than a known security or find-my-device app holds device admin. Larger estates should report every active admin through the EMM. See the Android Enterprise Security Guide and the Mobile Device Management Security Guide.
Detection
MITRE's detection strategy for Device Administrator Permissions (DET0630) correlates management and vetting evidence rather than a real-time device feed: the permission state seen through an Android Enterprise device policy controller or app vetting, manifest review for device admin metadata, and dynamic traces where an app calls DevicePolicyManager.resetPassword(), lockNow(), wipeData() or setCameraDisabled() soon after activation.
- App vetting: flag any APK declaring a
DeviceAdminReceiverwithandroid.app.device_adminmetadata, unless it is an approved management or security app. - Accessibility plus admin: treat an app that requests both accessibility service and device admin as high risk; this is the self-approval pattern ATT&CK describes. ATT&CK tracks accessibility abuse separately as Mobile T1453 Abuse Accessibility Features.
- Play Integrity environment details:
appAccessRiskVerdictlabels such asUNKNOWN_CONTROLLINGshow an app not installed by Google Play that can control the device and your app's inputs;playProtectVerdictofHIGH_RISKshows dangerous apps found. - MTD: alerts for unknown device admin apps and sideloaded installs.
- User reports: a sudden PIN change, an unexpected wipe or an app that cannot be uninstalled are often the first sign.
Metrics
- Number of devices with a device admin app that is not on the approved list (target: zero).
- Percentage of the Android estate enrolled in work profile or fully managed mode rather than legacy device admin.
- Percentage of devices restricted to managed Google Play.
- Median time from an unknown-admin alert to removal.
- Number of apps approved with both accessibility and device admin, each with a documented reason.
Removing a rogue device admin: step by step
- Isolate: remove the device from conditional access and revoke its sessions.
- Preserve evidence if the device belongs to a high-risk user; see the Mobile Spyware Infection Response Playbook.
- Deactivate the admin: per the Android docs, users must first unregister an app as administrator before uninstalling it. Where the device is managed, use the EMM to remove the app; where malware blocks the settings screen through accessibility, safe mode or a factory reset is the fallback.
- Uninstall and scan: remove the app and run Play Protect or the MTD scan again.
- Rotate credentials: banking trojans that use this technique also target one-time codes and app credentials; reset passwords, revoke refresh tokens and re-enrol device certificates.
- Re-enrol in a supported mode and confirm the device passes integrity checks before restoring access.
Where identity fits
A device admin with wipe rights can destroy evidence and lock users out of the second factor they depend on. If the phone is the user's authenticator, plan an out-of-band recovery path before you need it, and avoid SMS-based codes on Android where an app can read them. The EMM's own service credentials, which hold real device admin or device owner power across the estate, are high-value machine identities: protect them like privileged accounts. See Mobile Access Credentials.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| ATT&CK for Mobile | M1006 Use Recent OS Version, M1011 User Guidance, M1013 Application Developer Guidance | Mitigations ATT&CK maps to T1626 and T1626.001 |
| NIST SP 800-53 Rev 5 | AC-6 Least Privilege, AC-19 Access Control for Mobile Devices, CM-11 User-installed Software, SI-3 Malicious Code Protection | Limit privilege, control installs, scan |
| NIST CSF 2.0 | PR.PS-05, DE.CM-09 | Prevent unauthorised software, monitor devices |
| CIS Controls v8.1 | Control 2 Inventory and Control of Software Assets, Control 10 Malware Defenses | Know which apps hold admin rights; block malware |
Common failure patterns
- Staying on legacy device admin management: the estate keeps a model Google has deprecated, and users stay used to approving admin prompts.
- Allowing sideloading on corporate devices: almost every procedure example arrives outside the official store.
- Approving accessibility services freely: this enables the self-grant path ATT&CK describes.
- Uninstalling without rotating credentials: the trojan has already taken codes and passwords.
- Ignoring user reports of PIN changes: these are often the first visible sign of abuse.
Practitioner checklist
- Enrol company devices as fully managed and personal devices with a work profile.
- Keep an approved list of apps allowed device admin and alert on anything else.
- Block unknown sources and keep Google Play Protect on.
- Review accessibility service grants alongside device admin grants.
- Enforce minimum Android version and patch level.
- Teach users to refuse unexpected device administrator prompts (M1011).
- Document the removal path, including safe mode and reset, for the service desk.
- Rotate credentials after any confirmed rogue admin.
Standards and references
- MITRE ATT&CK: Abuse Elevation Control Mechanism (Mobile T1626)
- MITRE ATT&CK: Device Administrator Permissions (Mobile T1626.001)
- Android Developers: Device administration overview
- Google for Developers: Device admin deprecation
- Android Developers: Play Integrity API integrity verdicts
- OWASP: Mobile Application Security Verification Standard
Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · MITRE ATT&CK T1548 Abuse Elevation Control Mechanism · Android Banking Trojans Guide · Mobile App Permissions