情報通信研究機構（NICT）は10月13日、【注意喚起】 相次ぐ情報漏えい、その原因の一つは「アプリ解析からのサーバ攻撃」において、脅威情報分析チームLETTICEが国内で相次ぐ情報漏えい事案の原因の一つとして、公開Androidアプリを解析し、接続先のサーバを攻撃する「A2B攻撃（App-to-Backend Attack）」を特定したと発表した。

アプリから得られるAPIなどの情報を悪用し、サーバの脆弱性を狙う手法で、iOSアプリやWebサービスにも同様のリスクがあるという。NICTは、AIによる攻撃の高度化にも警鐘を鳴らし、事業者に対策を呼びかけている。

公開Androidアプリを解析、サーバごとに攻撃手法を変える「A2B攻撃」

A2B攻撃は、一般に公開されているAndroidアプリを解析し、得られた情報をもとに、アプリの接続先であるバックエンドサーバを攻撃する手法だ。

NICTによると、今回確認された攻撃では、攻撃者はGoogle Playの日本地域で公開されているAndroidアプリを入手し、プログラムを解析。アプリが通信するサーバの接続先やAPIの構成、通信に使用するパラメータ、応答データの構造などを調べていた。

そのうえで、収集した情報をもとに攻撃対象となる箇所を特定し、個々のAPIの仕様や処理内容に合わせたリクエストを送信して、脆弱性を探索・悪用していたという。

この攻撃の特徴は、不特定多数のサーバに同じ攻撃を仕掛けるのではなく、公開アプリから得られた情報を使い、対象となるサーバごとに攻撃内容を変えている点にある。

また、認証を必要としないAPIだけでなく、利用者アカウントでログインした後に利用できるAPIも攻撃対象となる。アプリ自体に脆弱性がなくても、バックエンドサーバの認証やアクセス権限の確認などに不備があれば、不正アクセスや個人情報の漏えいにつながるおそれがある。

  • A2B攻撃の流れ。公開アプリの解析から攻撃対象の特定、脆弱性の悪用までを示している（出典：NICT）

    A2B攻撃の流れ。公開アプリの解析から攻撃対象の特定、脆弱性の悪用までを示している（出典：NICT）

SSRFやSQLインジェクションなど4種類の脆弱性が標的に

NICTによると、今回確認されたA2B攻撃では、主にSSRF、RCE、SQLインジェクション、IDORの4種類の脆弱性が探索・悪用の対象となっていた。

これらの脆弱性が悪用されると、バックエンドサーバに保存された個人情報の窃取や、外部から直接アクセスできない内部システムへの不正アクセスなどにつながるおそれがある。

例えば、SSRF（Server-Side Request Forgery）は、サーバに意図しない通信を行わせる脆弱性だ。悪用されると、通常は外部からアクセスできない内部システムやクラウド環境の情報を取得される可能性がある。

RCE（Remote Code Execution）は、サーバ上で不正なプログラムやコマンドを実行できる脆弱性で、攻撃者にサーバを操作され、情報の窃取や改ざんにつながるおそれがある。

SQLインジェクションは、データベースへの問い合わせ処理に不正なSQLを混入させる攻撃だ。成功すると、データベースに保存された顧客情報などが不正に取得・改ざんされる可能性がある。

IDOR（Insecure Direct Object Reference）は、アクセス権限の確認が不十分な場合に生じる脆弱性だ。例えば、APIに指定する利用者IDを変更するだけで、別の利用者の個人情報を取得できてしまうケースが該当する。

このように、アプリ自体が正常に動作していても、接続先のバックエンドサーバに脆弱性があれば、情報漏えいにつながる可能性がある。

特にA2B攻撃では、公開アプリの解析によってAPIの構造や通信内容などを把握し、サーバごとに攻撃を組み立てる点が特徴となる。アプリ側の制御だけでは不正なAPIリクエストを防げないため、バックエンドサーバ側で適切な認証・認可や入力値の検証を行うことが重要となる。

2026年8月以降のログ確認を推奨、3つの対策を提示

NICTは、Androidアプリを公開する事業者に対し、「侵害の確認」「脆弱性の点検」「暫定的な緩和策」の3つの対策を早急に実施するよう推奨している。

  • NICTがAndroidアプリを公開する事業者に推奨する3つの対策（出典：NICT）

    NICTがAndroidアプリを公開する事業者に推奨する3つの対策（出典：NICT）

侵害の確認では、公開しているAPIやサーバを洗い出し、不審なアクセスの有無を調査する。対象には、現在利用しているAPIだけでなく、旧バージョンのAPIやサブドメイン、検証環境、クラウド上の公開サービスなども含まれる。

特に、2026年8月以降のアクセスログ、APIログ、認証ログなどを優先的に確認し、可能であれば、それ以前のログも調査するよう求めている。

確認すべき不審な操作としては、認証なしでの大量の情報取得、連番IDを使ったアクセス、他の会員情報の閲覧・変更、不審な認証トークンの発行、管理機能の利用などが挙げられている。

脆弱性の点検では、前述の4種類に加え、認証・セッション管理の不備やクラウドストレージの設定不備なども確認する。例えば、Amazon S3やGoogle Cloud Storage（GCS）、Firestoreなどに、本来許可されていない権限でアクセスできないかを調べることを推奨している。

暫定的な緩和策としては、国外や不要なアクセス元からの通信制限、不要なAPIや管理機能の停止、WAFなどによるアクセス制御、認証情報の無効化・再発行などを挙げている。

脆弱性を直ちに修正できず、暫定的な対策でもリスクを十分に低減できない場合には、該当するAPIや機能、必要に応じてサービス全体の一時停止も検討するよう求めている。

NICTは、今回の攻撃に関連するIoC（侵害指標）として、以下の3件のIPアドレスを公開している。

  • 69.10.51[.]162
  • 210.149.87[.]120
  • 207.241.172[.]54

これらのIPアドレスは、攻撃に関連する通信の有無を調べる際の手掛かりとなる。ただし、該当するIPアドレスとの通信が確認された場合でも、それだけで侵害を断定することはできず、アクセスログや通信内容などと併せて判断する必要がある。

NICTは、攻撃手法や侵害の確認方法、脆弱性の点検項目などをまとめた詳細資料「A2B攻撃に関する注意喚起」を公開している。具体的な確認方法や対策については、同資料で確認できる。

なお、同様の問題はAndroidアプリに限らず、iOSアプリやWebサービスのバックエンドAPIでも発生する可能性がある。

NICTは、AIによってアプリの解析や脆弱性探索が効率化され、攻撃がより多くのシステムに広がる可能性にも警鐘を鳴らしている。公開アプリの解析を完全に防ぐことは難しいため、アプリ側の制御だけに頼らず、バックエンドサーバ側で適切な認証・認可や入力値の検証を行うことが重要だとしている。