T1645: Compromise Client Software Binary
Adversaries may modify system software binaries to establish persistent access to devices. System software binaries are used by the underlying operating system and users over adb or terminal emulators.
Adversaries may make modifications to client software binaries to carry out malicious tasks when those binaries are executed. For example, malware may come with a pre-compiled malicious binary intended to overwrite the genuine one on the device. Since these binaries may be routinely executed by the system or user, the adversary can leverage this for persistent access to the device.
Analyst context for executives and security teams
T1645 matters because it describes tampering with core mobile client/system binaries on Android or iOS so that malicious code runs whenever those trusted binaries are executed. For leaders, the practical issue is device trust: if the operating system components themselves may be modified, normal app-centric controls and user behavior training are not enough. Enterprise access decisions should depend on device integrity signals, update status, and whether compromised or unsupported mobile devices can reach sensitive resources.
Executive priority
Prioritize this where mobile devices access executive communications, regulated data, privileged workflows, or operational systems. The business question is not only “do we have mobile malware protection,” but “can we prove device integrity before allowing enterprise access?” ATT&CK links this technique to mitigations around security updates, attestation, locked bootloaders, and Android Verified Boot/system partition integrity, making it relevant to mobile access policy, compliance evidence, incident response scoping, and lifecycle decisions for devices that no longer receive prompt security updates.
Technical view
This is a mobile ATT&CK technique for Android and iOS. MITRE does not provide tactic mapping or detection text for this object, so SOC and IR teams should validate controls through the related detection strategy DET0712 and the listed mitigations rather than assume log-based coverage. Defensive validation should focus on whether mobile device posture data can identify failed attestation, unlocked bootloaders where applicable, missing security patch levels, disabled or unavailable verified boot/system partition integrity protections, and anomalous replacement or execution of trusted system binaries when such telemetry is available.
Likely telemetry
- Mobile device management or enterprise mobility inventory showing OS version, security patch level, device model, and support status
- Remote attestation results where available, including pass/fail integrity posture
- Bootloader lock state checks for devices that expose this capability
- Android Verified Boot or system partition integrity status where available
- Mobile security product alerts or forensic artifacts related to modified system/client binaries
Detection direction
- Confirm whether DET0712 or equivalent internal detection logic is implemented; the ATT&CK object names a related detection strategy but provides no detailed detection text here.
- Do not rely only on app installation telemetry; this behavior concerns modified system/client binaries that may execute routinely outside normal app review visibility.
- Tune posture-based detections around attestation failure, unlocked bootloader state, unsupported patch level, and integrity-check failure before treating binary compromise as directly observable in routine SOC logs.
- Use relationship context to inform threat hunting for Android and iOS mobile malware families that MITRE maps to this technique, but avoid assuming any specific family without local evidence.
- Account for false positives and operational exceptions such as test devices, rooted/jailbroken research devices, or unsupported legacy devices; those should be explicitly segmented or denied enterprise access rather than silently accepted.
Mitigation priorities
- Maintain security update requirements and remove or restrict enterprise access for devices that cannot receive or have not installed recent security updates.
- Enable remote attestation where available and block access from devices that fail attestation.
- Periodically verify bootloader lock state on devices that support bootloader unlocking.
- For Android, require devices that include and enable Verified Boot/system partition integrity protections where feasible.
- Tie mobile compliance posture to access control decisions so a device integrity failure becomes an enforceable business control, not just an advisory alert.
Analyst notes and limits
MITRE maps this technique to Android and iOS and describes persistence through modified system software binaries. Relationship context includes multiple Android software examples and Pegasus variants for Android and iOS, plus mitigations M1001, M1002, M1003, and M1004. The strongest defensive value is in device trust enforcement: patch currency, attestation, bootloader state, and verified system partition integrity.
Official detection guidance is not provided in the supplied ATT&CK fields, and tactics are not specified. The related detection strategy DET0712 is named but not described here. Local mobile management, attestation, access control, and forensic telemetry determine whether this behavior can be detected or only mitigated through posture enforcement.
Compromise Client Software Binary
Adversaries may modify system software binaries to establish persistent access to devices. System software binaries are used by the underlying operating system and users over adb or terminal emulators.
Adversaries may make modifications to client software binaries to carry out malicious tasks when those binaries are executed. For example, malware may come with a pre-compiled malicious binary intended to overwrite the genuine one on the device. Since these binaries may be routinely executed by the system or user, the adversary can leverage this for persistent access to the device.
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.
Groups, software, and campaigns
S0655: BusyGasper
BusyGasper is Android spyware that has been in use since May 2016. There have been less than 10 victims, all who appear to be located in Russia, that were all infected via physical access to the device.[1]
S0293: BrainTest
S0294: ShiftyBug
S0550: DoubleAgent
DoubleAgent is a family of RAT malware dating back to 2013, known to target groups with contentious relationships with the Chinese government.[1]
S0289: Pegasus for iOS
Pegasus for iOS is the iOS version of malware that has reportedly been linked to the NSO Group. It has been advertised and sold to target high-value victims.[1][2] The Android version is tracked separately under Pegasus for Android.
S0324: SpyDealer
S0407: Monokle
S0316: Pegasus for Android
Pegasus for Android is the Android version of malware that has reportedly been linked to the NSO Group. [1] [2] The iOS version is tracked separately under Pegasus for iOS.
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 | f7d7e2b660c4… |
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]
Android-VerifiedBoot
Android. (n.d.). Verified Boot. Retrieved December 21, 2016.
Open source URL -
[2]
NIST Mobile Threat Catalogue APP-27Open source URL
-
[3]
mitre-attack T1645Open 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.