When malware hooks Android system APIs, it can change what the operating system reports to security tools and to apps, so a compromised device looks clean. MITRE ATT&CK for Mobile tracks this as T1617 Hooking, under the Defense Evasion tactic. Hooking normally depends on root access and a root framework such as Xposed or Magisk, or on a virtualisation layer that hosts the target app. This guide explains how the technique shows up, why on-device checks alone are not enough, and how remote attestation, MDM compliance and app vetting expose it. It is for mobile security engineers, app developers in regulated sectors and SOC analysts. For the wider matrix, see the MITRE ATT&CK for Mobile Guide.
Key takeaways
- Android only in ATT&CK. ATT&CK v20 lists T1617 for Android; no iOS procedure is recorded.
- Hooking lies to defenders. FjordPhantom returned false information to detection mechanisms and pretended Google Play Services were unavailable.
- Root or a container is usually required. ATT&CK describes hooking through root frameworks with an exploit or existing root, and FjordPhantom delivered its hooks through a virtualisation solution instead.
- Verify on the server, not the device. Android's key attestation guidance says on-device validation can be fooled if Android on the device is compromised.
- ATT&CK lists two mitigations. M1002 Attestation and M1010 Deploy Compromised Device Detection Method, because both can often detect rooted devices.
What T1617 is
ATT&CK describes hooking as altering the return values or data structures of system APIs and function calls to hide artefacts and evade detection. The usual route is a third-party root framework, such as Xposed or Magisk, used with a system exploit or existing root access, with custom modules that hook system APIs to change how parts of the system behave or appear.
The enterprise counterparts are T1574 Hijack Execution Flow and T1014 Rootkit. See the T1574 Hijack Execution Flow Defensive Guide and the Rootkits and Bootkits Guide. On mobile, the related techniques are T1670 Virtualization Solution, which can host an app and inject a hooking framework into it, and T1631 Process Injection.
Platform scope
ATT&CK v20 lists Android as the only platform. On iOS, Apple's platform security guide describes executable memory restrictions: writable and executable pages are limited to apps with an Apple-only dynamic code-signing entitlement, and entitlements are digitally signed so they cannot be changed. ATT&CK records no iOS hooking procedure, so this page does not describe one.
Real cases from ATT&CK procedure examples
| Software | Hooking behaviour recorded by ATT&CK | Context |
|---|---|---|
| FjordPhantom (S1208) | Injected malicious code and a hooking framework into the hosted app's process through a virtualisation solution; returned false information to detection mechanisms, pretended Google Play Services were unavailable, and manipulated UI functionality | Android malware first discovered in September 2024, targeting Indonesia, Thailand and Vietnam, distributed through email and messaging apps |
| GodFather (S1231) | Used the Xposed hooking framework to intercept HTTP requests and responses, capturing and exfiltrating sensitive information such as credentials | Android banking malware that uses virtualisation to mimic legitimate apps; first identified in 2020 |
| Monokle (S0407) | Hooks itself to appear invisible to the Process Manager | Targeted Android surveillanceware |
The pattern matters for app owners: FjordPhantom and GodFather did not need to break the banking app itself. They ran it inside an environment they controlled and hooked the APIs the app used to check its own safety. See the Android Banking Trojans Guide.
Why on-device checks fall short
Root detection, emulator detection and integrity checks that run on the device ask the operating system questions. If the operating system's answers are hooked, the checks return whatever the attacker chooses. OWASP's MASVS-RESILIENCE category frames these runtime controls as defence in depth that helps an app confirm it runs on a trusted platform, and states that anti-tampering must not substitute for sound security architecture with server-side validation. The design rule follows: produce evidence on the device, judge it on the server.
Detection: signals that survive hooking
| Signal | Source | What it shows |
|---|---|---|
Play Integrity deviceIntegrity labels | Play Integrity API, verdict decrypted and checked server-side | MEETS_STRONG_INTEGRITY (on Android 13 and later, hardware-backed signals and a recent security patch) and MEETS_DEVICE_INTEGRITY indicate a genuine certified device; missing labels raise risk |
Play Integrity appRecognitionVerdict | Play Integrity API | PLAY_RECOGNIZED means Play recognises the signing certificate and the binary is unmodified |
Play Integrity appAccessRiskVerdict | Play Integrity API (opt-in) | Other apps that can capture the screen, draw overlays or control the device |
| Key attestation root of trust | Hardware-backed key attestation, chain validated on a server | Attestation reports bootloader lock state and verified boot state; an unlocked bootloader or unverified boot is a strong risk signal |
| MTD and MDM compliance | MTD agent, Android Enterprise compliance | Root framework artefacts, unknown apps, failed attestation |
| Dynamic analysis | App vetting sandbox | App process loading external modules or native libraries from non-system paths into the zygote or app_process runtime (ATT&CK DET0719) |
Key attestation details that matter
- Validate off the device: Android's guidance says to verify on a separate server, because on-device validation can be fooled if the device is compromised.
- Check the root and revocation: the chain must end in a Google attestation root, and every certificate must be checked against the revocation status list.
- Check the security level:
attestationSecurityLevelmust beTrustedEnvironmentorStrongBox; software attestation can be forged. - Read the first extension only: only the first occurrence of the attestation extension in the chain is trustworthy.
Attestation proves boot and hardware state, not the absence of malware. A device with a locked bootloader can still run a malicious virtualisation app, which is why the appAccessRiskVerdict, MTD app scanning and app vetting are needed alongside it. See Mobile App Attestation.
Prevention
- Keep verified boot intact: Android Verified Boot builds a chain of trust from a hardware root of trust through the bootloader to the system partitions, with rollback protection. MDM compliance should block devices with unlocked bootloaders from corporate data.
- Block rooted and failed-attestation devices: ATT&CK M1002 recommends prohibiting devices that fail attestation from accessing enterprise resources.
- Deploy compromised device detection: ATT&CK M1010 covers MTD apps and MDM capabilities that flag rooted devices, noting some methods are trivial to evade and others more sophisticated.
- Restrict app sources: block unknown sources so virtualisation apps carrying hooking frameworks cannot be sideloaded.
- Design apps for a hostile device: keep decisions server-side, require attestation for sensitive actions, and treat client-side checks as signals. See Rooted, jailbroken and emulated devices.
How to implement
- Measure first. Collect Play Integrity verdicts or key attestation results for all sessions in report-only mode and see what share of real users fall into each tier.
- Set tiered policy. Android advises tiered enforcement because fewer devices reach the top labels. For example: require
MEETS_DEVICE_INTEGRITYfor login andMEETS_STRONG_INTEGRITYfor high-value payments. - Enable MDM compliance rules. Mark rooted, unlocked or failed-attestation devices non-compliant and remove access to corporate apps through conditional access.
- Add vetting rules. Flag apps that bundle hooking frameworks or host other apps in a virtual container.
- Roll out by ring. Pilot with staff devices, then a small share of customers; track false positives from custom ROMs and older devices.
- Plan rollback. Keep a server-side flag to drop enforcement to report-only if verdict outages or false positives hit legitimate users.
Decision guidance
- Corporate managed devices: enforce attestation and compliance strictly; there is little legitimate need for root.
- Consumer banking and payment apps: use tiered verdicts and step-up rather than blanket blocks, because MASVS notes platform-specific checks can exclude legitimate users on other Android flavours.
- Public-interest apps: MASVS suggests favouring verifiable design and server-side validation over heavy anti-tampering where transparency matters.
Where identity fits
GodFather's Xposed hooks captured credentials from HTTP traffic. The same position lets hooked malware read OAuth access tokens, refresh tokens and API keys inside the app process. Bind tokens to hardware-backed keys, keep them short-lived, and require attestation before issuing them. See the Mobile Access Credentials guide.
Metrics that show it is working
- Share of sensitive API calls with a valid server-verified integrity verdict.
- Managed devices non-compliant for root, unlocked bootloader or failed attestation, and time to remediate.
- Sessions with
appAccessRiskVerdictrisk flags, tracked by week. - False positive rate for integrity-based blocks among customers.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK for Mobile | T1617 Hooking; DET0719; M1002 Attestation; M1010 Deploy Compromised Device Detection Method | Technique, detection strategy and listed mitigations |
| NIST CSF 2.0 | DE.CM-09, PR.PS-05 | Monitoring runtime environments; preventing unauthorised software |
| NIST SP 800-53 Rev 5 | SI-7, AC-19, SI-4 | Software and information integrity, mobile device access control, monitoring |
| ISO/IEC 27001:2022 Annex A | A.8.1, A.8.7 | User endpoint devices, protection against malware |
| OWASP MASVS | MASVS-RESILIENCE | Trusted platform checks and tamper detection |
Common failure patterns
- Client-side root check as the only control: hooks can make the check return clean.
- Verifying attestation on the device: a compromised OS can fool local validation.
- Ignoring virtualisation apps: a locked, unrooted device can still host a container app that hooks the target app.
- All-or-nothing enforcement: requiring the strongest label everywhere locks out legitimate older devices and pushes teams to switch checks off.
- Accepting software attestation: software-backed attestation uses a key in public AOSP source and can be forged.
Practitioner checklist
- Verify Play Integrity or key attestation on the server, never in the app.
- Reject attestation chains that do not end in a Google root or that include revoked certificates.
- Require
TrustedEnvironmentorStrongBoxsecurity level. - Mark rooted or unlocked devices non-compliant in MDM.
- Opt in to
appAccessRiskVerdictfor high-risk customer apps. - Flag virtualisation and hooking frameworks in app vetting.
- Bind tokens to hardware-backed keys and keep them short-lived.
Standards and references
- MITRE ATT&CK: T1617 Hooking
- Android Developers: Verify hardware-backed key pairs with key attestation
- Android Developers: Play Integrity API overview
- Android Open Source Project: Verified Boot
- Apple Platform Security: Runtime process security
- OWASP: Mobile Application Security Verification Standard
Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Mobile App Attestation · Rooted, jailbroken and emulated devices · Mobile App Shielding and RASP Buyers Guide · Mobile Threat Defense Buyer's Guide · Mobile T1670 Virtualization Solution · Mobile T1631 Process Injection · Mobile T1629 Impair Defenses