TL;DR: Coruna and DarkSword style iOS exploit kits can hook app functions, bypass sandbox protections, and extract passwords, tokens, Keychain items, and files from targeted apps, according to Guardsquare research, while its testing found 17 wallet apps failed to detect common hooking and injection techniques. The lesson for mobile security teams is that runtime compromise turns bearer secrets, trust checks, and static storage into high-value failure points.
At a glance
What this is: Guardsquare examines how Coruna and DarkSword-style iOS exploit kits bypass app trust checks, hook sensitive functions, and steal live credentials and data from targeted apps.
Why it matters: This matters because mobile security controls that protect data at rest do not stop runtime interception, which is where bearer secrets, trust decisions, and session theft now converge for identity and access teams.
Context
iOS app hardening is no longer just about protecting files on disk or trusting the operating system sandbox. When exploit kits can intercept app functions at runtime, the control problem shifts to whether sensitive data can be trusted at the moment it is read, decrypted, or sent.
That creates a direct governance issue for identity and application teams because bearer tokens, passwords, seed phrases, and device trust checks can all be abused once the execution environment is compromised. In this case, the article’s starting position is typical of modern mobile threats: attackers are targeting runtime trust, not only static storage.
Key questions
Q: What breaks when mobile app trust is enforced only on the device?
A: Device-only enforcement is visible to the attacker and can be bypassed, patched, or stripped out in a repackaged app. That means the organisation is trusting a control that runs inside the same environment it is trying to defend. The safer pattern is to verify app integrity on the server before sensitive API actions are allowed.
Q: Why do stolen mobile tokens and passwords create such a large identity risk?
A: They create risk because they are reusable outside the device and often remain valid until explicitly revoked. If an exploit captures a bearer secret at runtime, the attacker can replay it from another location and bypass the original device controls. That is why short-lived, device-bound, or continuously verified credentials are safer than portable secrets.
Q: How do teams know if mobile app hardening is actually working?
A: Look for reduced success in reverse engineering, fewer successful tampering attempts and cleaner separation between legitimate user traffic and suspicious API requests. If attackers can still extract logic or reach backend services through repackaged clients, the hardening layer is not holding. Measurement should focus on attack cost and trust quality, not only alert counts.
Q: Should organisations prioritise device-bound credentials over stronger local storage?
A: Yes, when the application handles high-value identity data or financial transactions. Better local storage helps at rest, but it does not stop runtime interception once the secret is loaded for use. Device-bound credentials reduce portability, limit replay, and make compromise dependent on continued control of the device itself.
Technical breakdown
How function hooking bypasses mobile trust checks
Function hooking places attacker-controlled logic at the start of a function so the malicious code runs before the app’s intended logic. In mobile exploit chains, that lets an attacker alter outcomes such as certificate checks, authentication flows, or sensitive reads without changing the app binary on disk. The result is not just code tampering but trust inversion: security decisions are made inside a compromised runtime. For identity and access security, this is especially dangerous because bearer credentials often move through standard helper functions before they are used.
Practical implication: treat runtime integrity as part of authentication and session governance, not just a mobile app hardening concern.
Why Keychain storage still leaves a live exposure window
The Keychain protects secrets at rest, but it does not eliminate exposure once the application requests those secrets into memory. If an exploit hooks the retrieval path, the attacker can capture tokens or passwords at the exact moment they are returned to the app. That creates a short but decisive exposure window that static encryption alone does not close. This is the core weakness in many mobile identity flows: the secret remains safe when dormant, then becomes stealable during legitimate use.
Practical implication: reduce reliance on reusable bearer secrets and assume retrieval-time interception is a realistic attack path.
How hardware-bound signing changes the attacker’s position
Asymmetric device-bound signing changes the problem from secret theft to live device presence. Instead of exporting a private key or token, the app keeps the signing key inside the Trusted Execution Environment and requests signatures as needed. If the attacker cannot extract the key, they must remain on the device and control the runtime to keep using the account. That narrows persistence and makes the attack far less durable after reboot or hook loss. It also aligns security with continuous proof of possession rather than static credential possession.
Practical implication: prefer device-bound credentials and signing flows where session value depends on live device control rather than portable secrets.
Threat narrative
Attacker objective: The attacker wants to steal live credentials and sensitive app data while bypassing app trust checks and mobile protections.
- Entry begins when a user visits a malicious website that triggers the exploit kit against the mobile device.
- Credential access occurs through function hooking, sandbox escape, and trust bypasses that expose passwords, tokens, Keychain items, and seed phrases in real time.
- Impact is live data theft and session hijacking, with the attacker able to reuse stolen secrets from elsewhere or stay active through ongoing runtime control.
Breaches seen in the wild
- postmark-mcp malicious MCP server 2025: A fake Postmark MCP server on npm quietly BCC'd every email AI agents sent through it to an attacker, using victims' own Postmark tokens.
- DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Runtime trust is now the real control boundary for mobile identity. Once exploit kits can hook functions inside the app, traditional trust assumptions about the operating system and sandbox stop being reliable. The issue is not only malware presence but whether authentication, certificate checks, and secret retrieval still mean what the app thinks they mean. For practitioners, mobile assurance has to shift toward runtime integrity and response.
Bearer secrets are the weakest link in hostile mobile runtimes. Passwords, tokens, and seed phrases remain high-value because they are reusable outside the device once stolen. That makes them structurally different from device-bound credentials that are only useful while the protected runtime remains intact. The more an app depends on portable secrets, the more a single hook turns compromise into account takeover.
Keychain protection is necessary but not sufficient when the retrieval path is owned. Storing secrets in the Keychain reduces exposure at rest, but it does not solve interception at the moment of use. This is a classic lifecycle gap: protection is strong while data sleeps and weaker when data is operational. Practitioners should treat retrieval-time interception as part of the identity threat model.
Hardware-backed signing creates a more durable governance model than secret export. If the private key never leaves the Trusted Execution Environment, the attacker cannot simply copy it and leave. That changes the operational problem from credential theft to runtime containment, which is much easier to reason about in mobile risk governance. For identity programmes, device binding is not a niche control, it is a way to reduce portable trust.
Moving-target hardening is becoming a baseline requirement for mobile apps with identity value. Rotating code paths, shifting detection points, and layering integrity checks do not eliminate exploitation, but they raise the cost of sustained reverse engineering. That matters because attackers are optimising for scale, not bespoke effort. The practitioner takeaway is that mobile app protection must assume adaptive adversaries and continuous re-testing.
From our research library:
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
- Read next: API Key Management Guide
What this signals
Live interception is the governance gap mobile teams need to model. The problem is not only whether secrets are stored securely, but whether they can survive being requested inside a hostile runtime. That makes runtime telemetry, session revocation, and device-bound authentication the controls that matter most when mobile apps carry identity value.
Device binding is the named concept that should replace secret portability in high-risk mobile flows. If a private key stays inside the Trusted Execution Environment, attackers cannot lift it and reuse it elsewhere, which sharply changes the economics of compromise. Teams should use that design pattern wherever mobile apps hold credentials that can drive account takeover, payments, or sensitive transactions.
For practitioners
- Harden runtime integrity checks Detect hooking, dynamic library injection, and jailbreak state early, then send those events to your backend so you can revoke sessions or step up transaction controls.
- Replace reusable bearer secrets Move away from passwords and long-lived tokens where possible, and prefer device-bound signing flows that keep private keys in the Trusted Execution Environment.
- Encrypt sensitive data before system calls Do not hand raw secrets to standard helper functions or storage APIs if you can pre-encrypt them inside application logic first.
- Use layered certificate validation Pin trusted certificates or public keys for critical network paths so a compromised device trust store cannot silently enable man-in-the-middle interception.
- Refresh app structure frequently Rotate code layouts, relocation points, and tamper checks across releases so hooks written for one version do not remain effective for long.
Key takeaways
- Mobile exploit kits now target the moment secrets are used, not just where they are stored.
- The Guardsquare article shows that runtime hooks can bypass trust checks and expose passwords, tokens, Keychain items, files, and keys in live execution.
- Teams should pair runtime detection with device-bound credentials and backend response so a compromised app cannot quietly keep trusting itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centers on live interception of passwords, tokens, and keys from compromised app runtimes. |
| NHI-04 — Insecure Authentication | Hooked certificate and trust checks show how authentication controls can be bypassed inside the app runtime. | |
| Recommendation — Reduce secret leakage by removing portable credentials from mobile runtime flows and revoking exposed tokens quickly. Harden authentication paths so runtime hooks cannot silently bypass trust verification or session validation. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Bearer tokens and keys in the article behave like authenticators whose lifecycle must be controlled tightly. |
| Recommendation — Apply IA-5 to limit authenticator reuse and rotate or revoke mobile secrets that can be intercepted at runtime. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The exploit abuses app-side authorization assumptions to access data and session material. |
| Recommendation — Use PR.AA-05 to restrict what mobile sessions can reach if runtime integrity is no longer trustworthy. | ||
| MITRE ATT&CK | TA0006;TA0040 — Credential Access; Impact | The attack chain combines credential theft with downstream account misuse and data theft. |
| Recommendation — Map mobile hooking activity to TA0006 and TA0040 so detections and response plans focus on theft and impact. | ||
Key terms
- Function Hooking: A technique that redirects an application call so attacker-controlled code runs before or instead of the original function. In mobile security, hooking is dangerous because it can expose secrets, alter trust checks, or manipulate transaction logic while the app still appears to operate normally.
- Sandbox Escape: A sandbox escape is when code breaks out of its intended isolation boundary and gains access to host capabilities. In identity terms, it turns a constrained non-human execution path into a privileged runtime that can touch files, secrets, or downstream systems.
- Trusted Execution Environment: A Trusted Execution Environment is a protected hardware-backed area where code runs with stronger isolation from the host system. In AI inference, the point is not just secrecy in transit, but limiting what operators, hypervisors, and surrounding infrastructure can observe during processing.
- Device binding: A control that links an authenticator or key pair to a specific endpoint so the same secret cannot be copied and reused elsewhere. It strengthens assurance, but the binding step itself becomes a high-value target if attackers can intercept the enrollment process.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org