A2B攻撃とは？総務省・NICTが警告した「アプリ解析からのサーバ攻撃」をネットワークエンジニアが解説

2026年10月13日、NICT（情報通信研究機構）が「A2B攻撃」という聞き慣れない攻撃手法について注意喚起を出しました。国内で相次いでいる情報漏えいの原因の一つが、公開されているAndroidアプリを解析し、その接続先サーバを狙う攻撃だった、という内容です。

同じ日には総務省もこの注意喚起を公式サイトで取り上げ、事業者や関係団体に対策の徹底を呼びかけています。

一方、SNSでは「総務省 グラブル」という組み合わせも話題になりました。オンラインゲームの外部サイトがサーバーに過剰アクセスしていた件と、総務省・NICTのA2B攻撃の注意喚起が同じ日に出たため、両者を結び付ける投稿が広がったようです。結論から言うと、この2つは別の話です。

この記事では、ネットワークエンジニア（以下、NE）の視点で次の4点を整理します。

• A2B攻撃とは何か、どういう流れで攻撃されるのか
• 狙われている4つの脆弱性
• NICTが事業者に推奨している3つの対策と、ネットワーク側でできること
• ゲームの過剰アクセス騒動とは何が違うのか、AI時代に必要なリテラシー

A2B攻撃とは？アプリを「地図」にしてサーバを狙う攻撃

A2B攻撃（App-to-Backend Attack）は、公開アプリを解析して得た情報で、アプリの裏側にあるバックエンドサーバを攻撃する手法です。名付けたのは、NICTのサイバーセキュリティネクサス（CYNEX）にある脅威情報分析チーム「LETTICE」です。

ポイントは、アプリ自体に脆弱性がなくても成立することです。アプリはサーバの接続先やAPIの仕様を知っているので、解析されるとそれが攻撃者に渡ります。サーバ側の認証・認可や入力値チェックに穴があれば、そこを狙い撃ちされます。

NICTの資料によると、攻撃の流れは次のとおりです。

1. Google Playの日本地域で公開されているAndroidアプリを入手する
2. アプリを解析し、APIの接続先・エンドポイント・パラメータ・応答データの構造を調べる
3. 集めた情報から、サーバごとの仕様に合わせた攻撃リクエストを組み立てる
4. 脆弱性を探し、見つかれば悪用して情報を抜き取る

攻撃の段階では、公式アプリを経由する必要はありません。アプリから読み取った「通信のお作法」をまねて、自作のスクリプトから直接APIを叩きます。リクエストの形式が正しければ、サーバから見て正規アプリの通信と見分けにくくなります。

なお、ログイン不要のAPIだけでなく、会員登録してログインした後に使えるAPIも対象になるとされています。また、同じ問題はiOSアプリやWebサービスのAPIでも起こりうると、NICT自身が書いています。

A2B攻撃で狙われる4つの脆弱性

NICTは、今回の攻撃で主に狙われている脆弱性として次の4つを挙げています。どれも以前から知られた脆弱性です。A2B攻撃の特徴は、アプリ解析で狙う場所を絞り込んでくる点にあります。

個人的に一番怖いのはIDORです。仕組みが単純で、URLやリクエストの「user_id=1001」を「1002」に変えるだけで成立することがあります。アプリの画面上では自分のデータしか見えないので、開発中に気付きにくい脆弱性でもあります。

従来の攻撃と何が違う？なぜ今注目されているのか

違いは「無差別」か「その会社専用」かです。よくある攻撃は、既知の脆弱性を持つ機器やソフトを、不特定多数に向けて片っ端から試します。A2B攻撃は、アプリから読み取った仕様をもとに、サーバごとに攻撃内容を変えています。

もう一つの背景がAIです。NICTは、AIの活用でアプリ解析や脆弱性探索が効率化され、こうした攻撃がより多くのシステムに広がるおそれがあると指摘しています。以前は手間がかかったアプリの読み解きが手軽になれば、「うちは小さい会社だから狙われない」は通用しにくくなります。

10月7〜9日には個人情報保護委員会、JPCERT/CC、国家サイバー統括室、総務省からも、相次ぐ不正アクセスへの注意喚起が出ています。NICTの資料はこれらを参考文献に挙げたうえで、漏えい事案の原因の一つとしてA2B攻撃の手口を具体的に示しています。

手口そのものは昔からある

誤解のないように書くと、「アプリを解析して、非公開のAPIを直接叩く」手口自体は新しくありません。「A2B攻撃」という呼び名は今回NICTが付けたものですが、海外では10年以上前から事例があります。

• Snapchat（2013〜2014年）：研究者が非公開APIの「友だち検索」機能の問題を指摘し、詳細を公開しました。その約1週間後、研究者とは無関係の第三者によって、電話番号を総当たりで照合した約460万件のユーザー名と電話番号が流出しています。
• Peloton（2021年）：フィットネス機器のAPIが、認証なしで利用者の年齢・性別・居住都市・ワークアウト記録などを返していました。最初の修正後も、ログインさえしていれば他人のデータが見える状態が残っていました。典型的なIDOR/BOLAです。
• OWASP API Security Top 10（2019年版）：Webセキュリティの指針で知られるOWASPが、API版のリスク一覧で1位に挙げたのがBOLA（IDOR）でした。2023年版でも1位のままです。

つまり、今回新しいのは手口ではなく、国内の漏えい事案の原因として具体的に示された点と、AIで解析の手間が下がってきている点です。

NICTが推奨する3つの対策

NICTは、Androidアプリを公開している事業者に「侵害の確認」「脆弱性の点検」「暫定的な緩和策」の3つを早急に実施するよう推奨しています。前提にあるのは、アプリは解析されるものとして考える、という割り切りです。

1. 侵害の確認

• アプリが使うAPIに加え、サブドメイン、旧バージョンのAPI、検証環境、クラウド上の公開サービスまで洗い出す
• 2026年8月以降のアクセスログ・APIログ・認証ログを見て、公開されたIoC（IPアドレス、User-Agentなど）と一致する通信がないか調べる
• IoCとの一致だけでなく、認証なしでの大量取得、連番IDでのアクセス、他会員情報の閲覧・変更など、普段と違う操作がないか確認する

IoCの具体的な値はNICTのPDFに載っています。IoCに一致しないから安全、とは言い切れない点も明記されています。

2. 脆弱性の点検

• 認可不備（IDOR/BOLA）：IDを変えると他人や他テナントのデータが見えないか
• 認証・セッション管理：トークンの不正発行や偽造、認証回避ができないか。固定の認証情報や暗号鍵が露出していないか
• SQL/NoSQLインジェクション、SSRF
• S3・GCS・Firestoreなどクラウドストレージの設定不備
• 危険なデシリアライズ、任意ファイル書き込み、管理機能の公開

3. 暫定的な緩和策

• 国外や不要なアクセス元からの通信を一時的に制限する
• 不要な公開API、管理機能、検証環境を止める
• アクセス頻度や連番IDの指定を監視し、レート制限やWAFで制御する
• 漏えいが疑われる認証情報やトークンを無効化・再発行する
• 直せない重大な脆弱性があれば、APIや機能、場合によってはサービス全体の一時停止も検討する

恒久対策については、アプリ側の制御だけに頼らず、サーバ側で認証・認可や入力値の検証をすることが重要だと締めくくられています。総務省のお知らせも、利用者側からの通信は信頼できるとは限らないことを前提に、サーバ側で対策するよう求めています。

ネットワークエンジニアの視点：ネットワーク側でできること・できないこと

先に結論を書くと、A2B攻撃の本丸はサーバの作り（アプリケーション層）です。ネットワーク側の対策は「時間稼ぎ」と「被害を見つける」役割だと考えています。

ネットワーク側でできること

• 公開ホストの棚卸し：FWのNAT・ポリシー、DNSのレコードを見直すと、忘れられた検証環境や旧APIが見つかることがあります。NICTの「洗い出し」はここから始められます
• アクセス元の制限：国内向けサービスなら、FortiGateなどのGeo-IP（国別）アドレスオブジェクトで国外からの通信を絞るのは手早くできる暫定策です。ただし、攻撃者が国内のIPアドレスやプロキシを使えば効きません。海外の利用者やCDN経由の通信を巻き込まないかの確認も必要です
• 管理画面・検証環境を閉じる：検証環境や管理画面が、本番と同じように外部から到達できる状態のまま残っていることがあります。送信元IPで絞るか、VPN経由に寄せます
• ログが残っているか確認：NICTは8月以降のログ確認を推奨しています。FWやロードバランサのログ保存期間が足りないと、調べようがありません

ネットワーク側では止めにくいこと

IDORは、ネットワークから見ると正規のHTTPS通信です。ログイン済みのユーザーが、正しい形式のリクエストを送っているだけに見えます。FWやIPSのシグネチャでは区別できず、WAFでも素の設定では止めにくい攻撃です。

効いてくるのは「量と順番」の監視です。同じアカウントやIPから、連番のIDを短時間に大量に取りに来ていないか。ここはAPIゲートウェイやWAFのレート制限、ログの相関分析の出番になります。

NEとして気をつけたいのは、開発側に「ファイアウォールがあるから大丈夫」と思わせないことです。境界防御は大事ですが、A2B攻撃は境界を正面から通ってきます。

境界の機器そのものが狙われた事例は、【FortiBleed】FortiGate約7.4万台の認証情報流出｜現役NEが教える今すぐの対策で解説しています。

よくある疑問

総務省の注意喚起とグラブルの外部サイト騒動は関係ある？

直接の関係はないと考えられます。同じ10月13日、グランブルーファンタジー（グラブル）の公式Xが、運営の想定しない方法でサーバーに過剰なアクセスを繰り返す外部サイトがあるとして、作成者への対応を進めると発表しました。古戦場（ランキングイベント）のデータを集計するサイトだったと言われています。

「アプリ」「サーバへの攻撃」という話題が同じ日に重なったため、SNSでは「総務省がグラブルの件で動いた」といった冗談まじりの投稿も見られました。ただ、総務省のお知らせはNICTの注意喚起を受けたものです。NICTが分析したのは国内で相次ぐ情報漏えい事案で、対象は個人情報を盗む攻撃です。ゲームのデータ集計による負荷とは、目的も性質も違います。

ゲームの非公式ツールがサーバを圧迫する話も、グラブルが初めてではありません。2016年にはポケモンGOで、APIから直接データを集める非公式マップサイトが乱立しました。運営のNianticはサーバ負荷を理由にこれらをブロックし、ブロック後にサーバ資源の消費が大きく下がったと説明しています。悪意ある攻撃でもファンのツールでも、サーバへの影響は同じだという趣旨でした。

とはいえ、共通点もあります。どちらも「公式クライアント以外からAPIを直接叩かれる」ことを、サーバ側が前提にしておく必要がある、という点です。レート制限があれば、過剰アクセスや連番IDの総当たりを早い段階で検知・抑制しやすくなります。ただし、IDOR自体は認可チェックで直す必要があります。

スマホの利用者は何かする必要がある？

NICTの注意喚起は事業者向けで、利用者が今すぐやるべき操作は示されていません。アプリをアンインストールしても、サーバ側にある登録情報は消えないため、直接の対策にはなりません。

利用者側でできるのは、漏えいした前提で備えることです。サービスごとにパスワードを使い回さない、使っていないサービスは退会する、登録する情報を必要最小限にする、といった基本が効きます。

具体的な備え方は、個人情報漏洩は防げない。だから「漏れても困らない」状態をつくるにまとめています。

AIで誰でもツールを作れる時代に必要なリテラシー

NICTが指摘したAIによる効率化は、攻撃者だけの話ではありません。アプリの通信を調べて、データを自動で集めるスクリプトを書く。以前なら専門知識が必要だった作業が、今はAIの助けを借りれば形にしやすくなっています。

グラブルの件も、目的はゲームのデータ集計だったと言われており、攻撃を狙ったものではなかったとみられます。それでもサーバに負荷をかけ、他のプレイヤーに影響が出かねない状況になりました。「作れる」と「作っていい」の間には線があり、AIで作る敷居が下がるほど、その線を知らずに越える人は増えると思います。

ツールを作る側が気をつけたいこと

• 利用規約で、自動取得や非公式クライアントが禁止されていないか確認する
• アクセス頻度は自分で絞る。相手のサーバは自分の持ち物ではない
• 悪意がなくても、過剰なアクセスはアカウント停止の対象になりうる。度が過ぎれば業務妨害として法的責任を問われる可能性もある
• 他人のデータが見えてしまったら、それ以上触らずに運営へ報告する

作られる側（事業者）が前提にしたいこと

• APIを直接叩いてくるのは攻撃者だけではない。善意のツール作者やファンも来る
• だからこそ、レート制限と認可チェックを最初から入れておく。悪意の有無に関係なく、サーバと利用者を守りやすくなる

攻撃する側も、うっかり迷惑をかける側も、使う道具は同じになりつつあります。作る人・運営する人の両方が、この前提を持っておくことが大切です。

まとめ

A2B攻撃は、公開アプリを「サーバへの地図」として使う攻撃です。アプリの難読化で解析を完全に防ぐことは難しく、NICTも、アプリの中身やAPIの仕様が知られても安全なサーバにしておくことが重要だとしています。

• 事業者：IoCでログを確認し、IDOR・SQLインジェクション・SSRF・RCEを重点点検する
• NE：公開ホストの棚卸し、アクセス元の制限、ログ保存期間の確認で時間を稼ぐ
• 利用者：漏えいした前提で、パスワードの使い回しをやめ、不要なアカウントを減らす

「アプリ側でチェックしているから大丈夫」という前提を、一度疑ってみるきっかけにしてください。

関連記事：「直す」より「作り直す」時代へ｜サイバー攻撃からの復旧判断をエンジニアが解説

参考文献

• NICT「【注意喚起】相次ぐ情報漏えい、その原因の一つは『アプリ解析からのサーバ攻撃』」（2026年10月13日）
• 総務省「不正アクセスによる情報漏えい等の事案を踏まえた対応について（公開アプリの解析情報を悪用した攻撃への注意喚起）」（2026年10月13日）
• CYNEX Library 注意喚起ページ
• 注意喚起PDF（攻撃手法の詳細・IoC掲載）
• インサイド「『グラブル』公式、サーバーに過剰アクセスを行う”外部サイト”に注意喚起」
• TechCrunch：Snapchatのユーザー名・電話番号流出（2013年12月）
• Infosecurity Magazine：PelotonのAPIからの情報露出（2021年5月）
• OWASP API Security Top 10 2019：API1 BOLA
• PCWorld：Nianticによる非公式マップのブロック（2016年8月）