T1629.003: Disable or Modify Tools
Adversaries may disable security tools to avoid potential detection of their tools and activities. This can take the form of disabling security software, modifying SELinux configuration, or other methods to interfere with security tools scanning or reporting information. This is typically done by abusing device administrator permissions or using system exploits to gain root access to the device to modify protected system files.
Analyst context for executives and security teams
This Android technique matters because an attacker who can disable mobile security tools, weaken SELinux, or modify protected system files can reduce the organization’s ability to see and respond to compromise on managed devices. For leaders, the key issue is not only malware prevention; it is whether mobile devices retain trustworthy security posture, reporting, and access-control signals after an attempted compromise.
Executive priority
Prioritize this where Android devices access enterprise email, identity systems, financial applications, regulated data, or operational workflows. Leadership should ask whether device access is conditioned on recent security patch level, whether unsupported devices are decommissioned, whether Verified Boot is required where possible, and whether incident responders can distinguish a healthy endpoint from one where defenses have been impaired. This also supports audit evidence for mobile device hygiene and access governance.
Technical view
ATT&CK lists this as an Android sub-technique of Impair Defenses. The supplied description points to abuse of device administrator permissions, root obtained through system exploits, SELinux configuration changes, and modification of protected system files. SOC and mobile security teams should validate coverage against DET0693 and confirm that MDM/EMM, mobile security tooling, and device health signals can reveal security-tool tampering, rooting/compromise indicators, patch-level gaps, and system partition integrity failures. Related software and campaign relationships show this behavior appears across multiple Android malware families, so detections should focus on the behavior rather than a single family name.
Likely telemetry
- Android device security patch level and update compliance from MDM/EMM or equivalent management tooling
- Device administrator permission grants, changes, or suspicious use affecting security controls
- Mobile security tool health, reporting status, disablement, or configuration-change events
- Rooted or compromised device indicators from built-in, MDM/EMM, or mobile security detection methods
- Verified Boot or system partition integrity status where available
Detection direction
- Because ATT&CK provides no official detection text for this technique, validate the related DET0693 strategy against local Android management and mobile security telemetry.
- Tune for defense-impairment outcomes: security application disabled, reporting stopped, device admin permissions abused, rooted state detected, Verified Boot/integrity failures, or unexpected system configuration changes.
- Correlate tampering indicators with patch-level noncompliance and unsupported devices, since M1001 emphasizes security updates and decommissioning devices without update support.
- Account for false positives from legitimate administration, troubleshooting, device enrollment changes, OS upgrades, or sanctioned security-tool replacement.
- Avoid relying only on application-based mobile security agents; the technique explicitly includes methods that may interfere with scanning or reporting.
Mitigation priorities
- Enforce timely Android security updates and restrict enterprise access for devices without recent patch levels, consistent with M1001.
- Purchase and retain devices with vendor or carrier commitments for prompt security updates; decommission devices that no longer receive them.
- Require and monitor Android Verified Boot or equivalent system partition integrity capability where supported, consistent with M1004.
- Deploy compromised-device detection through built-in device mechanisms, MDM/EMM, mobile security applications, or other enterprise methods, recognizing that some methods may be easier to evade than others.
- Provide user guidance on risky configuration changes and behaviors that could grant excessive permissions or weaken device protections.
Analyst notes and limits
The most decision-useful question is whether mobile trust signals remain reliable after an adversary attempts to impair defenses. This technique is associated in the supplied relationships with multiple Android malware entries and one campaign, but that should be treated as context for prioritizing behavior-based coverage, not as evidence of current exposure in any specific environment.
The object has no ATT&CK tactic listed and no official detection text. The supplied mitigation descriptions are partially truncated in places, so recommendations are limited to the visible official fields and relationships. Local validation is required to determine which Android versions, device models, management tools, and telemetry sources can actually report the relevant integrity, patch, root, and security-tool health signals.
Disable or Modify Tools
Adversaries may disable security tools to avoid potential detection of their tools and activities. This can take the form of disabling security software, modifying SELinux configuration, or other methods to interfere with security tools scanning or reporting information. This is typically done by abusing device administrator permissions or using system exploits to gain root access to the device to modify protected system files.
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
S1214: Android/SpyAgent
Android/SpyAgent is a variant of spyware in the MoqHao phishing campaign primarily targeting Korean and Japanese users.[1] Fake security applications were used to target Japanese users, while fake police applications were used to target Korean users. Both fake applications have common C2 commands and share the same crash report key on a cloud service.[1]
S1054: Drinik
Drinik is an evolving Android banking trojan that was observed targeting customers of around 27 banks in India in August 2021. Initially seen as an SMS stealer in 2016, Drinik resurfaced as a banking trojan with more advanced capabilities included in subsequent versions between September 2021 and August 2022.[1]
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]
S1094: BRATA
BRATA (Brazilian Remote Access Tool, Android), is an evolving Android malware strain, detected in late 2018 and again in late 2021. Originating in Brazil, BRATA was later also found in the UK, Poland, Italy, Spain, and USA, where it is believed to have targeted financial institutions such as banks. There are currently three known variants of BRATA.[1][2][3]
S1061: AbstractEmu
AbstractEmu is mobile malware that was first seen in Google Play and other third-party stores in October 2021. It was discovered in 19 Android applications, of which at least 7 abused known Android exploits for obtaining root permissions. AbstractEmu was observed primarily impacting users in the United States, however victims are believed to be across a total of 17 countries.[1]
S0480: Cerberus
S0422: Anubis
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]
S1195: SpyC23
SpyC23 is a mobile malware that has been used by APT-C-23 since at least 2017. SpyC23 has been observed primarily targeting Android devices in the Middle East.[1]
There are multiple close variants of SpyC23, such as VAMP[2], GnatSpy[3], Desert Scorpion and FrozenCell, which add some additional functionality but are not significantly different from the original malware.
S0420: Dvmap
S0494: Zen
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]
C0033: C0033
C0033 was a PROMETHIUM campaign during which they used StrongPity to target Android users. C0033 was the first publicly documented mobile campaign for PROMETHIUM, who previously used Windows-based techniques.[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 | 94be008b3fbc… |
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]
mitre-attack T1629.003Open 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.