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
Security 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.
Additional 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.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
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]TrendMicro-Obad
Veo Zhang. (2013, June 13). Cybercriminals Improve Android Malware Stealth Routines with OBAD. Retrieved December 9, 2016.
- [2]MerkleScience_Godfather_April2023
Merkle Science. (2023, April 25). The Godfather Android Malware: Threat under the lens. Retrieved July 16, 2025.
Open source URL - [3]cyble_chameleon_0423
Cyble Research & Intelligence Labs. (2023, April 13). Banking Trojan targeting mobile users in Australia and Poland. Retrieved August 16, 2023.
Open source URL - [4]ThreatFabric_Chameleon_Dec2023
ThreatFabric. (2023, December 21). Android Banking Trojan Chameleon can now bypass any Biometric Authentication. Retrieved July 7, 2025.
Open source URL - [5]Bitdefender Mandrake
R. Gevers, M. Tivadar, R. Bleotu, A. M. Barbatei, et al.. (2020, May 14). Uprooting Mandrake: The Story of an Advanced Android Spyware Framework That Went Undetected for 4 Years. Retrieved July 15, 2020.
Open source URL - [6]threatfabric_sova_0921
ThreatFabric. (2021, September 9). S.O.V.A. - A new Android Banking trojan with fowl intentions. Retrieved February 6, 2023.
Open source URL - [7]ThreatFabric_Crocodilus_March2025
ThreatFabric. (2025, March 28). Exposing Crocodilus: New Device Takeover Malware Targeting Android Devices. Retrieved November 24, 2025.
Open source URL - [8]bitdefender_flubot_0524
Filip TRUȚĂ, Răzvan GOSA, Adrian Mihai GOZOB. (2022, May 24). New FluBot Campaign Sweeps through Europe Targeting Android and iOS Users Alike. Retrieved February 28, 2023.
Open source URL - [9]NIST Mobile Threat CatalogueAPP-22Open source URL
- [10]NIST Mobile Threat CatalogueAPP-22Open source URL
- [11]mitre-attackT1629.001Open source URL
- [12]mitre-attackT1629.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.