「一般公開していないから安全」は通用しない JPCERT/CCが示した不正アクセス4つの手口：アプリの裏側にあるAPIまで

「一般公開していないシステムだから安全」と考えていないだろうか。JPCERT/CCは、国内組織で相次ぐ不正アクセスによる情報漏えいを巡り、攻撃の痕跡や手口を公表した。標的は一般利用者向けアプリにとどまらず、BIツールや従業員向け管理システムにも及ぶ。公表された4つのケースから、見落としがちな侵入口と対策の要点を探る。

[＠IT]

　JPCERT/CCは2026年10月8日、国内組織で不正アクセスによる個人情報などの漏えい被害が相次いでいるとして、注意喚起を公表した。

　被害の対象は一般利用者向けのアプリだけではない。BI（ビジネスインテリジェンス）ツールや従業員向け管理システムでも、内部に保存していた情報が漏えいするケースが報告されている。JPCERT/CCは2026年10月9日に情報を更新し、不審な送信元IPアドレスやWebシェルを使った攻撃の痕跡を追加した。

管理用APIの悪用からWebシェル設置まで　今危ない4つのケースを解説

　今回の注意喚起は、日常的に発生するランサムウェア攻撃などとは別に、大量の個人情報などの漏えいにつながる攻撃類型が増加している恐れがあるとして、注意を促すものだ。

　JPCERT/CCによると、複数の製品やサービスで被害が発生している一方、技術情報の共有が不足しており、把握できている情報は限定的かつ断片的だという。全ての事案で同一の攻撃手法が使われたと確認されているわけではない。今回の注意喚起では、報告された攻撃手法や痕跡を4つのケースに分類している。

ケースA　ソフトウェアの既知の脆弱性悪用

　ケースAは、標的ごとにさまざまなソフトウェアの既知の脆弱（ぜいじゃく）性を探索し、悪用を試みる攻撃だ。単一の脆弱性を共通して悪用するのではなく、標的の環境に応じて異なる脆弱性を探している可能性がある。また、脆弱性だけでなく、機器の管理不備を突き、環境設定ファイルやバックアップファイルの窃取を試みるケースも想定されている。JPCERT/CCは2026年10月9日、及び同年10月7日に悪用されていた不審な送信元IPアドレス「20.210.128[.]125」を追加した。

ケースB　アプリの管理用APIを悪用した不正操作

　ケースBは、アプリの管理用APIを悪用した不正操作だ。一般公開されているスマートフォンアプリを解析してAPIのエンドポイントやキーを特定し、通常の画面操作では実行できない内部APIにアクセスする手口が報告されている。

　具体的には、ユーザー権限の変更や不正アカウントの作成の他、HTTPヘッダや認証トークンの与え方を変えて応答の違いを調べる手口、NoSQLインジェクションによるアカウント情報の探索などが含まれる。他のシステムへの侵害で窃取したAPIキーを悪用するケースも報告された。

　APIのエンドポイントやキーがアプリの解析によって判明すること自体と、APIの不正利用が成立することは別の問題だ。重要なのは、サーバ側で利用者の認証や権限の検証が適切に実施され、許可されていない操作を拒否できるかどうかだ。

　JPCERT/CCはケースBに関連して、不審な送信元IPアドレスも公表した。2026年10月9日の更新では5件を追加している。追加分のうち2件は同年8月28日に観測されたものだ。既出のIPアドレスについても、調査時点では正規利用されている可能性があるとしている。User-Agentの例として「curl/7.88.1」「python-requests/2.34.2」なども掲載した。

ケースC　BIツール「Metabase」の脆弱性悪用

　ケースCは、BIツール「Metabase」のSQLインジェクションの脆弱性「CVE-2026-72898」の悪用だ。この脆弱性もAPIへの不正なリクエストを通じて悪用される。JPCERT/CCは2026年8月14日に同脆弱性に関する注意喚起を公表しており、影響を受ける製品や対策の詳細については、同資料を参照するよう求めている。

　今回の注意喚起では、2026年8月上旬〜9月上旬に悪用された不審な送信元IPアドレス3件と、User-Agentの例として「python-requests/2.33.1」「Metabase-GHSA-vwf4/2.0」を掲載した。

ケースD　アプリケーションサーバへのWebシェル設置

　ケースDは、公開Webサーバからアクセス可能なアプリケーションサーバにWebシェルが設置された事案だ。JPCERT/CCが2026年10月9日の更新で追加した。

　報告された事案では、WARファイル内のJSPファイルが悪性のWebシェルとして動作する。Webシェルは、リクエストに含まれる特定のクエリパラメーターを受け取り、シェルコマンドとして実行する機能を持つ。同年9月には「124.133.237[.]18」からWebシェルに対するGETおよびPOSTリクエストが繰り返し確認された。

　Webシェルが設置されていた場合、サーバで不正なコマンドを実行される恐れがある。公開Webサーバだけでなく、そこからアクセスできるアプリケーションサーバも含めて、侵害の有無を確認する必要がある。

今すぐ実行したい　JPCERT/CCが推奨する対策

　JPCERT/CCは対策として、まずAPIへのアクセスに単位時間当たりのリクエスト件数制限を設け、短時間に繰り返されるアクセスや大量実行を防ぐよう推奨した。ログイン、パスワードリセット、SMS送信、検索処理など、悪用や負荷のリスクが高い機能には、それぞれレート制限や利用回数制限を設定する。

　また、非公開APIを含む各エンドポイントでアクセス制御を実施し、許可された利用者やHTTPメソッドからのアクセスだけを受け付けるよう求めている。API利用者やAPIトークンに付与する権限は必要最小限にとどめ、トークンには適切な有効期限を設定する。不要になったトークンや漏えいが疑われるトークンを速やかに無効化できる仕組みも必要だ。APIのセキュリティ対策については、OWASPのガイドラインなどを参照するよう案内している。

　これらに加え、JPCERT/CCは次のような対策も挙げた。

• 利用地域が限定されるサービスでは、アクセス元の地域を制限する
• 既知の脆弱性の影響を受けるバージョンには、修正済みの更新版を適用する
• Webサーバなどが侵害された後の横展開対策を見直す
• 不正アクセスの検知体制と、検知後の初動対応を点検する
• 漏えい発生時の二次被害を防ぐため、顧客に多要素認証などを平時から呼び掛ける
• 業務上不要なサービスや管理機能のインターネット公開を停止する
• 法令や契約で定められた保存期間を過ぎたデータや、利用目的を終えたデータを残さない

　今回の注意喚起で見落とせないのは、一般利用者向けのサービスだけでなく、従業員向けシステムやBIツールなど、不特定多数の利用者からのアクセスを想定していないシステムも被害に遭っている点だ。

　情報システム部門は、インターネット公開の有無だけで安全性を判断するのではなく、管理機能やAPIのアクセス制御、トークンの権限と有効期限、サーバ間の接続範囲まで点検したい。併せて、過去のアクセスログやWebシェルの痕跡を確認し、すでに侵害されていないかを調べることも重要になる。

　JPCERT/CCは、今回の注意喚起に関連する不審なアクセスや侵害が疑われる事象、攻撃手法、侵害原因などについて情報提供を呼び掛けている。