A2B攻撃とは
2026年10月13日、NICTのCYNEXが「相次ぐ情報漏えい、その原因の一つは『アプリ解析からのサーバ攻撃』」という注意喚起を出し、この攻撃を「A2B攻撃（App-to-Backend）」と名付けました。
公開されているアプリを解析して、接続先のサーバーやAPIの仕様を割り出し、バックエンドの弱点を突く攻撃です。アプリ自体に脆弱性がなくても、サーバー側の認証・認可に不備があれば漏えいにつながります。
典型的な手口
- 静的解析（LLMに説明させながらAPIの仕様を洗い出す）
- アプリに埋め込まれたAPIキーの抜き取り
- 通信の傍受・改ざん（MitM）
- 署名を再現して、アプリなしでAPIを叩く
- APIの脆弱性を突く（BOLA/IDOR、余計な項目の返却、アプリ側での認可判定、古いAPI）
- 自動化・Bot化
AWSで見る「攻撃の時間軸」
- 公開前：Cognito（短命トークン・PKCE）、Secrets Manager、Verified Permissions、アテステーション
- 0〜1秒：AWS WAF（レート制限・Bot Control・ATP/ACFP）、API Gatewayのスロットリング
- 1〜5分：CloudWatchの異常検知、Contributor Insights
- 5〜15分：GuardDuty（Runtime Monitoring・RDS Protection）
- 15分〜1時間：EventBridge → Lambdaで自動封じ込め
- 1〜24時間：Detective、Athena、CloudTrail Lakeで調査
初心者がつまずきやすいポイント
- Bot Controlの「トークンなし」ルールは、既定では記録（Count）するだけでブロックしません。ブロックするにはルールを1本追加します
- Contributor Insightsはユニーク数を数えられません。「1人が何種類のIDを見たか」はLogs Insightsの
countDistinctで確かめます - 「IDを1秒に1件ずつ書き換える」ようなゆっくりした攻撃は、WAFもGuardDutyも素通りします。止められるのは、サーバー側の認可チェックとアプリのログです
記事では、4枚の図で攻撃の流れと防御の位置を整理しています。構造化ログの例やContributor Insightsのルールも載せました。
※2026年10月時点の公開情報に基づきます。