CAPEC-660
Root/Jailbreak Detection Evasion via Hooking
An adversary forces a non-restricted mobile application to load arbitrary code or code files, via Hooking, with the goal of evading Root/Jailbreak detection. Mobile device users often Root/Jailbreak their devices in order to gain administrative control over the mobile operating system and/or to install third-party mobile applications that are not provided by authorized application stores (e.g. Google Play Store and Apple App Store). Adversaries may further leverage these capabilities to escalate privileges or bypass access control on legitimate applications. Although many mobile applications check if a mobile device is Rooted/Jailbroken prior to authorized use of the application, adversaries may be able to "hook" code in order to circumvent these checks. Successfully evading Root/Jailbreak detection allows an adversary to execute administrative commands, obtain confidential data, impersonate legitimate users of the application, and more.
On this page
Ask an AI about this attack pattern
Show the prompt
Explain the attack pattern CAPEC-660: Root/Jailbreak Detection Evasion via Hooking: how it unfolds, what it needs and how to prevent and detect it in my systems. Use https://capec.mitre.org/data/definitions/660.html and https://cve.bz/cve/capec/660?via=ask-ai-copy, which lists recent CVEs with the weaknesses it exploits. Cite the sources.Opens a third-party assistant; its answer is its own, not cve.bz's. The prompt holds only this attack pattern's id and public links.
How the attack unfolds
Explore
The attacker looks for a way in.
[Identify application with attack potential] The adversary searches for and identifies a mobile application that could be exploited for malicious purposes (e.g. banking, voting, or medical applications).
1 technique
- Search application stores for mobile applications worth exploiting
Experiment
They probe what they found.
[Develop code to be hooked into chosen target application] The adversary develops code or leverages existing code that will be hooked into the target application in order to evade Root/Jailbreak detection methods.
3 techniques
- Develop code or leverage existing code to bypass Root/Jailbreak detection methods.
- Test the code to see if it works.
- Iteratively develop the code until Root/Jailbreak detection methods are evaded.
Exploit
They carry out the attack.
[Execute code hooking to evade Root/Jailbreak detection methods] Once hooking code has been developed or obtained, execute the code against the target application to evade Root/Jailbreak detection methods.
1 technique
- Hook code into the target application.
Prerequisites
The targeted application must be non-restricted to allow code hooking.
Skills required
- High skill
Knowledge about Root/Jailbreak detection and evasion techniques.
- Medium skill
Knowledge about code hooking.
Resources required
The adversary must have a Rooted/Jailbroken mobile device.
The adversary needs to have enough access to the target application to control the included code or file.
Consequences
| Impact | Affects | Note |
|---|---|---|
| Execute Unauthorized Commands | Integrity, Authorization | Through Root/Jailbreak Detection Evasion via Hooking, the adversary compromises the integrity of the application. |
| Gain Privileges | Confidentiality, Access Control, Authorization | |
| Read Data | Confidentiality, Access Control | An adversary may leverage Root/Jailbreak Detection Evasion via Hooking in order to obtain sensitive information. |
Mitigations
Ensure mobile applications are signed appropriately to avoid code inclusion via hooking.
Inspect the application's memory for suspicious artifacts, such as shared objects/JARs or dylibs, after other Root/Jailbreak detection methods.
Inspect the application's stack trace for suspicious method calls.
Allow legitimate native methods, and check for non-allowed native methods during Root/Jailbreak detection methods.
For iOS applications, ensure application methods do not originate from outside of Apple's SDK.
Weaknesses it exploits
- CWE-829 Inclusion of Functionality from Untrusted Control Sphere
Recent CVEs with these weaknesses
- 4.4CVE-2026-123858
In JetBrains PhpStorm before 2026.3 project files could be automatically uploaded to a deployment server from untrusted projects
- 5.5CVE-2026-123854
In JetBrains PyCharm before 2026.3 code execution was possible in Safe Mode via a crafted Jupyter notebook widget module
- 7.8CVE-2026-123853
In JetBrains IntelliJ IDEA before 2026.3, 2026.2.2 code execution was possible in Safe Mode via project-controlled JVM options of the build process
- 7.0CVE-2026-123849
In JetBrains IntelliJ IDEA before 2026.3 code execution was possible in untrusted projects via the Terraform File Watchers
- 3.3CVE-2026-123843
In JetBrains IntelliJ IDEA before 2026.3 untrusted projects could trigger changes to GPG agent configuration
- 7.8CVE-2026-123838
In JetBrains IntelliJ IDEA before 2026.3 code execution was possible in Safe Mode via UI Designer form file
- 3.6CVE-2026-123833
In JetBrains IntelliJ IDEA before 2026.3 database connections could be established in untrusted projects
- 9.6CVE-2026-123832
In JetBrains CLion before 2026.2 code execution was possible in Safe Mode via JSON compilation database
The newest records naming one of them. Each weakness's page lists them all.
Related attack patterns
- Part of
- CAPEC-251 Local Code Inclusion
Examples
An adversary targets a non-restricted iOS banking application in an attempt to compromise sensitive user data…
An adversary targets a non-restricted iOS banking application in an attempt to compromise sensitive user data. The adversary creates Objective-C runtime code that always returns "false" when checking for the existence of the Cydia application. The malicious code is then dynamically loaded into the application via the DYLD_INSERT_LIBRARIES environment variable. When the banking applications checks for Cydia, the hooked code returns "false", so the application assumes the device is stock (i.e. not Jailbroken) and allows it to access the application. However, the adversary has just evaded Jailbreak detection and is now able to glean user credentials and/or transaction details.
An adversary targets a mobile voting application on an Android device with the goal of committing voter fraud…
An adversary targets a mobile voting application on an Android device with the goal of committing voter fraud. Leveraging the Xposed framework, the adversary is able to create and hook Java code into the application that bypasses Root detection methods. When the voting application attempts to detect a Rooted device by checking for commonly known installed packages associated with Rooting, the hooked code removes the suspicious packages before returning to the application. As a result, the application believes the device is stock (i.e. not Rooted) when in actuality this is not the case. Having evading Root detection, the adversary is now able to cast votes for the candidate of their choosing as a variety of different users.
MITRE's words, unchanged: CAPEC-660 at MITRE. CAPEC is Copyright © 2007–2026, The MITRE Corporation, used under the CAPEC terms of use: “The MITRE Corporation (MITRE) hereby grants you a non-exclusive, royalty-free license to use Common Attack Pattern Enumeration and Classification (CAPEC™) for research, development, and commercial purposes. Any copy you make for such purposes is authorized provided that you reproduce MITRE’s copyright designation and this license in any such copy.” CAPEC and the CAPEC logo are trademarks of The MITRE Corporation. Credits. All attack patterns.