Mobile T1645 Compromise Client Software Binary: Detecting and Removing System Level Persistence

When mobile malware writes itself into the system partition, a factory reset may not remove it and normal app management tools may not even list it. ATT&CK for Mobile v20 tracks this as Compromise Client Software Binary (T1645), a Persistence (TA0028) technique on Android and iOS: the adversary modifies or replaces system software binaries, or plants an app in a protected system location, so that it runs whenever the system or user runs them. It almost always follows privilege escalation through an exploit or existing root access. This page is for mobile security engineers, MDM administrators and incident responders: what the technique looks like, the procedure examples ATT&CK records, the platform integrity features that defeat it, how to detect a modified device and what recovery really requires. For the wider matrix, see the MITRE ATT&CK for Mobile Guide.

Key takeaways

• It needs root or an exploit first. Every ATT&CK v20 procedure example either abuses existing root access or exploits the device to gain it, so patch currency is the first control.
• Verified boot is the main barrier. Android Verified Boot and Apple's signed system volume check system code against a manufacturer signature, and ATT&CK maps Lock Bootloader (M1003) and System Partition Integrity (M1004) to this technique.
• Attestation tells you, remotely, when the barrier is gone. Device attestation (M1002), such as Play Integrity device verdicts or MDM compliance checks, flags devices with unlocked bootloaders or uncertified images.
• Factory reset is not always enough. ATT&CK records BrainTest copying an APK to /system/priv-app to survive a factory reset; recovery means reflashing a signed image or replacing the device.
• Android and iOS both appear. Pegasus for iOS and Pegasus for Android both modify the system partition, so this is not only an Android problem.

What T1645 is

ATT&CK describes system software binaries as those used by the operating system and by users over adb or terminal emulators. Adversaries modify these client software binaries to carry out malicious tasks when they run; for example, malware may ship a pre-compiled malicious binary intended to overwrite the genuine one. Because the system or user runs these binaries routinely, the change gives persistent access. The technique has no sub-techniques in v20. Its enterprise counterpart is T1554 Compromise Host Software Binary.

Two patterns appear in the procedure examples: replacing or modifying an existing system binary, and installing an additional app package into a system location such as /system/priv-app so that it gains system app status and resists removal.

Real cases from ATT&CK v20

Monokle's certificate installation matters beyond persistence: a certificate in the system trust store lets the adversary intercept TLS traffic from apps that trust system certificates, which ties T1645 to adversary-in-the-middle activity.

Platform integrity features

Android

• Android Verified Boot: builds a chain of trust from a hardware-protected root of trust through the bootloader to the boot partition and other verified partitions, including system and vendor. Each stage checks the next before handing over control. Since Android 7.0 Verified Boot is strictly enforced, so a compromised device is stopped from booting rather than only warned.
• Rollback protection: Verified Boot allows updates only to newer versions, which stops an adversary from keeping an exploit alive by reverting to an older vulnerable build.
• Locked bootloader: the root of the chain. An unlocked bootloader lets a user or attacker flash an unsigned system image. ATT&CK maps M1003 Lock Bootloader to T1645.

iOS and iPadOS

• Signed system volume (SSV): on iOS 15 and iPadOS 15 or later the system volume is protected by a cryptographic seal. Each file's data is hashed with SHA-256 when read, the hashes roll up to a root hash (the seal) signed by Apple, and data that does not match is not returned. A mismatch at boot prompts the user to update the system software, and users cannot turn SSV off on these platforms.
• Exploit chains still matter: Pegasus for iOS shows that a capable adversary can reach the system partition, so the controls that keep exploitation hard (current OS, Lockdown Mode for high-risk users) are part of the defence. See the Apple Lockdown Mode Guide.

Mitigations ATT&CK maps to T1645

MEETS_DEVICE_INTEGRITY indicates a genuine, certified Android device; on Android 13 and later it carries hardware-backed proof of a locked bootloader and a certified manufacturer OS image. MEETS_STRONG_INTEGRITY adds security updates within the last year for all partitions. MEETS_BASIC_INTEGRITY only means basic checks passed and the bootloader may be unlocked, so it is not sufficient evidence against T1645. App developers can use the same verdicts in their own backends; see Mobile App Attestation.

Detection

ATT&CK v20's detection strategy for T1645 is evidence based rather than real time. On Android it correlates file hash changes for system binaries against a known-good baseline, writes to system binary paths by processes that are not trusted update sources, and management or vetting evidence, treating state queries as periodic observations. On iOS it correlates an MDM integrity check failure on a supervised device following jailbreak detection, Apple MDM DeviceInformation and SecurityInfo queries, and network flow metadata.

MVT, maintained by Amnesty International's Security Lab and contributors, supports analysis of iOS backups, filesystem dumps and sysdiagnose files and of Android backups. See the Mobile Forensics Guide.

Response and recovery

1. Isolate. Mark the device non-compliant so conditional access blocks corporate apps, and remove it from Wi-Fi networks that trust device certificates.
2. Preserve evidence before wiping. Take a backup or sysdiagnose under the consent process; once reflashed, system partition evidence is gone. Follow the Mobile Spyware Infection Response Playbook.
3. Revoke what the device held. Device certificates, VPN profiles, app tokens and any service credentials provisioned through MDM.
4. Restore a signed image. Because system partition persistence can survive a factory reset, reinstall the manufacturer-signed OS (on iOS, a restore that reinstalls the OS; on Android, the OEM's signed factory image with the bootloader relocked), or replace the device.
5. Re-enrol and re-attest. Only return the device to service after attestation passes at the required level.
6. Look sideways. Check other devices of the same model and OS version for the same exploit path.

Where identity fits

A device with a modified system partition can read anything the OS can, including tokens, client certificates and keys held by enterprise apps. Device and app attestation are machine identity checks: they let a backend decide whether to trust a device's claims. Bind high-value tokens to hardware-backed keys where the platform supports it, gate token issuance on attestation, and treat a T1645 finding as a compromise of every credential provisioned to that device. See the Mobile Device Management Security Guide for protecting the MDM service credentials that push those certificates.

How to implement

1. Set the baseline. Define the minimum attestation level per data class (for example MEETS_DEVICE_INTEGRITY for email, MEETS_STRONG_INTEGRITY for privileged tools).
2. Measure first. Report attestation results across the fleet for two to four weeks without blocking, to find old or uncertified models.
3. Replace, then enforce. Retire devices that cannot pass, then switch the compliance rule to block.
4. Test the response path. Run a tabletop that ends in a reflash and token revocation, and time it.
5. Roll back narrowly. If a model fails unexpectedly after an OEM update, grant a time-boxed exception for that model rather than lowering the global level.

Measuring it

• Percentage of managed Android devices passing MEETS_DEVICE_INTEGRITY.
• Percentage of iOS and Android devices on a supported OS within the patch window.
• Number of devices with unlocked bootloaders or failed integrity checks, and their time to quarantine.
• Time from integrity failure to credential revocation.

Common failure patterns

• Accepting MEETS_BASIC_INTEGRITY as proof. It allows unlocked bootloaders, so it does not rule out a modified system.
• Factory reset as the fix. System partition persistence, as with BrainTest, can survive it.
• Keeping end-of-support devices. No security updates means the exploit used to gain root stays open.
• Allowing developer or custom-ROM devices into production access. They fail the very checks that detect this technique.
• Wiping before evidence capture. The team loses the ability to confirm scope and lateral exposure.

Framework mapping

Practitioner checklist

• Require a locked bootloader and certified OS image on every corporate Android device.
• Gate corporate access on MEETS_DEVICE_INTEGRITY or stronger, not basic integrity.
• Enforce minimum OS and patch levels; retire unsupported models.
• Alert on jailbreak or integrity check failure on supervised iOS devices.
• Inventory system trust certificates and privileged apps against the OEM baseline.
• Capture evidence before wiping, under a consent-based process.
• Recover with a signed OS image, not only a factory reset.
• Revoke device certificates and tokens on any integrity failure.

Standards and references

• MITRE ATT&CK: Compromise Client Software Binary, Mobile T1645
• Android Open Source Project: Verified Boot
• Apple Platform Security: Signed system volume security
• Android Developers: Play Integrity API integrity verdicts
• MITRE ATT&CK: Attestation, Mobile M1002
• Mobile Verification Toolkit documentation
• NIST: SP 800-53 Rev 5 Security and Privacy Controls

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Android Enterprise Security Guide · iOS and iPadOS Enterprise Security Guide · Mobile Malware Guide