JPCERT/CC Confirms AI-Assisted API Attacks: 6 Defenses Every Security Team Needs Now

TL;DR

• AI is now confirmed on the attacker side. In October 2026, JPCERT/CC reported that the actors behind Japan’s run of data breaches used AI to scan for known vulnerabilities and to attack services through their APIs.
• The entry point is your own app. Attackers download public Android and Flutter apps, decompile them, extract endpoints, keys and signing logic, then call production APIs directly.
• The flaws are old. The speed is new. Embedded secrets, missing server-side authorization and unvalidated URL fetches are well understood. AI agents compress the time from app download to data exfiltration.
• Perimeter and client-side controls will not catch this. The traffic looks like a legitimate client talking to a legitimate API, so a WAF or API gateway sees clean requests. Only business logic security can tell the difference.
• AppSentinels brings API discovery, API red-teaming and API runtime protection into one API security platform, so BOLA, BFLA, scripted clients and SSRF attempts are found before release and stopped in production.

The question every security leader should be asking this quarter

For most of 2026, the debate about AI in offensive security has been hypothetical. Could frontier models find zero-days? Would autonomous agents run entire intrusions? Japan’s breach wave has given us a more useful answer, and it is less exotic than the headlines suggested.

On October 15, 2026, JPCERT/CC published findings from its examination of servers operated by the attackers behind a string of Japanese data breaches. Its conclusion: the attackers used AI to scan for known vulnerabilities and to attack services through their APIs. Two private investigations followed within days. GMO Cybersecurity by Ierae linked an open-source AI penetration testing tool called ARTEX to attacks on roughly 20 Japanese companies, and CrowdStrike tied the same tool to campaigns against South Korean banks.

The lesson for CISOs is direct. AI did not hand attackers a new class of vulnerability. It handed them a faster, cheaper way to exploit the API weaknesses most organizations already carry. That changes the math on every unprotected endpoint you own, and it raises the bar for what an API security program must deliver.

What investigators found on the attack servers

JPCERT/CC’s team, working with several partner organizations, described three servers. Taken together, they read like a production line for API abuse.

• Mobile apps as raw material. The servers held Android APK files, including apps published for markets outside Japan, along with traces of the operators testing the APIs those apps talk to.
• Reverse-engineering tooling. Investigators found artifacts from jadx, a standard Android decompiler, and Blutter, an open-source tool that recovers the structure of compiled Flutter apps.
• AI coding agents in the workspace. Directory listings showed configuration folders for agentic coding tools, including Claude Code and OpenAI Codex CLI, on the attackers’ machines.
• SSRF test harnesses. A small Python HTTPS server was set up to answer certain requests with redirects, a classic technique for slipping past URL allowlists.
• Post-exploitation tooling. A separate server carried tools aimed at MySQL, Jenkins and mail gateways, EDR evasion attempts and web shells, signs that some operators aim to persist inside networks.

Japan’s NICT had already named the core pattern on October 13: the A2B (app-to-backend) attack. The JPCERT/CC findings show what that pattern looks like when it is industrialized.

The A2B playbook, step by step

Security teams tend to picture API attacks as noisy fuzzing against a perimeter. The A2B playbook is quieter and far more precise.

1. Acquire the client. The attacker downloads your public app from an app store. No phishing, no exploit, no alert.
2. Decompile and read it. Tools like jadx and Blutter expose endpoints, request formats, hidden parameters, API keys and request-signing logic. An AI coding agent can summarize thousands of decompiled files in minutes.
3. Rebuild the client in a script. With the signing logic recovered, the attacker writes a standalone client that your backend cannot distinguish from your app.
4. Probe the business logic. The script iterates object IDs, swaps user context, calls admin-only functions and tests URL-fetch features for SSRF.
5. Extract at scale. Once a broken authorization check is found, data leaves through a legitimate endpoint, one valid-looking request at a time.

The scale this enables is already visible. SourceNext disclosed on October 15 that a member information API was abused between October 9 and 13, exposing data on about 22.5 million members. The company has not said whether a mobile app was the starting point, but the incident shows the blast radius of a single endpoint that returns more than it should.

Why AI changes the economics

Every step above was possible before 2026. What changed is cost. Reading a decompiled app used to take a skilled analyst days. Writing a working client that reproduces custom request signing took more. AI agents collapse that effort, which means attackers can now work through entire app-store categories instead of choosing a handful of high-value targets.

That has three implications for defenders:

• Obscurity has expired. Undocumented endpoints, unusual parameter names and compiled code bought time when analysis was expensive. That time is gone.
• Long-tail apps are now targets. Regional apps, legacy versions and low-traffic services get the same scrutiny as flagship products.
• Dwell time between discovery and exploitation is shrinking. A flaw shipped in Monday’s release can be weaponized before Friday.

Five assumptions that no longer hold

Most API breaches in this wave trace back to a trust decision someone made years ago. These are the ones to retire now.

• Only our app calls this endpoint. Anyone with the APK can call it. Assume every request may come from a script.
• Request signing proves the caller is legitimate. If the signing key ships inside the app, it ships to the attacker. Signing proves possession of the app, nothing more.
• Obfuscation and Flutter compilation protect our logic. Published research has shown attackers recovering private keys and signing routines from compiled Flutter builds and calling production APIs without the app.
• Authenticated means authorized. A valid session token says who the caller is. It says nothing about whether they should see record 10,482. That gap is Broken Object Level Authorization (BOLA), and it ranks first in the OWASP API Top 10. Its sibling, Broken Function Level Authorization (BFLA), lets ordinary users call admin functions.
• We validated the URL before fetching it. A check that runs once, before a redirect, is a check the attacker controls. SSRF defenses must re-validate the final destination.

6 defenses every security team needs now

JPCERT/CC’s guidance points in the right direction. Turning it into a program that holds up across hundreds of fast-changing endpoints takes six defenses, each mapped to a capability in the AppSentinels API security platform.

1. Continuously discover every API you expose. Attackers build their endpoint list by reading your app. Your inventory has to be at least as complete, including unmanaged APIs and zombie APIs no one has retired. How AppSentinels helps: API Discovery & Posture Management builds a live inventory from traffic and flags posture gaps as you ship.

2. Know which endpoints return sensitive data. An A2B attack is only as damaging as the data behind the API. Map which endpoints return personal, financial or credential data, and treat any that over-return as priority fixes. How AppSentinels helps: Sensitive Data Discovery classifies sensitive fields in API traffic, so you see your exposure the way a harvesting script would.

3. Enforce authorization on the server, per object and per function. Authentication confirms identity. Authorization decides whether that identity may read this record or call this function. Every request needs both checks, evaluated server-side, to close BOLA and BFLA gaps. How AppSentinels helps: the Business Logic Graph maps users, roles, objects and workflows, so authorization gaps are visible endpoint by endpoint.

4. Red-team your APIs continuously. Adversaries now use AI agents to probe APIs on their schedule. An annual pentest leaves months of exposure between tests, which is why continuous red-teaming has become the baseline. How AppSentinels helps: API Red-Teaming runs business-logic-aware attack scenarios, including BOLA and BFLA abuse, across your API estate. One technology enterprise used it to complete business logic testing across 3,500 APIs in days.

5. Protect APIs at runtime with business logic context. A rebuilt client sends valid tokens and correct signatures, so a WAF or API gateway sees clean traffic. Baselining how real users move through each workflow exposes the script that iterates IDs, skips steps or pulls records in bulk. How AppSentinels helps: API Runtime Protection applies business logic security to live traffic and stops abuse in real time, while Incident Response gives teams the evidence to investigate. A national payments operator relies on it for runtime protection of its real-time payment rails.

6. Lock down every server-side URL fetch. Restrict fetch destinations to an allowlist, block internal ranges and cloud metadata endpoints, and re-validate the final destination after every redirect. How AppSentinels helps: AppSentinels flags SSRF attempts against your APIs. A US online marketplace used it to find a blind SSRF its AI red-teamer could not reach.

Why security teams choose AppSentinels for app-to-backend defense

AppSentinels is an API security platform built for abuse that hides inside legitimate API traffic. It connects API discovery, API red-teaming and API runtime protection through one model of how your business logic works.

• One platform across the API lifecycle. Discovery, testing and protection share the same Business Logic Graph, so a gap found in red-teaming becomes a control enforced in production. Governance & Compliance keeps posture reporting ready for audit.
• Built for the agents attackers now use. The same business logic analysis extends to AI agents and MCP servers through agentic AI security, AI discovery and posture management, AI red-teaming, AI runtime protection and MCP security, informed by the OWASP Agentic Top 10.
• Proven across industries. Customers in banking and financial services, healthcare, media and entertainment, retail and eCommerce, SASE and enterprise technology rely on AppSentinels to secure their APIs.

A 30-day action plan for security teams

1. Week 1: Decompile your own apps. Run jadx and Blutter against your current release builds, including regional and legacy versions. Log every key, token, endpoint and signing routine you find.
2. Week 2: Pull secrets out of the client. Replace embedded keys with short-lived, per-user tokens issued after login. Rotate anything already exposed.
3. Week 3: Inventory and test authorization. Map every API your apps call, then test each one for object-level and function-level authorization, not just authentication.
4. Week 4: Turn on behavioral monitoring. Baseline normal usage, alert on sequential ID access and bulk extraction, and audit every feature that fetches a user-supplied URL.

The bottom line

Japan’s breach wave is a preview of how most API breaches will unfold from here: public app in, AI-assisted analysis in the middle, customer data out. The weaknesses are familiar. The window to fix them is closing faster than most roadmaps assume. Security teams that understand how their APIs are meant to behave will spot the script hiding behind a valid signature. That understanding is what business logic security delivers, and it is why API discovery, API red-teaming and API runtime protection now belong in one program.

Book a demo to see how AppSentinels stops app-to-backend abuse.

Frequently Asked Questions