iOS exploit kits are bypassing app trust and stealing live data

At a glance

What this is: This is an analysis of modern iOS exploit kits that bypass app controls to intercept runtime secrets and app data.

Why it matters: It matters because mobile apps that rely on static tokens, predictable system calls, or weak runtime hardening can expose identity material and session trust even when the underlying platform is compromised.

By the numbers:

• Coruna targeted 17 crypto wallet apps in Guardsquare’s test, and every app failed to identify that sensitive functions had been hooked.
• 23 exploits and targeted iOS versions up to, and targeted iOS versions up to 17.2.1.
• DarkSword infected iOS versions 18.4 through 18.7 via malicious websites before escaping the WebKit sandbox.

👉 Read Guardsquare's analysis of Coruna, DarkSword, and iOS app hardening

Context

Mobile app security fails when teams assume the operating system alone will protect secrets after a device compromise. In this case, the primary issue is runtime trust, because exploit kits can hook functions, bypass certificate checks, and read data the app loads into memory.

That creates a direct identity and access problem for mobile programmes, not just a code-hardening problem. Passwords, bearer tokens, Keychain items, and signing workflows all become exposed once malicious code can intercept calls inside the app or the operating system.

The starting position described here is increasingly typical for consumer and financial apps, especially where the app still relies on static secrets, predictable APIs, and trust in the device state.

Key questions

Q: What breaks when mobile apps rely on bearer tokens after a device compromise?

A: Bearer tokens become replayable once an attacker can hook the app or intercept memory at runtime. The secret may still be encrypted at rest, but the moment it is loaded for use, it can be copied and reused from another device. That is why mobile identity design should minimise reusable credentials and shift critical flows toward device-bound proofs.

Q: Why do iOS exploit kits make mobile identity assurance harder?

A: They attack the trust layer between the operating system and the app, where authentication and transaction data are actually handled. If the attacker can alter hooks, trust checks, or system calls, the app may approve actions while exposing credentials. Security teams need to govern runtime integrity, not just storage encryption.

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: Who is accountable when a mobile app passes audit but still leaks sensitive data at runtime?

A: Accountability sits with the programme owners who accepted incomplete evidence. Security, engineering, and compliance teams should define who signs off on runtime proof, who owns remediation, and which control objective failed. In regulated environments, audit success without behavioural verification is not a durable assurance model.

Technical breakdown

How iOS function hooking steals secrets at runtime

Function hooking redirects execution before the original function runs, letting an attacker inspect or alter values as they pass through the app. In the Coruna scenario, a hook can force security checks to succeed or capture sensitive outputs such as tokens and passwords in memory. This matters because the app may still appear healthy while its trust decisions are silently manipulated. Runtime tampering is therefore more dangerous than simple file theft, because it attacks the moment secrets are used rather than where they are stored.

Practical implication: harden high-value functions against tampering and treat runtime integrity as a control, not just a detection problem.

Why Keychain and flat-file storage fail under compromise

The system Keychain is better than storing secrets in application files, but it does not solve the problem if an attacker can hook the code path that retrieves the secret. Flat files are easier still, because an attacker only needs sandbox escape to read them. The real distinction is that storage protection and access-path protection are different controls. If the secret is loaded into memory as a bearer token, it can be stolen at the point of use even when at-rest encryption is in place.

Practical implication: reduce bearer-token dependence and design workflows so secrets are not exposed in app memory longer than necessary.

Why device-bound signing reduces replay risk

Device binding shifts trust from a reusable secret to asymmetric signing inside the Trusted Execution Environment. The private key never leaves hardware, so an attacker who hooks the app cannot simply copy a token and replay it elsewhere. That changes the attacker’s economics: they must keep live control of the device to request signatures in real time. For mobile identity flows, this is a much narrower and more volatile attack surface than static credentials that can be exfiltrated once and reused indefinitely.

Practical implication: move high-risk sessions and transactions toward device-bound proofs instead of reusable bearer secrets.

Threat narrative

Attacker objective: The attacker wants live access to identity material and session trust so they can hijack accounts and exfiltrate data at scale.

1. Entry occurs when the user visits a malicious website that silently triggers the exploit kit on the device.
2. Credential access follows when hooked functions intercept passwords, tokens, Keychain items, or seed phrases as the app uses them.
3. Impact occurs when the attacker reuses the stolen material for session hijacking, account takeover, or financial theft from outside the device.

NHI Mgmt Group analysis

Runtime secret exposure is now the central mobile identity failure mode. The article shows that once an app loads bearer secrets into memory, platform protections alone no longer govern access. That turns mobile security into an identity problem as much as an application problem, because tokens and passwords become live identity artefacts the attacker can intercept. Practitioners should treat runtime secret handling as a governed trust boundary.

Static secrets create a replayable trust model that exploit kits can monetise quickly. When a token can be lifted once and reused elsewhere, the attacker’s job is simple: capture, replay, profit. Device-bound signing weakens that model by tying access to the original hardware state and a live signing flow. For mobile IAM and fraud teams, the governance question is no longer only where secrets are stored, but whether they are reusable at all.

App hardening is now part of identity assurance for mobile channels. Detecting hooks, rotating code structure, and validating certificates are not just defensive coding patterns. They are controls that preserve the integrity of authentication, transaction approval, and session continuity. In identity programmes that rely on mobile approvals, the absence of runtime integrity checks should be treated as an assurance gap.

Hook detection should be viewed as an incident signal, not a local app feature. The article’s testing failure across 17 apps shows how often this control is missing in practice. Once the app can report tampering to the backend, the security team can revoke tokens, raise friction, or quarantine suspicious sessions before identity theft completes. Practitioners should connect mobile telemetry to account-level response.

What this signals

Static-secret dependency is becoming a mobile risk multiplier: when identity material can be replayed outside the device, the programme inherits both application compromise and account compromise. Teams should expect more pressure to combine runtime integrity, device binding, and risk-based session control in a single mobile assurance model.

The governance issue is not simply whether an app encrypts data at rest. The question is whether identity assertions survive a compromised runtime, because that is where fraud, session hijacking, and credential theft converge. Referencing the OWASP Non-Human Identity Top 10 is useful here as a reminder that reusable secrets and poor lifecycle control are recurring failure patterns, even when the target is a mobile application.

For practitioners

• Harden runtime integrity checks Instrument high-value functions to detect hooking, injection, and trust-store tampering, then send those signals to backend risk engines for token revocation or step-up controls.
• Replace reusable bearer tokens Move critical mobile flows toward device-bound asymmetric signing in the Trusted Execution Environment so a stolen secret cannot be replayed from another device.
• Reduce predictable secret-handling paths Avoid using the same standard iOS functions for every sensitive operation, and pre-encrypt values before they reach public APIs or storage layers.
• Validate certificate trust explicitly Pin trusted certificates or public keys for sensitive network calls so a compromised root store cannot silently convert a secure session into a man-in-the-middle channel.
• Increase structural churn between releases Rotate detection placement and relocate sensitive functions so hooks built for one version fail against the next release.

Key takeaways

• Modern iOS exploit kits can turn a compromised runtime into a credential theft channel, even when the app appears secure at rest.
• The most useful evidence in the article is the complete failure of 17 tested apps to detect hooking, which shows how often runtime trust controls are absent.
• Device-bound signing, runtime integrity telemetry, and less reusable secret handling are the controls that materially change attacker economics.

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.
• 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.
• 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.
• Runtime Integrity: Runtime integrity is the assurance that what a system executes matches what defenders expect at the moment of execution. It matters because malware or exploit code can change memory, cache, or process behaviour without changing the on-disk file, which makes artifact-based checks incomplete on their own.

What's in the full article

Guardsquare's full post covers the operational detail this post intentionally leaves for the source:

• Experiment setup showing how Roothide and SSLKillSwitch were used to test hooking detection across targeted apps
• Step-by-step hardening patterns for anti-hooking checks, including multi-layered detection and backend alerting
• Implementation guidance for device binding, Keychain handling, and certificate pinning in mobile apps
• Version-rotation tactics that force attackers to rebuild hooks after each release

👉 The full Guardsquare article covers the exploit mechanics, test results, and defensive roadmap in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners build stronger control models for identity material that must survive real-world compromise.