The World Cup is filling stadiums and the NBA playoffs are filling living rooms — and both are filling scammers' pockets. Big sporting events are an annual gift to fraudsters: millions of people are buying tickets fast, placing bets faster, and doing nearly all of it on a phone. Demand is high, patience is low, and that combination is exactly what attackers exploit.
What's changed is who gets fooled and how. The old advice — "only download official apps from the App Store or Google Play" — is still good advice, but it's no longer enough. Consumers using genuine, legitimately published apps are being defrauded too, because the attack has moved underneath the app itself: into the secrets the app carries, the APIs it talks to, and the tokens that prove who you are. And AI has quietly removed most of the friction that used to protect those layers.
This post breaks down how the scams actually work, why "use a real app" isn't the safety guarantee people think it is, and what app developers need to build in — zero secrets architecture, runtime secrets protection, RASP, and certificate pinning — to make buying a ticket or placing a bet genuinely safe.
How the Scams Actually Work
Ticketing Scams
The classic version is social: a too-good resale listing, a fake "verified" seller in a marketplace, a QR code that resolves to a lookalike checkout page. The buyer pays, gets a screenshot of a "ticket," and discovers at the turnstile that the barcode was sold to ten other people or never existed.
The more dangerous modern version is technical. Attackers clone the look and flow of a legitimate ticketing app, or repackage the real app with malicious code, then push it through unofficial channels, sideloading links shared in fan groups, or even — temporarily — through gaps in app store review. To the user, it looks and behaves like the genuine app. Logins work. Tickets appear. Behind the scenes, the credentials and payment details flow to the attacker.
Betting Scams
Betting apps raise the stakes because they sit directly on top of money and identity. Common patterns this season include fake sportsbook apps promising impossible odds or "guaranteed" parlays, phishing flows that mimic a legitimate book's deposit screen, and account-takeover attacks where a stolen session lets a fraudster drain a balance or launder funds through bets. Because betting apps require ID verification and bank or card linkage, a compromised account is a full identity-and-payment package, not just a lost ticket.
Why "I Only Use Legitimate Apps" doesn't Save You
Here's the uncomfortable part. A user can download the real app, from the real store, with the real developer signature — and still be exposed. The reason is that the security boundary most people imagine (the app store gate) isn't where the modern attack happens.
Every mobile app is shipped to a fundamentally untrusted environment: the user's device, which the attacker may also control. A determined attacker can pull the app's binary apart, read what's inside it, watch the traffic it sends, and manipulate it while it runs. The legitimacy of the download says nothing about the resilience of the runtime.
Three things inside a typical app become the prize:
Hardcoded secrets. Many apps ship with API keys, tokens, or credentials baked into the binary so the app can talk to backend services. Developers often assume these are hidden because they're compiled and obfuscated. They aren't hidden — they're just inconvenient to find. Once extracted, a stolen API key lets an attacker impersonate the legitimate app to its own backend.
API endpoints and their trust assumptions. The app's backend frequently assumes that any request carrying a valid app key or token came from the real app. Break that assumption and the API becomes an open door: a scammer's script can buy up ticket inventory, scrape pricing, create fake accounts in bulk, or replay a captured session.
OAuth tokens and session credentials. The token that proves "this is a logged-in user" is exactly what an attacker wants. Steal it off the device or off the wire and you don't need the password — you are the user, until the token expires.
So the consumer did everything right and still got robbed, because the weak point was the app's architecture, not the user's judgment.
How AI Tilts the Field Toward the Attacker
None of these attack techniques are new. What's new is that AI has collapsed the time, skill, and cost required to pull them off — turning what used to be specialist work into something closer to a commodity.
Defeating obfuscation. Obfuscation has long been the default answer to "how do we protect what's in our app?" The honest answer was always obfuscation slows attackers down; it doesn't stop them. AI-assisted reverse-engineering tooling now slashes that slowdown. Models can help rename mangled symbols, infer the purpose of decompiled functions, summarize control flow, and surface likely locations of secrets in minutes rather than days. The obfuscation that bought a developer weeks of safety might now buy hours.
Finding and abusing stolen API keys. Once a key is extracted, AI helps an attacker understand the surrounding API quickly — what the endpoints expect, how requests are structured, how to script high-volume abuse. The reconnaissance step that used to require patient manual probing is increasingly automated.
Credential and token theft at scale. AI lowers the bar for building convincing phishing flows, fake checkout screens, and lookalike apps, and for orchestrating credential-stuffing and token-replay campaigns. The same generative tools that help legitimate developers ship faster help fraudsters spin up believable fakes faster too.
The strategic takeaway: defenses that relied on attacker effort being high are eroding. If your security model assumes "nobody will bother to dig this out," AI just made bothering cheap.
What App Developers Need to Build in
Protecting sports fans and bettors isn't about asking users to be more careful. It's about removing the things worth stealing and making the app defend itself while it runs. Four capabilities matter most.
Zero Secrets Architecture
The most reliable way to protect a secret in a mobile app is to not put it there. A zero secrets architecture means no API keys, tokens, or credentials are hardcoded or stored in the app binary at all. Instead, the app proves its authenticity at runtime and receives what it needs only after that proof succeeds — secrets are delivered just-in-time and never persisted where they can be extracted. If there's nothing in the binary to find, AI-accelerated reverse engineering has nothing to harvest.
Runtime Secrets Protection
For the secrets an app legitimately needs while operating, runtime secrets protection ensures they exist only transiently, are delivered to genuine app instances rather than baked in, and are never written to the binary or local storage in a recoverable form. The principle is that a secret should never sit at rest inside the app waiting to be lifted. This pairs naturally with zero secrets architecture: the binary ships clean, and live secrets are provisioned dynamically only to instances that have proven they're real.
RASP (Runtime Application Self-Protection)
RASP gives the app the ability to detect and respond to attacks against itself in real time. It watches for the signals of a compromised environment — tampering and repackaging, running on a rooted or jailbroken device, debuggers or instrumentation frameworks attached, emulators, hooking tools — and can react by shutting down sensitive functionality, refusing to release secrets, or terminating. Because the modern attack happens at runtime on a device the attacker may control, the app needs to be able to notice it's under attack and defend itself rather than trusting its surroundings.
Certificate Pinning
Certificate pinning ensures the app will only talk to your backend over a connection it can cryptographically verify, rejecting intercepting proxies and man-in-the-middle setups even when the device's trust store has been tampered with. By default, a mobile app trusts every certificate authority in the device's trust store — dozens of roots the developer never chose and can't vouch for, any one of which (or a maliciously installed extra root) can be used to issue a certificate that lets an attacker sit invisibly in the middle of the connection. Pinning narrows that trust from "any CA the device happens to trust" down to the specific certificate or key that the app developer and publisher actually control. This directly attacks token theft and traffic manipulation: a fraudster who can't sit in the middle of the connection can't quietly capture OAuth tokens or rewrite requests in flight.
This matters across all sectors: medical apps, transaction processing apps,
Pinning has earned a reputation for being brittle, and that reputation comes almost entirely from static pinning — pins hardcoded into the binary and shipped with the app. When a certificate rotates, expires unexpectedly, or has to be revoked, a statically pinned app can't reach its own backend until users install an update, which is a recipe for self-inflicted outages. But static pinning isn't the only option, and its fragility isn't inherent to pinning itself. Dynamic pinning decouples the pin set from the app binary: pins are delivered and updated at runtime from a trusted source, so certificates can be rotated, added, or revoked over the air without shipping a new app version or risking a lockout. That removes the operational landmine developers rightly fear while keeping the security benefit. Pinning is most effective when combined with RASP and runtime secrets protection, so that the pin set is delivered only to genuine, attested app instances and any attempt to bypass or strip out the pinning logic is itself detected and blocked — closing the loophole attackers usually reach for, which is simply disabling pinning rather than defeating it.
How They Work Together
These four aren't a menu to pick from — they reinforce each other. Zero secrets architecture means there's nothing in the binary to steal. Runtime secrets protection ensures the secrets that do flow are released only to genuine, attested app instances and never left at rest. RASP makes sure those secrets are only ever requested by an app running in a safe state. And certificate pinning protects the channel they travel over. The result is an app that proves it's real before it gets anything worth stealing, defends itself if the environment turns hostile, and gives an attacker no static loot to walk away with.
The Bottom Line
This season's fans and bettors are doing their best — checking for the official app, looking for the verified badge, trusting the store. That diligence matters, but it can't cover a gap that lives inside the app's own architecture. The scams that hurt the most don't trick the user into a bad download; they exploit the secrets, APIs, and tokens that a legitimately downloaded app was never built to protect.
AI has made exploiting those weaknesses faster and cheaper than ever, which means the burden has shifted decisively onto developers. For anyone building ticketing or betting apps, security can no longer be a layer of obfuscation laid over hardcoded secrets and hopeful trust. It has to be designed in: nothing worth stealing in the binary, secrets that exist only at runtime for verified instances, an app that defends itself when attacked, and a connection that can't be hijacked. Build that, and a sold-out stadium stays a celebration instead of a crime scene.
Ted Miracco
CEO of Approov
Ted’s high-technology experience spans 30 years in cybersecurity, electronic design automation (EDA), RF/microwave circuit design, semiconductors, and defense electronics.