2026.11.07 セキュリティ

A2B攻撃とは：NICTが特定したアプリ解析起点のサーバ攻撃と自社APKの点検手順

A2B攻撃（App-to-Backend Attack）は、Google Playで公開されているAndroidアプリを攻撃者が解析し、そこで知った接続先やAPIの仕様をもとにバックエンドサーバを狙う攻撃です。国立研究開発法人情報通信研究機構（NICT）の脅威情報分析チームLETTICEが2026年10月13日に名付け、国内で相次ぐ情報漏えいの原因の一つとして注意喚起しました。この記事では、A2B攻撃の定義と狙われる4種の脆弱性を整理したうえで、自社のAPKから攻撃者に何が見えるかをjadxで確かめるコマンド、連番IDの総なめをアクセスログから探す手順、IDORの検証方法、クラウドストレージの設定例までを実装者向けにまとめます。

まとめ：A2B攻撃で狙われる4種の脆弱性と事業者が今週中に済ませる点検の順番

A2B攻撃の本体はアプリではなくサーバ側の不備です。NICTは、アプリ自体に脆弱性が無くても、バックエンドのAPIに認証・認可や入力値検証の不備があれば漏えいにつながると明記しています。狙われているのはSSRF、RCE、SQLインジェクション、IDOR（BOLA）の4種です。

事業者が先に着手する順番は次のとおりです。最初に、自社APKを逆コンパイルして埋め込まれた接続先と鍵を一覧にし、公開中のホストを棚卸しします。次にアクセスログで連番IDの総なめや認証なしの大量取得が無いかを調べ、侵害の有無を確かめる手順です。そのうえで、2つの検証アカウントを使ってIDORを点検し、クラウドストレージの公開設定を閉じます。

アプリの難読化を強めるのは最後で構いません。解析を完全に止める手段は無く、NICT自身も「アプリ側の制御のみに依存しない」設計を恒久策に挙げています。認可の修正が終わる前に難読化ツールの購入へ予算を回すのは、この攻撃に対しては順番の誤りです。

A2B攻撃とは何か：NICTのLETTICEが2026年10月に名付けた攻撃の定義と流れ

A2B攻撃という名称は、NICTの報道発表（2026年10月13日）とCYNEX Libraryに掲載された注意喚起の本文で示されたものです。LETTICEは、NICTのサイバーセキュリティネクサス（CYNEX）で2024年2月に発足した脅威情報の共同分析チームです。

公開Androidアプリの解析から接続先とAPI仕様を集めてサーバを狙う2段の手口

攻撃は2段に分かれます。1段目で、攻撃者はGoogle Playの日本地域で公開されているAndroidアプリを入手し、プログラムを解析します。集めるのは、APIの接続先、エンドポイント（APIの個別機能を呼び出すアクセス先）、パラメータ、応答データの構造です。

2段目では、その情報をもとに攻撃対象になりうる箇所を特定し、個々のAPIの仕様や処理内容に合わせたリクエストを送って脆弱性を探します。注意喚起のPDF（全7ページ）には、この流れと狙われた脆弱性を示す図が載っています。

見落としやすいのは、画面に出ない機能も攻撃面になる点です。アプリの中に古い版のAPIや管理用の呼び出しが残っていれば、利用者の画面に無くても攻撃者には見えています。

不特定多数への一斉攻撃と違い対象のAPI仕様ごとに攻撃内容を変える特徴

NICTが挙げる特徴は、同じ攻撃を多数のサーバに一斉に試すのではなく、解析で得た情報を使ってサーバごとに攻撃の中身を変えている点です。既知の脆弱性を総当たりで探すスキャンとは性質が違います。

このため、WAFの汎用シグネチャだけでは止まりにくくなります。正規のアプリと同じ形式のリクエストで、IDの値だけを差し替えて送られると、通信の見た目は正常な利用と区別できません。NICTは、AIでプログラム解析や脆弱性探索が効率化され、こうした攻撃がより多くのシステムに及ぶ可能性にも触れています。

JPCERT/CCケースBや政府の緊急対策パッケージとA2B攻撃の関係

手口は、JPCERT/CCが2026年10月に注意喚起した不正アクセスのケースB（アプリ解析から内部APIを突く手口）と重なります。ケースBで観測された攻撃手順とAPI側の実装対策は、API不正アクセス対策の実装手順で設定例つきで扱っています。

政府も動いています。2026年11月6日のサイバーセキュリティに関する関係閣僚会議（第2回）の資料2「サイバーセキュリティ緊急対策パッケージ（案）について」では、A2B攻撃を特定したNICTの分析能力の強化が施策に入りました。一過性の話題ではなく、当面は点検を求められる論点だと考えてください。

A2B攻撃で探索・悪用されたSSRF・RCE・SQLインジェクション・IDORの4種と被害

NICTの注意喚起は、今回確認したA2B攻撃で主に探索・悪用された脆弱性として4種を挙げています。どれもサーバ側の実装の問題で、アプリの改修だけでは直りません。

4種の脆弱性ごとに狙われる機能と漏えいに至る経路を比べた一覧

脆弱性	狙われやすい機能	起きること
SSRF	URL取得・画像処理・文書変換	内部網やメタデータの読み出し
RCE	デシリアライズ・ファイル書き込み	サーバ上で任意の命令を実行
SQLインジェクション	検索・絞り込みのAPI	個人情報の取得や認証の回避
IDOR（BOLA）	会員IDを受け取るAPI	他人の氏名やメールの取得

件数の被害が大きくなりやすいのはIDORです。NICTは、識別子が推測・列挙しやすい場合に大量漏えいにつながると書いています。SSRFは単発でもクラウドの認証情報が抜かれると被害が一気に広がるおそれがあるため、警戒が必要です。仕組みと防御実装はSSRFの解説、入力の組み立て方はSQLインジェクションの攻撃例と対策に譲ります。

ログイン後のAPIも標的になる理由とアプリ側の制御に頼った設計の失敗例

認証を必要としないAPIだけが危ないわけではありません。NICTは、利用者アカウントで認証した後に使えるAPIも攻撃対象になると明記しています。攻撃者は自分で正規の会員登録をし、正しいトークンを手に入れたうえで、リクエスト中の会員IDだけを書き換えます。

典型的な失敗は「アプリの画面では自分のIDしか送らないから大丈夫」という設計です。OWASP API Security Top 10のAPI1:2023も、クライアントから届いたIDで対象を決めるAPIでは、操作のたびに利用者の権限を確かめる実装を求めています。サーバ側での検査の書き方はIDORと認可バイパスの実装対策で解説しています。

自社のAndroidアプリから攻撃者に見える情報をjadxで確かめる手順

攻撃者と同じ視点で、自社が公開しているAPKを開いてみるのが点検の出発点です。対象は自社が権利を持つアプリに限ります。

jadxでAPKを逆コンパイルし接続先URLと埋め込み鍵を抽出するコマンド

jadxはAPKやdexをJavaのソースに戻すオープンソースの逆コンパイラで、2026年11月時点の最新版はv1.5.6系です。実行には64bit版のJava 11以降が必要で、macOSなら brew install jadx で入ります。次の例は、逆コンパイルした結果から接続先のURLと、鍵として使われる典型的な文字列の形式を探します。

# 自社のAPKを逆コンパイルする（出力先は out_app）
jadx -d out_app app-release.apk

# 接続先URLを出現回数の多い順に並べる
grep -rhoE "https?://[A-Za-z0-9._:-]+(/[A-Za-z0-9._/{}-]*)?" out_app \
  | sort | uniq -c | sort -rn | head -50

# 埋め込まれた鍵・証明書・ストレージの接続先を探す
grep -rnoE "AIza[0-9A-Za-z_-]{35}|AKIA[0-9A-Z]{16}|BEGIN [A-Z ]*PRIVATE KEY|[a-z0-9-]+\.firebaseio\.com|[a-z0-9.-]+\.s3[.-][a-z0-9.-]*amazonaws\.com" out_app

1つ目の検索で、本番以外のホスト名（stg・dev・test・旧版の v1 など）が出てきたら要注意です。2つ目で鍵が見つかった場合、その鍵は既に漏れているものとして扱い、権限の縮小と再発行に進みます。埋め込み鍵の発行と失効の設計はAPIキー管理の実装にまとめたとおりです。動的解析まで含めて調べたい場合は、MobSFの導入と動的解析が手順の参考になります。

抽出した接続先から旧版API・検証環境・公開ストレージを棚卸しする方法

NICTが侵害の確認の最初に求めているのは、インターネットに公開しているホストの列挙です。対象には、アプリが使うAPIに加え、サブドメイン、旧バージョンのAPI、検証環境、クラウド上の公開サービスまで含めるよう書かれています。

実務では、前の手順で出たURLの一覧を、インフラ側の台帳（DNSのレコード、ロードバランサの設定、クラウドの公開リソース）と突き合わせます。アプリにあるのに台帳に無いホストは、管理者が把握していない公開面です。逆に、台帳にあってアプリから参照されない旧版APIは、停止候補として次の緩和策に回します。

R8の難読化やPlay Integrity APIで防げる範囲と防げない範囲の線引き

AndroidのR8はクラス名やメソッド名を短い名前に置き換えますが、通信先のURLやパラメータ名のような文字列は動作に必要なので残ります。難読化は解析の手間を増やすだけで、接続先を隠す手段にはなりません。

Play Integrity APIは、リクエストが正規のアプリと端末から来たかをサーバ側で判定する材料になります。ただし、判定結果をどのAPIで必須にし、判定に通った利用者に何を許すかはサーバ側の実装次第で、利用者ごとの認可の代わりにはなりません。OWASPのモバイル向け検証基準MASVSでも、リバースエンジニアリングと改ざんへの耐性（MASVS-RESILIENCE）は認証・認可（MASVS-AUTH）とは別のカテゴリです。両方を満たす前提で考え、片方で他方を代替しないでください。

NICTが推奨する3つの対策を実装と運用の作業に落とした点検の手順

NICTはAndroidアプリを公開する事業者に、侵害の確認、脆弱性の点検、暫定的な緩和策の3つを早急に行うよう求めています。それぞれを手を動かせる作業に置き換えます。

侵害の確認：連番IDの総なめをアクセスログから探すawkのコマンド例

NICTは、IoC（IPアドレスやUser-Agent）との一致に加え、認証なしでの大量の情報取得、連番IDなどを使ったアクセス、他会員の情報の閲覧・変更、認証トークンの不審な発行、管理機能の利用といった通常と異なるAPI操作を確認するよう求めています。IoCの値は注意喚起のPDFに載っているため、照合は原文から行ってください。ここでは、IoCに頼らず連番IDの総なめを見つける例を示します。

# nginx の combined 形式を想定。/api/v1/users/<数字> へのアクセスを
# 送信元IPごとに「何種類の会員IDに触れたか」で数え、50種類以上を表示する
awk '{
  if (match($7, /\/api\/v1\/users\/[0-9]+/)) {
    id = substr($7, RSTART + 14, RLENGTH - 14)
    key = $1 SUBSEP id
    if (!(key in seen)) { seen[key] = 1; cnt[$1]++ }
  }
} END { for (ip in cnt) if (cnt[ip] >= 50) print cnt[ip], ip }' access.log | sort -rn

通常の利用者が触れる会員IDは自分の1つだけなので、1つのIPが数十種類に触れていれば強い兆候です。しきい値の50は出発点で、法人契約で1人が複数の会員を管理するサービスでは上げてください。IPやUser-Agentでの絞り込み方は不正アクセスの痕跡を見つけるコマンド例が参考になります。

脆弱性の点検：2つの検証アカウントでIDORを確かめるcurlの手順

IDORの点検は、検証環境に会員を2人作り、Aのトークンで「Bのデータ」を要求するだけで始められます。NICTも、会員IDなどの識別子を変えることで他者や他テナントの情報を閲覧・変更できないかを確かめるよう求めています。

# 検証用アカウントAのトークンと、アカウントBの会員IDを用意する
TOKEN_A="（アカウントAのアクセストークン）"
ID_B="10002"

# AのトークンでBのプロフィールを要求する。403か404なら正常、200なら認可の不備
curl -s -o /dev/null -w "%{http_code}\n" \
  -H "Authorization: Bearer ${TOKEN_A}" \
  "https://api-stg.example.com/api/v1/users/${ID_B}/profile"

1本のAPIで済ませず、jadxで抽出したエンドポイントのうち、IDを受け取るものを全部同じ形で回します。参照（GET）だけでなく更新（PUT・PATCH・DELETE）も対象です。OWASPは、この種の認可テストを自動テストに組み込み、失敗する変更はデプロイしない運用を勧めています。

FirestoreとS3で認証なしのアクセスを塞ぐルールと公開ブロックの設定例

NICTの点検項目には、S3、GCS、Firestoreなどに認証なし、または本来許可していない権限でアクセスできないかの確認が入っています。Firestoreなら、公式ドキュメントの条件の書き方に沿って、本人のドキュメントだけを読み書きできるようにします。

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, update, delete: if request.auth != null && request.auth.uid == userId;
      allow create: if request.auth != null;
    }
  }
}

# S3 はバケット単位でパブリックアクセスを4項目とも遮断する
aws s3api put-public-access-block --bucket "$BUCKET" \
  --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

S3の4項目の意味はブロックパブリックアクセスの公式解説にあります。Cloud Storage for Firebaseのルール設計はCloud Storage for Firebaseの解説で扱っています。

暫定的な緩和策：不要APIと検証環境の停止から認証情報の再発行までの順番

直せるまでの間は、被害の拡大を止める手当てを先に入れます。NICTが挙げる緩和策を、効果が出るまでの速さで並べると次の順になります。

不要な公開API、管理機能、検証環境へのアクセスを停止または制限する
漏えいや悪用が疑われる認証情報とトークンを無効化し、再発行する
国外や不要な送信元からの通信を一時的に制限する
アクセス頻度や連続した識別子の指定を監視し、レート制限やWAFで制御する
直ちに修正できず危険を許容できる水準まで下げられないときは、APIや機能、場合によってはサービス全体の一時停止を検討する

停止と鍵の失効は数時間で終わるうえ、効果が確実です。国外からの通信制限は、海外在住の利用者がいるサービスでは業務への影響を確かめてから入れます。レート制限の設定値の決め方は、前出のAPI不正アクセス対策の記事に設定例があります。

A2B攻撃への対応で自社で済ませる範囲と外部の脆弱性診断へ依頼する条件

点検の多くは社内で進められます。一方で、自社で調べても判断がつかない領域は、外部への依頼を検討する対象です。その境目を条件で示します。

アプリの難読化強化より先にバックエンドの認可を直すべきと言い切れる理由

先に直すのはバックエンドの認可です。NICTの注意喚起は、公開アプリの解析自体を完全に防ぐのは難しいと述べ、APIの仕様が知られてもサーバの安全が保たれる設計を求めています。難読化ツールや耐タンパ製品の導入は、認可の点検が全エンドポイントで終わった後に検討すれば十分です。

見送ってよい場面もはっきりしています。アプリが参照専用で、個人情報も決済も扱わず、APIが公開情報だけを返すなら、難読化への投資は効果に見合いません。逆に、会員情報や注文履歴をIDで引くAPIを1本でも持つなら、今週中に前章のcurlの点検を回してください。

外部の脆弱性診断へ依頼すべき条件と診断の際に渡すAPKとAPI一覧

次のどれかに当てはまる場合は、社内の点検だけで終わらせず外部の診断を入れます。1つ目は、jadxの結果に管理用や旧版のエンドポイントが混ざっていて、誰が作ったか分からないとき。2つ目は、URL取得や画像変換のようにSSRFの入口になる機能を持つとき。3つ目は、アクセスログで兆候が見つかり、影響範囲を短期間で確定させる必要があるときです。

依頼時には、公開中のAPK、APIのエンドポイント一覧、認証方式、検証用アカウント2つを渡すと、ブラックボックスでの探索に時間を取られずに済みます。一創の脆弱性診断・セキュリティ診断では、アプリのAPIを含むバックエンドの診断を受け付けています。診断の種類と費用の目安を比較する際の参考は、脆弱性診断の進め方と外注時の判断基準です。

個人情報の漏えいが疑われたときの個人情報保護委員会への報告期限

A2B攻撃で個人データが抜かれた疑いが出た時点で、報告義務の確認が始まります。不正アクセスのように不正の目的による漏えい等のおそれがある事態は、件数にかかわらず個人情報保護委員会への報告の対象です。速報はおおむね3〜5日以内、確報は60日以内が期限になります。対象の4類型と書き方は個人情報保護委員会への報告義務の実務を確認してください。

よくある質問

A2B攻撃について、開発や運用の担当者から寄せられやすい質問をまとめました。

iOSアプリやWebサービスだけを提供している場合も対象になりますか？

iOSアプリやWebサービスも対象です。NICTが確認した事例はAndroidアプリを手がかりにしたものですが、注意喚起は同様の問題がiOSアプリやWebサービスのバックエンドAPIでも起こりうると明記しています。Webサービスでも、ブラウザの開発者ツールでAPIの接続先とパラメータは誰でも見られます。入口がアプリかブラウザかに関係なく、サーバ側の認証・認可と入力値の検証が守りの中心です。この記事のログ確認とIDORの点検はそのまま使えます。

注意喚起に載っているIoCはどこで確認できますか？

NICTのCYNEX Libraryに掲載された注意喚起のPDFに、攻撃に関連するIoCの一部が載っています。NICTは、IoCとの一致だけで侵害の有無を断定できないため、アクセスログや通信内容と合わせて判断するよう求めています。IoCに一致しなくても、連番IDへの大量アクセスや他会員の情報の閲覧があれば調査を進めてください。PDFは改訂される場合があるため、照合の直前に最新版を開き直すのが確実です。

A2B攻撃の被害を受けた企業名は公表されていますか？

NICTの報道発表と注意喚起の本文には、個別の被害企業名や件数は書かれていません。国内で相次ぐ情報漏えいの原因の一つとして、この攻撃手法による情報の不正取得を確認したという書き方にとどまっています。個別の事案の公表は各社の発表によります。自社が被害を受けたかどうかは、外部の報道を待たずにログで確かめるほうが確実です。

自社のアプリを逆コンパイルして点検しても問題ありませんか？

自社が権利を持つアプリの点検として行うなら、一般に問題になりにくい作業です。ただし、外部の開発会社に作らせたアプリでは、契約上の権利の帰属や利用条件を確かめてから進めてください。組み込んでいる商用SDKの利用規約が逆コンパイルを制限している場合もあります。他社のアプリを解析する行為はこの記事の対象外です。点検で得たソースや鍵は社外に出さず、作業後に削除します。

委託先が開発・運用しているアプリでは誰が点検を進めるべきですか？

点検の責任は、アプリを公開している発注側の事業者にあります。NICTの推奨も、Androidアプリを公開している事業者に向けたものです。実際の作業は委託先に頼んでも構いませんが、ホストの棚卸し結果とIDORの点検結果は発注側で受け取り、未対応の項目を把握しておきます。委託先との責任分担を見直す際は、サイバー対処能力強化法と委託先への影響も参考になります。