TL;DR: Sports and betting fraud now succeeds against genuine mobile apps because attackers target hardcoded secrets, backend API trust assumptions and session tokens, according to Approov, while AI lowers the cost of reverse engineering and abuse. The real control shift is from trusting app stores to protecting the app at runtime with zero secrets architecture, runtime secrets protection, RASP and certificate pinning.
At a glance
What this is: This is an analysis of how legitimate mobile apps are being abused for ticketing and betting fraud through exposed secrets, API trust failures and token theft.
Why it matters: It matters because IAM and application security teams need to treat mobile app runtime protection as part of identity and credential governance, not just app store review.
Context
Mobile fraud often begins after the app download, not before. A legitimate app running on an attacker-controlled device can still expose API keys, tokens and session credentials if those assets are embedded in the binary or trusted too broadly at runtime.
In this threat model, the app store gate is only a distribution control, not a runtime assurance control. That makes mobile app security an identity problem as well as an application problem, because the app is carrying the credentials that prove who the user is.
Key questions
Q: What breaks when a mobile app still contains secrets or tokens in its binary?
A: The app stops being a thin client and becomes a reusable credential store. Attackers can extract API keys, impersonate the app, and replay or automate requests against the backend. That turns a single downloaded app into a scalable abuse surface, especially when the backend trusts any request that presents a valid-looking token or key.
Q: Why do legitimate mobile apps still get abused for fraud?
A: Because app store legitimacy does not protect the runtime environment. Once the app runs on a device the attacker can inspect, modify or proxy, the real security question becomes whether the app leaks secrets, trusts the wrong client, or lets stolen sessions be replayed before they expire.
Q: What are the signs that a mobile app’s anti-tamper controls are failing in practice?
A: Warning signs include keys that can be traced through obfuscated code, runtime hooks that still reveal sensitive flows, and protections that only slow down analysis rather than stop it. If a reviewer can bypass the control chain with a small set of tooling and recover payment logic or master keys, the defensive layer is brittle.
Q: How should security teams balance pinning with certificate rotation in mobile apps?
A: Use dynamic pinning rather than hardcoded static pins wherever possible. That lets the trust set change without forcing an app update, while still preventing interception. The goal is to preserve channel integrity without creating self-inflicted outages when certificates rotate, expire or need to be revoked.
Technical breakdown
How hardcoded secrets become reusable app credentials
Hardcoded secrets are API keys, tokens or credentials compiled into the app so it can talk to backend services. Obfuscation may make them harder to spot, but it does not remove them from the binary. Once extracted, the attacker can impersonate the app to its own APIs, automate abuse, or create scripts that behave like trusted clients. In practice, the security boundary has moved from the store listing to the runtime environment, where the attacker can inspect, patch or replay the app’s behaviour. See the Mobile App Security Guide. See the Mobile App Security Guide.
Practical implication: Eliminate embedded credentials and move to runtime-issued secrets that are never recoverable from the binary.
Why API trust assumptions fail in repackaged mobile apps
Mobile backends often assume that a request carrying a valid app token or key came from the genuine app. Repackaging, sideloading and instrumentation break that assumption because a malicious client can still present a valid-looking request while changing its source or intent. The problem is not only authentication, but client authenticity and request integrity. When the backend cannot distinguish a genuine app from a cloned one, attackers can scrape data, create accounts or automate purchases at scale. This is why API trust must be coupled to device and app attestation, not just a static secret.
Practical implication: Bind backend access to attested app instances and refuse requests that cannot prove client integrity.
How token theft turns mobile sessions into account takeover
OAuth tokens and session credentials are especially valuable because they already represent an authenticated user. If an attacker steals them from the device or intercepts them in transit, the password is no longer needed. The compromise window lasts until the token expires or is revoked, which is why long-lived mobile sessions are so dangerous. In betting and ticketing flows, that can mean account takeover, balance theft, or fraudulent ticket access. The architectural issue is not just login security, but how long a bearer credential remains usable once exposed.
Practical implication: Shorten token lifetimes, limit session scope and make bearer credentials harder to intercept or replay.
Threat narrative
Attacker objective: The attacker wants to impersonate trusted mobile clients and users well enough to steal value, automate abuse and move money or tickets without detection.
- Entry occurs when attackers clone, repackage or instrument a legitimate mobile app, or use a genuine app running on a compromised device to reach trusted APIs.
- Credential harvest happens when hardcoded secrets, OAuth tokens or session credentials are extracted from the binary, memory or network traffic.
- Escalation follows when those credentials are replayed against backend services to impersonate the app or the user and automate abusive actions.
- Impact is ticket fraud, account takeover, balance theft, API abuse and unauthorised access to app-backed services.
Breaches seen in the wild
- Google API Keys Exposure — Gemini AI: Google API keys exposed in client-side code via Gemini AI integrations, creating data leak risk.
- Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.
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
Mobile app runtime trust is now the real control boundary: the old assumption that store review equals safety no longer holds when the app carries the credentials attackers want. A legitimate binary on an untrusted device can be reverse engineered, instrumented or repackaged, which means governance has to move from distribution approval to runtime assurance. The practical conclusion is that mobile apps need controls that verify the app instance before releasing anything valuable.
Zero secrets architecture is now an identity control, not just a secure coding preference: if the app binary contains reusable credentials, the app itself becomes a credential container. That shifts the problem into mobile app security and makes secret lifecycle design part of access governance. The field should treat hardcoded mobile secrets as preventable identity exposure, not as a packaging weakness.
AI has lowered the attacker cost of client-side abuse: reverse engineering, API discovery and convincing fake app flows are all cheaper than they were a few years ago. That changes the economics of fraud against mobile ticketing and betting apps because attackers no longer need high skill or long dwell time to extract value. Security programmes should assume commodity tooling will keep shrinking the effort required to harvest mobile credentials.
Certificate trust must be narrowed at the application layer: mobile apps that accept any certificate authority in the device trust store leave room for interception and token theft. The more robust model is to pin trust to the specific backend certificate or key the publisher controls, while also defending the app runtime so pinning cannot be quietly stripped out. Practitioners should view this as channel governance, not just transport hygiene.
Identity proof at login is not enough when the session itself is the asset: ticketing and betting flows often carry identity, payment and authorisation in the same mobile session. Once a bearer token is stolen, the attacker inherits the user’s authenticated state until expiry. The governance lesson is that session integrity, token lifetime and device trust must be managed together, or the strongest login flow can still end in fraud.
Read next: Mobile App Security Guide
What this signals
Mobile app fraud has become a governance problem, not just a user education problem: the attacker does not need to trick every user into installing a fake app if the genuine app already carries reusable credentials. That means the programme question is whether runtime trust, token handling and backend authorisation are designed to survive reverse engineering and interception, not whether users remembered to download from the official store.
Zero secrets architecture should be treated as a control objective: when the binary contains no reusable secrets, AI-assisted reverse engineering has less to harvest and less to automate. The remaining work shifts to attestation, runtime enforcement and session governance, which is where mobile fraud controls now need to converge.
For practitioners
- Eliminate embedded mobile secrets Remove API keys, tokens and credentials from the app binary and issue only runtime secrets to verified app instances.
- Bind backend trust to app attestation Require evidence that the client is a genuine, untampered app before granting access to ticketing or betting APIs.
- Treat token theft as a session design problem Reduce bearer token lifetime, limit scope and revoke sessions aggressively when misuse or device compromise is suspected.
- Harden transport against interception Pin the app to approved backend certificates or keys so intercepting proxies cannot quietly capture or rewrite requests.
- Detect repackaging and instrumentation Block or degrade app behaviour when the runtime shows signs of rooting, jailbreaking, debuggers or hooking frameworks.
Key takeaways
- The core risk is that a legitimate mobile app can still be compromised through its secrets, APIs and sessions even when the download path was legitimate.
- The article argues that AI has reduced the effort required to reverse engineer, clone and abuse mobile app trust relationships.
- Protecting these apps requires runtime assurance, short-lived secrets and stricter channel trust, not just better app store hygiene.
Related NHI Mgmt Group resources: Mobile App Security Guide · Mobile App Security Testing Guide · Lost or Stolen Device Response Checklist · Vulnerability Management Guide
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, OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 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 centres on secrets embedded in mobile apps and extracted at runtime. |
| NHI-04 — Insecure Authentication | The article shows how stolen tokens and weak client trust let attackers impersonate users and apps. | |
| NHI-07 — Long-Lived Secrets | Bearer tokens and session credentials remain exploitable for too long once exposed. | |
| Recommendation — Remove embedded credentials and prevent secret exposure from mobile binaries and logs. Harden runtime authentication so stolen tokens and cloned clients cannot act as trusted identities. Shorten token lifetimes and revoke exposed mobile sessions quickly. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | The backend trusts valid-looking requests and tokens from untrusted mobile clients. |
| Recommendation — Require stronger authentication signals before accepting mobile API requests. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about enforcing access decisions based on trusted client identity and session integrity. |
| Recommendation — Tie mobile API access to verified entitlements and revoke unsafe session authorisations. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator lifecycle is central to the exposed tokens and session credentials discussed. |
| Recommendation — Manage mobile authenticators with short lifetimes, revocation and rotation controls. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack path includes extracting secrets and reusing them to move through backend services. |
| Recommendation — Map mobile secret theft to credential access and lateral movement detections. | ||
Key terms
- Zero-Secrets Architecture: Zero-secrets architecture is a design approach where the client does not store durable secrets that attackers can extract and reuse. It shifts trust to runtime controls, ephemeral credentials, and back-end verification so that compromise of the app binary does not automatically expose lasting access.
- Runtime Secrets Protection: Runtime secrets protection means credentials are delivered only when the application and session context have been verified. It reduces the value of reverse engineering because the secret is not permanently embedded in the binary or left exposed on the device.
- Certificate Pinning: A trust control that restricts a client to a specific certificate authority, public key, or certificate for a given connection. It can reduce exposure to unexpected certificates, but it also makes trust changes harder because the client may reject valid replacements after rotation or revocation.
- Runtime Application Self-Protection: RASP is a runtime control that detects and can block suspicious application behaviour as it happens. In NHI contexts, it can contain abuse from service accounts or tokens, but it does not replace identity ownership, entitlement review, rotation, or deprovisioning.
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 is designed for practitioners who need to connect identity controls to the broader security stack their programmes depend on.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org