NICT、国内情報漏えいにつながる「A2B攻撃」を特定―Androidアプリ解析からサーバーを狙う手口、AIによる高度化にも警告

情報通信研究機構（NICT）は2026年10月13日、国内で相次ぐ情報漏えい事案の原因の一つとして、一般公開されたAndroidアプリを解析し、接続先のバックエンドサーバーを攻撃する手法を特定したと発表しました。NICTの脅威情報分析チーム「LETTICE」は、この手法を「A2B攻撃（App-to-Backend Attack）」と命名しています。

攻撃者はアプリの解析からAPIの接続先や通信仕様を把握し、サーバー側の認証・認可や入力値検証などの弱点を狙います。アプリ本体に脆弱性が見つからなくても、顧客情報を保管するバックエンドが攻撃を受ける点が特徴です。NICTは侵害の確認、脆弱性の点検、暫定的な緩和策という3種類の対応を示しました。NICTが同日15時に更新した詳細注意喚起（Rev 1.1、全7ページ）では、侵害調査の対象期間や、攻撃に関連するIPアドレス3件も公開しています。

NICTによるA2B攻撃の注意喚起のサマリー

• 公表日：2026年10月13日
• 公表機関：国立研究開発法人情報通信研究機構（NICT）、脅威情報分析チームLETTICE
• 攻撃手法：公開Androidアプリを解析し、接続先サーバーのAPIや通信仕様に関する情報を把握して攻撃に利用
• 被害との関係：NICTは国内の情報漏えい事案の原因の一つとして同手法を特定
• 主な問題箇所：バックエンドAPIの認可不備や、サーバー側の入力値検証などの不備
• 対象：Androidアプリ提供事業者。iOSアプリやWebサービスのAPIにも類似の問題が生じる可能性
• 推奨対応：侵害の確認、脆弱性の点検、暫定的な緩和策
• AIとの関係：アプリ解析や脆弱性探索の効率化によって攻撃対象が広がる可能性への警告。AIを使った実際のA2B攻撃の確認を示す発表ではない
• 詳細注意喚起：2026年10月13日14時公開、15時にRev 1.1へ更新（表現の軽微な修正）。7ページ構成
• ログ調査：2026年8月以降のアクセスログ・APIログ・認証ログを優先し、可能であればそれ以前も確認
• IoC：攻撃に関連するIPアドレス3件を公表。単独一致で侵害と断定しない

A2B攻撃とは―配布アプリがサーバー攻撃の手掛かりになる

A2B攻撃では、攻撃者は正規に公開されているAndroidアプリを入手して解析し、アプリとバックエンドサーバーの間で行われる通信の仕組みを調べます。アプリに含まれる情報や通信からAPIの接続先・利用方法などを把握した上で、サーバーに対して、その仕様に合わせた不正なリクエストを送ります。

アプリの画面上から操作できないAPIであっても、サーバーが外部からのリクエストを受け付け、利用者や操作対象ごとの権限確認が不十分であれば、認可されていない情報の取得や操作が可能になるおそれがあります。NICTによると、認証なしで利用できるAPIだけでなく、一般利用者としてログインした後に呼び出せるAPIも攻撃対象になります。

NICTは、事業者が非公開だと考えているサーバーの内部仕様でも、配布アプリを解析することで攻撃者に知られ得る点を問題視しています。アプリのコードや通信仕様を利用者に見せない設計と、サーバー側で権限を検証する設計は別のものです。

主な確認対象はIDOR/BOLA、SSRF、RCE、SQLインジェクション

NICTの詳細資料は、今回確認されたA2B攻撃で主に探索・悪用の対象となった脆弱性として、SSRF、RCE、SQLインジェクション、IDORの4種類を明示しています。IDORはオブジェクト単位の認可不備を指すBOLAとも関連する問題です。以下は攻撃を受けたAPIを点検する際の整理であり、個別の国内事件すべてで4種類が悪用されたという意味ではありません。

APIキーを持っている、正規アプリと同じ通信形式を使っている、といった条件だけでアクセスを許可しないことが基本です。実際の認可はAPI側で利用者・権限・対象データごとに判定する必要があります。

NICTが示した3種類の対策

NICTは公開アプリが解析されることを前提として、次の3項目を事業者へ推奨しています。

1．侵害の確認―APIとアクセスログを調べる

NICTは、アプリが使うAPIだけでなく、サブドメイン、旧バージョンのAPI、検証環境、クラウド上の公開サービスを含め、公開ホストを列挙するよう求めています。管理台帳に載っていない旧APIや検証用エンドポイントを見落とさないことが前提です。

ログについては、2026年8月以降のアクセスログ・APIログ・認証ログを優先して確認し、可能であればそれ以前もさかのぼるよう案内しています。IoCとの照合に加え、未認証での大量取得、連番IDを指定するアクセス、別会員情報へのアクセス、認証トークンの不審な発行、管理機能の利用などを調べます。

不審な通信が見つかった場合には、ログインの成否だけでなく、アクセス先のデータ、閲覧や変更の有無、認証情報の悪用の範囲まで確認することが推奨されています。

2．脆弱性の点検―サーバー側の認可と入力値検証を確認

IDOR/BOLAなどの認可不備に加え、次の項目をNICTは具体的な点検対象に挙げています。

• 認証・セッション管理：トークンの不正発行・偽造、認証回避、固定された認証情報や暗号鍵の露出
• SQL／NoSQLインジェクション：外部入力によるデータの不正な取得・変更
• SSRF：URL取得、画像処理、文書変換機能などから内部ネットワークやクラウドのメタデータサービスに到達できないか
• クラウドサービス・ストレージ：S3、GCS、Firestoreなどが未認証または過剰な権限で操作できないか
• コード実行・ファイル操作：危険なデシリアライズ、任意ファイルの書き込み・上書き、不適切に公開された管理機能

また、会員IDやデータIDを指定するAPIでは、別会員や別テナントの情報を閲覧・変更できないか、対象データとアクセス権限を組み合わせて確認します。端末アプリ上の画面制御は、サーバー側の認可の代わりになりません。

3．暫定的な緩和策―不要なAPIの停止と認証情報の見直し

NICTは、影響を受ける業務を考慮しながら、次の暫定措置を適用するよう案内しています。

• 国外からのアクセスや不要なアクセス元からの通信を一時的に制限する
• 不要な公開API、管理機能、検証環境を停止またはアクセス制限する
• APIの呼び出し頻度、連続した識別子の指定などを監視し、必要に応じてレート制限やWAFで制御する
• 認証情報やトークンの漏えい・悪用が疑われる場合は無効化・再発行する
• 脆弱性を修正できず、暫定的な制限でもリスクを許容可能な水準まで下げられない場合は、該当APIや機能、必要に応じてサービス全体の一時停止を検討する

これらは一時的な対処です。恒久対策では、攻撃者が正規アプリを経由せずAPIを直接呼び出せることを前提に、バックエンドでの認証・認可・入力値検証を修正する必要があります。

NICTが公開したA2B攻撃関連IoC―IPアドレス3件

NICTの詳細注意喚起Rev 1.1（6ページ）には、今回確認された攻撃に関連する侵害指標（IoC）の一部として、次のIPアドレスが掲載されています。誤クリックや自動リンク化を避けるため、ドットを[.]に置き換えて記載します。

NICTはこれらを「攻撃に関連するIoCの一部」と位置付けています。特定のアドレスを攻撃者の専用設備と断定する資料ではありません。該当IPから通信があっただけで侵害と判断したり、一律遮断したりするのではなく、アクセス時刻、呼び出されたAPI、認証結果、取得・変更されたデータ、通常業務の通信かどうかを照合してください。

同資料はIoCとしてIPアドレスやUser-Agentなどを挙げていますが、6ページで具体値が示されているのは上記3つのIPアドレスです。User-Agentの具体的な文字列は同ページには掲載されていません。

JPCERT/CCも10月8日に「アプリ解析からAPIへの不正操作」を注意喚起

今回のNICT発表に先立ち、JPCERT/CCは10月8日、国内組織で相次ぐ不正アクセスを受け、スマートフォンアプリの解析からAPIのエンドポイントやキーを特定する攻撃を「ケースB」として紹介しました。10月9日の更新では、不審なアクセス元の情報なども追加しています。

JPCERT/CCは、通常のアプリ画面から実行できない内部APIを通じた権限変更、不正アカウント作成、応答内容の確認、NoSQLインジェクションによる情報探索などの報告を挙げました。APIの認可制御や利用回数制限、最小権限、トークンの有効期限と失効手順を確認するよう求めています。

ただし、NICTとJPCERT/CCの資料が、完全に同じ攻撃者や全く同じ被害事案を対象にしていると公表されたわけではありません。両機関の注意喚起は、国内の公開アプリ・APIを巡る攻撃への備えとして併せて参照できます。

関連：JPCERT/CC、国内で相次ぐ個人情報漏えいに注意喚起―API悪用・既知脆弱性・Metabase攻撃を確認

AIによる解析の効率化は将来リスクとして指摘

NICTは、AIの利用によってアプリ解析や脆弱性探索が効率化され、A2B攻撃が多くのシステムへ広がる可能性にも注意を促しています。今回の発表は、AIを利用した特定の攻撃ツールの名称や、AI利用がどの被害事案で確認されたかを列挙したものではありません。

公開アプリを解析する手段が変化しても、問題の中心は、配布されたアプリからバックエンドの情報を調べられることと、サーバーが不正な要求を適切に拒否できるかにあります。

情報システム部門・アプリ運営企業が確認したいこと

モバイルアプリを外部の開発会社に委託している企業では、アプリのソースコードの診断だけでなく、アプリから接続するバックエンドAPIの設計・運用も確認対象です。アプリを公開した後の機能追加や改修で、新しいAPIが生まれた際にも管理対象へ登録する運用が考えられます。

当面の対応としては、公開APIの棚卸し、ログの保存・分析、APIごとの認証と認可、管理用エンドポイントへの外部からの到達可否、固定認証情報の扱いを確認します。特に個人情報の検索・ダウンロード・一括出力を許すAPIは、一般利用者向けのAPIと分けて権限および監視設定を点検する必要があります。

NICTの注意喚起は企業名別の被害一覧ではなく、実際の国内情報漏えいの分析を踏まえて攻撃手法を特定した資料です。現時点の公開情報だけで、最近の特定企業のアプリ侵害を一律に「A2B攻撃が原因」とすることはできません。

注意喚起を作成したLETTICEは、NICTのサイバーセキュリティネクサス（CYNEX）において2024年2月に発足した脅威情報の共同分析チームです。NICTは今回の注意喚起をシステム点検の手掛かりとして利用するよう案内する一方、個別システムの診断や改修についての技術相談は受け付けていません。具体的な調査は社内の担当者や開発・運用委託先、セキュリティ専門事業者と進める必要があります。

出典

• 【注意喚起】相次ぐ情報漏えい、その原因の一つは「アプリ解析からのサーバ攻撃」 – 情報通信研究機構（NICT、2026年10月13日）
• 【注意喚起】相次ぐ情報漏洩、その原因の一つは「アプリ解析からのサーバ攻撃」（詳細PDF、Rev 1.1・全7ページ） – NICT LETTICE／CYNEX Library
• 直近で相次いでいる国内組織における不正アクセスに関する注意喚起（JPCERT-AT-2026-0030） – JPCERT/CC（2026年10月8日公開、9日更新）