T1617: Hooking
Adversaries may utilize hooking to hide the presence of artifacts associated with their behaviors to evade detection. Hooking can be used to modify return values or data structures of system APIs and function calls. This process typically involves using 3rd party root frameworks, such as Xposed or Magisk, with either a system exploit or pre-existing root access. By including custom modules for root frameworks, adversaries can hook system APIs and alter the return value and/or system data structures to alter functionality/visibility of various aspects of the system.
Analyst context for executives and security teams
Hooking matters because it can make a compromised Android device lie about what is happening on it. By using root frameworks such as Xposed or Magisk, malware or surveillanceware can change system API responses and data structures so security tools, enterprise apps, or users see a cleaner device state than reality. For executives, the practical issue is trust: mobile access decisions, fraud controls, and incident triage may be based on device signals that an attacker is actively manipulating.
Executive priority
Prioritize this where Android devices access enterprise email, identity portals, financial workflows, regulated data, or operational systems. The business question is whether mobile trust decisions depend only on local device checks that hooking can tamper with, or whether stronger attestation and compromised-device detection are enforced before access is granted. This technique also affects audit and compliance evidence because a device may appear compliant while local APIs have been manipulated.
Technical view
ATT&CK lists this as an Android mobile technique with no official tactic or detection text provided. SOC, mobile security, and IR teams should validate coverage around rooted or otherwise compromised Android devices, presence or abuse of root frameworks such as Xposed or Magisk, and discrepancies between device-reported state and remote attestation or EMM/MDM posture. Relationship context identifies DET0719, Detection of Hooking, as a detection strategy, and mitigations M1002 Attestation and M1010 Deploy Compromised Device Detection Method. Related Android software using this behavior includes Monokle, FjordPhantom, and GodFather, which makes the technique relevant to mobile surveillanceware and banking-malware investigation scenarios without implying current exposure in any environment.
Likely telemetry
- Android device posture and compliance status from EMM/MDM or mobile security tooling
- Remote attestation results, where available, such as SafetyNet or Samsung Knox TIMA Attestation as referenced by ATT&CK mitigation guidance
- Root or jailbreak indicators, including evidence of Xposed, Magisk, or similar root frameworks
- Mobile application inventory and suspicious installed package/module information
- Enterprise access logs showing mobile device identity, posture result, and access decision
Detection direction
- Confirm whether DET0719-aligned hooking detection is implemented or mapped in the mobile detection program; ATT&CK does not provide official detection details for this technique.
- Do not rely solely on device-local API responses for compliance or compromise decisions, because hooking is specifically intended to alter return values and visibility.
- Correlate local device posture with remote attestation, EMM/MDM state, identity access logs, and mobile security alerts to find inconsistent or suspicious device trust signals.
- Tune for false positives from legitimate rooted test devices, developer devices, sanctioned research tooling, or enterprise-approved mobile testing environments.
- Review whether mobile malware investigations for related software families such as Monokle, FjordPhantom, or GodFather include checks for hooking, virtualization, root frameworks, and manipulated UI or device-state evidence where supported by case data.
Mitigation priorities
- Enable remote attestation where available and prohibit devices that fail attestation from accessing enterprise resources, consistent with M1002.
- Deploy compromised-device detection capabilities through built-in device mechanisms, mobile security applications, EMM/MDM, or other enterprise methods, consistent with M1010.
- Use conditional access policies so sensitive enterprise resources require trustworthy device posture rather than unenforced or local-only checks.
- Define an exception process for rooted or developer Android devices so business-approved cases do not weaken production access controls.
- Include mobile device trust, attestation failure handling, and evidence preservation in incident response playbooks.
Analyst notes and limits
The key defensive value is not simply detecting a hook; it is deciding whether the organization can still trust Android device posture signals when malware may be manipulating local APIs. This technique should be reviewed with identity, mobile security, SOC, fraud, and compliance stakeholders because it can affect both access decisions and the reliability of investigation evidence.
The supplied ATT&CK object has no official detection text, no specified tactics, and only Android is listed as a platform. This take is limited to the provided ATT&CK fields, external reference, and relationships. Local device fleet architecture, EMM/MDM configuration, attestation availability, and mobile logging maturity are required to determine actual exposure or detection coverage.
Hooking
Adversaries may utilize hooking to hide the presence of artifacts associated with their behaviors to evade detection. Hooking can be used to modify return values or data structures of system APIs and function calls. This process typically involves using 3rd party root frameworks, such as Xposed or Magisk, with either a system exploit or pre-existing root access. By including custom modules for root frameworks, adversaries can hook system APIs and alter the return value and/or system data structures to alter functionality/visibility of various aspects of the system.
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
S0407: Monokle
S1231: GodFather
GodFather is an Android banking malware that uses virtualization to mimic legitimate applications and abuses accessibility services and other permissions to evade detection and exfiltrate sensitive data. First identified in 2020, GodFather targets nearly 500 banking applications, cryptocurrency wallets, and exchanges worldwide; however, its virtualization-based attacks have primarily focused on several Turkish financial institutions. This capability enables threat actors to steal banking credentials and other sensitive account information. [1][2]
S1208: FjordPhantom
FjordPhantom is a malicious Android application first discovered in September 2024 with targets in Southeast Asia, specifically Indonesia, Thailand, and Vietnam. FjordPhantom was distributed through email and messaging applications. Once installed, the application launches a virtualization solution to steal important information, such as bank accounts, and to manipulate the user interface. The malicious activity from the virtualization solution runs alongside legitimate banking applications.[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.0 | Current bundle | a1f0d1658047… |
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 T1617Open 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.