The string of personal-data leaks reported by organizations across Japan this month has a common thread, and it runs through the mobile apps those organizations ship. JPCERT/CC says the attackers pulled apart Android application packages to discover the APIs the apps talk to, then attacked those APIs directly, using AI to scan for known vulnerabilities along the way.
The findings come from the original report by JPCERT/CC's Attack Infrastructure Investigation Team, published October 21. It follows an alert JPCERT/CC issued on October 8 about unauthorized access incidents at multiple Japanese organizations involving leaks of personal and other information. Working with several organizations, the team identified a number of servers it believes were used in the attacks, and found that the attackers had also targeted web services built for users outside Japan.
The app is the map to the server
A mobile app has to know how to reach its back end, which means the app itself contains a map of the API: addresses, request formats, and sometimes the secrets used to sign requests. JPCERT/CC found evidence on one attack server that the operators had analyzed APK files and then tested the associated APIs for vulnerabilities such as server-side request forgery (SSRF), a flaw that tricks a server into fetching a URL on the attacker's behalf. A Python script on that server acted as an HTTPS server that answered specific requests with an HTTP 302 redirect, which JPCERT/CC says appears to have been used for SSRF testing. The same server held apps aimed at users outside Japan.
A second server held more APK files plus two reverse-engineering tools: jadx, for Android apps, and Blutter, an open-source tool for analyzing compiled Dart code inside Flutter apps. A directory named apk_extract/ and files such as strings_libapp.txt suggested strings were being pulled out of the apps' native libraries. Japan's NICT has separately warned that app analysis followed by server attacks is one cause of the recent leaks.
Signs of a push into internal networks
On a third server, which JPCERT/CC says was not directly related to these attacks, investigators found files tied to attack techniques against web applications, MySQL, Jenkins servers and email gateways, evidence of attempts to evade EDR products, and web shells believed to have been deployed inside a targeted network. JPCERT/CC reads that as the attackers trying to move from exposed services into internal networks.
Stop shipping API secrets inside apps
JPCERT/CC's appendix points to public research showing that tools like Blutter can recover embedded RSA private keys and request-signing logic from a compiled Flutter app, enough to build a standalone client that talks to the production API without the real app. Its recommendations follow directly:
- Do not embed private keys used for API authentication, or long-lived credentials, in applications.
- Authenticate and authorize on the server. Do not rely on request signing or code obfuscation inside the app.
- Rate-limit APIs, monitor for anomalous requests, and assume clients other than your app will call them.
- For APIs that fetch external URLs, restrict where they can connect and validate redirect destinations too.
JPCERT/CC published three server addresses: 210[.]149[.]87[.]120, 118[.]26[.]36[.]16 and 69[.]10[.]51[.]162. It is asking researchers who find related infrastructure, or incidents affecting Japanese organizations, to share them at info[at]jpcert[.]or[.]jp so it can notify victims.
Japan has had a rough year, from hacktivist floods to real breaches, but this case carries a lesson well beyond its borders: anything compiled into an app should be treated as published, because someone with the right tools, and now some AI help, will read it.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.