NICTが10月13日に出した注意喚起

情報通信研究機構（NICT）のサイバーセキュリティネクサス（CYNEX）で活動する脅威情報分析チーム LETTICE が、2026年10月13日に注意喚起を公開した。題は「相次ぐ情報漏洩、その原因の一つは『アプリ解析からのサーバ攻撃』」で、全7ページ。同じ日の15時に表現を直した改訂版（Rev 1.1）が出ている。

国内では、個人情報などの漏洩の公表が相次いでいる。 LETTICE は、その原因の一つとして、攻撃者が Google Play の日本地域で公開されている Android アプリを解析し、解析結果を使ってアプリの裏側にあるサーバを攻撃する手口を確認したとしている。資料はこの手口を A2B 攻撃（App-to-Backend Attack）と呼ぶ。

直接の対象は、Android アプリを公開している事業者だ。ただし資料の最後には、同じ問題は iOS アプリや Web サービスの裏側の API でも起こりうると書かれている。自社のアプリや、ログインして使う会員ページを持つ会社は、作りを外注していても無関係ではない。

アプリの裏側のサーバとは

会員アプリが画面に出す会員情報や注文の履歴は、ふつう事業者のサーバに置かれている。アプリはログインや一覧の表示のたびに、サーバの決まった窓口へ問い合わせ、返ってきた答えを画面に出す。この窓口を API と呼び、窓口ごとの宛先を エンドポイント と呼ぶ。資料の脚注は、このサーバを「Web サイトやアプリの裏側で、ログイン認証や利用者情報の管理などを行うサーバ」と説明している。

A2B攻撃はどう進むのか

資料の図1は、手口を4つの段階で示している。

公開されているアプリを入手し、プログラムを解析する
解析の結果から、サーバの接続先、エンドポイント、送る値（パラメータ）、返ってくるデータの形を調べ、攻撃できそうな所を特定する
そのサーバの API の仕様に合わせた要求を組み立てて送り、脆弱性を探す
見つけた脆弱性を悪用する

資料によれば、この攻撃の特徴は、同じ攻撃を不特定多数のサーバに試すのではなく、アプリの解析で得た情報を使い、サーバごとに攻撃の中身を変えている点にある。ログインが要らない API だけでなく、利用者としてログインした後に使える API も狙われる場合があるという。

資料は AI の影響にも注意を促している。 AI によってプログラムの解析や脆弱性の探索が効率化され、こうした攻撃が、より多くのシステムに向けられる可能性がある、という書き方である。手間がかかるから小さな会社のアプリは後回しにされる、という前提は置きにくい。

アプリに穴が無くても漏れるのはなぜか

資料は、Android アプリ自体に脆弱性が無くても、サーバの API に認証や認可、入力値の検証の不備があれば、個人情報の漏洩やサーバへの不正アクセスにつながる可能性があると書いている。

理由は、攻撃者がアプリを通さずに API を直接呼べることにある。アプリの画面が自分の情報しか表示しない作りでも、それは画面の作りであって、サーバの守りではない。攻撃者は解析で窓口の宛先と送る値を知り、アプリを使わずにサーバへ直接要求を送る。サーバが要求のたびに「誰が」「何を」求めているかを確かめていなければ、画面からは見えないはずの情報まで返してしまう。資料も、恒久的な対策として、アプリ側の制御だけに頼らず、サーバ側で認証や認可、入力値の検証を行うことを挙げている。

アプリが解析されること自体を完全に防ぐのは難しい、とも資料は書く。そのうえで、アプリの内部構造や API の仕様が攻撃者に知られた場合でもサーバの安全が保たれるように設計し、運用することを求めている。

狙われている4つの穴

資料が、A2B 攻撃で探索と悪用の対象になっているとして挙げる脆弱性は4種類だ。並びは資料のとおりにした。

SSRF：外からの要求によって、サーバに本来しない通信をさせる。外から直接届かない社内のシステムや、クラウドの設定情報（メタデータ）に手が届き、機密情報を取られる可能性がある。
RCE（リモートでのコード実行）：外からの要求によって、サーバの上で不正な命令やプログラムを動かせる。情報の窃取、データの改ざん、不正なプログラムの実行など、深刻な被害につながる可能性がある。
SQL インジェクション：API に送る値を通して、データベースに不正な処理を実行させる。保存された個人情報を不正に取られたり、ログインを回避されたりする可能性がある。
IDOR（BOLA とも呼ぶ）：会員 ID などの番号を指定して情報を取り出す API で、その人が見てよい情報かを確かめていない。要求の中の番号を変えるだけで、他の利用者の氏名やメールアドレスが取れてしまう場合がある。番号が推測しやすく、順に並べて試せると、大量の漏洩につながるおそれがある。

IDOR は、前の節で書いた「画面の作りに頼った守り」がどう破れるかを、そのまま示している。

NICTが勧める対策

資料は、Android アプリを公開している事業者に、次の3つを早急に行うよう勧めている（図2）。

侵害の確認

アプリが使う API、サブドメイン、古い版の API、検証環境、クラウド上の公開サービスまで含めて、インターネットに出ている窓口を洗い出す
2026年8月以降のアクセスログ、API のログ、認証のログを見て、攻撃の痕跡を示す情報（IoC。IP アドレスや User-Agent など）との一致や、不審なアクセスがないかを調べる。できれば、それより前のログも見る
ログインせずに大量の情報を取る、連番の ID を使って次々にアクセスする、他の会員の情報を見たり変えたりする、認証トークンが不審に発行される、管理機能が使われる、といった普段と違う操作がないかを見る
不審なアクセスがあれば、影響の有無と範囲を急いで調べる

資料の6章には、IoC の一部として IP アドレスが3つ載っている。資料自身が、IoC との一致だけで侵害を断定することはできないとして、アクセスログや通信内容と合わせて判断するよう書いている。

脆弱性の点検

会員 ID などを変えて、他人や他の契約先（テナント）の情報が見えたり変えられたりしないか
認証トークンの不正な発行や偽造、他人の認証情報の取得、認証の回避ができないか。固定された認証情報や暗号の鍵が露出していないか
SQL インジェクションや NoSQL インジェクションで、データベースの情報を取ったり変えたりできないか
URL の取得、画像の処理、文書の変換といった機能を通じて、社内のネットワーク、クラウドのメタデータ、サーバ内のファイルに届かないか
S3、GCS、Firestore などのクラウドの保管場所に、認証なしで、または本来ない権限で入れないか
危険なデシリアライズ、任意のファイルの書き込みや上書き、管理機能の不適切な公開がないか

暫定的な緩和策

国外からのアクセスや、要らないアクセス元からの通信を一時的に制限する
使っていない公開 API、管理機能、検証環境を止めるか、アクセスを絞る
API へのアクセスの頻度や、番号を順に指定する要求を見張り、必要に応じてレート制限（一定時間あたりの回数の上限）や WAF で制御する
認証情報やトークンの漏洩や悪用が疑われるときは、無効にして発行し直す
脆弱性が見つかれば速やかに直す。すぐに直せず、重大な脆弱性があるかも確かめられず、一時的な制限でもリスクを許容できる水準まで下げられないときは、その API や機能、必要ならサービス全体の一時停止を検討する

アプリや会員ページを外注している会社が確かめること

上の対策の多くは、開発会社や保守の担当者の作業だ。アプリや会員ページを外注で作り、保守も同じ会社に任せているなら、社内で手を動かす前に、委託先がどこまで確かめたかを聞くのが早い。 NICT の対策から、発注した側が聞けて、答えで状況が分かるものを4つ選んだ。

アプリやページが使う API の一覧はあるか。古い版や検証用の環境も入っているか
2026年8月以降のアクセスの記録を、資料の IoC と照らして確かめたか。記録は何日分残っているか
会員番号や注文番号を変えた要求で、他の利用者の情報が返らないことを確かめたか
使っていない API、管理画面、検証用の環境を止めたか、アクセスを絞ったか

2つ目で記録の日数を聞くのは、8月以降を見るには、それだけの期間の記録が残っている必要があるからだ。 1つ目の一覧が無いなら、それを作ってもらうところから始まる。

委託先へは、たとえば次のように送ればよい。

○○様

10月13日に、情報通信研究機構（NICT）の脅威情報分析チームが、公開アプリを解析して裏側のサーバを狙う攻撃について注意喚起を出しました。こちらで公開しているアプリ（会員ページ）について、次の4点の状況を教えてください。

使っている API の一覧（古い版や検証用の環境を含む）があるか

2026年8月以降のアクセスの記録を、注意喚起の IoC と照らして確かめたか。記録は何日分残っているか

会員番号などを変えた要求で、他の利用者の情報が返らないことを確かめたか

使っていない API、管理画面、検証用の環境を止めたか

注意喚起の資料：https://cynex.nict.go.jp/pdf/library/lettice/261013-01.pdf

答えが「分からない」だった場合は、資料の暫定的な緩和策のうち、使っていない入口を止めることと、国外からのアクセスを絞ることを先に相談するとよい。どちらも、アプリの作りを直す前にできる。

Kanau Tech™では、お預かりした情報の扱いをAIの利用方針に、データの置き場所をセキュリティ対策に書いている。委託先への確かめ方や、返ってきた答えの読み方の相談も受け付けている。

出典

NICT CYNEX 脅威情報分析チーム LETTICE「【注意喚起】相次ぐ情報漏洩、その原因の一つは『アプリ解析からのサーバ攻撃』」（2026年10月13日、Rev 1.1、全7ページ） https://cynex.nict.go.jp/pdf/library/lettice/261013-01.pdf （2026年10月14日に確認）

同じ資料が参考文献に挙げている、国の機関などの注意喚起：

個人情報保護委員会「大規模な漏えい等事案を踏まえた対応について（注意喚起）」（2026年10月7日） https://www.ppc.go.jp/news/careful_information/261007_alert/
JPCERT/CC「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」（2026年10月8日） https://www.jpcert.or.jp/at/2026/at260030.html
内閣官房国家サイバー統括室「不正アクセスによる漏えい等の事案を踏まえた対応について」（2026年10月9日） https://www.cyber.go.jp/pdf/press/taiou.pdf
総務省「不正アクセスによる情報漏えい等の事案を踏まえた対応について（注意喚起）」（2026年10月9日） https://www.soumu.go.jp/menu_kyotsuu/important/kinkyu02_000678.html

関連記事:

IPA「AIセキュリティ短信」2026年8月号から中小企業が読み取るべき5つの論点：脆弱性の悪用が公開から48時間以内に集中する話
セキュリティ対策：Kanau Tech がお預かりしたデータをどこに置き、どう守るか

A2B攻撃とは？公開アプリの解析から裏側のサーバを狙う手口と、委託先に確かめる4つのこと