Mobile T1629 Impair Defenses: Stopping Android Malware That Blocks Removal

Android malware that switches off Google Play Protect, bounces the user away from the uninstall screen or locks them out of their own phone turns a routine clean-up into an incident. MITRE ATT&CK for Mobile tracks this as T1629 Impair Defenses, under Defense Evasion (TA0030), with three sub-techniques: Prevent Application Removal, Device Lockout, and Disable or Modify Tools. ATT&CK v20 lists the technique and its sub-techniques for Android only; iOS is not listed. This guide explains each sub-technique, the Android platform changes that narrow it, the enterprise policies that block it, and how to detect and recover. It is for mobile security engineers, MDM administrators and incident responders, and builds on the MITRE ATT&CK for Mobile Guide.

Key takeaways

• Two Android features carry most of this technique. Device administrator rights and accessibility services appear in nearly every ATT&CK procedure example for T1629.
• Play Protect is the usual target. ATT&CK lists Anubis, BRATA, Cerberus, Chameleon, Drinik, FluBot, Mandrake, SpyC23 and AbstractEmu disabling Google Play Protect.
• An accessibility allowlist is the strongest single control. ATT&CK maps enterprise policy using DevicePolicyManager.setPermittedAccessibilityServices to restrict accessibility to approved apps.
• Platform changes help, if devices are current. Android 7 limited passcode reset to device and profile owners, and later releases deprecated device admin policies and simplified removal of admin apps.
• Play Protect state is observable. The Play Integrity API reports POSSIBLE_RISK when Play Protect is off, which gives backends and MTD a signal to act on.

What T1629 covers

ATT&CK describes T1629 as modifying components of the victim environment to hinder or disable defensive mechanisms, both preventive (such as anti-malware) and detective, and both native defences and tools installed by users or mobile endpoint administrators. Two procedure examples sit at the technique level: GodFather intercepts API returns from banking apps that look for malicious services and returns an empty list, hiding its presence; CherryBlos sends the user back to the home screen when they open the malicious app's settings and automatically approves permission requests. The technique mirrors Enterprise T1685 Disable or Modify Tools; see the T1685 Disable or Modify Tools Defensive Guide for the desktop and server view.

T1629.001 Prevent Application Removal

ATT&CK describes two routes. The older one abuses the device administration API: on earlier Android versions a device administrator app had to be deactivated by the user before it could be uninstalled, which OBAD and Mandrake exploited. Android later changed this so the user can deactivate and uninstall an administrator app in one step. The second route abuses accessibility services: the app watches the screen for the uninstall confirmation and injects a back press or a home action through performGlobalAction(int), as ATT&CK documents for Anubis and Gustuff. GodFather, Chameleon and FluBot use accessibility services in the same way, and S.O.V.A. returns to the home screen during uninstall.

• M1012 Enterprise Policy: on managed devices, set an explicit list of accessibility services with DevicePolicyManager.setPermittedAccessibilityServices. A malicious app that cannot become an accessibility service cannot block its own removal this way.
• Restricted settings: Google's Android help explains that Android may restrict some settings, accessibility among them, after an app is installed, and the user must explicitly allow restricted settings; parts of this flow apply to Android 13 and later. Users should treat a prompt to allow restricted settings for an unfamiliar app as a warning sign.
• M1011 User Guidance: warn users against granting accessibility or device administrator access, and teach them how to revoke both in Settings.

T1629.002 Device Lockout

The classic method is to obtain device administrator rights and call DevicePolicyManager.lockNow(). ATT&CK also lists newer methods: AndroidOS/MalLocker.B uses a crafted "call" notification screen, TrickMo shows a WebView with a persistent cursor, and Rotexy locks an HTML page in the foreground that demands card details matching data intercepted from SMS. ATT&CK notes these can be very difficult to get around and typically require booting into safe mode to uninstall the malware.

Before Android 7, device administrators could reset the lock screen passcode to lock the user out. ATT&CK records that Android 7 restricted passcode reset to device or profile owners such as MDMs. Android's device admin deprecation notice adds that from Android 11 the USES_POLICY_RESET_PASSWORD policy stops working for apps targeting API level 24 and above, while USES_POLICY_FORCE_LOCK and USES_POLICY_WIPE_DATA remain available for consumer use. Lock and wipe are still reachable by a malicious device admin, which is why the grant prompt matters.

T1629.003 Disable or Modify Tools

ATT&CK describes disabling security software, modifying SELinux configuration or otherwise interfering with security tools, usually through device administrator permissions or root exploits that modify protected system files. Procedure examples include Drinik using accessibility services to disable Play Protect, BRATA removing installed antivirus apps, Dvmap turning off VerifyApps, Zen modifying SELinux enforcement mode, and the PROMETHIUM group using StrongPity during campaign C0033 to modify permissions on a rooted device.

• M1004 System Partition Integrity: Android Verified Boot builds a chain of trust from hardware through the bootloader to the boot and system partitions, and rollback protection stops a device reverting to an older, vulnerable Android version. Unauthorised changes to system files are detected at boot.
• SELinux: Android's documentation states SELinux applies mandatory access control to all processes, including root, and that Android ships in enforcing mode, with full enforcement across all domains since Android 5.0. A device found in permissive mode is a strong compromise or tampering signal.
• M1010 and M1001: deploy compromised device detection and keep security patches current, because root access, which most of this sub-technique depends on, usually comes through an unpatched vulnerability.

Detection and measurement

ATT&CK v20 detection strategies for T1629 correlate Android Enterprise permission grant state and managed package inventory with app vetting evidence, such as dynamic traces of apps invoking package management, device policy or accessibility global actions. Treat MDM queries as periodic snapshots.

Metrics:

• Percentage of managed devices with an accessibility allowlist enforced.
• Number of devices reporting Play Protect off, and median time to remediate.
• Percentage of devices passing the device integrity verdict.
• Count of non-MDM apps with device administrator rights (target: zero).
• Percentage of devices on a security patch level less than 90 days old.

Implementing the controls

1. Move off legacy device admin. Android recommends device owner (company-owned) or work profile (personally owned) management, both available since Android 5.0, in place of device administrator apps. Use an EMM that supports these modes.
2. Enforce the accessibility allowlist. Start with a pilot ring and an allowlist built from current legitimate use (screen readers, password managers that need it), monitor complaints for two weeks, then widen. Roll back by clearing the list, which permits all services again.
3. Block installs from unknown sources with DISALLOW_INSTALL_UNKNOWN_SOURCES, since nearly all T1629 families arrive sideloaded.
4. Protect the security tooling itself. Prevent users removing the MTD agent and MDM app with the EMM's uninstall-blocking policy and alert on removal.
5. Gate access on integrity. Configure conditional access to deny corporate apps to devices that fail integrity or report Play Protect off; keep a documented exception path for urgent business need.

Responding when defences are impaired

• Safe mode for lockout and blocked removal: ATT&CK notes lockout malware typically requires booting into safe mode to uninstall it. Put the steps for each device model in the service desk runbook before you need them.
• Revoke, then remove: remove device administrator rights and accessibility access for the package, uninstall it, then turn Play Protect back on and run a scan.
• Assume credential theft: banking trojans in this family overlay login screens and read one-time codes. Reset the user's passwords and revoke mobile sessions and tokens.
• Rooted or SELinux-modified devices: do not trust a clean-up. Preserve evidence, then factory reset or reflash the device. See the Mobile Forensics Guide and the Mobile Spyware Infection Response Playbook.

Where identity fits

MDM, MTD and Play Protect are themselves privileged software. The EMM's enrolment tokens, the service accounts that push policy and the API keys that MTD tools use to report into the SIEM and identity provider are non-human identities worth protecting: an attacker who can change the accessibility allowlist or unenrol a device from the console impairs defences for the whole fleet. See the Mobile Device Management Security Guide.

Framework mapping

Common failure patterns

• No accessibility allowlist: managed devices permit any app to become an accessibility service, which is the route most current banking trojans use to block removal.
• Legacy device admin MDM: fleets still managed through device administrator APIs rather than device owner or work profile modes, losing the controls that need those modes.
• Ignoring Play Protect state: backends that call the Play Integrity API but discard the playProtectVerdict, missing the clearest sign that defences were switched off.
• Cleaning a rooted device in place: removing the visible app from a device with modified system files and returning it to the user.
• Not alerting on agent removal: the MTD agent disappears from a device and nobody notices until the next audit.

Practitioner checklist

• Manage company-owned devices as device owner and personal devices with a work profile.
• Enforce an accessibility services allowlist on every managed device.
• Block installs from unknown sources and alert on any non-MDM app with device administrator rights.
• Read playProtectVerdict and device integrity in your apps and act on POSSIBLE_RISK.
• Block removal of MDM and MTD apps and alert when either stops reporting.
• Set a maximum security patch age in compliance policy.
• Document safe mode recovery for locked-out users in the service desk runbook.
• Reflash, rather than clean, devices that show root or SELinux changes.

Standards and references

• MITRE ATT&CK: Impair Defenses (Mobile T1629)
• MITRE ATT&CK: Prevent Application Removal (T1629.001)
• MITRE ATT&CK: Device Lockout (T1629.002)
• Google: Device admin deprecation
• Android Open Source Project: Verified Boot
• Android Open Source Project: Security-Enhanced Linux in Android
• Android Developers: Play Integrity API integrity verdicts
• Google: Allow restricted settings on Android

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Mobile Malware Guide · Mobile Banking App Security Guide · Mobile Threat Defense Buyer's Guide