Key takeaways

  • JPCERT/CC, Japan's national computer emergency response team, says it has confirmed that the attackers behind Japan's recent run of data breaches used AI to scan for known vulnerabilities and to attack services through their APIs. It found this while examining servers the attackers used, together with several organizations.
  • On those servers, it found Android app files (APKs), tools for reverse engineering apps, including jadx and Blutter for apps built with Flutter, and a script for testing SSRF (server-side request forgery) using redirects.
  • The same servers were used against web services outside Japan too, and stored apps made for other regions.
  • A separate server showed tools aimed at MySQL, Jenkins and mail gateways, attempts to bypass EDR, and web shells, signs of attackers trying to move inside networks.
  • JPCERT/CC published three IP addresses. Two were already in its October 8 warning; one, 118.26.36[.]16, is new.
  • Its advice: do not embed secret keys in apps, authenticate and authorize on the server, rate-limit and monitor APIs, and check where a URL fetch ends up after redirects.

What JPCERT/CC investigated#

On October 8, JPCERT/CC warned about the data breaches that Japanese organizations had been announcing one after another, and described the patterns it was seeing, including API abuse. On October 13, NICT, the national research institute for information and communications technology, gave one of those patterns a name: the A2B (app-to-backend) attack, in which attackers analyse a company's mobile app to find and abuse the servers behind it.

JPCERT/CC's new post, published on October 15 by its attack infrastructure research team, goes one step further. Working with several organizations, it examined servers used by the attackers themselves, and describes what was on them. It says it found several such servers on the internet, and that they were attacking web services outside Japan as well.

The post also contains the sentence most people in Japan's security community have been waiting for:

In the course of this work, we confirmed that the attackers were using AI to carry out scans for known vulnerabilities and attacks via APIs.

The post does not explain how JPCERT/CC established that AI was used. It shows file listings and a script from the servers, but nothing specific to AI.

Inside the attack servers#

Server What JPCERT/CC found
Server 1 Android APK files, including apps offered in regions outside Japan, and traces of the attacker analysing them and testing the related APIs for SSRF and other flaws. A Python script that runs as an HTTPS server and answers certain requests with an HTTP 302 redirect, probably used to test for SSRF
Server 2 Several APK files, with files related to jadx, a common Android app decompiler, and Blutter, an open-source tool for reverse engineering Flutter apps. Folders such as apk_extract/ and files such as strings_libapp.txt, which suggest strings were pulled out of the apps' native code
Server 3 A server not directly related to the breach wave, with tools for attacking web applications, MySQL databases, Jenkins servers and mail gateways, traces of attempts to bypass EDR, and web shells probably planted in victims' networks

Server 1 and Server 2 match what NICT described on October 13: attackers take a company's published app, pull it apart, find the API endpoints and how the app talks to them, and then go after the APIs directly. Server 3 shows a different stage: not just pulling data out through an API, but trying to get inside a network and stay there.

Why a redirect script matters#

SSRF is a flaw in which an attacker makes a server fetch a URL on the attacker's behalf. Many apps have features that do this legitimately, such as fetching a preview for a link or importing an image from a URL. If the server does not control where it fetches from, an attacker can point it at internal addresses that should never be reachable from outside, such as internal APIs or, in cloud environments, the metadata service that can hand out credentials.

A common defence is to check the URL before fetching it. A redirect gets around that: the attacker supplies a harmless-looking URL on their own server, which passes the check, and that server answers with a 302 redirect to an internal address. If the target follows the redirect without checking again, the defence fails. That is the kind of test the script on Server 1 appears to support, and it is why JPCERT/CC's advice says to validate the destination after redirects.

Why Flutter apps are not a hiding place#

Flutter lets developers build Android and iOS apps from one codebase. Its release builds compile Dart code ahead of time into native code (libapp.so on Android), which makes them harder to read than ordinary Android apps. Some developers treat that as protection.

JPCERT/CC's appendix explains why it is not. Blutter recovers the structure of compiled Flutter code. JPCERT/CC cites a technical write-up from June 2026 in which researchers used Blutter and other tools on a real Flutter app, found an RSA private key embedded in it along with the logic used to sign API requests, recreated the signing, and then called the production API from a standalone Python script, without the app.

The lesson goes beyond Flutter. If an app holds a secret that the server trusts, anyone who downloads the app holds it too.

What JPCERT/CC recommends#

Area Recommendation
Secrets Do not embed private keys used for API authentication, or long-lived credentials, in apps
Authentication and authorization Do not rely on signing or obfuscation inside the app. Authenticate users on the server, and authorize each request according to what is being accessed and what is being done
API abuse Apply rate limits and watch for abnormal requests. Assume that requests will come from something other than your own app
SSRF For APIs that fetch external URLs, restrict the destinations, and check the destination again after redirects

Indicators of compromise#

JPCERT/CC lists three IP addresses. As with its earlier list, addresses like these can change hands or be shared, so treat a match as a reason to look closer, not as proof of compromise.

IP address In earlier lists?
210.149.87[.]120 Yes, in JPCERT/CC's October 8 warning and NICT's list
118.26.36[.]16 New
69.10.51[.]162 Yes, in JPCERT/CC's October 8 warning and NICT's list

JPCERT/CC asks anyone with related information, such as attacker IP addresses or techniques, to share it, and says it is contacting organizations it believes may be targeted.

What we don't know yet#

  • How JPCERT/CC established that AI was used, and which AI tools or services
  • Which victims the servers are linked to. The post names none
  • When each IP address was in use, and what Server 3's web shells were connected to
  • Which services outside Japan were attacked

Our analysis#

AI confirmed, but not the kind people feared#

As far as we have seen, this is the first time a Japanese public body has said it confirmed AI use in this breach wave, rather than warning that AI could speed attacks up. It is an important step. It is also worth reading precisely.

JPCERT/CC says AI was used to scan for known vulnerabilities and to attack through APIs. Nothing in the post points to AI finding new, unknown flaws, the scenario behind the "frontier AI" warnings that have spread in Japan this year. Everything on the servers it describes, APK decompilers, a Flutter analysis tool, an SSRF test script, works on weaknesses that defenders already know how to fix: secrets in apps, missing server-side authorization, unrestricted URL fetches.

That matches the view in our analysis of whether frontier AI is behind the breach wave: the holes were already there, and AI is plausibly helping attackers find and use them faster and at greater scale. JPCERT/CC's finding confirms the second half. It does not change the first.

A headline without the evidence#

In our view, the post is also a little disappointing on the very point it leads with. Its opening says AI use was confirmed, and that sentence is what Japanese media and readers will pick up. But the body says nothing more about AI: not what kind of AI or service was used, not which tasks it performed, not what on the servers showed it. Every file listing and script it describes would look the same if a person had done the work with ordinary tools.

We do not doubt that JPCERT/CC has grounds for the statement, and there may be good reasons, such as ongoing investigations or partners' confidentiality, for not showing them. But a confirmation with no detail is hard for defenders to use, and easy for others to stretch into "AI did it". Even a few sentences, for example whether AI was used to read decompiled code, to write exploit scripts or to drive scanning, would tell defenders much more about what they are facing.

The app is not a security boundary#

Several of this year's largest breaches in Japan went through APIs: member data pulled out through functions that were never meant to return other people's records. The newest example is software maker SourceNext, which said on October 15 that a member information API was abused from October 9 to 13 to take data on about 22.5 million members, including passwords. JPCERT/CC does not mention SourceNext, and SourceNext has not said whether an app was involved, so we cite it only as an example of the same class of weakness.

What JPCERT/CC's findings show is how attackers get there. They do not need to break into the company first. They download the public app, read it, and talk to the API directly. Anything the server trusts because "only our app would send this", a hidden endpoint, a signed header, a key in the code, should be assumed known to attackers.

More of this, please#

JPCERT/CC's October 8 warning published attacker IP addresses and User-Agent strings; NICT named the A2B attack and listed what to check; and now JPCERT/CC has described the attackers' own infrastructure, with IoCs. Compared with the vague "beware of unauthorized access" warnings that used to be the norm, this is real progress, and defenders can act on it.

In our view, the next step is to connect it to cases. The victims' own notices rarely say more than "a vulnerability" or "unauthorized access". JPCERT/CC, NICT and the government bodies that receive incident reports are in a better position than anyone to say which weaknesses were behind which kinds of incidents, without naming victims if necessary.

What this means for readers#

  • If you publish a mobile app, decompile your own release builds, including Flutter builds, with the same free tools attackers use, and look for keys, tokens, endpoints and signing logic.
  • Remove secrets from apps. Use short-lived, per-user tokens issued after login, and enforce what each user may access on the server.
  • Inventory your APIs, including old and undocumented ones, and check each endpoint for authorization, not just authentication.
  • Rate-limit and monitor API calls that return personal data, and alert on volume, sequential IDs and unusual clients.
  • Find every feature that fetches a URL, block internal and metadata addresses, and re-check the destination after each redirect.
  • Check your logs for the three IP addresses above, and for activity from the addresses in JPCERT/CC's October 8 warning.

Japanese terms at a glance#

Japanese Reading Meaning
攻撃元サーバー kōgeki-moto sābā Attack (source) server
攻撃インフラ kōgeki infura Attack infrastructure
既知の脆弱性 kichi no zeijakusei Known vulnerability
API経由での攻撃 API keiyu de no kōgeki Attack via an API
リバースエンジニアリング ribāsu enjiniaringu Reverse engineering
会員情報取得API kaiin jōhō shutoku API Member information retrieval API
秘密情報の埋め込み himitsu jōhō no umekomi Embedding secrets (in an app)
サーバー側での認証・認可 sābā-gawa de no ninshō ninka Server-side authentication and authorization