A2B攻撃とは｜アプリ解析からのAPI不正アクセスが相次ぐ理由と企業の点検手順

国内で何が起きているのか？

国内の幅広い組織で、外部に公開しているアプリやWebサービスが起点とみられる不正アクセスと情報漏えいが続いています^[6]。IPAは、特定の製品の脆弱性を狙った攻撃とは断定されていないものの、公表事例の傾向から、外部公開しているアプリケーションやサービスの侵害、アカウントの侵害が起点になっていることがうかがえるとしています^[6]。

1. 10月7日

   個人情報保護委員会が注意喚起

   大量の個人データが外部からの不正アクセスで漏えいした事案を踏まえ、技術的な安全管理措置の見直し内容を先取りして示しました^[4]。

2. 10月8日

   JPCERT/CCが注意喚起を公開

   相次ぐ漏えい被害について、確認されている攻撃手法と痕跡、推奨する対策を公開しました（9日・23日に更新）^[1]。

3. 10月9日

   国家サイバー統括室・IPA・総務省が対策を要請

   ウェブシステムの管理や委託先を含む対策の徹底、外部公開アプリ・サービスの速やかな点検などを事業者に求めました^[5][6][10]。

4. 10月13日

   NICTが「A2B攻撃」を注意喚起

   公開Androidアプリの解析結果を使ってバックエンドサーバーを攻撃する手法を、漏えいの原因の一つとして確認したと発表しました^[3]。

5. 10月15日

   JPCERT/CCが攻撃インフラの調査結果を公表

   攻撃者がAIを使って既知の脆弱性のスキャンやAPI経由の攻撃を行っていたことを確認したと報告しました^[2]。

6. 10月19日

   JIPDECが経営者向け資料を公開

   プライバシーマーク付与事業者の経営者に向けて、不正アクセス対策で経営者が果たす役割をまとめました^[8]。

7. 10月23日

   JPCERT/CCが注意喚起を更新

   API経由の不正な操作（ケースB）に、アプリを解析する攻撃の新たな送信元と「公開されているアプリと同じUser-Agent」を追記し、AIを使ったペネトレーションテスト基盤の悪用（ケースE）を加えました^[1]。

8. 10月26日

   IPAが利用者向けの対処を公開

   漏えいの連絡を受けた利用者からの相談が多数寄せられているとして、二次被害を防ぐ対処を解説しました^[7]。

JPCERT/CCは、一般利用者向けのアプリだけでなく、BI（ビジネスインテリジェンス）ツールや従業員向けの管理システムのように、不特定多数からのアクセスを想定していないシステムが被害に遭い、内部の情報が漏えいしたケースもあると指摘しています^[1]。「お客さま向けのアプリを持っていないから関係ない」とは言い切れません。

IPAによると、一部のサービスでは運転免許証の画像やクレジットカード情報が流出した事例も報告されており、情報漏えいの対象となった利用者から「自分の情報が漏えいしたという連絡がきたが、どう対応すればよいか」という相談が数多く寄せられています^[7]。

トレンドマイクロが被害組織のプレスリリースなどの一次情報をもとに集計したところ、2026年1〜9月に公表された国内組織のセキュリティインシデントは607件で、すでに2025年の1年分（594件）を上回りました。10月9日時点では659件に達しています^[12]。

公式発表で原因にAPIやアプリが挙がっている例

被害を受けた組織の公表を見ると、原因としてAPIやアプリのサーバーを名指しした例が9〜10月に複数あります^{[13][14][15][16][17]}。下の表は、各組織が自ら公表した文面から原因の表現を引用したもので、APIの名指しはないものの、他の利用者の情報を取得できる脆弱性を原因に挙げた例も含めています。

A2B攻撃とはどんな攻撃か？

A2B攻撃は、誰でもダウンロードできる公開アプリを手がかりに、その裏側でログインや会員情報の管理を担うサーバー（バックエンドサーバー）を狙う攻撃です。NICTは、Androidアプリそのものに脆弱性がなくても、サーバー側のAPIに認証・認可や入力値の検証の不備があれば、個人情報の漏えいや不正アクセスにつながる可能性があるとしています^[3]。

API（Application Programming Interface）は、アプリとサーバーが情報をやり取りするための窓口です。アプリの画面に表示される会員情報やポイント残高は、アプリがAPIに問い合わせて受け取ったものです。利用者が画面から操作できることは限られていても、窓口そのものは画面を通さずに直接呼び出すことができます。

1. アプリの入手と解析：攻撃者はGoogle Playの日本地域で公開されているAndroidアプリを入手し、プログラムを解析して、通信先のサーバー、APIの構成、使われるパラメータなどを調べます^[3]。
2. 弱点の探索：集めた情報をもとに、サーバーやAPIごとに攻撃内容を変えながら、脆弱性がないかを探ります。NICTは、不特定多数のサーバーに同じ攻撃を試すのではなく、対象ごとに攻撃を組み立てる点を特徴に挙げています^[3]。
3. 悪用と情報の取得：認証が要らないAPIだけでなく、利用者としてログインした後に使えるAPIも攻撃の対象になる場合があります^[3]。

JPCERT/CCの注意喚起（ケースB）には、具体的な手口として、公開アプリを解析してAPIの接続先やキーを特定すること、画面操作では実行できない内部APIを使って利用者の権限を変えたり不正なアカウントを作ったりすること、他のシステムの侵害で盗んだAPIキーを使うことなどが挙げられています^[1]。

JPCERT/CCは攻撃に使われた可能性のあるサーバーを調べ、攻撃者がAndroidアプリの配布ファイル（APK）を解析し、関連するAPIにSSRFなどの脆弱性がないかを調べていた痕跡や、アプリ解析用のツールに関するファイルを確認しました。攻撃者がAIを使って既知の脆弱性のスキャンやAPI経由の攻撃を行っていたことも確認しています^[2]。NICTも、AIでプログラムの解析や脆弱性の探索が効率化され、こうした攻撃がより多くのシステムに及ぶ可能性に注意を促しています^[3]。

見分けにくさも特徴です。JPCERT/CCは、IPアドレスによる制限を回避するためにTorの出口ノードやレジデンシャルプロキシ（一般家庭の回線を経由させる中継サービス）を使ったアクセスを確認しており、10月23日の更新では、アクセスに「公開されているアプリと同じUser-Agent」が使われる例も加えました^[1]。送信元のIPアドレスやUser-Agentだけで正規の利用者と攻撃を見分けることは難しいということです。

狙われている4つの弱点は何か？

NICTによると、A2B攻撃で主に探索・悪用されているのは、SSRF、RCE、SQLインジェクション、IDORの4種類の脆弱性です^[3]。いずれもアプリの画面からは見えないサーバー側の弱点で、外から見て問題なく動いていても存在しえます。

中でもIDORは、身近なたとえでいえば「受付で会員番号を言うと、本人確認をせずにその番号の人の書類を渡してしまう窓口」です。自分の情報を取得するAPIで、リクエスト中の番号を書き換えるだけで他の利用者の情報が返ってくる、といった形で現れます^[3]。Webアプリのセキュリティ団体OWASPがまとめたAPIの主要リスク一覧（2023年版）でも、同じ問題であるBOLA（Broken Object Level Authorization）が1位に挙げられています^[9]。

個人情報保護委員会も、10月7日に改訂した注意喚起資料に「APIが悪用される事例」を加えました。ログインした攻撃者がパラメータを書き換えることで、本来取得できない他の利用者の情報を取得できた事案で、原因として、管理対象から漏れているAPIがあったこと、レスポンスに不要な情報が含まれ会員IDが連番だったためAPIの仕様を推測しやすかったこと、大量アクセスを制限するレートリミットがなかったことを挙げています^[11]。

アプリの中に埋め込まれた秘密情報も入口になります。JPCERT/CCは、アプリ内に共通の秘密鍵やAPI認証用の秘密情報が埋め込まれている場合、それを抜き出されることで、正規のアプリを介さないAPIリクエストを作られるおそれがあると説明しています。Flutterで作られたアプリについては、公開されている解析事例をもとに、コードがコンパイル（機械向けの形式に変換）されていても、内部に埋め込まれた秘密情報やAPIの認証処理を特定できる可能性があることを示しています^[2]。

自社は関係あるのか？どう見分ければいい？

スマートフォンアプリを公開している企業はもちろん、インターネットからAPIで呼び出せるシステムを持つ企業は、点検の対象になると考えてください。NICTは、同様の問題はAndroidアプリに限らず、iOSアプリやWebサービスのバックエンドAPIでも起こりうるとしています^[3]。

見落としやすいのは、使われなくなった古いAPIや検証用の環境です。NICTは、侵害の確認で列挙すべき対象として、アプリが利用するAPIのほか、サブドメイン、旧バージョンのAPI、検証環境、クラウド上の公開サービスを挙げています^[3]。アプリの更新で新しいAPIに切り替えても、古い窓口が開いたままになっていないかを確認する必要があります。

今週中に確認すべきことは？

最初にやることは、守る対象の洗い出しと、すでに侵入されていないかの確認です。NICTは、APIとインターネットに公開しているホストを列挙したうえで、2026年8月以降のアクセスログ・APIログ・認証ログを確認し、可能であればそれ以前のログも確認するよう求めています^[3]。

ログの確認範囲について、IPAは直近1か月、その後3か月というように段階的に広げて確認すること、今後も複数回の調査が必要になる可能性を踏まえて、誰がどのように調査できるかを把握しておくことを勧めています^[6]。ログを取っていない、あるいは保存期間が短いと分かった場合は、それ自体が今回の点検で見つかった課題です。

ログの点検で被害に気づいた例もあります。DCMホールディングスは、子会社が運営する会員サービス「マイボ」の会員情報を管理するシステムに9月21日、通常とは異なる多数のアクセスがあり、10月8日にサイバー攻撃に関する注意喚起を受けてアクセス記録を点検したところ、第三者による不正アクセスが判明したと公表しています^[20]。

不審な送信元の情報は、JPCERT/CCの注意喚起とNICTの注意喚起（PDF）に掲載されています。JPCERT/CCは、掲載したIPアドレスは調査の時点では正規に利用されている可能性もあるとしており、照合結果だけで判断しないよう注意が必要です^[1]。

弱点はどう点検すればいいのか？

点検の前提は「アプリは解析され、APIは直接呼び出される」と考えることです。NICTは、恒久的な対策として、攻撃者がアプリを介さずにAPIを直接操作できることを踏まえ、アプリ側の制御だけに頼らず、サーバー側で認証・認可や入力値の検証を行うことが重要だとしています^[3]。

NICTは、被害の発生や拡大を防ぐ暫定的な緩和策として、国外など不要なアクセス元からの通信の一時的な制限、不要な公開APIや管理機能・検証環境の停止、アクセス頻度の監視とレート制限（APIへのリクエスト数の制限）などを挙げています^[3]。JPCERT/CCも推奨する対策として、レート制限、利用地域が限られるサービスでのアクセス元の地域制限、APIトークンへの最小限の権限付与と適切な有効期限の設定などを示しています^[1]。NICTは、脆弱性をすぐに修正できない場合や、重大な脆弱性の有無を確認できず、暫定的な制限でもリスクを許容できる水準まで下げられない場合は、該当するAPIや機能、必要に応じてサービス全体の一時停止も検討するよう求めています^[3]。

アプリの難読化（解析しにくくする加工）や、アプリ内での署名処理は、対策の柱にはなりません。JPCERT/CCは、アプリ内の署名処理や難読化だけに依存せず、サーバー側で利用者を認証し、操作の対象や内容に応じた認可を行うよう勧めています^[2]。

実際の侵入経路を想定した検証の進め方は、攻撃者と同じ手順で確かめる検証の流れと、生成AI時代の攻撃の手口でも紹介しています。人を経由した侵入への備えは、ハッキング対策は「人」からで解説しています。

アプリ開発を外部に委託している場合はどうする？

開発や運用を委託していても、預けた情報が漏えいしたときの説明責任は自社にも生じます^[8]。JIPDECは経営者に対して、委託先のセキュリティ対策が自社と同じ水準かを確認し、その内容を記録に残すよう求めています^[8]。国家サイバー統括室も、委託先の管理体制や責任分界の確認、契約での報告義務の規定などを挙げています^[5]。

• 自社のアプリが使っているAPIとサーバー、旧バージョンのAPIや検証環境を含めた一覧はあるか^[3]
• 2026年8月以降のログを確認したか、その結果はどうだったか^[3]
• 会員IDなどを書き換えて他人の情報を取得できないか（IDOR）を、アプリを介さずに確かめたことがあるか^[3]
• アプリに秘密鍵や長期間有効な認証情報を埋め込んでいないか^[2]
• 不正アクセスや漏えいが起きた場合の報告義務と連絡体制が、契約で決まっているか^[5]

これらは、各機関の注意喚起の点検項目を、委託先への問い合わせに置き換えたものです。回答があいまいな項目は、点検が済んでいないものとして扱い、いつまでに誰が確認するかを決めてください。

経営層は何を決めればいいのか？

経営層が決めるのは、点検の優先度と、そのための人と予算です。IPAは、大量の情報資産を持つ事業者の経営者に、サイバーセキュリティリスクを経営の重要課題と認識し、自らのリーダーシップのもとで点検と見直しを至急行うよう求めています^[6]。

国家サイバー統括室は、インターネットに公開しているシステムは「いつ攻撃を受けてもおかしくない」という前提で対策を講じることが重要だとし、対策の一つに定期的な脆弱性診断の実施を挙げています^[5]。JIPDECは経営者の役割を「知る（現状を確認する）」「動く（問題があればすぐ対応させる）」「投資する（人・モノ・カネを惜しまない）」の3つにまとめ、システム管理を一人に任せる「ひとり情シス」をやめるよう呼びかけています^[8]。

持っている情報を減らすことも、経営判断です。個人情報保護委員会は、利用する必要がなくなった個人データを遅滞なく消去する努力義務（個人情報保護法第22条）が徹底されず、漏えい事案がより深刻化した例にも接しているとして、保有する個人データの必要性を改めて確認するよう求めています^[4]。同委員会は、技術的な安全管理措置の見直し内容を、確定（来年4月の予定）に先立って示しており、アクセス制御、アクセス者の識別と認証、外部からの不正アクセスの防止、不正アクセスの検知などの項目ごとに手法の例を挙げています^[4]。

まとめ

A2B攻撃は、公開アプリを解析して裏側のAPIの仕様を調べ、サーバーごとに攻撃を組み立てる手口で、国内で相次ぐ情報漏えいの原因の一つと確認されています^[3]。狙われるのはSSRF・RCE・SQLインジェクション・IDORといったサーバー側の弱点で、アプリ自体に問題がなくても被害につながりえます^[3]。

今週中に、API・公開ホストの一覧を作り、2026年8月以降のログを確認してください^[3]。そのうえで、アプリを介さずにAPIを直接操作して、他人の情報に届かないかを確かめ、委託先にも同じ点検を求めることが、今回の一連の注意喚起から読み取れる最初の一歩です。