On October 13, 2026, Japan's National Institute of Information and Communications Technology (NICT) named one of the methods behind the country's wave of data breaches: attackers are downloading public Android apps, taking them apart to learn how they talk to their servers, and then attacking those servers directly. NICT calls this an "A2B attack", short for App-to-Backend. The Ministry of Internal Affairs and Communications asked businesses the same day to act on the warning.

Key takeaways

  • Attackers download apps published on Google Play in Japan, analyze them to find the backend servers, APIs and parameters they use, and then craft attacks for each backend. NICT says this has been confirmed as one cause of the breaches hitting Japanese organizations.
  • The app itself does not need to have a flaw. What matters is whether the server behind it checks who is asking and what they are asking for.
  • Four kinds of vulnerability are mainly targeted: IDOR/BOLA (changing an ID to read someone else's data), SQL injection, SSRF and remote code execution.
  • NICT asks app publishers to check logs back to August 2026, inspect their APIs for these flaws, and restrict access where needed, up to suspending an API or service.
  • A2B is a specific form of the API abuse JPCERT/CC described on October 8. The three IP addresses NICT published are all on JPCERT/CC's list.
  • NICT says AI is making app analysis and vulnerability hunting more efficient. It does not say AI was confirmed in these attacks.

What NICT found#

The warning comes from LETTICE, a threat intelligence team set up in 2024 within NICT's cybersecurity hub CYNEX, made up of volunteers from participating organizations. Based on its own investigation, it describes the attack in two stages:

  1. Analyze the app. The attacker obtains an Android app published in the Japan region of Google Play and analyzes its code to find the backend server it connects to, the API endpoints, the parameters it sends and the structure of the responses it receives.
  2. Attack the backend. Using that map, the attacker identifies the parts of the backend that could be attacked and sends requests tailored to each API's design, looking for and exploiting vulnerabilities.

The key point, NICT says, is that this is not one attack sprayed at many servers. Each backend gets an attack built from its own app. Both APIs that need no login and APIs used after a user logs in are targets, so even features meant for ordinary users can be abused if the backend's access control is weak.

NICT does not say how many organizations were hit or name any of them.

The four flaws attackers look for#

Vulnerability What it means What can happen
IDOR / BOLA (Insecure Direct Object Reference / Broken Object Level Authorization) The server does not check whether the user asking for a record is allowed to see it Changing a member ID in a request returns someone else's name, email and other data. If IDs are sequential or guessable, the whole database can be pulled
SQL injection Input sent through an API is run as part of a database query Personal data is read straight out of the database, or login is bypassed
SSRF (Server-Side Request Forgery) The server can be made to send requests it should not Access to internal systems or cloud metadata that is not reachable from outside
RCE (Remote Code Execution) The server can be made to run the attacker's commands Data theft, tampering and installing malicious programs

In our view, IDOR is the one of these that fits the scale of Japan's breaches most directly. An app that loads "my profile" by sending a member number is, to an attacker who has read the app, a template for loading every member's profile.

What NICT asks app publishers to do#

1. Check whether you have been hit

  • List every API and internet-facing host, including subdomains, old API versions, test environments and public cloud services.
  • Review access, API and authentication logs from August 2026 onwards, and earlier if possible, for the published IoCs and for unusual behavior: large amounts of data retrieved without login, requests stepping through sequential IDs, other members' data viewed or changed, suspicious token issuance, and use of admin functions.

2. Inspect your APIs

  • Authorization: can changing an ID show another user's or another tenant's data?
  • Authentication and sessions: can tokens be forged or obtained, or login bypassed? Are fixed credentials or encryption keys exposed in the app?
  • SQL and NoSQL injection.
  • SSRF, through features that fetch URLs, process images or convert documents.
  • Cloud storage such as S3, GCS or Firestore that can be reached without proper authorization.
  • Unsafe deserialization, arbitrary file writes and exposed admin functions.

3. Contain the risk while you fix it

  • Temporarily restrict access from overseas or other unnecessary sources.
  • Stop or restrict unneeded APIs, admin functions and test environments.
  • Watch request rates and sequential ID patterns, and use rate limiting or a WAF.
  • Revoke and reissue credentials and tokens that may be compromised.
  • If a serious flaw cannot be fixed quickly, consider suspending the API, the feature or the whole service.

For the long term, NICT's message is simple: attackers can call your API without using your app at all. Authentication, authorization and input validation must happen on the server, not in the app. The same applies to iOS apps and the APIs behind web services.

Indicators of compromise#

NICT published three IP addresses linked to the attacks, noting that a match alone does not prove a compromise:

IP address Also on JPCERT/CC's list
69.10.51[.]162 Yes, and flagged as a priority by Macnica
210.149.87[.]120 Yes, and flagged as a priority by Macnica
207.241.172[.]54 Yes, added on October 9

JPCERT/CC's full list, with more addresses, is in our article on its warning.

Our analysis#

A name for JPCERT/CC's "Case B"#

JPCERT/CC's October 8 warning described four patterns behind the breaches. Its second, abuse of internal APIs, began with analyzing publicly available smartphone apps to find API endpoints and keys. NICT's A2B attack is that pattern, studied in more depth and given a name. The overlap in indicators supports this: all three addresses NICT published are on JPCERT/CC's list. NICT also adds detail JPCERT/CC did not give: the source is Android apps on Google Play in Japan, the attack is tailored to each backend, and the main targets are four specific kinds of flaw.

When JPCERT/CC's warning came out, we wrote that "the app is the map". In our view, NICT's findings confirm it. An API that is "internal" only because it does not appear in the app's screens is not protected; anyone who downloads the app can find it.

Why this fits Japan's breaches#

Many of the services hit this autumn are app-first: membership apps, point programs, booking apps and restaurant apps. A2B explains why so many different companies, using different systems, were breached in a similar way in a short time. Attackers did not need one shared vulnerability. They needed one method, applied to each app in turn. That also fits Macnica's finding that most companies' notices gave too little detail to identify a cause: an IDOR flaw in a company's own API is not a product vulnerability with a CVE number, and it is easy to describe vaguely as "unauthorized access".

Breaches that fit the profile#

NICT names no victims, and no company has said it was hit by an A2B attack. But several of the breaches disclosed this autumn involved the systems behind an app, and the little their notices say is consistent with what NICT describes:

  • Yakiniku King: attackers broke into the member management system of the chain's official app and took data on 99.8% of its 10.8 million users. The company has not said how.
  • Seicomart: the attacker reached the member database through the server behind its app. Seicomart has since decided that members will no longer be able to view or change their own details online.
  • Lawson: a mechanism its app uses to show users their own information was accessed without authorization.

Taking almost every member's record, and abusing a function meant to return each user's own data, is what an authorization flaw such as IDOR would allow. In our view, these cases fit the A2B pattern. That is an inference from the outside: none of the companies has described the flaw, and they may have been breached in other ways.

AI, again#

NICT's subtitle speaks of "vulnerability hunting made more advanced by AI". Read closely, the warning says AI is making program analysis and vulnerability discovery more efficient, and that this could let such attacks reach more systems. It does not say AI was confirmed in the attacks it observed. That matches the view in our article on whether AI is behind the breach wave: the holes are old ones, such as missing authorization checks, and AI may be making the work of finding them in app after app cheaper.

What this means for readers#

  • If you publish a mobile app for users in Japan, assume it has already been analyzed. Test every API it calls, including ones not shown in the app, with someone else's IDs and with no login.
  • Check your logs from August, for the three IP addresses above and JPCERT/CC's list, and for sequential ID requests and bulk retrieval.
  • Remove secrets from your app. Any API key, token or credential built into an app can be extracted.
  • Do not forget old API versions and test environments. NICT names them specifically, because they are often left running without the protections of production.
  • If you use a Japanese service's app, there is nothing to do differently, but expect more breach notices from app-based services as companies check their logs.

Japanese terms at a glance#

Japanese Reading Meaning
A2B攻撃 ē-tsū-bī kōgeki A2B (App-to-Backend) attack
アプリ解析 apuri kaiseki App analysis (reverse engineering)
バックエンドサーバ bakkuendo sāba Backend server
認可不備 ninka fubi Missing or broken authorization
侵害指標（IoC） shingai shihyō Indicator of compromise
注意喚起 chūi kanki Warning, alert
情報通信研究機構（NICT） Jōhō Tsūshin Kenkyū Kikō National Institute of Information and Communications Technology