Mobile T1625 Hijack Execution Flow on Android

When malware replaces an Android system library or framework file, its code runs every time any app calls the hijacked function, and an ordinary uninstall will not remove it. MITRE ATT&CK for Mobile records this as T1625 Hijack Execution Flow, a Persistence technique with one sub-technique, T1625.001 System Runtime API Hijacking. ATT&CK v20 lists the technique for Android only, and every procedure example depends on write access to protected system locations, which in practice means a rooted or otherwise compromised device. This guide covers how the technique works, which platform controls stop it, how to detect a tampered device through attestation and integrity verdicts, and how to respond. It is for mobile security engineers, MDM and MTD administrators and incident responders. For the wider matrix, see the MITRE ATT&CK for Mobile Guide.

Key takeaways

It needs a compromised system partition. ATT&CK examples (Dvmap, Zen, FlexiSpy) all modify files under /system, which Android Verified Boot is designed to protect.
Attestation is the main control. ATT&CK maps T1625 to M1002 Attestation and M1004 System Partition Integrity: check device integrity remotely rather than trusting the device to report on itself.
Cleaning in place is unreliable. A device whose system image has been altered should be reflashed with a factory image or replaced, not just have an app removed.
Your own apps can open a smaller version of the hole. Loading code from writable storage is the app-level hijack vector MITRE's detection strategy highlights; Android 14 requires dynamically loaded files to be read-only.
iOS is not listed. ATT&CK does not record T1625 for iOS; iOS system integrity is covered by Apple's boot chain and is not addressed here.

What T1625 is

ATT&CK defines Hijack Execution Flow as running malicious payloads by hijacking the way the operating system runs applications: manipulating how it locates programs or libraries, or poisoning the locations it searches. On mobile, the single sub-technique is the system runtime case.

T1625.001 System Runtime API Hijacking: per ATT&CK, an adversary overwrites a standard OS API library with a malicious alternative to hook core functions. The adversary's code then runs whenever any app on the device calls the overwritten function. This gives persistence and, often, the ability to observe or alter what every app sees.

Procedure examples from ATT&CK

Software	Behaviour recorded by ATT&CK v20	Precondition
Dvmap (S0420)	Replaces `/system/bin/ip`; injects code by patching `libdmv.so` or `libandroid_runtime.so` depending on OS version	Write access to the system partition
Zen (S0494)	Installs itself on the system partition and can replace `framework.jar` to intercept and modify standard Android API behaviour	Write access to the system partition
FlexiSpy (S0408)	Installs boot hooks into `/system/su.d`; uses root to set reboot hooks	Root access
YiSpecter (S0311)	Hijacked normal application launch routines to display ads (parent technique)	As recorded at technique level

T1625.001 replaced the older Mobile technique T1400 Modify System Partition, which ATT&CK now marks as revoked. Older threat reports may use the T1400 ID.

Platform controls that block system tampering

Android Verified Boot (AVB): per the Android Open Source Project, Verified Boot builds a chain of trust from a hardware-protected root of trust through the bootloader, boot partition and verified partitions such as system and vendor, checking each stage before running it. Android 7.0 began strictly enforcing it so compromised devices cannot boot, and Android 8.0 introduced AVB with rollback protection, so a device cannot be downgraded to an older vulnerable build to keep an exploit. ATT&CK maps this to M1004 System Partition Integrity.
Locked bootloader: Verified Boot only protects a device whose bootloader is locked. Developer or test devices with unlocked bootloaders should never hold corporate data.
Security updates and recent OS (our recommendation; ATT&CK maps these to the exploit precondition, not to T1625): system partition writes almost always follow a privilege escalation exploit; patched devices remove the known paths.
Managed device policy: on Android Enterprise fully managed devices, block developer options and USB debugging, and restrict app sources. See the Android Enterprise Security Guide and Android Platform Tools and ADB.

Detection: attestation and integrity verdicts

A tampered device cannot be trusted to report that it is tampered, so detection relies on attestation that is rooted in hardware and checked on a server (M1002 Attestation). The Play Integrity API is one widely used source.

Play Integrity verdict	Meaning (Android Developers)	Suggested response
`MEETS_STRONG_INTEGRITY`	Genuine certified device with a security update in the last year (Android 13 and later)	Full access for high-risk apps
`MEETS_DEVICE_INTEGRITY`	Genuine certified device; on Android 13 and later, hardware-backed proof that the bootloader is locked and the OS is a certified image	Normal access
`MEETS_BASIC_INTEGRITY` only	Passes basic checks; bootloader may be unlocked and the device may not be certified	Restrict sensitive data and tokens
No label (empty)	Signs of attack such as API hooking, system compromise such as root, or not a physical device	Block and investigate

MITRE's detection strategy for T1625.001 (DET0689) places most detection in app vetting and controlled analysis: multiple apps seeing inconsistent or altered results from core system APIs is the runtime sign of a hooked framework. The parent strategy (DET0694) also flags apps loading executables or libraries from writable locations such as external storage, app cache or /data/local/tmp/.

MDM and MTD signals: root or compromised-device flags, unexpected changes in OS build fingerprint, and integrity verdict changes over time.
Forensics: for a suspected targeted device, use consensual acquisition and review with MVT. See the Mobile Verification Toolkit (MVT) and the Mobile Forensics Guide.

Metrics

Percentage of managed devices returning MEETS_DEVICE_INTEGRITY or stronger at each check.
Number of devices with an unlocked bootloader or developer options enabled.
Percentage of devices within the vendor's security update window.
Median time from a failed integrity verdict to access removal.
Number of in-house apps that load code dynamically, with a documented exception for each.

Securing your own apps against library hijacking

App teams cannot stop a rooted device being rooted, but they can avoid making hijacking easier and can react when integrity fails.

Avoid dynamic code loading: Android's Android 14 behaviour changes require that, for apps targeting API 34 or higher, all dynamically loaded files are marked read-only, and recommend avoiding dynamic code loading where possible because it raises the risk of code injection.
Never load from writable shared storage: ship native libraries inside the signed APK. See APK Signing.
Check integrity on the server: request a Play Integrity token for sensitive actions and verify it server-side, checking requestDetails (package, nonce, timestamp) first. See Mobile App Attestation.
Follow MASVS-RESILIENCE: OWASP MASVS treats platform integrity checks as defence in depth that supports, but never replaces, the rest of the standard.

Response: step by step

Contain: remove the device from conditional access and revoke its sessions as soon as an integrity verdict fails.
Preserve evidence if a targeted attack is suspected: take a consensual acquisition before any reset. See the Mobile Spyware Infection Response Playbook.
Revoke credentials: rotate OAuth refresh tokens, MDM enrolment certificates, VPN and Wi-Fi certificates and any API keys stored by managed apps.
Restore: reflash a factory image from the manufacturer or replace the device; confirm the bootloader is locked afterwards.
Verify: re-enrol, confirm MEETS_DEVICE_INTEGRITY or stronger, then restore access.
Learn: record how the device lost integrity (sideloaded app, unpatched OS, developer mode) and adjust policy.

Where identity fits

A hooked framework sees what every app sees, including tokens in memory and credentials typed into login screens. Treat a device that has lost system integrity as a full credential compromise for every identity on it, human and machine. See the Mobile Access Credentials guide.

Framework mapping

Framework	Reference	Relevance
ATT&CK for Mobile	M1002 Attestation, M1004 System Partition Integrity, M1001 Security Updates, M1006 Use Recent OS Version	Mitigations ATT&CK maps to T1625 and its exploit preconditions
NIST SP 800-53 Rev 5	SI-7 Software, Firmware, and Information Integrity; SI-2 Flaw Remediation; AC-19 Access Control for Mobile Devices	Integrity verification, patching, mobile access conditions
NIST CSF 2.0	PR.PS-02, DE.CM-09	Maintain software, monitor runtime environments
CIS Controls v8.1	Control 4 Secure Configuration, Control 7 Continuous Vulnerability Management	Locked bootloader, patch levels
OWASP MASVS	MASVS-RESILIENCE, MASVS-CODE	App-side integrity checks and safe code loading

Common failure patterns

Trusting on-device root checks alone: hooked frameworks can return false results to the app that asks; verify attestation on the server.
Uninstalling and moving on: system partition changes survive app removal, so do not rely on uninstalling; follow the device maker's guidance on reflashing a verified factory image.
Allowing basic integrity for sensitive apps: MEETS_BASIC_INTEGRITY alone permits unlocked bootloaders.
Developer devices with production access: unlocked test phones end up holding corporate tokens.
Not rotating machine credentials: certificates and API keys on the device remain valid after the phone is replaced.

Practitioner checklist

Require a locked bootloader and Verified Boot on every managed Android device.
Gate sensitive apps on server-verified MEETS_DEVICE_INTEGRITY or MEETS_STRONG_INTEGRITY.
Block developer options and USB debugging through MDM on corporate devices.
Enforce a minimum patch level and retire devices outside the update window.
Remove dynamic code loading from in-house apps or mark loaded files read-only.
Reflash or replace, never just clean, a device with system partition changes.
Rotate every token, certificate and key the device held after confirmed tampering.

Mobile T1625 Hijack Execution Flow: Detecting System Partition Tampering on Android