T1625.001: System Runtime API Hijacking
Adversaries may execute their own malicious payloads by hijacking the way an operating system runs applications. Hijacking execution flow can be for the purposes of persistence since this hijacked execution may reoccur at later points in time.
On Android, adversaries may overwrite the standard OS API library with a malicious alternative to hook into core functions to achieve persistence. By doing this, the adversary’s code will be executed every time the overwritten API function is called by an app on the infected device.
Analyst context for executives and security teams
System Runtime API Hijacking is a mobile Android persistence risk: if an attacker can replace a standard operating system API library with a malicious one, their code can run whenever apps call that API. For leaders, the decision point is whether enterprise Android devices are trusted enough to access business resources, and whether failed integrity or attestation checks actually change access decisions.
Executive priority
Prioritize this where Android devices access enterprise data, identity-protected applications, or regulated workflows. The supplied ATT&CK mitigations point to governance questions executives can act on: are remote attestation and Verified Boot required, are non-compliant devices blocked from enterprise resources, and can compliance teams prove those controls are enforced? This behavior is material because normal app activity can repeatedly trigger malicious code once the runtime library is hijacked, making simple app removal or user action insufficient in some cases.
Technical view
For SOC, mobile security, and IR teams, validate Android-focused coverage for hijacked execution flow rather than only suspicious apps. The ATT&CK description centers on overwriting a standard OS API library with a malicious alternative that hooks core functions for persistence. Relationship context links this sub-technique to Hijack Execution Flow, to prior Modify System Partition context, to detection strategy DET0689, and to Android software examples FlexiSpy, Dvmap, and Zen. Because no official detection text is supplied, teams should map DET0689 to local mobile telemetry and confirm whether system partition integrity, boot state, runtime library integrity, and device attestation results are observable and actionable.
Likely telemetry
- Android device attestation results and attestation failure history
- Verified Boot or system partition integrity status
- MDM/UEM device compliance state and enterprise resource access decisions
- Signals that the bootloader or system partition integrity posture has changed, where available
- File or integrity baselines for standard OS API/runtime libraries, where supported
Detection direction
- Do not assume app-level mobile threat detection is sufficient; validate whether runtime library or system partition integrity changes can be detected.
- Use DET0689 as the ATT&CK-linked detection strategy, but require local documentation of data sources, alert logic, and response actions because the official detection field is not provided.
- Tune triage around high-confidence integrity and attestation failures; these may be more decision-useful than behavioral app alerts for this technique.
- Correlate suspicious Android persistence findings with device compliance, attestation, and enterprise access logs to determine whether the device should remain trusted.
- Account for false positives from legitimate device servicing, development configurations, or unsupported device states, but require documented exception handling.
Mitigation priorities
- Enable remote attestation when available and prohibit devices that fail attestation from accessing enterprise resources, as described by M1002 Attestation.
- Require Android devices to include and enable Verified Boot so the system partition integrity is cryptographically checked, as described by M1004 System Partition Integrity.
- Make attestation and Verified Boot status part of IAM, MDM/UEM, and compliance evidence rather than treating them as optional mobile security signals.
- For incident response, treat failed integrity checks on enterprise Android devices as a containment decision point, not just a device hygiene issue.
Analyst notes and limits
The strongest supported defensive emphasis is device trust: attestation, Verified Boot, system partition integrity, and access control decisions for Android devices. The supplied relationships show known software using this behavior, but this take does not infer current activity, attribution, or customer exposure.
ATT&CK provides no official detection narrative and no tactic value for this object. Telemetry and detection guidance therefore must be validated against the organization’s Android fleet, MDM/UEM capabilities, attestation support, and mobile IR tooling. Only Android is supported by the supplied platform field.
System Runtime API Hijacking
Adversaries may execute their own malicious payloads by hijacking the way an operating system runs applications. Hijacking execution flow can be for the purposes of persistence since this hijacked execution may reoccur at later points in time.
On Android, adversaries may overwrite the standard OS API library with a malicious alternative to hook into core functions to achieve persistence. By doing this, the adversary’s code will be executed every time the overwritten API function is called by an app on the infected 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.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Mobile | T1400 | Modify System Partition | Modify System Partition revoked by this object. |
| Mobile | T1625 | Hijack Execution Flow | This object subtechnique of Hijack Execution Flow. |
Groups, software, and campaigns
S0420: Dvmap
S0494: Zen
S0408: FlexiSpy
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 | 6d61ba372ab1… |
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]
NIST Mobile Threat Catalogue APP-27Open source URL
-
[2]
mitre-attack T1625.001Open 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.