JPCERT/CCは2026年10月15日、相次ぐ不正アクセスに関する調査結果を公開しました。攻撃者がAIを使って既知の脆弱性のスキャンやAPI経由の攻撃を行っていたことや、Androidアプリを解析してAPIを特定する手口を確認したとしています。利用者向け画面だけでなく、アプリの裏側で動くサーバーの認証・認可や、クラウドの認証情報の管理を点検する必要があります。
翌16日には、日本経済新聞社が開発用クラウドへの不正アクセスと情報漏えいを発表しています。ただし、これらの公表事案がすべて同じ攻撃者や手法によるものと確認されたわけではありません。事案ごとに確認済みの事実と未確認の点を踏まえ、運用上の確認点を整理します。
公開アプリを解析し、裏側のAPIを狙う攻撃
JPCERT/CCの調査報告では、攻撃元とみられるサーバーから、Androidアプリの配布ファイルであるAPKや、解析ツールに関係するファイルが見つかっています。アプリを解析してAPIの接続先や処理を調べ、SSRFなどの弱点がないか確認した痕跡も報告されています。調査には、日本国外向けサービスを狙った動きや、今回の攻撃と直接関係しない別サーバーの情報も含まれます。すべてを国内組織への一連の攻撃とみなさないよう注意が必要です。
APIは、アプリや外部システムがサーバーと情報をやり取りする窓口です。正規のアプリだけが呼び出す想定でも、接続先や通信の仕組みが分かれば、別のプログラムからリクエストを送られる可能性があります。アプリ内の難読化や共通の署名処理だけに、サーバー側の安全性を委ねることはできません。
NICTの10月13日の注意喚起も、アプリ自体に脆弱性がなくても、バックエンドの認証・認可や入力値の検証に不備があれば不正アクセスや情報漏えいにつながるおそれがあると説明しています。
日経の発表は「約183万件」、認証情報の窃取経路は未公表
日本経済新聞社の10月16日の発表によると、システム開発に使うクラウドサービスの認証情報が何らかの方法で盗まれ、10月7日未明から朝にかけて不正アクセスを受けました。同社は不正アクセスに使われた認証情報を無効にしたとしています。個人情報保護委員会には10月11日に報告しました。
同社が公表した漏えい件数は、16日時点で約183万件です。件数による公表で、人数は示されていません。範囲は精査中としています。内訳として、氏名、メールアドレス、住所、電話番号、生年月日のいずれかを含む情報が約15万件、そのうちメールアドレスを含むものが約12万件とされています。このほか、単体では個人を特定できない識別子のみの情報が約168万件あります。クレジットカード情報は含まれないとしています。
同日時点では、情報の悪用などの二次被害やシステム停止、データ改ざんは確認されていないとの説明です。認証情報が盗まれた具体的な経路は発表されておらず、この事案をJPCERT/CCのAPI攻撃やAI利用と直接結び付ける根拠は確認できません。
APIは「ログインできるか」だけでなく「何を操作できるか」を確認
JPCERT/CCの10月8日公開・9日更新の注意喚起は、既知の脆弱性、設定ファイルなどの管理不備、APIキーの窃取など複数の経路を挙げ、サーバー側の対策を求めています。BIツールや従業員向け管理システムなど、不特定多数のアクセスを想定していないシステムも被害に遭っているとしています。
NICTも公開APIやサーバーの洗い出しを求めています。運用上は、APIを一覧にし、接続先や担当部署が分からない古い機能を残さないよう整理してください。JPCERT/CCの注意喚起と10月15日の調査報告の推奨事項を合わせると、主な確認点は次のとおりです。
- 操作対象ごとに認可する: ログイン済みでも、別の利用者の情報を読んだり書き換えたりできないか確認します。APIの経路とGET・POSTなどのHTTPメソッドごとに、必要な権限をサーバー側で判定します。
- 共通の秘密情報に依存しない: 長期間有効なAPIキーや秘密鍵を配布アプリに埋め込まず、権限と有効期間を絞ります。漏えい時に無効化・再発行できる運用も必要です。
- 機能別に呼び出し回数を制限する: ログイン、パスワード再設定、SMS送信、検索処理など、悪用のリスクが高い機能ごとに制限し、大量の実行や異常な増加を監視します。
- 外部URLを取得する処理を点検する: SSRF対策としてアクセス先を制限し、転送先が変わるリダイレクト後の宛先も検証します。
これらに加え、サーバーやアプリケーションの更新、管理機能の公開範囲、不要なデータの保有を見直します。JPCERT/CCが例に挙げたMetabaseなど、個別製品の脆弱性はそれぞれの告知に沿って対応してください。Metabaseについては、Metabaseの脆弱性を扱った記事も参照してください。
クラウド認証情報は、失効後の影響調査まで行う
ここからは、JPCERT/CCの認証情報管理の推奨事項と日経の公表を踏まえた、運用上の確認点です。開発環境にも実データがある場合、認証情報の漏えいが本番サービスとは別の経路で情報流出につながり得ます。
APIキーやクラウドの認証情報は、所有者、利用先、権限、有効期間を把握し、使っていないものを失効させます。可能な構成では、固定の長期鍵を減らし、有効期間の短い認証情報を使うことも検討してください。管理者権限や広いデータ読み出し権限が、開発用の処理に必要なのかも見直します。
窃取が疑われる場合、鍵の無効化・再発行と同時に、アクセスされた期間、対象データ、実行された操作をログで調べます。権限を追加された利用者がいないか、新しい鍵が作られていないかも確認します。現在の鍵を変えただけでは、すでに行われた操作や流出した情報は分かりません。
平常時の監視では、大量取得、普段と異なるアクセス元、権限や鍵の変更を追えるようにします。調査で公表されたIPアドレスなどは確認の手掛かりになりますが、過去の指標が現在も攻撃用とは限りません。JPCERT/CCも、公表したIPアドレスが調査時点では正規に使われている可能性があると注記しています。運用上は、公表された指標と一致しないことだけで安全と判断せず、操作内容と時刻を照合してください。
参考情報
- JPCERT/CC: 連続不正アクセス事案の攻撃手法に関する調査
- JPCERT/CC: 直近で相次いでいる国内組織における不正アクセスに関する注意喚起
- NICT: 相次ぐ情報漏洩、その原因の一つは「アプリ解析からのサーバ攻撃」
- 日本経済新聞社: 不正アクセスによる個人情報漏洩について
本記事は2026年10月20日時点で確認できた情報に基づきます。個別事案の調査結果や被害範囲は、各組織の続報を確認してください。
コメント