A2B攻撃が突く、意図しない公開

何が公表されたか

NICTの脅威情報分析チームLETTICE（レティス）によると、攻撃者はGoogle Playの日本地域で公開されているAndroidアプリを入手して解析し、アプリが通信するサーバーの接続先、APIの構成、パラメータを集めます。攻撃者は集めた情報をもとに、狙うサーバーに合わせて攻撃の内容を変えています。NICTは、サーバーごとに攻撃を変える点を特徴に挙げています^[3]。

NICTは、アプリ自体に脆弱性がなくても、サーバー側の認証や認可、入力値の検証に不備があれば漏えいにつながると指摘しました。同じ問題はiOSアプリやWebサービスでも起こりうるとしています。AIについては、アプリの解析や脆弱性の探索がAIで効率化され、こうした攻撃がより多くのシステムに及ぶ可能性に注意が必要だとしています^[3]。

renueの見解

NICTはA2B攻撃を「原因の一つ」としています。NICTやJPCERT/CCが示した手口に共通するのは、アプリ運用者が外に出していないと考えていたものが、実際には外から見え、届く状態にあったという点です^[3][4]。renueは、同じ状態がAndroidアプリに限らずiOSアプリや社内向けのツールにも広く見られることから、不正アクセスの増加を説明する有力な要因の一つだと考えています。

10月に入ってからの発表は、どれも、アプリやAPIの仕様を外から調べられ、アプリ運用者の想定していない使い方をされたことを示しています。JPCERT/CCは10月8日の注意喚起で、公開されているスマートフォンアプリを解析してAPIの接続先やキーを特定する手口と、本来は画面の操作では実行できない内部のAPIを狙う手口を挙げました^[4]。個人情報保護委員会は、パラメータを書き換えるだけで他の利用者の情報を取得できた事例を公表しています^[5]。マクニカの分析は、サイトごとの構造やAPIの不備を探す攻撃は手間がかかるため従来は主流ではなかったものの、今回は事案への対応を通じてその動きが具体的に見えてきた、と報告しました^[6]。基本方針で取り上げた、社内向けに立てたBIツールや管理画面が入口になった事例も、構造は同じです。

サイトごとに仕様を調べ、それに合わせて攻撃を変える作業は、これまで攻撃者にとって割に合わないものでした。NICTが特徴に挙げた、サーバーごとに攻撃を変える手法が成り立つのは、AIによってこの手間が小さくなり、攻撃者の運用が楽になったためだとrenueは見ています。基本方針の2章基本方針のページへ移動で述べた、AIによる攻撃コストの低下が、アプリとAPIの領域に表れたものです。

なぜ、意図しない公開が起きるのか

アプリは利用者の端末に配布されるため、誰でも入手して解析できます。ここがWebアプリとの違いです。Webアプリでブラウザに届くのは、画面を表示するためのコード（HTMLやJavaScript）が中心です。アプリには、APIを呼び出す手順、認証に使う鍵、組み込んだSDKまで、サーバーとやり取りするためのプログラム一式が入っています。コードを難読化していても、埋め込まれた認証情報は解析で取得される可能性があります^[6]。renueは、AIを使えば難読化したアプリでもAPIの呼び出し方まで解析できると考えています。

解析すると、通信先のサーバー、呼び出せるAPIの一覧、リクエストの形式（パラメータの名前や値の型）がわかります。画面からは使わせていない機能、古いバージョンのAPI、検証環境の接続先、埋め込んだままの鍵がアプリに残っていれば、それらも見つかります。

APIはアプリからのみ呼び出され、画面にない機能や接続先は外部に知られない、という前提は、もう成り立ちません。NICTも、アプリが解析されること自体を完全に防ぐことは困難だとしています^[3]。

renueが考える対処法

renueは、アプリが解析されることを前提に、公開する必要のない接続先を閉じたうえで、アプリの内部構造やAPIの仕様を知られても安全なように、バックエンドを堅牢にすることが重要だと考えています。NICTも、恒久的な対策として、アプリ側の制御だけに頼らず、バックエンドのサーバー側で認証、認可、入力値の検証を行うことが重要だとしています^[3]。

外から届く接続先の一覧は、配布しているアプリと画面のコードから作ります。社内の台帳や設計書をもとにすると、会社が把握していない接続先が一覧から漏れるためです。renueは公開面とリポジトリからの洗い出しをAIエージェントに任せており、A2B攻撃への備えでは対象をアプリと画面のコードに広げます。コードから届く接続先、API、鍵、ストレージを書き出す作業は、攻撃者と同じ入口からの棚卸しです。

一覧に載った接続先のうち、使っていない古いAPI、検証環境、管理用の機能は、公開を止めるか接続元を制限します。アプリに埋め込まれた鍵は、無効にして再発行します。

利用者向けに公開する必要があるAPIについては、「誰が、誰のデータに触れてよいか」を1つずつサーバー側で判定することが欠かせません。IDを別の利用者のものに書き換えても情報が返らないことは、実際に試して確認します。NICTは特に、SSRF（サーバーに内部への通信をさせる攻撃）、RCE（遠隔からのコード実行）、SQLインジェクション、IDOR（IDを書き換えると他者の情報に触れられる不備）の4種類について、バックエンドのAPIを重点的に点検するよう勧めています^[3]。APIの数が多くても、テストの作成と実行をAIエージェントに任せれば、手が回らなくなることはありません。

攻撃をすでに受けていないかは、ログで調べます。NICTは、2026年8月以降のアクセスログ、APIログ、認証ログを確認し、可能であればそれ以前のログも確認するよう求めており、攻撃に使われた接続元のIPアドレスなども公開しています^[3]。ログでは、連番のIDを順に試すアクセスや、認証なしでの大量の取得が残っていないかを調べます。

この流れは、基本方針の3章基本方針のページへ移動の3-3（外部からの通信経路を絞る）と3-5（影響度で分類する）を、アプリとAPIに当てはめたものです。renueのAI脆弱性診断では、AIによるコード分析と侵入テストで、認証と権限、外部との接点を確かめています。A2B攻撃が狙う箇所は、この診断の対象そのものです。

今日確かめること

出典

1. NICT「【注意喚起】相次ぐ情報漏えい、その原因の一つは『アプリ解析からのサーバ攻撃』」（2026年10月13日）
2. 総務省「不正アクセスによる情報漏えい等の事案を踏まえた対応について（公開アプリの解析情報を悪用した攻撃への注意喚起）」（2026年10月13日）
3. NICT CYNEX 脅威情報分析チームLETTICE 注意喚起の詳細（2026年10月13日）
4. JPCERT/CC「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」（2026年10月8日、10月9日更新）
5. 個人情報保護委員会「大規模な漏えい等事案を踏まえた対応について（注意喚起）」（2026年10月7日）
6. マクニカ セキュリティ研究センター「相次ぐWEBシステムからの情報漏洩事案について」（2026年10月7日）
7. renue「世間で増加する不正アクセスに対する、renueの基本方針と取り組み」（2026年10月13日）