T1629: Impair Defenses
Adversaries may maliciously modify components of a victim environment in order to hinder or disable defensive mechanisms. This not only involves impairing preventative defenses, such as anti-virus, but also detection capabilities that defenders can use to audit activity and identify malicious behavior. This may span both native defenses as well as supplemental capabilities installed by users or mobile endpoint administrators.
Analyst context for executives and security teams
T1629 matters because it describes Android adversary behavior aimed at weakening the very controls an organization depends on to prevent, detect, or investigate mobile compromise. For leaders, the practical question is not only whether mobile security tools are deployed, but whether devices can report when those tools, native protections, or administrative controls are being disabled, bypassed, or made ineffective.
Executive priority
Prioritize this as a mobile resilience and evidence-quality issue. If an Android device can impair defenses, incident responders may lose trustworthy visibility, users may be unable to remove malicious apps, and conditional access decisions may rely on stale or incomplete device posture. Executive review should focus on patch-level enforcement, MDM/EMM policy coverage, compromised-device detection, Android Verified Boot support, and whether unsupported or unpatched devices are allowed to access enterprise resources.
Technical view
This Android technique has no official ATT&CK detection text, but it is linked to detection strategy DET0687 and to sub-techniques covering prevention of application removal, device lockout, and disabling or modifying tools. SOC, mobile security, and IR teams should validate whether their MDM/EMM, mobile threat defense, and endpoint posture sources can identify abnormal changes to device administrator privileges, accessibility abuse, security tool disablement, root or system-partition integrity issues, and loss of expected mobile telemetry. Treat missing or suddenly silent device signals as potentially meaningful, not merely as collection failure.
Likely telemetry
- MDM/EMM device posture, compliance, policy, and enrollment status
- Android security patch level and OS version information
- Verified Boot or system partition integrity status where available
- Compromised-device, rooted-device, or jailbreak-style detection results for Android
- Mobile threat defense alerts and health/status events
Detection direction
- Validate DET0687-aligned coverage in the local environment rather than assuming ATT&CK provides a ready detection analytic; the official object does not include detection logic.
- Alert on high-risk posture transitions such as loss of mobile security agent reporting, downgrade from compliant to noncompliant state, newly detected root indicators, or failed integrity checks.
- Correlate application-removal prevention, device lockout behavior, device administrator abuse, accessibility service abuse, and security tool tampering because ATT&CK models these as sub-techniques of Impair Defenses.
- Tune for administrative and helpdesk-driven false positives, including legitimate MDM policy changes, device migrations, OS upgrades, or sanctioned security tool replacement.
- Measure blind spots explicitly: unmanaged Android devices, devices without current security updates, devices outside MDM/EMM scope, and devices whose mobile threat defense agent can be disabled without escalation.
Mitigation priorities
- Enforce security updates through M1001: require recent Android security patch levels for enterprise access and decommission devices that no longer receive updates.
- Use M1004 where supported: ensure Android devices include and enable Verified Boot to protect system partition integrity.
- Deploy M1010 compromised-device detection through native device capabilities, MDM/EMM, mobile security applications, or other enterprise methods, while recognizing that some methods may be easier to evade than others.
- Apply M1012 enterprise policy to control allowed device behavior, application management, compliance requirements, and access to enterprise resources.
- Provide M1011 user guidance so users know how to report lockout, inability to uninstall apps, unusual permission prompts, or mobile security tools that appear disabled.
Analyst notes and limits
The relationship context is important: T1629 is a parent technique with Android sub-techniques for preventing app removal, locking out the user, and disabling or modifying tools. ATT&CK also lists Android malware software entries CherryBlos and GodFather as using this technique, but that should be used as threat-intelligence context only, not as evidence of activity in any given environment.
The supplied ATT&CK object does not specify tactics and provides no official detection procedure. Telemetry availability depends heavily on Android version, device ownership model, MDM/EMM enrollment, mobile threat defense deployment, and whether devices are still supported by the vendor or carrier. Local validation is required before making coverage, compliance, or incident-readiness claims.
Impair Defenses
Adversaries may maliciously modify components of a victim environment in order to hinder or disable defensive mechanisms. This not only involves impairing preventative defenses, such as anti-virus, but also detection capabilities that defenders can use to audit activity and identify malicious behavior. This may span both native defenses as well as supplemental capabilities installed by users or mobile endpoint administrators.
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.002 | Device Lockout Sub-technique | Device Lockout subtechnique of this object. |
| Mobile | T1629.003 | Disable or Modify Tools Sub-technique | Disable or Modify Tools subtechnique of this object. |
| Mobile | T1629.001 | Prevent Application Removal Sub-technique | Prevent Application Removal subtechnique of this object. |
Groups, software, and campaigns
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]
S1225: CherryBlos
CherryBlos is an Android malware that steals credentials and redirects cryptocurrency to adversary-controlled wallets. CherryBlos was labelled Robot 999 in its first appearance in April 2023; since then, various aliases have been used, including GPTalk, Happy Miner, and SynthNet. The threat actors behind CherryBlos uploaded the malware to different Google Play regions, such as Malaysia, Vietnam, Indonesia, Philippines, Uganda, and Mexico.[1]
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.1 | Current bundle | 8baf3f59b809… |
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]
Samsung Knox Mobile Threat Defense
Samsung Knox Partner Program. (n.d.). Knox for Mobile Threat Defense. Retrieved March 30, 2022.
Open source URL -
[3]
mitre-attack T1629Open 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.