公開アプリからサーバを狙う「A2B攻撃」とは NICTの注意喚起を解説

NICT(情報通信研究機構)は2026年10月13日、国内で相次ぐ情報漏えいの原因の一つとして、公開アプリを解析してサーバを攻める手法を特定したと注意喚起しました。NICTの脅威情報分析チームLETTICEが、この手法を「A2B攻撃(App-to-Backend Attack)」と名付けています。総務省も同じ日に、この注意喚起を踏まえた対応を事業者に呼びかけました。

速報の内容は、NICT、公開アプリの解析を悪用した攻撃に注意喚起 サーバ側の点検をにまとめています。この記事では、攻撃の背景、狙われる弱点、そして自社がアプリやWeb APIを出している場合に何を点検するかを、NICTの原文に沿って深掘りします。攻撃の手順や再現の方法は扱いません。

A2B攻撃とは何か

A2B攻撃は、公開されているアプリの「解析」と、そこで分かった情報を使った「サーバへの攻撃」を組み合わせたものです。流れは、NICTの資料で次のように示されています。

攻撃者は、一般に公開されているAndroidアプリを入手し、プログラムを解析します。これにより、アプリが通信するサーバの接続先、API(アプリとサーバが情報をやり取りする仕組み)のエンドポイント、パラメータ、応答データの構造などを調べます。そのうえで、対象のサーバの仕様に合わせた攻撃を組み立てて実行します。

この攻撃の特徴は、不特定多数のサーバに同じ攻撃をばらまくのではなく、サーバごとに攻撃内容を変える「狙い撃ち」である点です。アプリを出している会社から見ると、一般には公開していないつもりのサーバの内部仕様が知られ、自社の弱点をピンポイントで突かれることになります。

重要なのは、アプリ自体に脆弱性がなくても被害が起こり得ることです。攻撃者はアプリを介さず、サーバのAPIを直接操作できます。認証が不要なAPIだけでなく、ログイン後に使うAPIも、サーバ側のアクセス制御に不備があれば対象になります。

なぜ今、注意喚起なのか

2026年の秋は、大量の個人情報が漏えいする事案が国内で相次ぎました。LETTICEは独自の調査で、その原因の一つがA2B攻撃だと特定しました。同じ時期に、JPCERT/CC(10月8日)、個人情報保護委員会(10月7日)、国家サイバー統括室(10月9日)、総務省(10月9日)も、相次ぐ不正アクセスへの注意喚起を出しています。

NICTは、AIの活用でアプリの解析や脆弱性の探索が効率化されている点にも注意を促しています。これまで手間のかかった作業が効率化されると、同じ攻撃がより多くのシステムに広がるおそれがあります。また、同様の問題はAndroidアプリに限らず、iOSアプリやWebサービスのバックエンドAPIでも起こり得るとしています。

主に狙われている4つの弱点

NICTは、A2B攻撃で主に狙われている脆弱性として、次の4種類を挙げています。いずれも、守る側が自社のサーバで「ないか」を確かめるためのものです。

とくにIDOR(BOLAとも呼びます)は、理解しておきたい弱点です。たとえば、自分の情報を取得するAPIで、リクエストの中のID番号を書き換えるだけで、他の利用者の氏名やメールアドレスが取得できてしまう、という問題です。IDが連番など推測しやすい形だと、順番にたどって大量の情報が漏れるおそれがあります。

自社は関係あるか

次のいずれかに当てはまる会社が対象です。

• 社外向けのアプリ(会員アプリ、予約、ネット通販など)を出している会社
• 社内向けのアプリを配っている会社
• アプリがなくても、Webサービスのバックエンド(APIやサーバ)を公開している会社
• 上記を開発会社や運用会社に委託している会社。点検の実務は委託先が担うことが多いため、情シスは「誰が何を確かめるか」を整理します

アプリやAPIを一つも公開していない会社は、この攻撃の直接の対象ではありません。ただし、取引先や委託先のサービスを通じて自社のデータが扱われている場合は、相手の対応状況を確かめておくと安心です。

情シスがやること(NICT推奨の3つを深掘り)

NICTは、Androidアプリを公開する事業者に、次の3つを早急に行うよう推奨しています。アプリやAPIを委託している場合は、委託先と分担して進めます。

1. 侵害の確認(すでに攻撃を受けていないか)

• 公開しているAPIとホストを洗い出します。アプリが使うAPIのほか、サブドメイン、旧バージョンのAPI、検証環境、クラウド上の公開サービスも対象に含めます。
• 2026年8月以降のアクセスログ・APIログ・認証ログを確認し、NICTが公表したIoC(侵害指標。IPアドレスやUser-Agentなど)との一致や、不審なアクセスがないかを調べます。可能であれば、それより前のログも確認します。
• 認証なしでの大量の情報取得、連番IDを使ったアクセス、他会員情報の閲覧・変更、認証トークンの不審な発行、管理機能の利用など、通常と異なるAPIの操作がないかを見ます。
• 不審なアクセスが見つかったら、認証が成功したか、どのデータにアクセスされたか、情報が取得・変更されたかなど、影響の範囲を速やかに調べます。

IoCは、ログ点検の手がかりとして使います。NICTは、IoCとの一致だけで侵害を断定することはできないとして、ログや通信内容と併せて総合的に判断するよう書いています。

2. 脆弱性の点検(狙われる弱点がないか)

NICTは、次の点を重点的に点検するよう挙げています。

• 認可不備(IDOR/BOLA): 会員IDなどの識別子を変えて、他人や他テナントの情報を見たり変えたりできないか
• 認証・セッション管理の不備: 認証トークンの不正発行・偽造・認証回避ができないか。固定の認証情報や暗号鍵が露出していないか
• SQL・NoSQLインジェクション: 外部からの入力でデータベースの情報を不正に取得・変更できないか
• SSRF: URLの取得、画像処理、文書変換などの機能を通じて、内部ネットワークやクラウドのメタデータ、ローカルファイルにアクセスできないか
• クラウドサービス・ストレージの設定不備: S3、GCS、Firestoreなどに、認証なしや本来許可されていない権限でアクセスできないか
• コード実行・ファイル操作: 危険なデシリアライズ、任意のファイルの書き込み・上書き、不適切な管理機能の公開がないか

3. 暫定的な緩和策(すぐに直せないとき)

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

恒久的な対策として設計や実装を見直すときは、攻撃者がアプリを介さずにAPIを直接操作できることを前提に、アプリ側の制御だけに頼らず、サーバ側で認証・認可と入力値の検証を行うことが重要だと、NICTは書いています。

委託先・開発会社への聞き方(編集部の整理)

アプリやAPIを外部に委託している会社は、次を文書で確かめると、分担が決めやすくなります。

• 自社のどのアプリ・API・公開サーバが対象になり得るか。旧バージョンのAPIや検証環境が、外から見える状態で残っていないか
• 2026年8月以降のアクセスログ・認証ログが残っていて、IoCと照らした点検ができるか
• 上の4つの弱点(SSRF・RCE・SQLインジェクション・IDOR)と、クラウドストレージの設定を点検してもらえるか。結果をいつ報告してもらえるか
• 緊急時に、不要なAPIの停止やアクセス制限、認証情報の再発行を、どれだけ早く実施できるか

書かれていないこと、この記事で扱わないこと

• 攻撃の具体的な手順や再現の方法。NICTは注意喚起の詳細(攻撃手法、主に狙われる脆弱性、確認・対策方法、IoC)をCYNEX LibraryのPDFで公開しています。点検の実務は、公表資料を手がかりに、社内のセキュリティ担当や開発・運用の委託先、専門事業者と進めてください。
• 被害にあった具体的な企業名や件数。今回の注意喚起は、個別の事案の公表ではありません。
• A2B攻撃と、個別の漏えい事案との一対一の結びつき。NICTは「原因の一つ」としています。

2026年10月13日時点の内容です。