A2B 攻撃とは｜Android アプリ解析で狙われる API の確認手順

はじめに

2026 年 10 月 13 日、NICT（情報通信研究機構）の脅威情報分析チーム LETTICE は、国内で相次ぐ情報漏えい事案の原因の一つとして、公開されている Android アプリを解析し、その接続先のバックエンドサーバーを攻撃する手法を特定したと発表しました。LETTICE はこの手法を「A2B 攻撃（App-to-Backend Attack）」と名付け、CYNEX Library で詳細な注意喚起（PDF・全 7 ページ）と IoC（侵害指標）を公開しています。

A2B 攻撃は単一の新しい脆弱性（CVE）ではなく、攻撃の進め方に付けられた名称です。そのため「パッチを当てれば終わり」という対応はなく、Android アプリを公開している企業は、アプリの接続先 API とバックエンドの安全性を自ら点検する必要があります。アプリの開発・保守を外部に委託している場合は、API の管理責任者が社内で明確になっていないこともあり、点検の起点を決めることが最初の課題になります。

本記事では、A2B 攻撃の仕組みと、アプリとバックエンドの構成に沿った自社 API の点検方法に絞って解説します。国内の公表事例は『情報漏えいはなぜ起きる？｜国内事例から考える情シス・インフラの対策』で整理していますが、個々の事例が A2B 攻撃によるものかは NICT の資料では示されていません。公式情報の確認基準日は 2026 年 10 月 14 日（日本時間）です。

結論として、A2B 攻撃で問題になるのはアプリが解析されることそのものではなく、解析で分かった API にサーバー側の不備が残っていることです。アプリは解析される前提に立ち、API ごとに認証の要否と必要な権限を明確にしたうえで、サーバー側の認可と入力値の検証が機能しているかを確認することが対策の軸になります。あわせて、NICT が示した 2026 年 8 月以降のログ確認から着手することをおすすめします。

A2B 攻撃とは？Android アプリ解析からサーバー攻撃までの流れ

A2B 攻撃は、公開 Android アプリの解析と、その結果を使ったバックエンドサーバーへの攻撃を組み合わせた手法です。ここでは定義と観測内容を確認したうえで、アプリとサーバーの役割の違いを整理します。

NICT が示した A2B 攻撃の定義

LETTICE の詳細注意喚起（Rev 1.1、2026 年 10 月 13 日 15:00 更新）によると、今回確認された攻撃の流れは次のとおりです。

1. Google Play の日本地域で公開されている Android アプリを入手する。
2. アプリのプログラムを解析し、通信先のバックエンドサーバー、API の構成、エンドポイント、パラメーター、応答データの構造などを調べる。
3. 得られた情報をもとに、個々のサーバーの構成や API の仕様に合わせたリクエストを組み立て、脆弱性を探索・悪用する。

特徴は、不特定多数のサーバーへ同じ攻撃を送るのではなく、アプリの解析結果を使ってサーバーごとに攻撃内容を変えている点です。また、認証不要の API だけでなく、利用者アカウントでログインした後に使える API も攻撃対象になる場合があるとされています。

AI については、プログラム解析や脆弱性探索の効率化により、こうした攻撃がより多くのシステムに広がる可能性への注意が示されています。今回観測された個々の攻撃に AI が使われたことを示す記述は、NICT の資料にはありません。AI の関与は将来のリスクとして読み、観測事実とは分けて扱うのが適切です。

Android アプリから分かること

Android アプリは、利用者の端末へ配布された時点でプログラム一式が手元に渡ります。そのため、アプリに含まれる接続先のドメイン名、API のパス、リクエストの組み立て方、アプリに埋め込まれた API キーなどの固定値は、解析によって読み取られる可能性があります。NICT のプレスリリースは、事業者から見た影響を次のように説明しています。

参考: NICT プレスリリース「【注意喚起】 相次ぐ情報漏えい、その原因の一つは『アプリ解析からのサーバ攻撃』」
「一般には公開していないつもりのサーバの内部仕様が攻撃者に知られ」
https://www.nict.go.jp/press/2026/10/13-1.html

ここで区別したいのは、API のエンドポイントが知られることと、API に不備があることは別の問題という点です。エンドポイントの URL やパラメーターは、通信を観察するだけでも分かる情報であり、秘密として守ることを前提にできません。一方、知られたエンドポイントに対して、他人のデータを返す、権限のない操作を受け付ける、不正な入力をそのまま処理するといった不備があれば、それが情報漏えいの直接の原因になります。

アプリとバックエンドの責任分界

次の表は、会員向け Android アプリの一般的な構成を例に、各要素の役割を編集上整理したものです。特定の製品や事例の構成ではありません。

アプリで管理者用のボタンを表示しない、他人の会員番号を入力する画面を用意しないといった制御は、正規のアプリを正規に操作する利用者にしか効きません。攻撃者は解析で得た情報をもとに、アプリを経由せずにリクエストを送れるため、サーバー側で同じ制限を実装していなければ、画面上の制限は防御として機能しません。

アプリの脆弱性とサーバーの脆弱性の違い

NICT は、Android アプリ自体に脆弱性がなくても、バックエンドの API に認証・認可や入力値の検証などの不備があれば、情報漏えいや不正アクセスにつながる可能性があるとしています。アプリの脆弱性診断で問題がなかったことは、API の安全性を示すものではありません。点検の対象は、アプリが通信するサーバー側の API と公開ホストに加え、アプリに埋め込まれた認証情報や鍵を含むアプリとバックエンドの両方です。

同様の問題は Android に限らず、iOS アプリや Web サービスのバックエンド API でも起こり得ると NICT は指摘しています。iOS アプリや Web のフロントエンドも、通信内容や配布物から API の仕様を調べられる点は同じです。Android 版だけを点検するのではなく、同じ API を共有する iOS 版や Web 版も同じ範囲で確認することをおすすめします。

A2B 攻撃で狙われる API の弱点

NICT の詳細注意喚起は、今回の攻撃で主に探索・悪用の対象となった脆弱性として、SSRF、RCE、SQL インジェクション、IDOR の 4 種類を挙げています。加えて、点検項目として認証・セッション管理の不備、NoSQL インジェクション、クラウドサービス・ストレージの設定不備なども示しています。ここでは、アプリの解析結果と結び付きやすく、実務で見落とされやすい順に整理します。

IDOR / BOLA: 認証済みでも他人の情報が見える

IDOR（Insecure Direct Object Reference）は、API が利用者 ID やデータ ID などの識別子を受け取る際に、アクセス権限を確認していないことで起きる脆弱性です。OWASP API Security Top 10 2023 では、同じ問題を API1「Broken Object Level Authorization（BOLA、オブジェクト単位の認可不備）」として最上位に挙げています。

説明のため、架空の会員情報取得 API を例にします。次のリクエストは本記事で作成した例で、実在のサービスや検証結果ではありません。利用者 A（会員 ID 10023）が、自分のアクセストークンを付けて自分の会員情報を取得するリクエストです。

GET /api/v1/members/10023
Authorization: Bearer <利用者 A のアクセストークン>

利用者 A が URL の末尾を 10024 に書き換えて同じリクエストを送った場合、サーバーの応答は次の 2 つに分かれます。

後者の状態では、利用者 A は正規にログインした会員であり、認証は成功しています。それでも他人の情報が返るのは、認証は「誰か」を確認する仕組みで、「そのデータを扱ってよいか」を確認する認可とは別の処理だからです。会員 ID が連番などで推測しやすい場合、識別子を順に変えるだけで大量の情報を取得できる可能性があると NICT も指摘しています。

識別子を推測しにくい値にすることは、列挙を難しくする効果はあります。ただし、識別子の形式は認可の代わりになりません。

参考: OWASP API Security Top 10 2023「API1:2023 Broken Object Level Authorization」
“Object IDs can be anything from sequential integers, UUIDs, or generic strings.”
（オブジェクト ID は、連番の整数、UUID、一般的な文字列など、どのような形式でもあり得ます。）
https://api-security.owasp.org/editions/2023/en/0xa1-broken-object-level-authorization/

OWASP は、利用者から受け取った ID でデータにアクセスするすべての処理で、オブジェクト単位の認可を確認するよう求めています。また、セッションの利用者 ID とパラメーターの ID を比較するだけでは、一部のケースにしか対処できないとしています。家族会員、法人の管理者、店舗スタッフなど、他者のデータを扱う正当な権限がある設計では、その関係をサーバー側で判定する必要があるためです。

認証・トークン管理と管理機能の認可不備

NICT は点検項目として、認証トークンの不正発行・偽造、他者の認証情報の取得、認証回避のほか、アプリなどに固定された認証情報や暗号鍵の露出を挙げています。アプリに埋め込んだ API キーは、解析で取り出される前提で扱う必要があります。API キーが「どのアプリからの呼び出しか」を示すだけで、それだけで個人データを取得できる設計であれば、キーの漏えいがそのまま情報漏えいにつながります。

一般利用者のトークンで管理用 API を呼び出せる問題は、OWASP では API5「Broken Function Level Authorization（BFLA、機能単位の認可不備）」に当たります。BOLA がデータ単位の問題であるのに対し、BFLA は呼び出せる機能の問題です。画面にない内部 API を使った権限変更やアカウント作成は、JPCERT/CC が報告したケース B の手口と共通しています。ケース B の手口や、レート制限・トークン管理の役割と限界は『JPCERT/CC の不正アクセス注意喚起｜4 つの攻撃手口と点検手順』で解説しています。

SQL インジェクション・SSRF・RCE と設定不備

入力値の検証に関わる脆弱性も、アプリの解析でパラメーターや処理内容が分かると狙いやすくなります。NICT の記載をもとに、確認の着眼点を整理します。

SQL インジェクション・NoSQL インジェクション

API への入力を通じてデータベースに不正な処理を実行させる脆弱性です。個人情報の不正取得や認証の回避につながります。検索、絞り込み、並べ替えなど、パラメーターがクエリの組み立てに使われる API を優先して確認します。

SSRF（Server-Side Request Forgery）

外部からのリクエストによって、サーバーに意図しない通信を行わせる脆弱性です。NICT は、URL の取得、画像処理、文書変換などの機能を通じて、内部ネットワーク、クラウドのメタデータサービス、ローカルファイルへアクセスできないかの確認を求めています。プロフィール画像を URL で登録する機能などが該当し得ます。

RCE（Remote Code Execution）

外部からのリクエストで、サーバー上で不正なコマンドやプログラムを実行できる脆弱性です。NICT は、危険なデシリアライズ、任意ファイルの書き込み・上書き、不適切な管理機能の公開などを点検対象に挙げています。

クラウドサービス・ストレージの設定不備

NICT は S3、GCS、Firestore などを例に、認証なし、または本来許可されていない権限でアクセスできないかの確認を求めています。アプリがバックエンドサーバーを経由せず、クラウドのストレージやデータベースへ直接接続する構成では、そのアクセス制御の設定が認可の役割を担います。

自社の API が A2B 攻撃の対象か確認する方法

自社が影響を受けるかは、Android アプリを公開しているかではなく、公開アプリから到達できる API に不備があるかで決まります。次の手順は、NICT の推奨対策を点検の作業順に編集上整理したものです。ただし、すでに不審なアクセスなど侵害を疑う兆候がある場合は、すべての手順の完了を待たず、ログの保全、影響調査、必要な封じ込めを並行して進めてください（次章で解説します）。

認可の確認は、自社が管理し、試験の許可を得たシステムだけで実施してください。本番環境で試験する場合は、テストアカウントとテストデータの範囲、実施時間、監視部門への事前連絡を決めておくと、試験のアクセスを攻撃と誤認する事態を避けられます。

A2B 攻撃対策の点検表

次の表は、手順で確認する観点と、未確認・要対応と判断する状態の目安をまとめたものです。「区分」列では、NICT の注意喚起に記載がある観点と、本記事で運用面から追加した観点を分けています。NICT の記載事項は「推奨する対策」として示されたもので、法令上の義務ではありません。

この表は、点検を「方針を決めた」段階で止めず、「実際の設定やログで確かめた」段階まで進めることを意図しています。確認方法を決めただけの項目は、未確認として残すことをおすすめします。

NICT が推奨する侵害確認と暫定対策

NICT は Android アプリを公開する事業者に対し、「侵害の確認」「脆弱性の点検」「暫定的な緩和策」の 3 種の対策を早急に実施するよう推奨しています。脆弱性の点検項目は前章までで整理したため、ここでは侵害の確認と暫定的な緩和策を中心に解説します。

侵害の確認: ログで見るポイント

NICT は、2026 年 8 月以降のアクセスログ、API ログ、認証ログなどを確認し、可能であればそれ以前のログも確認するよう求めています。IoC との一致に加えて、通常と異なる API 操作がないかを確認することが重要です。NICT が挙げた観点を、確認するログと着眼点に置き換えると次のようになります。

SSRF の悪用を調べる場合は、外部からのリクエストに加えて、バックエンドサーバーから内部ネットワークやクラウドのメタデータサービスへ出ていく通信の記録も確認対象になります。不審なアクセスが見つかった場合、NICT は、認証の成否、アクセス先のデータ、情報の取得・変更の有無、認証情報の悪用など、影響と範囲を速やかに調査するよう求めています。

NICT が公開した IoC の扱い方

NICT は詳細注意喚起の中で、攻撃に関連する IoC の一部として送信元の IP アドレスを公表しています。一覧は今後更新される可能性があるため、本記事では転載せず、調査時点の NICT の詳細注意喚起（PDF）を直接参照することをおすすめします。

本記事の確認時点（NICT の PDF は Rev 1.1、JPCERT/CC は 10 月 9 日更新版）では、NICT が掲載した 3 件の IP アドレスは、いずれも JPCERT/CC の「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」のケース B（API 経由での不正な操作）にも掲載されています。NICT の資料は参考文献として JPCERT/CC の注意喚起を挙げていますが、両者が同一の攻撃者や同一の活動を観測したとは、どちらの公開資料にも記載されていません。アドレスの一致は事実として扱い、同一の事案と結論づけないことが適切です。JPCERT/CC のケース B には NICT の資料にない IP アドレスや User-Agent の例も掲載されているため、ログ調査では両方の最新版を確認してください。

参考: JPCERT/CC「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」
「調査時点では正規利用されている可能性もあります。」
https://www.jpcert.or.jp/at/2026/at260030.html

NICT も、IoC との一致だけで侵害の有無を断定できないため、アクセスログや通信内容と併せて総合的に判断するよう注記しています。IoC を使う際は、次の点に注意します。

• 一致した場合は、そのアクセスがどの API に、どの認証状態で、どの結果（ステータスコード、応答サイズ、処理内容）だったかを確認する。
• 一致しなかった場合も侵害がなかった根拠にはならない。公開された IoC は一部であり、攻撃者は送信元を変えられる。
• ログの保存期間が 2026 年 8 月まで届かない場合は、確認できた期間を記録し、それ以前は未確認として扱う。
• ログのタイムゾーン（UTC か日本時間か）をそろえてから、公表された観測時期と照合する。

暫定的な緩和策

NICT は、業務への影響を考慮しながら、必要に応じて次の暫定的な緩和策を実施するよう推奨しています。

• 国外からのアクセスや、不要なアクセス元からの通信を一時的に制限する。
• 不要な公開 API、管理機能、検証環境へのアクセスを停止または制限する。
• アクセス頻度や連続した識別子の指定を監視し、必要に応じてレート制限や WAF などでアクセスを制御する。
• 認証情報やトークンの漏えい・悪用が疑われる場合は、無効化・再発行を行う。
• 脆弱性が確認された場合は速やかに修正する。

さらに NICT は、直ちに修正できない場合や、重大な脆弱性の有無を確認できず暫定的な制限でもリスクを許容できる水準まで下げられない場合は、該当する API や機能、必要に応じてサービス全体の一時停止を検討するよう求めています。アプリ内の識別子を推測しにくくする、アプリを更新するといった対応だけでは、すでに公開されている API の不備は解消されない点に注意が必要です。旧バージョンのアプリは配布後も利用者の端末に残り、解析にも使えるためです。

不審な操作が見つかった場合は、ログやサーバーの状態の保全と、トークンの無効化や API の制限などの封じ込めを並行して進めます。ログの保存期間による消失を防ぐため、調査範囲が決まる前でも関連ログの取得を先に行うことをおすすめします。初動の進め方は、前述の JPCERT/CC 記事の「侵害が疑われる場合の初動対応」で整理しています。NICT は個別システムの診断や技術相談には対応していないため、社内での判断が難しい場合は、委託先やセキュリティ専門事業者に相談します。

A2B 攻撃を防ぐために見直したい API 設計

恒久対策の前提は、アプリの内部構造や API の仕様が攻撃者に知られても安全な状態を保つことです。NICT の詳細注意喚起は、まとめで次のように述べています。

参考: NICT LETTICE「【注意喚起】相次ぐ情報漏洩、その原因の一つは『アプリ解析からのサーバ攻撃』」（PDF、Rev 1.1）
「公開アプリが解析されること自体を完全に防ぐことは困難です。」
https://cynex.nict.go.jp/pdf/library/lettice/261013-01.pdf

アプリの難読化などは解析の手間を増やす効果はありますが、API の不備を補うものではありません。設計の見直しでは、次の点を優先することをおすすめします。

• 認証・認可をサーバー側で実装する。識別子を受け取るすべての API でオブジェクト単位の認可を、すべての管理用 API で機能単位の認可を確認し、権限の異なるアカウントによる自動テストをリリース前の確認に組み込む。
• アプリに秘密を置かない。アプリに埋め込む API キーは公開情報として扱い、個人データへのアクセスには利用者ごとのトークンと認可を必須にする。
• トークンの権限と有効期間を絞る。一般利用者のトークンに管理機能の権限を含めず、漏えい時に無効化できる仕組みを用意する。
• 公開範囲を縮小する。管理用 API を利用者向け API と別の経路に分け、社内ネットワークや特定の送信元からのみ到達できるようにする。旧バージョンの API と検証環境は停止時期を決めて管理する。
• 監査ログと異常検知を設計に含める。利用者 ID とアクセスしたデータの識別子をログに残し、取得件数や識別子の連続指定を検知できるようにする。

API ゲートウェイ、WAF、レート制限は、大量アクセスの抑制や既知の攻撃パターンの遮断に役立ちます。一方、IDOR / BOLA のリクエストは形式上は正常なリクエストと区別がつかず、「このデータの所有者か」は WAF やゲートウェイでは通常判定できません。これらはサーバー側の認可を前提に、被害の拡大を抑える層として位置付けます。

まとめ

A2B 攻撃は、公開 Android アプリの解析で得た API の情報を手掛かりに、バックエンドサーバーの不備を狙う手法です。アプリが解析されることは防ぎきれないため、API の棚卸し、サーバー側の認証・認可の確認、2026 年 8 月以降のログ調査を早期に進めることが対応の中心になります。

• A2B 攻撃は手法の名称で、単一の CVE への対応では解決しない。
• エンドポイントが知られることより、API 側の不備が問題になる。
• 画面での制限は、サーバー側の認可の代わりにならない。
• 認証済みでも、オブジェクト単位の認可がなければ他人の情報が漏れる。
• 旧 API や検証環境を含めて棚卸しし、管理責任者を明確にする。
• IoC との一致や不一致だけで、侵害の有無を判断しない。
• WAF やレート制限は、認可を補う層として位置付ける。

以上、最後までお読みいただきありがとうございました。