A2B攻撃とは｜公開アプリを解析してサーバーを狙う手口。NICTと総務省の注意喚起(2026年10月13日)と、アプリを出している会社が今やること

何が起きたか(2026年10月13日の発表)

NICTの脅威情報分析チームLETTICE(レティス)は2026年10月13日、国内で相次ぐ情報漏えいの原因の一つとして、公開されているAndroidアプリを解析し、その結果を悪用してアプリの接続先のサーバーを攻撃する手口を特定した、と発表しました。手口には「A2B攻撃(App-to-Backend Attack)」という名前が付けられ、仕組みと、アプリを出している事業者に推奨する3種類の対策をまとめた注意喚起が公開されています。

総務省は同じ日に、この注意喚起を受けた形で事業者と関係団体に向けた注意喚起を出しました。総務省は10月9日にも、相次ぐ漏えいを受けて不正アクセス対策の注意喚起を出しており、今回はその続報にあたります。総務省の文書は、アプリ自体に脆弱性がなくてもサーバー側の脆弱性が悪用されれば漏えいにつながる、利用者側からの通信は信頼できるとは限らないことを前提に、アプリ側の制御だけに頼らずサーバー側で認証・認可や入力値の検証を行うことが重要だ、と書いています。

この秋の漏えいの多くで、各社の公表は「不正アクセス」までで、手口は明かされていません。NICTの発表は、その一部について手口が分かったという位置づけです。NICTは社名を挙げていません。この記事の末尾で関連づけている事案も、A2B攻撃だったとNICTや各社が公表しているわけではなく、公式アプリのサーバーが経路だったと公表されている、という共通点で並べています。

2026年10月15日には、JPCERT/CCも攻撃元のサーバーの調査結果を公表しました。NICTの注意喚起を参考情報に挙げ、攻撃者がAndroidアプリの配布ファイルを解析して接続先のAPIを特定し、SSRFなどの弱点がないかを調べていた痕跡を確認したとしています。別のサーバーでは、Flutter(複数の環境向けにアプリを作る仕組み)で作られたアプリの解析に使うツールに関連するファイルも見つかっています。

JPCERT/CCは同じ調査で、攻撃者がAIを使って既知の脆弱性のスキャンやAPI経由の攻撃をしていたことも確認したとしています。どの会社の事案かは、JPCERT/CCも書いていません(2026-10-21時点)。

出典: NICT「【注意喚起】相次ぐ情報漏えい、その原因の一つは『アプリ解析からのサーバ攻撃』」(プレスリリース、2026-10-13) / 総務省「不正アクセスによる情報漏えい等の事案を踏まえた対応について(公開アプリの解析情報を悪用した攻撃への注意喚起)」(2026-10-13) / 総務省「不正アクセスによる情報漏えい等の事案を踏まえた対応について(注意喚起)」(2026-10-09) / JPCERT/CC Eyes「連続不正アクセス事案の攻撃手法に関する調査」(2026-10-15)

A2B攻撃の仕組み(4つの段階)

スマートフォンアプリは、それ単体では動いていません。会員の登録やログイン、注文の履歴の表示といった機能は、アプリがインターネット越しにサーバー(バックエンドサーバー)へ問い合わせて動いています。アプリとサーバーの間の窓口がAPI(Application Programming Interface)です。NICTの注意喚起に沿って、A2B攻撃の流れを4つの段階に分けると次のようになります。

• 公開アプリの入手・解析: 攻撃者は、Google Playの日本地域で公開されているAndroidアプリを入手し、プログラムを解析して、アプリが通信するサーバーの接続先、APIの構成、通信で使うパラメータ(送る項目)、応答データの構造を調べます
• 攻撃対象の特定: 解析結果から、サーバー側で攻撃の対象になりそうな箇所(どのAPIに、どんな値を送ると、何が返るか)を絞り込みます
• 対象サーバーに合わせた攻撃の実行: 個々のAPIの仕様に合わせたリクエストを送って、弱点を探し、見つかれば悪用します。不特定多数のサーバーに同じ攻撃を試すのではなく、相手ごとに攻撃の中身を変えるのが特徴です
• サーバーの弱点の悪用: サーバーに弱点があれば、内部のシステムやデータベースに不正にアクセスされ、会員情報などが取られます

アプリを出している側から見ると、一般には公開していないつもりのサーバーの内部仕様が攻撃者に知られ、自社の弱点をピンポイントで狙われる、ということになります。NICTは、ログインしなくても使えるAPIだけでなく、利用者としてログインした後に使えるAPIも攻撃の対象になりうる、と書いています。一般利用者向けに公開している機能でも、サーバー側のアクセス制御に不備があれば悪用されます。

NICTは、AIの活用でプログラムの解析や脆弱性の探索が効率化され、こうした攻撃がより多くのシステムに広がる可能性にも注意が必要だ、としています。これは懸念として書かれているもので、個々の事案でAIが使われたと確認された、という意味ではありません。

出典: NICT 脅威情報分析チームLETTICE 注意喚起の本文PDF(全7ページ、Rev 1.1 2026-10-13 15:00更新) / NICT CYNEX Library「【注意喚起】相次ぐ情報漏洩、その原因の一つは『アプリ解析からのサーバ攻撃』」(2026-10-13)

狙われている4種類の弱点

NICTが、今回確認された攻撃で主に探索・悪用の対象になっているとして挙げた脆弱性は4種類です。どれも、アプリではなくサーバー側のプログラムや設定の問題です。

このうちIDORは、NICTの例でいえば「自分の情報を取得するAPIで、リクエスト中の識別子を変えるだけで他の利用者の情報が取れてしまう」という不備です。難しい技術は要りません。だからこそ、アプリの通信の仕組みが分かれば真っ先に試されます。

出典: NICT 脅威情報分析チームLETTICE 注意喚起の本文PDF(全7ページ、Rev 1.1 2026-10-13 15:00更新)

アプリを出している会社が今やること(NICTの3種類の対策)

NICTは、Androidアプリを公開している事業者に、次の3種類の対策を早急に実施するよう推奨しています。順番も、この順です。自社で開発していない会社は、開発会社や運用の委託先に、この3つをそのまま依頼することになります。

1. 侵害の確認(すでに入られていないか)

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

2. 脆弱性の点検(弱点が残っていないか)

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

3. 暫定的な緩和策(直すまでの間、被害を広げない)

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

NICTは、恒久的な対策としてシステムの設計・実装を見直す際には、攻撃者がアプリを介さずにAPIを直接操作できることを踏まえ、アプリ側の制御だけに依存せず、サーバー側で適切な認証・認可や入力値の検証を実施することが重要だ、と書いています。総務省の注意喚起も同じ点を強調しています。アプリを解析されること自体を完全に防ぐのは難しい、というのがNICTの前提です。

自社で開発していない会社が、開発会社・運用委託先に聞くこと

アプリを外部に発注している会社では、上の3つをそのまま依頼したうえで、次の点を文章で答えてもらうと、状況がつかめます。答えが返ってこない、または「アプリ側で制御しているので問題ない」という答えだけが返ってくる場合は、この手口への備えができていない可能性があります。

• 公開しているAPIとサーバーの一覧はあるか。旧バージョンのAPIや検証環境が、まだインターネットから見える状態になっていないか
• 会員IDなどの識別子を変えて他人のデータを要求したとき、サーバー側で拒否する仕組みが入っているか。それを最近いつ確かめたか
• APIの回数制限と、ログの保管期間は。2026年8月以降のログを今から確認できるか
• アプリの中に、固定のAPIキーや暗号鍵、管理用の接続先が埋め込まれていないか
• 脆弱性の診断(外部の専門会社によるAPIの検査)を、最後にいつ受けたか。受けていないなら、今回の点検を機に受けるか

開発会社が自社の弱点を正直に答えるのは簡単ではありません。責めるためではなく、一緒に点検するための質問だと伝えたうえで聞くと、答えが返ってきやすくなります。

出典: NICT 脅威情報分析チームLETTICE 注意喚起の本文PDF(全7ページ、Rev 1.1 2026-10-13 15:00更新) / NICT CYNEX Library「【注意喚起】相次ぐ情報漏洩、その原因の一つは『アプリ解析からのサーバ攻撃』」(2026-10-13) / 総務省「不正アクセスによる情報漏えい等の事案を踏まえた対応について(公開アプリの解析情報を悪用した攻撃への注意喚起)」(2026-10-13)

Androidアプリだけの話ではない

NICTも総務省も、同様の問題はAndroidアプリに限らず、iOSアプリやWebサービスのバックエンドAPIでも発生する可能性がある、と明記しています。今回の注意喚起がAndroidを前提にしているのは、確認された攻撃がAndroidアプリの解析から始まっていたからで、iOSアプリだから安全、Webサービスだから無関係、ということではありません。

考え方は同じです。アプリやブラウザからサーバーに送られる通信は、利用者が正規のアプリを使っているとは限りません。攻撃者は通信の中身を自由に作れます。だから、サーバー側で「この人はこのデータを見てよいか」「この入力は安全か」を毎回確かめる必要があります。JPCERT/CCが10月8日の注意喚起で、APIへのアクセスの回数制限・アクセス制御、不要な管理機能の公開停止を求めていたのも、同じ考え方です。JPCERT/CCは10月15日の調査の公表で、API認証用の秘密鍵や有効期間の長い認証情報をアプリに埋め込まないこと、正規のアプリ以外からのアクセスも想定してレート制限や監視をすることも推奨しています。

会員向けのアプリやWebサービスを持っている会社であれば、業種を問わず、この記事の「今やること」は当てはまります。

出典: 総務省「不正アクセスによる情報漏えい等の事案を踏まえた対応について(公開アプリの解析情報を悪用した攻撃への注意喚起)」(2026-10-13) / NICT「【注意喚起】相次ぐ情報漏えい、その原因の一つは『アプリ解析からのサーバ攻撃』」(プレスリリース、2026-10-13) / JPCERT/CC「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」(2026-10-08公開、10-09更新) / JPCERT/CC Eyes「連続不正アクセス事案の攻撃手法に関する調査」(2026-10-15)

相談先と、この記事に書いていないこと

NICTは、個々のシステムの診断や技術的な相談には対応していない、と明記しています。注意喚起を点検の手がかりにして、社内のセキュリティ担当者、開発・運用の委託先、セキュリティ専門事業者に相談して進めてほしい、という案内です。すでに不審なアクセスが見つかっている場合は、IPAの相談窓口(企業・組織向け)や、JPCERT/CCへの情報提供・インシデント対応の相談が使えます。どの種類の専門会社に何を頼むかが分からない場合は、当社のセキュリティ相談窓口でも無料で切り分けています。

NICTの注意喚起には、攻撃に関連する侵害指標(IoC)としてIPアドレスが載っています。この記事では、読者がログを調べる担当者とは限らないため、値を転記していません。ログの点検を依頼するときは、上の出典にあるPDFをそのまま渡してください。NICTは、IoCとの一致だけで侵害を断定することはできず、アクセスログや通信の内容と合わせて総合的に判断するように、とも書いています。

また、この記事は、どの会社の事案がA2B攻撃だったかを特定していません。NICTが社名を挙げていないためです。関連する事案として下に並べているのは、公式アプリのサーバーが経路だったと各社が公表している事案で、手口が同じだったという意味ではありません。

出典: NICT「【注意喚起】相次ぐ情報漏えい、その原因の一つは『アプリ解析からのサーバ攻撃』」(プレスリリース、2026-10-13) / IPA「不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について」(2026-10-09) / JPCERT/CC「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」(2026-10-08公開、10-09更新)

よくあるご質問

A2B攻撃とは何ですか

App-to-Backend Attackの略で、NICTの脅威情報分析チームLETTICEが2026年10月13日に名付けた手口です。一般に公開されているAndroidアプリを入手・解析して、接続先のサーバーやAPIの仕組みを調べ、その情報をもとにサーバー側の弱点を狙います。アプリ自体に脆弱性がなくても、サーバー側の認証・認可や入力の検証に不備があれば、不正アクセスや個人情報の漏えいにつながります。

自社のアプリはiOSだけです。関係ありますか

関係があります。NICTと総務省は、同様の問題はAndroidアプリに限らず、iOSアプリやWebサービスのバックエンドAPIでも発生する可能性があると明記しています。狙われるのはアプリではなくサーバー側なので、サーバー側の認証・認可と入力の検証が不十分なら、入口がどのアプリでも同じです。

開発会社に頼んで作ったアプリです。何を頼めばよいですか

NICTの3種類の対策、つまり①公開しているAPIとサーバーの洗い出しと2026年8月以降のログの点検 ②認可の不備やSQLインジェクションなど6項目の脆弱性の点検 ③不要なAPIの停止やレート制限などの暫定的な緩和策を、そのまま依頼してください。あわせて、会員IDを変えて他人のデータを要求したときにサーバー側で拒否されるか、アプリの中に固定のAPIキーが埋め込まれていないか、を文章で答えてもらうと状況がつかめます。

この秋の漏えいは、すべてA2B攻撃だったのですか

いいえ。NICTは「原因の一つ」として特定したと発表しており、社名も挙げていません。JPCERT/CCも10月8日の注意喚起で、すべての事案で同じ手口が使われたことを示すものではない、と書いています。各社の公表の多くは「不正アクセス」までで、手口は明かされていません。

NICTに自社のシステムを診てもらえますか

NICTは、個別のシステムに関する診断や技術的な相談には対応していない、と明記しています。注意喚起を点検の手がかりにして、社内の担当者、開発・運用の委託先、セキュリティ専門事業者に相談するよう案内しています。すでに被害が疑われる場合は、IPAの相談窓口(企業・組織向け)やJPCERT/CCへの相談が使えます。