A2B攻撃とは？NICTが警告するアプリ解析とAIエージェントによるAPI侵害の実態

はじめに：国内で相次ぐ情報漏えいと「A2B攻撃」の衝撃

2026年秋、日本国内のエンタープライズ、金融機関、インフラ事業者、教育機関において、大規模な不正アクセスや個人情報漏えい事案の公表が相次いでいます。従来型の標的型メール攻撃やWebサイトの改ざんとは異なり、被害を受けた組織の多くが「Web画面上の脆弱性診断はクリアしていた」「多要素認証（MFA）を導入していた」にもかかわらず、バックエンドのデータベースから顧客情報やアカウント情報が外部に持ち出される事態が発生していました。

この不可解なインシデントの深層に対し、極めて重要な一次情報がもたらされました。2026年10月13日、国立研究開発法人情報通信研究機構（NICT）のサイバーセキュリティネクサス（CYNEX）に所属する脅威情報分析チーム「LETTICE」（Leading Expert Team for Threat Intelligence Collection and Evaluation）が緊急の注意喚起を発表。一連の情報漏えい事案の主要な原因の一つとして、一般公開されているAndroidアプリケーションをリバースエンジニアリング（逆解析）し、抽出された非公開APIの仕様を手がかりにバックエンドサーバを直接攻略する新たな攻撃手法を特定し、これを「A2B攻撃（App-to-Backend Attack）」と命名したのです。

さらに、JPCERT/CCが10月15日に公表した攻撃インフラ調査や、国内大手クラウドWAF「Scutum」を開発するビットフォレストが10月14日に公開した実測ログにより、攻撃者がAIモデルやAIエージェントを攻撃基盤に統合し、8時間弱にわたり10段階で戦術を自律変化させながらAPIを探索・侵害していた生々しい実態が白日の下に晒されました。

本記事では、NICTが警鐘を鳴らすA2B攻撃の技術的メカニズム、攻撃者が狙う4つの重大脆弱性、AIエージェントによる攻撃の高度化、そして企業が今すぐ講じるべき緊急点検項目と恒久的なゼロトラストAPI防御策について、技術と実務の両面から徹底的に解説します。

A2B攻撃（App-to-Backend Attack）の全貌と仕組み

攻撃の基本ステップ：公開アプリからAPIへの直接バイパス

A2B攻撃（App-to-Backend Attack）とは、攻撃者がGoogle Playなどの公式ストアから一般ユーザーと同様に正規のモバイルアプリ（主としてAndroidアプリ）を入手し、そのバイナリコードを解析することで、通常は外部にドキュメント化されていないバックエンドサーバのAPI仕様、通信エンドポイント、パラメータ体系、認証方式を暴き出し、アプリを経由せずに直接バックエンドサーバへ攻撃リクエストを送り込む手口です。

攻撃の流れは、大きく以下の4段階に分類されます。

1. 公開バイナリの正規入手と逆コンパイル
   攻撃者は標的企業のAndroidアプリ（APKまたはAABファイル）を公式ストアからダウンロードします。その後、APKTool、JADX、Ghidraといった逆コンパイルツールや、バイナリ解析を支援する生成AIツールを活用し、DEXバイトコードからJavaやKotlinの可読コードを復元します。
2. 非公開APIエンドポイントとパラメータの抽出
   復元されたソースコードやマニフェストファイル、アセット内を探索し、通信先のホスト名、REST APIエンドポイントのURLパス（例: /api/v2/users/profile）、リクエストヘッダーの構造、送信されるJSONキー、さらにはコード内に誤って埋め込まれたAPIキーやシークレットトークンを網羅的にリストアップします。
3. クライアント制限の完全迂回（バイパス）
   通常、スマートフォンの画面（UI）上では、入力文字数の制限、プルダウンによる選択肢の固定、クライアントサイドでのバリデーション（入力値検証）が施されています。しかし攻撃者は、スマートフォン画面を一切操作せず、curlやカスタムスクリプト、APIテストツールを用いて、細工したHTTP/HTTPSリクエストをバックエンドサーバへ直接送信します。
4. サーバ仕様に最適化された精密攻撃の実行
   不特定多数のWebサーバに向けた画一的なスキャンとは異なり、攻撃対象のサーバが実際に処理するパラメータ名やデータ構造に合致したリクエストを組み立てるため、サーバ側の入力不備や認可漏れを極めて高い命中精度で突くことができます。

【従来のWeb攻撃】
攻撃者 ---> [汎用スキャンツール] ---> Webブラウザ向け公開ページ ---> WAF / サーバ
※ 汎用シグネチャに引っかかりやすく、検知・遮断が比較的容易

【A2B攻撃（App-to-Backend Attack）】
公式ストア ---> [公開Androidアプリ] ---> [逆アセンブル＆AI解析]
                                              |
                                      非公開API仕様・キー抽出
                                              |
攻撃者 (AIエージェント) ------------------------+---> [直接APIリクエスト] ---> バックエンドサーバ
※ アプリ画面を迂回し、正規フォーマットを模倣して認証・認可の隙間を突く

なぜアプリが無害でもバックエンドが破られるのか

A2B攻撃の本質的な恐ろしさは、「配布されているスマートフォンアプリ自体には一切の脆弱性が存在しない場合でも成立する」という点にあります。

多くの開発現場では、「アプリの通信内容は一般のWebブラウザのURLバーには表示されない」「通信経路はHTTPS（TLS）で暗号化されている」「バイナリコードをわざわざ分解して読む人間などいないだろう」という、いわゆる「隠蔽によるセキュリティ（Security through Obscurity）」の過信が根強く残っていました。

その結果、「画面側で入力チェックを行っているからサーバ側では省略しても大丈夫だろう」「このAPIは自社の公式アプリからしか呼ばれない前提だから、厳密なユーザー認証や認可判定を入れなくても内部APIとして機能する」といった誤った設計判断がバックエンド側に温存されてきました。

攻撃者がアプリを分解してAPI仕様を完全に手に入れた瞬間、その「隠蔽の壁」は完全に無力化されます。クライアント側に依存したセキュリティは、アプリのバイナリが攻撃者の手元に渡った時点で破綻しているのです。

攻撃者が狙う「4つの重大脆弱性」とその手口

NICT LETTICEが実際のインシデントおよび脅威動向を詳細に分析した結果、A2B攻撃において攻撃者が特に執拗に探索し、侵害に成功している脆弱性は以下の4つに集約されます。

1. IDOR / BOLA（オブジェクトレベルの認可不備）

• 概要: Insecure Direct Object Reference（IDOR）、またはOWASP API Security Top 10で筆頭に挙げられるBroken Object Level Authorization（BOLA）です。
• 手口: アプリ内のコードから、ユーザーのマイページや契約情報を取得するAPIエンドポイント（例: GET /api/v1/customer?account_id=98765）が特定されたとします。攻撃者は正規に取得したテスト用アカウントでログイン後、認証トークンは有効なまま、リクエスト内の account_id パラメータを連番（98766, 98767…）や推測可能なIDに書き換えて直接送信します。
• 影響: バックエンドサーバが「アクセスしているユーザー自身が、指定された account_id の正当な所有者であるか」をデータベース照合時などに厳密に認可検証していなければ、わずか数分間で数万件から数百万人分の個人情報、クレジットカード明細、口座情報が外部へ流出します。

2. SSRF（Server-Side Request Forgery）

• 概要: バックエンドサーバが、外部から指定されたURLやアドレスパラメータに対して意図しないリクエストを発行してしまう脆弱性です。
• 手口: アプリ内の画像プレビュー機能、外部Webhook連携、PDF帳票生成APIなどに、URLを指定するパラメータ（例: url=https://example.com/image.png）が含まれている場合、攻撃者はここを内部IPアドレス（http://127.0.0.1/admin やクラウド環境のメタデータエンドポイント http://169.254.169.254/latest/meta-data/）に改ざんします。
• 影響: サーバ内部のIAMロール権限やクラウドアカウントのマスターシークレットキーが窃取され、システム全体の完全な乗っ取りにつながります。

3. RCE（Remote Code Execution / リモートコード実行）

• 概要: サーバ上で攻撃者が意図した任意のシステムコマンドやコードを実行されてしまう致命的な脆弱性です。
• 手口: アプリからバックエンドへ送信されるシリアライズデータ（Javaオブジェクト、JSON、YAML、XML等）のデシリアライズ不備や、バックエンドで実行される画像処理ライブラリ、ファイル変換ツールへの引数受け渡しにおけるサニタイズ漏れを突きます。
• 影響: バックエンドサーバにWebシェル（遠隔操作バックドア）が設置され、内部ネットワークへのラテラルムーブメント（横展開）の足がかりとされます。

4. SQLインジェクション（SQLi）

• 概要: データベースに対するクエリ組み立てにおいて、入力パラメータのエスケープやプレースホルダ適用を怠ったことで生じる古典的かつ破壊的な脆弱性です。
• 手口: Web画面では文字種制限がかかっていても、直接APIを叩くことで検索条件パラメータやソートキーパラメータに不正なSQL構文（' UNION SELECT ... --）を注入します。
• 影響: データベーステーブル全体の全件ダンプ（抽出）、管理者権限の奪取、データの不可逆な改ざんが発生します。

従来の攻撃と何が違うのか？A2B攻撃の比較検証

A2B攻撃がなぜこれほどまでに多くの企業で発見が遅れ、被害が深刻化したのか。従来の一般的なWebアプリケーション攻撃との差異を比較表で整理します。

この比較から明らかなように、A2B攻撃は「標的企業の内部構造をアプリを通じてカンニングした上で、正規リクエストの仮面を被って弱点を突く」ため、旧来の境界型防御や静的WAFでは検知が極めて困難なのです。

AIエージェントが悪用される新たな次元：8時間自律攻撃の脅威

A2B攻撃の脅威を決定的なレベルに引き上げているのが、攻撃側における「生成AIおよび自律型AIエージェントの本格的な悪用」です。

国内WAFが観測した「10段階の自律シフト」攻撃

国内の代表的クラウドWAF「Scutum（スキュータム）」を提供するビットフォレスト社は、2026年10月10日夜から14日にかけて、自社監視網において「攻撃元がAIエージェントかどうかを判別するロジック」を試験導入し、日本企業への実際の攻撃ログを観測・公開しました。

その中で確認された最も象徴的な事案が、「1つの攻撃主体から8時間弱にわたり、10段階に推移した自律攻撃」です。

従来のボットネットや攻撃ツールは、指定された単一のスクリプト（例: パスワード総当たりやSQLiペイロードの連打）を機械的に実行するだけでした。しかし、観測されたAIエージェント攻撃は、サーバ側のHTTPレスポンスやエラーメッセージを逐次「理解」し、それに応じて攻撃ツールやアプローチを自律的に切り替えていました。

• 第1段階〜第3段階（偵察・高速スキャン）: 秒間約35件、延べ1万件に及ぶ高速スキャンを実施し、アクセス可能なエンドポイントとステータスコード（200、401、403、404、500）の応答マップを作成。
• 第4段階〜第6段階（パラメータ解析と脆弱性探索）: 401（未認証）や403（認可不可）が返ったエンドポイントに対し、ヘッダーにダミーのBearerトークンやAPIキーの形式を差し替えて応答の変化を観察。
• 第7段階〜第8段階（認証突破の試行）: 約250件に絞り込んだログイン総当たり試行を行い、エラーメッセージの違いから有効なアカウント体系を推測。
• 第9段階〜第10段階（アプリ解析に基づくAPI攻略・フォーム連投）: アプリ由来と見られる非公開パラメータを注入し、データベースや内部サービスへのアクセスを試行。

ビットフォレスト社の分析によれば、このAIエージェントは「Qwen 3.8 Flash Next」や「GLM-5.3 Flash」といった、安価かつ高速に動作する最新オープン系LLMを基盤モデルとして採用していることが判明しています。

サイバーセキュリティクラウドによる分散攻撃の観測

さらにサイバーセキュリティクラウド社の観測（2026年10月9日）でも、「わずか40分間で326個のIPアドレスを動的に使い分け、1,200件超のアクセスを分散実行する」という、WAFのIP制限（レートリミット）を回避する知能的なAIエージェントの振る舞いが確認されています。

リバースエンジニアリングで得られたAPI仕様をAIモデルにプロンプトとして入力し、ReAct（Reasoning and Acting）フレームワークやTool Calling機能を用いて「侵入手順の立案・実行・結果評価・次手実行」のループを自律回転させる環境が、すでに攻撃者の標準ツールキットになりつつあるのです。

企業のセキュリティ設計における根本的盲点：隠蔽による安全の崩壊

なぜ、これまで多くの企業がこの脅威に対処できなかったのでしょうか。その背景には、モバイルアプリ開発とインフラ運用の間に横たわる「構造的な盲点」が存在します。

モバイルアプリとWebブラウザの非対称性

Webブラウザの場合、開発者ツール（F12）を押せば誰でも通信内容やHTMLソースを見ることができます。そのため、Web開発者は「通信内容が見られること」を最初から前提として開発します。

しかしモバイルアプリの場合、コンパイルされてバイナリ化されている安心感に加え、OSのサンドボックス構造やHTTPS通信により、「中身はブラックボックスである」という心理的錯覚に陥りがちでした。さらに、以下のような開発実態が拍車をかけています。

1. アプリ専用APIのアクセス制限の甘さ:
   モバイル環境の通信は電波状況によって途切れやすいため、再試行処理（リトライ）を頻繁に行います。そのため、Web向けAPIに比べてレート制限の閾値が意図的に緩く設定されているケースが散見されます。
2. ハードコードされた機密情報:
   外部サービス（プッシュ通知、分析基盤、地図API等）のSDKを初期化する際、秘密鍵やクライアントシークレットをアプリのリソースファイルやソースコード内に直接書き込んでしまうミスが後を絶ちません。
3. レガシーAPIの放置（ゾンビAPI）:
   アプリの過去バージョンを利用しているユーザーをサポートするために、何年も前に作成した非推奨API（古い認証ロジックや入力チェックの甘いAPI）が、サーバ上で稼働し続けているケースが極めて多く見られます。

サードパーティ委託・シャドーAPIの管理不備

近年相次ぐ情報漏えい事案の中には、自社の基幹システムではなく「業務委託先が構築した問い合わせ管理システムやキャンペーン用アプリのバックエンド」が狙われた事例が多数含まれています。

元請け企業がアプリの表面的な機能検収だけを行い、バックエンドAPIの認可実装やセキュアコーディング規約の遵守状況まで監査していなかった結果、委託先が開発した脆弱なAPIから侵入され、グループ全体の顧客データが漏えいするというサプライチェーン攻撃の構図が確立してしまっています。

被害を防ぐための具体的処方箋：今すぐできる緊急対応と恒久対策

NICT、JPCERT/CC、ならびに情報セキュリティ推進機構（IPA）のガイダンスに基づき、企業が講じるべき「今日からできる緊急対策」と「根本的な恒久対策」をまとめます。

【緊急対策】侵害の確認と応急措置（今日着手すべき3項目）

1. 公開API・エンドポイント・資産の緊急棚卸し

• 自社がインターネット上に公開しているすべてのドメイン、サブドメイン、クラウドエンドポイント（API Gateway、Load Balancer）を再リスト化する。
• 過去の古いアプリバージョン専用に残されている旧API、ステージング環境、開発用エンドポイントが外部からアクセス可能になっていないか点検し、不要なエンドポイントは即刻停止・閉鎖する。

2. 2026年8月以降のAPIアクセスログの徹底調査

• 認可不備（BOLA/IDOR）の兆候: 連続したユーザーID、アカウント番号のパラメータを高速または継続的に指定しているアクセスログがないか確認。
• 異常なトークン発行: 通常と異なる時間帯や海外IPから、認証トークンが大量発行・再発行されていないか。
• エラーレートの急増: HTTP 401（Unauthorized）、403（Forbidden）、500（Internal Server Error）が特定のIPや同一User-Agentから集中して発生していないか。

3. 暫定的なアクセス制御と制限の適用

• 海外からのアクセスが不要な国内向けサービスであれば、GeoIPフィルタリングにより海外IPからのAPIアクセスを一時的に制限する。
• 同一IPまたは同一セッションからのAPIリクエスト頻度に対し、厳格なレートリミット（Rate Limiting）を適用する。
• ソースコード内への埋め込みが発覚したAPIキーやトークンは直ちに無効化し、再発行と同時にバックエンド側の検証ロジックを更新する。

【恒久対策】ゼロトラストAPIアーキテクチャへの刷新

1. 「クライアントは侵害・解析される前提」のゼロトラスト設計

• アプリは公開情報: スマートフォンアプリに含めたコード、設定、文字列は、世界中の攻撃者に読まれている前提で設計する。絶対に秘密情報をアプリ内に保持しない。
• サーバサイド認可の徹底（BOLA対策）: すべてのAPIリクエストにおいて、「JWT等のトークンに含まれる実行者ID」と「リクエスト対象のリソース所有者ID」が一致していることを、APIエンドポイントおよびデータベースクエリの直前で二重に検証する。

2. アプリケーション防御（AppSec）の多層化

• コード難読化と耐改ざん性: ProGuard、R8、DexGuard等を利用し、クラス名・メソッド名の難読化、文字列の暗号化を実施する。
• 証明書ピニング（SSL/TLS Pinning）: アプリとバックエンド間の通信において、正規のサーバ証明書の公開鍵をアプリ内に固定保持し、プロキシツール（Burp Suite等）による中間者傍受や通信解析を困難にする。
• デバイス整合性検証: Google Play Integrity API や Apple App Attest を導入し、正規ストアからインストールされた改ざんのないアプリ環境からの通信であるかをサーバ側で暗号学的に検証する。

3. コンテキスト認識型・AI対応WAF/API Gatewayの配備

• 静的なURLパターンマッチングだけでなく、リクエストヘッダーの論理的整合性、APIコール順序（画面遷移と一致しているか）、通信間隔の人間らしさをAI/機械学習でスコアリングする振る舞い検知型WAFを導入する。
• API定義書（OpenAPI / Swagger）に厳格に準拠した通信のみを通す「スキーマバリデーション」をAPI Gatewayレベルで強制する。

よくある質問（FAQ）

Q1. A2B攻撃はiOSアプリやWebサイトでも発生しますか？

A. はい、まったく同様に発生します。NICTの今回の注意喚起では、APKファイルの入手や逆コンパイルが比較的容易なAndroidアプリが主たる調査対象とされましたが、iOSアプリのIPAバイナリ解析や、Webブラウザ側のJavaScriptバンドルコード（Webpack等の生成物）を解析してバックエンドAPIを直接狙う手口も構造上完全に同一です。すべてのAPIバックエンドで同様の警戒が必要です。

Q2. アプリコードを難読化（ProGuard等）していればA2B攻撃は防げますか？

A. 難読化だけでは防げません。難読化は攻撃者の解析コストを増やし時間を稼ぐ「遅延策」にはなりますが、通信ログのプロキシキャプチャや動的解析（Frida等のフッキングツール）、あるいは最新のAIによる制御フロー解析を組み合わせることで、API仕様の特定は最終的に突破されます。根本的な対策は、アプリをどれだけ解析されても悪用を許さない「バックエンドサーバ側の厳格な認証・認可と入力検証」です。

Q3. 従来のシグネチャ型WAFでAIエージェントによる攻撃を遮断できますか？

A. 従来のシグネチャ型WAFだけでは遮断が極めて困難です。AIエージェントは正規のAPIスキーマに沿ったリクエスト構文を組み立て、IPアドレスを小刻みに分散させながら、サーバの応答に合わせて低速かつ知能的にアプローチを変更します。遮断には、リクエストの頻度・間隔を評価するレートリミットや、API呼び出しシーケンスの論理的一貫性を判定する振る舞い分析型WAF、デバイス整合性検証の併用が不可欠です。

Q4. アプリ開発を外部ベンダーに委託している企業は、まず何を確認すべきですか？

A. まず委託先に対して「過去バージョンを含む公開APIエンドポイント一覧」「各APIにおけるオブジェクトレベル認可（BOLA）の実装状況」「アプリ内にハードコードされた秘密情報の有無」の3点を至急照会してください。また、単なるアプリ機能の受け入れテストだけでなく、第三者のセキュリティ専門企業による「API診断」や「ペネトレーションテスト（侵入テスト）」を委託要件に組み込むことが極めて重要です。

まとめ：アプリを「安全な境界」と信じる時代の終焉

NICTによる「A2B攻撃」の特定と公表は、長年アプリケーション開発の現場に潜んでいた「アプリの内側は安全である」「見えないものは攻撃されない」という暗黙の前提に終止符を打つ決定打となりました。

さらに、AIエージェントの進化は、リバースエンジニアリングの参入障壁を劇的に引き下げ、脆弱性の探索と悪用のスピードを人間の対応能力を超えた領域へと加速させています。今や、公開されたアプリは「攻撃者にとっての仕様書」であり、インターネットに面したすべてのAPIは容赦ない自動攻撃の標的となっています。

企業が守るべきは、スマートフォン上の画面ではなく、裏側でデータを保持するバックエンドサーバそのものです。ゼロトラストの思想をエンドポイントだけでなく「APIアーキテクチャ」の芯まで徹底し、公開資産の総点検とサーバ側認可の再構築を直ちに進めることが、次なる情報漏えいを防ぐ唯一の道です。

参考ソース

• 【注意喚起】相次ぐ情報漏洩、その原因の一つは「アプリ解析からのサーバ攻撃」― AIで高度化する脆弱性探索、Androidアプリを手がかりにしたA2B攻撃に注意 ―（NICT CYNEX レポート / 2026年10月13日）
• 【注意喚起】相次ぐ情報漏えい、その原因の一つは「アプリ解析からのサーバ攻撃」（NICT プレスリリース / 2026年10月13日）
• 情報漏えいを招く新手口「A2B攻撃」とは？ NICTが暴いた実態と緊急対策（＠IT / 2026年10月15日）
• 国内WebサイトへのAIエージェント攻撃を観測 「8時間弱」続いた攻撃の推移を公開 国内セキュリティベンダー（ITmedia AI＋ / 2026年10月15日）
• AIエージェントによるウェブサイトへの攻撃の注意喚起（ビットフォレスト WAF Tech Blog / 2026年10月14日）
• 国内で相次いで公表された不正アクセスによる情報漏えい事案に関する調査結果（JPCERT/CC / 2026年10月15日）

関連記事

• AI基盤・デジタル主権・サイバーリスクの事実検証：一次情報から読み解く5つのシグナル
• 能動的サイバー防御が本日10月1日施行：警察・自衛隊の「侵入・無害化」解禁と日本のインフラ防衛
• AIエージェントに「身分証」を——KYA相互運用フレームワークとは