T1629.001: Prevent Application Removal
Adversaries may abuse the Android device administration API to prevent the user from uninstalling a target application. In earlier versions of Android, device administrator applications needed their administration capabilities explicitly deactivated by the user before the application could be uninstalled. This was later updated so the user could deactivate and uninstall the administrator application in one step.
Adversaries may also abuse the device accessibility APIs to prevent removal. This set of APIs allows the application to perform certain actions on behalf of the user and programmatically determine what is being shown on the screen. The malicious application could monitor the device screen for certain modals (e.g., the confirmation modal to uninstall an application) and inject screen input or a back button tap to close the modal. For example, Android's `performGlobalAction(int)` API could be utilized to prevent the user from removing the malicious application from the device after installation. If the user wants to uninstall the malicious application, two cases may occur, both preventing the user from removing the application.
* Case 1: If the integer argument passed to the API call is `2` or `GLOBAL_ACTION_HOME`, the malicious application may direct the user to the home screen from settings screen
* Case 2: If the integer argument passed to the API call is `1` or `GLOBAL_ACTION_BACK`, the malicious application may emulate the back press event
Analyst context for executives and security teams
Prevent Application Removal is a mobile persistence and defense-impairment behavior on Android where a malicious app abuses device administrator or accessibility capabilities to stop a user from uninstalling it. For business leaders, the practical issue is not only malware presence; it is loss of user and support-team control over the device, which can delay containment, weaken mobile incident response, and increase exposure where phones are used for banking, identity, approvals, or workforce access.
Executive priority
Treat this as a mobile resilience and control-governance concern. Executives should ask whether Android devices in scope are kept on recent OS versions, whether enterprise mobility policies can restrict risky administration/accessibility abuse, and whether support and IR teams have a tested path to remove or isolate a device when normal uninstall actions fail. The number of ATT&CK software relationships, including multiple Android banking malware families, makes this behavior material for organizations that rely on mobile devices for authentication, finance workflows, or regulated data access.
Technical view
This sub-technique applies to Android and is related to Impair Defenses. MITRE does not provide official detection text for this object, but the description points defenders toward validation of device administrator status, accessibility service use, and anomalous user-interface control around uninstall or settings screens. SOC and mobile security teams should confirm whether DET0598 or equivalent mobile detection logic can identify apps that request or hold device administrator privileges, abuse accessibility services, or interfere with uninstall confirmation flows. IR playbooks should account for cases where user-driven removal is blocked and escalation to EMM/MDM controls, OS-level remediation, or device isolation may be required.
Likely telemetry
- Android application inventory and package installation/removal events
- Device administrator activation/deactivation state for installed applications
- Accessibility service enablement and permission state
- EMM/MDM compliance, policy, and device posture records
- Mobile security alerts tied to suspicious administration or accessibility behavior
Detection direction
- Validate coverage for DET0598 or equivalent logic against Android apps that prevent removal through device administrator or accessibility abuse.
- Prioritize monitoring for non-enterprise or unexpected apps with device administrator capabilities or enabled accessibility services.
- Tune carefully around legitimate accessibility tools and approved device-management applications to reduce false positives.
- Correlate uninstall failure reports with app privilege state and EMM/MDM telemetry rather than treating them only as user-support issues.
- Use the software relationships as threat-intelligence context for triage, without assuming any named malware is present unless local evidence supports it.
Mitigation priorities
- Prioritize M1006: keep Android devices on recent OS versions to benefit from security architecture improvements, including changes that reduce older device administrator uninstall friction.
- Use M1012: apply enterprise mobility management policies to control allowed device behavior and support administrative remediation when user removal fails.
- Use M1011: provide user guidance on avoiding risky configuration changes and promptly reporting apps that request unusual administrator or accessibility privileges or resist removal.
- Ensure mobile IR procedures include isolation, enterprise policy action, and escalation paths for devices where normal uninstall is blocked.
Analyst notes and limits
The ATT&CK object has no specified tactics and no official detection narrative, so defensive recommendations are derived from the official description, platform, mitigation relationships, DET0598 relationship, and related software context. Related software includes OBAD, Gustuff, Anubis, Mandrake, S.O.V.A., FluBot, Chameleon, GodFather, and Crocodilus, indicating this behavior appears across multiple Android malware entries in ATT&CK.
This take is limited to the supplied ATT&CK/STIX fields and relationships. It does not establish active exploitation, customer exposure, attribution, or guaranteed detection. Local Android version mix, EMM/MDM capability, mobile telemetry availability, and approved accessibility/admin use must be reviewed to determine actual risk and coverage.
Prevent Application Removal
Adversaries may abuse the Android device administration API to prevent the user from uninstalling a target application. In earlier versions of Android, device administrator applications needed their administration capabilities explicitly deactivated by the user before the application could be uninstalled. This was later updated so the user could deactivate and uninstall the administrator application in one step.
Adversaries may also abuse the device accessibility APIs to prevent removal. This set of APIs allows the application to perform certain actions on behalf of the user and programmatically determine what is being shown on the screen. The malicious application could monitor the device screen for certain modals (e.g., the confirmation modal to uninstall an application) and inject screen input or a back button tap to close the modal. For example, Android's `performGlobalAction(int)` API could be utilized to prevent the user from removing the malicious application from the device after installation. If the user wants to uninstall the malicious application, two cases may occur, both preventing the user from removing the application.
* Case 1: If the integer argument passed to the API call is `2` or `GLOBAL_ACTION_HOME`, the malicious application may direct the user to the home screen from settings screen
* Case 2: If the integer argument passed to the API call is `1` or `GLOBAL_ACTION_BACK`, the malicious application may emulate the back press event
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.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Mobile | T1629 | Impair Defenses | This object subtechnique of Impair Defenses. |
Groups, software, and campaigns
S0286: OBAD
OBAD is an Android malware family. [1]
S1231: GodFather
GodFather is an Android banking malware that uses virtualization to mimic legitimate applications and abuses accessibility services and other permissions to evade detection and exfiltrate sensitive data. First identified in 2020, GodFather targets nearly 500 banking applications, cryptocurrency wallets, and exchanges worldwide; however, its virtualization-based attacks have primarily focused on several Turkish financial institutions. This capability enables threat actors to steal banking credentials and other sensitive account information. [1][2]
S1083: Chameleon
Chameleon is an Android banking trojan that can leverage Android’s Accessibility Services to perform malicious activities. Believed to have been first active in January 2023, Chameleon has been observed targeting users in Australia and Poland by masquerading as official applications. A new variant of Chameleon has expanded its targets to include Android users in the United Kingdom and Italy.[1][2]
S0485: Mandrake
Mandrake is a sophisticated Android espionage platform that has been active in the wild since at least 2016. Mandrake is very actively maintained, with sophisticated features and attacks that are executed with surgical precision.
Mandrake has gone undetected for several years by providing legitimate, ad-free applications with social media and real reviews to back the apps. The malware is only activated when the operators issue a specific command.[1]
S0406: Gustuff
S0422: Anubis
S1062: S.O.V.A.
S.O.V.A. is an Android banking trojan that was first identified in August 2021 and has subsequently been found in a variety of applications, including banking, cryptocurrency wallet/exchange, and shopping apps. S.O.V.A., which is Russian for "owl", contains features not commonly found in Android malware, such as session cookie theft.[1][2]
S9004: Crocodilus
Crocodilus is an Android banking Trojan that was discovered in March 2025. Crocodilus targeted users worldwide, including Turkey, Poland, Argentina, Brazil, Spain, the United States, Indonesia and India. Crocodilus has been customized based on the target location. For example, Crocodilus mimicked major Turkish and Spanish banks for users in Turkey and Spain, while users in Poland saw Facebook advertisements that promoted Crocodilus to claim bonus points.[1][2]
S1067: FluBot
FluBot is a multi-purpose mobile banking malware that was first observed in Spain in late 2020. It primarily spread through European countries using a variety of SMS phishing messages in multiple languages.[1][2] An international law enforcement operation of 11 countries eventually disrupted the spread of FluBot.[3]
All related ATT&CK context
Mitigation direction
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.2 | Current bundle | 11d5e5046c73… |
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]
NIST Mobile Threat Catalogue APP-22Open source URL
-
[2]
mitre-attack T1629.001Open 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.