連続不正アクセス事案の攻撃手法に関する調査

JPCERT/CCは、2026年10月8日に、国内の複数の組織で相次いで公表された不正アクセスによる個人情報などの漏えい被害に関する注意喚起を公開しました。 JPCERT/CCでは、複数の組織と連携し、攻撃に使用された可能性のあるインフラの調査を進めています。その過程で、攻撃者がAIを利用して、既知の脆弱性のスキャンやAPI経由での攻撃などを実施していたことを確認しました。こうした攻撃元サーバーはインターネット上で複数確認されており、日本以外の地域向けのWebサービスに対しても攻撃を行っていました。

本記事では、JPCERT/CCが攻撃元サーバーの調査を通じて確認した、国内外のWebサービスなどに対する攻撃の状況を紹介します。

攻撃元サーバーの調査その1

今回確認した攻撃の特徴の一つは、Android向けアプリケーションの配布ファイル（APKファイル）を解析し、特定したAPIを悪用する点です[1]。攻撃元サーバー上では、攻撃者がAPKファイルを解析し、関連するAPIにSSRF（Server-Side Request Forgery）などの脆弱性がないかを調査していた痕跡を確認しています。

図1は、調査対象サーバーで確認したファイル一覧の一部です。このサーバーには、日本以外の地域向けに提供されているアプリケーションが保存されていました。

図2は、SSRFの検証に使用されたと考えられるPythonスクリプトです。

このスクリプトはHTTPSサーバーとして動作し、特定のリクエストに対してHTTPステータスコード302のリダイレクト応答を返す処理を実装しています。

攻撃元サーバーの調査その2

別の調査対象サーバーでは、複数のAPKファイルとともに、Flutterアプリケーションのリバースエンジニアリングに利用されるBlutterや、Androidアプリケーションの解析に利用されるjadxに関連するファイルを確認しました。Blutterの詳細は、Appendix Aをご覧ください。

図3は、このサーバーで確認したファイル一覧の一部です。

図3：Androidアプリケーションの解析および脆弱性検証に関連するファイル一覧

このサーバーには、これらのツールに関連するファイルのほか、apk_extract/など、APKファイルの展開に関連する可能性のあるディレクトリも存在していました。また、strings_libapp.txtなど、ネイティブライブラリから抽出した文字列の保存先を示唆する名称のファイルも確認しました。

攻撃元サーバーの調査その3

今回の攻撃とは直接関係しない別のサーバーでは、Webアプリケーションへの攻撃に加え、MySQL、Jenkinsサーバー、メールゲートウェイなどを標的とする、さまざまな攻撃手法に関連するファイルを確認しました。

図4は、このサーバーで確認したファイル一覧の一部です。サーバー上では、EDRの回避（EDR Bypass）を試みた痕跡に加え、標的のネットワーク内に設置したと考えられるWebシェルなどを確認しました。これらの痕跡から、攻撃者はネットワーク内部への侵入を試みていたと考えられます。

おわりに

JPCERT/CCは、引き続き関係者と連携し、これらの攻撃への対応を進めていきます。関連する情報（攻撃元IPアドレス、攻撃手法など）をお持ちの場合は、JPCERT/CCまで情報をご提供いただけますと幸いです。また、攻撃の標的となっている可能性がある組織を確認した場合、当該組織に連絡しています。 JPCERT/CCから連絡を受けた際は対応をお願いいたします。

攻撃インフラ調査チーム

参考情報

[1] NICT：【注意喚起】相次ぐ情報漏洩、その原因の一つは「アプリ解析からのサーバ攻撃」
https://cynex.nict.go.jp/library/261013-01.html

Appendix A：Flutterアプリケーションのリバースエンジニアリングについて

Flutterは、単一のコードベースから複数のプラットフォーム向けのアプリケーションを開発できるフレームワークです。攻撃元サーバーで確認したBlutterは、Flutterアプリケーションに含まれるDartのAOT（Ahead-of-Time）コンパイル済みコードを解析するためのオープンソースツールです。 Blutterなどを用いたリバースエンジニアリングによって、アプリケーションの内部構造やAPIとの通信処理などを特定できる可能性があります。

2026年6月に公開されたIQCrafterの技術記事では、実際のFlutterアプリケーションを対象に、Frida、Blutter、LIEF、Capstoneなどを組み合わせて解析する手法が紹介されています。同記事では、libapp.soの静的・動的解析によって、アプリケーションに埋め込まれたRSA秘密鍵やAPIの認証処理、リクエストの署名生成ロジックを特定した事例が説明されています。さらに、署名処理を再現し、正規アプリケーションを介さずに、独立したPythonクライアントから本番環境のAPIへアクセスできたと報告されています。

また、NerdzLabが公開した技術記事でも、APKファイルやAOTコンパイル済みのlibapp.soを解析し、APIキーや秘密情報、クラス構造、関数アドレスなどを調査する手法が紹介されています。これらの事例は、Flutterアプリケーションのコードがコンパイルされていても、内部に埋め込まれた秘密情報やAPIの認証処理を特定できる可能性があることを示しています。

アプリケーション内に共通の秘密鍵やAPI認証に使用する秘密情報が埋め込まれている場合、これらの抽出によって、正規アプリケーションを介さないAPIリクエストの生成につながる恐れがあります。こうしたリスクを踏まえ、次の対策を実施することを推奨します。

秘密情報の保護：APIの認証に使用する秘密鍵や、有効期間の長い認証情報をアプリケーションに埋め込まない。
サーバー側での認証・認可：アプリケーション内の署名処理や難読化だけに依存せず、サーバー側で利用者を適切に認証し、操作対象や操作内容に応じた認可を実施する。
APIの不正利用対策：レート制限や異常なリクエストの監視を実施し、正規アプリケーション以外からのアクセスも想定する。
SSRF対策：外部URLの内容を取得するAPIでは、アクセス先を制限し、リダイレクト後の宛先も検証する。

参考情報：

Appendix B：IoC

210.149.87[.]120
118.26.36[.]16
69.10.51[.]162

攻撃元サーバーの調査 その1

攻撃元サーバーの調査 その2

攻撃元サーバーの調査 その3