Japan’s Data Leaks Started Where Few Teams Look: The Mobile App

Over the last week, multiple sources in Japan have identified a widening outbreak of data leaks via mobile API attacks. This includes detailed reports from an independent incident response team (JPCERT Coordination Center), analysis by security researchers at Macnica, a breach disclosure from one of the affected organizations (Park24), as well as multiple news stories from mainstream press in the region and international tech industry publications. 

Recent stories published by NHK World, Kyodo News, and Nippon.com provide an initial list of impacted companies and the number of stolen records, including:

• a popular Japanese barbecue restaurant chain: Member information for approximately 10.78 million customers.

• a large karaoke chain: Personal information on about 8.72 million customers.

• a second-hand goods retailer: Account information for up to 6.43 million customers.

• a major car rental operator: 6.6 million accounts, including over 1 million driver’s license images.

• a discount retail store chain: Member information for more than 1.73 million customers.

Security researchers have also speculated that this outbreak could be connected to similar attack clusters in South Korea, France, and Poland. On October 9, Hacker News summarized how attackers were gaining access in these instances:

• They analyze a publicly released smartphone app to find its API endpoints and keys.

• They attack internal APIs that cannot be used through the app's screens. Reported actions include changing a user's privileges, creating unauthorized accounts, comparing how the server answers when a header is added or removed or a malformed authentication token is sent, and finding account details through blind NoSQL injection.

• They use API keys stolen when another system was compromised.
  

While the full scope and impact are still unfolding, we can still look at the specific circumstances that enable attackers to steal credentials and attack mobile APIs.

Breaking down the attack chain

There are several notable details about the attacks in Japan, mostly in terms of the speed, scope, and scalability of the operation behind these incidents. The threat methodologies themselves, however, are nothing new. Existing mobile app defenses (when applied correctly) can address each point of opportunity in the attack cycle.

Static analysis: Scanning for hardcoded secrets

Prevention is always the best medicine. An attacker can’t steal secrets from a successfully reverse-engineered mobile application if there aren’t any secrets or hard-coded keys there in the first place. So the first step is making good architectural decisions from the jump.

Continuous scanning throughout the development process helps developers identify and remediate potential security issues as they code. As Boehm’s Curve describes, it’s cheaper and easier to make fixes earlier in the development cycle because the context of building that part of the code is still fresh in the developer’s mind.

It seems like a simple enough solution, but many mobile app developers skip static and dynamic scanning via a purpose-built mobile application security testing (MAST) solution due to increasing time-to-market pressure. They’re shipping code with known security issues (like hardcoded credentials) and dealing with the consequences later.

As we’re seeing in Japan, those downstream consequences can be quite severe.

Reverse engineering and runtime attacks

Given the chance, bad actors can analyze, explore, and exploit an underprotected mobile application. Common development tools like JEB, Ghidra, and Frida are often used for AI-assisted reverse engineering. Last month, Anthropic described how Claude AI was being abused to mass-download, decompile, and scan 1.8 million Android APKs in search of credentials, keys, and other secrets. Modern tools make reverse engineering much easier, even when an app is obfuscated. This new reality calls for modern, multilayered mobile app protections that make the reverse engineering process much harder, more time-consuming, and more costly for the attacker.

Protection starts with different kinds of code hardening to defend against static analysis. An effective solution should use multiple techniques that hide sensitive code, including control flow obfuscation, name obfuscation, code virtualization, and data encryption. But as previously mentioned, obfuscation alone isn’t enough today.

To counter things like dynamic code analysis and runtime attacks, mobile apps also need runtime application self-protection (RASP). RASP security checks are built into the code to monitor the application’s behavior during runtime operation and automatically trigger defensive actions when needed. For example, a check might be configured to respond to debugging by terminating the app or by restricting its functionality.

In the AI-era, scalability is another critical factor. If the same protections are used across multiple applications or releases, then a single successful attack can be automatically reused at scale (which is the worst-case scenario).

Mobile app teams can prevent this by using multiple defensive layers that change shape across builds, applications, and releases. This concept (known as polymorphism) means that a compiler mechanism generates a uniquely different and diverse set of security obstacles with each new application build or release. Polymorphism continuously “resets the clock” on reverse engineering attempts with new configurations that hinder their ability to understand the application's structure and behavior.

Spoofing and stuffing mobile APIs

Mobile APIs connect client-side mobile apps to server-side resources. API abuse can happen in a few different ways. They can be called by a non-genuine clone app (essentially, a legitimate app that’s been reverse-engineered and maliciously modified).

Once an attacker has stolen or extracted API keys in hand, they can also skip the investment of a cloning and spoofing attack by handing those credentials over to a bot, script, or agent. This is a classic credential stuffing fraud tactic used against high-value mobile apps (e.g, banking, retail, crypto wallets) to directly access backend services or take over accounts. But this approach can also be used against less sensitive (and often underprotected) apps for other malicious goals, such as data exfiltration.

The speed and scale of the Japan incidents suggests possible agentic AI involvement. Agents can replicate, scale, and adapt attacks at speeds far beyond old fashioned botnets. According to a new Akamai report, AI is making APIs “the dominant attack surface,” backed by an observed 113% increase in daily API attacks year-over-year.

Effective mobile API security today means establishing trust before granting access to anything on the backend. Only legitimate, validated mobile applications should be allowed to interact with your APIs. App attestation prevents API abuse by verifying that the frontend app on a mobile device is authentic, unmodified, and running on a secure device. It enforces dynamic security policies that automatically block bots, scripts, agents, and non-genuine apps from gaining access to server-side resources. While Google and Apple offer OS-based app attestation services that can reliably detect tampering with the app package on clean devices, they fall short against more sophisticated real-time attacks.

How Guardsquare can help

The ongoing attacks in Japan are (unfortunately) a perfect illustration of how wide the implications of insufficient or outdated mobile application protections can be. It also highlights why a defense-in-depth approach to mobile app security is now essential, even for apps that weren’t previously considered high value or high risk.

Guardsquare combines continuous MAST testing (in alignment with OWASP standards and guidelines) with multilayered, polymorphic protections (code hardening and RASP). It also includes dedicated app attestation capabilities for mobile API security, as well as real-time threat monitoring to help spot suspicious behaviors and expose broader threat campaign patterns.

Contact a Guardsquare expert today to learn more.