JPCERT/CC注意喚起AT-2026-0030とは？国内で相次ぐ不正アクセス5つの手口と岩井コスモ証券の件、自社サービスで確かめること

2026年の9月ごろから、国内の企業や団体で「不正アクセスによって会員情報が漏れました」という発表が続いています。飲食チェーンのアプリ、アンケートサイト、大学、そして証券会社まで、業種も規模もばらばらです。ニュースを追いかけていると、どれも同じ犯人が同じ方法でやっているように見えてしまいますが、実際にはそうとは限りません。

こうした状況を受けて、日本のセキュリティ事故の相談窓口であるJPCERT/CC（ジェーピーサート・コーディネーションセンター、国内のサイバー攻撃の情報を集めて注意を呼びかける一般社団法人）は、10月8日に「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」（JPCERT-AT-2026-0030）を出しました。10月9日と10月23日に内容が足され、23日の更新では、AIを使った「ペネトレーションテスト基盤」が攻撃に使われているという「ケースE」が加わっています。

この記事では、JPCERT/CCの注意喚起の本文と、同じ時期に出たJPCERT/CCの調査ブログ、NICT（情報通信研究機構）やセキュリティ各社の報告をもとに、国内で確認されている5つの攻撃の型を順番に説明します。そのうえで、10月14日に起きた岩井コスモ証券の不正アクセスと不正取引を、会社の発表に沿って詳しく見ていきます。

最後に、Webサービスやスマホアプリを作っている人、会社のWebサイトを担当している人が、自分のサービスで確かめておきたいことをまとめます。

9月から続く国内の不正アクセスと、国の動き

まず、この注意喚起が出るまでの流れを整理しておきます。JPCERT/CCの注意喚起は、冒頭で「2026年9月前後から、国内組織で不正アクセスによる個人情報等の漏えい被害が相次いでいる」と書いています。被害は複数の製品やサービスにまたがっていて、技術的な情報の共有が十分でないため、全体像はまだつかめていない、という書き方です。

注意喚起がもうひとつ強調しているのは、狙われたのが一般の利用者向けのアプリだけではない、という点です。BI（ビジネスインテリジェンス、社内のデータを集計してグラフや表にする道具）や、従業員向けの管理システムのように、そもそも不特定多数の人が使うことを想定していないシステムからも、内部の情報が漏れています。「お客さま向けのサイトは気をつけていたが、社内向けの道具は手薄だった」という組織にとっては、耳の痛い指摘です。

また、この注意喚起は、ときどき起きるランサムウェア（データを暗号化して身代金を要求する攻撃）の被害とは別に、「大量の情報漏えいにつながる攻撃」を扱うものだと位置づけられています。後で出てくる大阪公立大学の件はランサムウェアと大学が判断した事案なので、注意喚起の5つの型とは少し性格が違います。この点は表を作るときに分けて書きます。

この時期には、JPCERT/CCだけでなく、国の機関が次々に注意を呼びかけました。セキュリティの事件をまとめているブログ「piyolog」の整理と、各機関の公表をもとに、主なものを並べると次のとおりです。

IPA（情報処理推進機構、国のIT政策を支える独立行政法人）の「速やかに実施すべき対策等」は、まず自分たちが外に公開しているアプリやサービスを洗い出し、直近1か月のログに異常がないかを見て、その後3か月へと範囲を広げるよう勧めています。クラウドサービスやVPN（社外から社内のネットワークにつなぐための仕組み）など、部署ごとに契約している外部のサービスも含めて、身に覚えのないアカウントがないか、無効にしたはずのアカウントが有効に戻っていないかを確かめるよう求めています。

数字の面では、piyologによると、デジタル大臣が10月2日の会見で、不正の目的による漏えい等の件数を令和6年度7,604件、令和7年度3,822件と説明し、件数が多いことは確かでも、必ずしも増え続けているわけではないと述べています。報道で「急増」という言葉が目立つ一方で、統計の上では波があることも頭に入れておくとよいと思います。大きな事案が短い期間に集中したことで、ひとつの流れに見えている面もありそうです。

JPCERT/CCの注意喚起「AT-2026-0030」を読む

ここからは、注意喚起そのものの中身を見ていきます。注意喚起の管理番号はJPCERT-AT-2026-0030で、公開は10月8日、最終更新は10月23日です。更新履歴には、10月9日に「概要」と「攻撃手法や攻撃の痕跡」に情報を追記、10月23日に「概要」「攻撃手法や攻撃の痕跡」「参考情報」に追記し、攻撃手法の記載を整理した、とあります。

公開された当初の報道では「3つの攻撃手法」として紹介した記事と、「ケースA〜D」の4つとして紹介した記事があり、数え方が食い違っていました。10月9日の追記でWebシェルの事例（ケースD）が加わったことが、その理由と考えられます。10月23日にケースEが加わり、現在は5つの型が並んでいます。

5つの型を表にすると次のとおりです。表の「観測時期」は、注意喚起に載っている不審な通信元のIPアドレス（インターネット上の住所にあたる番号）の観測日や稼働日をもとにしたものです。

なお、ブリーフや一部のまとめ記事では「NoSQLインジェクションによるアカウント情報の窃取」を独立した型のように扱っているものも見かけますが、注意喚起の本文では、NoSQLインジェクションはケースB（API経由の不正操作）の中の一項目として書かれています。5つ目の型として独立しているのは、Webシェルの設置（ケースD）です。この記事では本文の分け方に従います。

不審な通信元のIPアドレスについても、注意喚起は慎重な書き方をしています。ケースBのIPアドレスは、調査した時点で正規の利用者が使っている可能性もあるため、「過去にこのアドレスからアクセスがあったかを確かめる」目的で使ってほしい、としています。Tor（トーア、通信元を隠すための中継の仕組み）の出口や、一般家庭の回線を借りる「レジデンシャルプロキシ」を経由したアクセスも確認されているので、IPアドレスで一律に遮断しても効果は限られます。

ケースAとD：既知の脆弱性、置きっぱなしのファイル、そしてWebシェル

最初に、比較的なじみのある2つの型から見ていきます。ケースAは「既知の脆弱性の探索」、ケースDは「Webシェルの設置」です。どちらも新しい手口ではありませんが、今回の一連の事案で実際に確認されています。

ケースA：既知の脆弱性を、標的ごとに片っ端から試す

脆弱性（ぜいじゃくせい）は、ソフトウェアの欠陥のうち、攻撃に使えてしまうもののことです。「既知の」脆弱性とは、すでに見つかって公表され、多くの場合は修正版も出ているものを指します。CVE（シーブイイー）という番号が振られていることが多く、「CVE-2026-72898」のように年と連番で呼ばれます。

注意喚起によると、ケースAの攻撃者は、標的ごとにさまざまな既知の脆弱性をスキャン（自動で順番に調べること）して、悪用を試みています。ここで言う「標的ごとに」は、ひとつの欠陥だけを狙って世界中を探す攻撃ではなく、狙ったサイトに合わせて使っていそうな製品の欠陥を幅広く当ててみる、というやり方です。報道でも、一連の攻撃は共通の脆弱性を突いているのではなく、標的ごとに弱点を探っている可能性がある、と伝えられています。

見落としやすいのは、ケースAには「脆弱性ではない管理の不備」を突く攻撃も含まれていることです。注意喚起は具体例として、環境設定ファイルやバックアップファイルの窃取を挙げています。

• 環境設定ファイルは、たとえば.envやconfig.php、application.ymlのように、データベースの接続先やパスワード、外部サービスのAPIキーを書いておくファイルです。
• バックアップファイルは、backup.zipやdb.sql、index.php.bakのように、作業のついでに作られて公開フォルダに残ってしまうことがあります。

注意喚起では、ケースAの不審な通信元として10月7日ごろに観測されたIPアドレスが1件挙げられています。数は少ないですが、型としては最も広く行われているものだと考えてよいと思います。

ケースD：アプリケーションサーバーに置かれたWARファイル

ケースDは、10月9日の追記で加わった型です。注意喚起によると、公開しているWebサーバーからアクセスできる位置にあるアプリケーションサーバーに、WARファイルが置かれる事例が確認されました。

少し用語を噛みくだきます。Webサイトの裏側では、画面を返す「Webサーバー」と、実際の処理を行う「アプリケーションサーバー」が分かれていることがあります。

• Javaで作られたシステムでは、TomcatやJBossといったアプリケーションサーバーがよく使われます。
• WAR（ウォー）ファイルは、Javaで作ったWebアプリをひとまとめにした配布用のファイルで、アプリケーションサーバーに置くと、そのアプリが動き始めます。
• JSPは、Javaで書かれたWebページの形式です。

攻撃者が置いたWARファイルの中のJSPは、簡易的な「Webシェル」として動いていました。Webシェルは、Webページの形をしているけれど、実際にはサーバーに好きな命令を実行させるための裏口です。

注意喚起によると、このWebシェルは特定のクエリパラメーター（URLの「?」の後ろに付ける値）を受け取り、その値をシェルコマンドとして実行する仕組みでした。つまり、URLに命令を書いて開くだけで、サーバーの上でその命令が動いてしまう状態です。不審な通信元からは、9月ごろにGETとPOSTのアクセスが繰り返されていたと書かれています。

WARファイルを置くには、ふつうはアプリケーションサーバーの管理画面を使います。Tomcatであれば「Manager」と呼ばれる管理用の画面があり、ここからWARファイルを上げて配置できます。注意喚起は、どうやってWARファイルを置かれたのかまでは書いていませんが、管理画面が外から届く場所にあり、初期設定や弱いパスワードのままだった場合は、この経路が使われることがあります。後半の「確かめること」で、管理画面の公開についてもう一度取り上げます。

Webシェルが置かれると、攻撃者はそのサーバーを足場にして、社内のほかのサーバーへ進もうとします。注意喚起が対策の中で「Webサーバーなどが侵害された後の横展開対策を見直す」ことを挙げているのは、このためです。横展開は、1台目に入った攻撃者が、ネットワークの中で隣のサーバーへ次々と移っていくことを指します。

ケースB：スマホアプリを解析して、画面にないAPIを叩く

ケースBは、今回の注意喚起の中で最も項目が多く、記述も詳しい型です。キーワードは「API」と「スマホアプリの解析」です。

APIと「画面からは使えない機能」

API（エーピーアイ）は、プログラム同士がやりとりするための窓口です。スマホアプリで会員情報を見たり、ポイントを使ったりするとき、アプリは裏でサーバーのAPIに「この会員の情報をください」「このポイントを使います」というリクエストを送っています。アプリの画面は、APIの結果を見やすく並べているだけです。

ここに落とし穴があります。アプリの画面にボタンがないからといって、その機能のAPIがサーバーに存在しないとは限りません。

たとえば、運営側の管理用の機能として「利用者の権限を変える」「アカウントを作る」APIがあり、それが一般の利用者と同じ入口から呼べる状態になっていることがあります。画面に出していないから安全、という考え方は、APIを直接呼ぶ攻撃者には通用しません。

注意喚起は、ケースBで確認された操作として次のものを挙げています。

• 公開されているスマートフォンアプリを解析し、APIのエンドポイント（APIの呼び出し先のURL）やキーを特定する
• 画面の操作では実行できない内部APIを狙い、利用者の権限を変えたり、不正なアカウントを作ったりする
• リクエストのヘッダー（通信に付ける付帯情報）を付けたり外したり、形式のおかしい認証トークンを付けたりして、応答の違いからサーバーの振る舞いを探る
• NoSQLインジェクションのブラインド探索で、アカウント情報を特定する
• ほかのシステムから盗んだAPIキーを使う

3つ目の「応答の違いから探る」は、地味ですが重要です。正しいトークンのとき、トークンがないとき、形式がおかしいときで、サーバーの返事がどう変わるかを比べれば、認証の確認がどこで、どれくらい厳しく行われているかが分かります。エラーの文面が丁寧すぎたり、トークンがなくても一部のデータが返ってきたりすると、それが手がかりになります。

NoSQLインジェクションの「ブラインド探索」とは

NoSQL（ノーエスキューエル）は、MongoDBのように、表の形ではなくJSONに近い形でデータを持つデータベースの総称です。SQLインジェクションが「入力にSQLの命令を混ぜてデータベースをだます」攻撃であるのと同じように、NoSQLインジェクションは「入力にデータベースの検索条件の書き方を混ぜてだます」攻撃です。

分かりやすい例を挙げます。ログインのAPIが、送られてきたJSONの{"user": "taro", "password": "..."}をそのままMongoDBの検索条件に渡しているとします。

• 攻撃者がパスワードの代わりに{"$ne": null}（「nullではない」という条件）を送ると、「パスワードが何であれ一致する」という意味になり、パスワードを知らなくても通ってしまうことがあります。
• {"$regex": "^a"}（「aで始まる」という条件）を送れば、「この利用者のパスワードやメールアドレスはaで始まるか」を1文字ずつ確かめることもできます。

「ブラインド探索」は、この最後のやり方のことです。データそのものは画面に表示されなくても、「一致した」「一致しなかった」という応答の違いだけを手がかりに、少しずつ情報を割り出していきます。

1回で分かる情報はわずかでも、自動で何万回も繰り返せば、アカウント情報を特定できてしまいます。後で紹介するリクエスト数の制限が対策として挙がっているのは、この種の地道な探索を遅くする効果があるからです。

アプリの中に、鍵と手順が書いてある

スマホアプリの解析については、NICTのサイバーセキュリティの研究チームLETTICEが、10月13日に「A2B攻撃（App-to-Backend Attack）」という名前で注意喚起を出しています。公開されているAndroidアプリを解析して、裏側のサーバーとやりとりするAPIの入口や仕様を調べ、そのサーバーに合わせた攻撃を仕掛ける、という流れです。NICTは、アプリ自体に欠陥がなくても、サーバー側の認証や認可、入力のチェックが弱ければ、不正アクセスや個人情報の漏えいにつながると指摘し、AIを使えばアプリの解析や弱点探しが速くなるため、影響を受けるシステムが増えるおそれがあるとしています。

JPCERT/CCが10月15日に公開した調査ブログ「連続不正アクセス事案の攻撃手法に関する調査」は、攻撃に使われたとみられるサーバーの中身を、複数の組織と協力して調べた結果です。あるサーバーには、Androidアプリの配布ファイル（APK）を解析し、見つけたAPIにSSRF（サーバーに別のサーバーへ勝手にリクエストを送らせる攻撃）などの弱点がないかを調べた痕跡がありました。別のサーバーには、Flutter（フラッター、ひとつのコードでiPhoneとAndroidのアプリを作れる仕組み）で作られたアプリを解析する道具「Blutter」や、Androidアプリを解析する道具「jadx」、複数のAPKファイルなどが置かれていました。

この調査ブログは、Flutterのアプリから、埋め込まれた秘密の鍵や、APIの認証の処理、リクエストに署名する手順を取り出し、公式アプリを使わずに本番のAPIを呼び出せることを示した外部の解説も紹介しています。そのうえで、次のような対策を挙げています。

• アプリの中に秘密の鍵や、長く使える認証情報を入れない
• アプリ側の署名や難読化（コードを読みにくくすること）に頼らず、認証と認可をサーバー側で行う
• 公式アプリ以外からのリクエストが来る前提で、回数の制限と異常なリクエストの監視を行う
• URLを受け取って取りに行くAPIは、行き先を制限し、転送先も確かめてSSRFを防ぐ

アプリを作る側から見ると、「アプリは利用者の手元にある以上、中身はいずれ読まれる」と考えるのが出発点になります。難読化は解析の手間を増やしますが、読まれないことを保証するものではありません。マクニカの解説も、コードを難読化していても解析によって取得されうると書いています。

ケースBで観測された通信の特徴

注意喚起には、ケースBの不審な通信元として、アプリ解析型で4件、それ以外で7件のIPアドレスが観測日とともに載っています。いちばん古いものは8月28日ごろで、新しいものは10月8日の夜から9日の未明にかけてです。

攻撃者のUser-Agent（通信に付ける「どのソフトから来たか」の自己申告）には、curlやpython-requests、一般的なChromeのものに加えて、公開アプリと同じものもあったとされています。アプリと同じUser-Agentを名乗られると、ログを見ても本物のアプリとの区別がつきにくくなります。

セキュリティ会社のサイバーセキュリティクラウドは10月9日、マクニカが公開したIPアドレスを起点に自社の観測データを調べ、同じ攻撃者とみられる相手が約40分間に326のIPアドレスを使い分けて1,200件を超えるアクセスをしていたと報告しました。

SQLインジェクションでログインの回避を試し、だめなら事前に作ったらしいアカウントで正規にログインし、ログイン後の機能でもう一度探り、ポイント制度のあるサイトでは他人のポイントを取れないかを探る、という流れだったそうです。1つのIPアドレスあたりのアクセス数が少ないため、「同じIPから大量のアクセスがあったら警報」という監視では見逃すおそれがある、と同社は指摘しています。

ケースC：BIツールMetabaseのSQLインジェクション（CVE-2026-72898）

ケースCは、特定の製品の特定の脆弱性です。Metabase（メタベース）は、データベースにつないで、売上や会員数などを集計したグラフや表を作れるオープンソースのBIツールです。エンジニアでなくても画面から集計できるので、スタートアップから大企業まで、社内の分析用として広く使われています。

JPCERT/CCは、この脆弱性について8月14日にすでに注意喚起（JPCERT-AT-2026-0023）を出しています。それによると、Metabaseは8月6日（日本時間）に、SQLインジェクションの脆弱性CVE-2026-72898を公表しました。

認証のいらないリクエストで、Metabase自身の設定や利用者を保存しているデータベース（アプリケーションデータベース）に不正なSQLを実行され、管理者の権限を取られる可能性があります。Metabaseによると、修正の前から攻撃に使われていた「ゼロデイ攻撃」が確認されており、海外では複数の組織が被害を公表していました。PoC（概念実証、攻撃が成り立つことを示すコード）とみられる情報も出回っていました。

影響を受ける版と、直った版は次のとおりです。

58系より前の版は影響を受けず、クラウド版のMetabase Cloudは対策済みです。「x」の部分は、無償のオープンソース版が「0」、有償版が「1」で始まる番号の付け方を指しています。

侵入されたかどうかの手がかりとして、JPCERT/CCは、このエンドポイントがインターネットから届く状態だった場合に、POST /api/session/reset_password（応答400）とGET /api/user/current（応答200）が続けて記録されていないかを見るよう勧めています。

Webサーバーのアクセスログを持っていれば、たとえばgrep -E "reset_password|/api/user/current" access.logのように絞り込んで、時刻と通信元を並べてみると確かめやすくなります。

侵入の可能性があれば、JPCERT/CCは次の対応を求めています。

• 利用者のセッション、APIキー、管理者アカウントを確認する
• Metabaseが接続しているデータベースのパスワードを変える
• 両方のログで不審な操作がないかを調べる

同じ8月6日には、別のSQLインジェクションの脆弱性CVE-2026-72899も公表されています。今回の注意喚起（AT-2026-0030）では、ケースCの不審な通信元として8月上旬から9月上旬に観測されたIPアドレスが3件挙がっており、User-Agentの例としてpython-requests/2.33.1とMetabase-GHSA-vwf4/2.0が示されています。後者は、攻撃用のスクリプトが自分で名乗っている名前とみられます。

ケースE：AIペネトレーションテスト基盤が攻撃に使われた

10月23日の更新で加わったケースEは、AIを使った「ペネトレーションテスト基盤」が攻撃に使われている、というものです。ペネトレーションテストは、依頼を受けた専門家が、実際に侵入を試みてシステムの弱さを確かめる検査のことです。本来は守る側のための正当な仕事ですが、その作業をAIに任せる道具が出てきたことで、攻撃する側も同じ道具を使えるようになりました。

注意喚起が名前を挙げているのは、Cairn（ケルン）、CyberStrikeAI（サイバーストライクAI）、ARTEX（アーテックス）などです。これらを使った攻撃は、主にインターネットに公開されたWebアプリを狙い、脆弱性の探索と悪用、設定ファイルやバックアップファイルの窃取を試みていました。

インターネットに公開されたWSUSサーバーを狙う試行も含まれます。WSUS（ダブリューサス）は、社内のWindowsパソコンに更新プログラムを配るためのマイクロソフトのサーバーで、本来は社内だけで使うものです。不審な通信元として、9月23日から10月20日ごろにかけて観測された9件のIPアドレスが載っています。

3つの道具について、公表されている情報を簡単にまとめます。

ARTEXについてpiyologがまとめたところでは、READMEでは利用目的を個人の学習や手元での検証に限り、外部へのスキャンや攻撃を禁じていました。9月の版では、政府や教育機関のサイトを初期設定で対象外にする規則も足されています。

それでも、オープンソースとして公開された道具は、作り手の意図と関係なく使えてしまいます。開発者が10月8日に更新の終了と非公開化を表明した後も、GitHubのフォーク（複製）や派生版、Dockerのイメージが多数残っていると報告されています。

「AIが使われた」と言える根拠はどこまであるか

ここは丁寧に分けておきたいところです。国内の一連の事案で「AIが使われた」という話には、確かめられた事実と、振る舞いからの推測が混ざっています。

• 確認された事実：JPCERT/CCは10月15日の調査ブログで、攻撃に使われた可能性のあるインフラを調べた結果、攻撃者がAIを使って既知の脆弱性のスキャンやAPI経由の攻撃を行っていたことを確認した、と書いています。ただし、どのAIのモデルや道具を使ったのかまでは書かれていません。注意喚起のケースEは、具体的な道具の名前を挙げています。
• 振る舞いからの推測：サイバーセキュリティクラウドは、攻撃者が1つ1つの応答を見て次の手を変えていること、人手では難しい量なのに道具特有の規則性がないことから、AIエージェントかそれに近い仕組みの可能性があるとしつつ、AIの利用を直接示す痕跡は確認していないと明記しています。マクニカも、一連の事案でAIが使われたと断定できるログや痕跡は確認していない、としています。
• その中間：piyologの整理によると、イエラエ（GMOサイバーセキュリティ byイエラエ）は10月19日、攻撃元のインフラでARTEXが使われていたと公表し、攻撃元のインフラが日本企業約20社を標的にしていたとしています。この報告の本文は、執筆時点で同社のサイトが簡易版で運用されていて直接確かめられませんでした。

この見方は、守る側にとっては悪い話ばかりではありません。狙われているのが基礎的な不備であれば、基礎的な対策で多くを防げるからです。逆に言えば、「うちは小さいサイトだから狙われない」という考えは通じにくくなっています。人の手間がかからない以上、小さなサイトにも順番が回ってきます。

岩井コスモ証券：委託先の「管理機能」から売買注文まで

ここからは、同じ時期に起きた国内の事案のうち、証券会社で不正な取引まで起きた岩井コスモ証券の件を、会社の発表に沿って詳しく見ていきます。この件は、注意喚起のどのケースに当たるのかは公表されていませんが、「利用者向けの入口は固かったのに、管理機能から入られた」という点で、注意喚起の指摘とよく重なります。

関係する会社と、時系列

岩井コスモ証券は大阪に本社を置く証券会社で、インターネットで株を売り買いするためのシステムを、株式会社トレードワークス（東証スタンダード上場）から提供を受けています。トレードワークスは、証券会社向けにネット取引のシステムを作って運用している会社です。今回、攻撃を受けたのはこのトレードワークスのシステムで、岩井コスモ証券から見ると「外部委託先」にあたります。

両社の発表と報道をもとに、時系列を並べると次のとおりです。

トレードワークスが説明した原因

トレードワークスの10月16日の適時開示は、原因を次のように説明しています。利用者のログインには多要素認証やパスキーなど多重化された認証が設けられており、通常の経路からの不正ログインは防がれていた。一方で、同社のシステムの一部の管理機能に設定の不備があり、第三者にこれを悪用された。

これは同社の管理が不十分だったことによるもの、という内容です。悪用された管理機能を通じて、利用者のパスワードが取得されたことは確認されていない、とも書かれています。

多要素認証は、パスワードに加えて、スマホのアプリやSMSの確認コードなど、もうひとつ別の確認を求める仕組みです。パスキーは、パスワードの代わりに、スマホやパソコンに保存された専用の鍵情報と、指紋や顔などの本人確認を組み合わせてログインする新しい方式で、偽のサイトにだまされて入力してしまう被害に強いとされています。岩井コスモ証券は2025年9月から、ログイン時の多要素認証を必須にしていたと報じられています。

つまり、利用者が使う玄関はしっかり固められていました。それでも被害が出たのは、運営側が使う「管理機能」という別の扉に不備があったからです。

管理機能がどのようなもので、どんな設定の不備があったのか、そこからどうやって売買の注文につながったのかは、公表されていません。手口が知られると同じ被害が広がるおそれがあるため、詳しく書かないのは理解できる判断です。

トレードワークスは、事象が分かった当日のうちに、悪用された管理機能の利用停止、不正に確立された接続の無効化と攻撃元からの通信の遮断、攻撃者の特性に応じた対策の強化を行ったとしています。あわせて、同社のシステムを使っているほかの金融機関も点検し、同様の事象は確認されていないと説明しています。損失と対応費用は同社が全額を負担する方針で、加入しているサイバー保険の適用を見込んでいます。

第2報で明らかになった不正取引

10月20日の第2報で、売買管理システムへの攻撃と不正な注文が初めて公表されました。不正アクセスのあった10月14日に、7口座で顧客の意図しない売買の注文が出され、そのうち5口座で約定（注文が成立すること）しました。対象の顧客には14日に個別に連絡し、取引を発注前の状態に戻す措置は完了していて、顧客の負担は生じていない、としています。

第1報で不正取引に触れなかった理由について、同社は、16日の時点では同様の被害を防ぐための対策を段階的に進めている最中で、手口につながる情報の公表を控えていた、対策を講じて確認を終えたため第2報で報告した、と説明しています。漏えいの人数が増えたのは、委託先と調査を続ける中でアクセス記録に加えて通信記録も精査し、14日の不正アクセスの際にすでに生じていた漏えいを新たに把握したためで、新たな侵入や漏えいが起きたわけではない、とも書かれています。

同社は、不正取引は漏えいした個人情報を使ったものではないと説明しています。漏えいしたのは氏名、メールアドレスなどで、取引に使う暗証番号は含まれていません。漏えいした情報だけでは、証券口座へのログインや取引はできないとしています。

10月21日の報告と、残る疑問

10月21日の報告では、悪意ある第三者がシステムの脆弱性を突いて総当たり攻撃を仕掛けた、と説明されています。攻撃を遮断するまでの間に5件の不正な約定が起き、4,975人分の顧客情報が攻撃者から閲覧できる状態だったが、取引に必要なパスワードなどの重要な情報はマスキング（伏せ字にすること）されていて見られなかった、としています。

今回の不正取引はパスキー認証が突破されたものではないとしたうえで、利用者にはパスキーの設定を強く勧めています。金融庁が毎月公表している不正取引の発生状況では、昨年5月以降に同種の事案はなかった、という説明もあります。

この件から読み取れることを、開発者の目線で2つ挙げておきます。

1. 利用者の認証を強くすることと、運営側の機能を守ることは別の仕事だ、ということです。どれだけ利用者のログインを固めても、管理用の機能に別の入口があれば、そこが狙われます。
2. 総当たり攻撃への備えです。ログインだけでなく、管理機能やAPIのあらゆる入口で、回数の制限や失敗が続いたときの遮断、異常の検知が必要になります。

トレードワークスが再発防止策として、管理機能へのアクセス制限の強化、不正な通信の遮断、ログインの異常を即時に検知する仕組み、定時点検を含む監視体制の強化を挙げているのは、この両方に対応するものです。

岩井コスモ証券の口座を持っている人は、心当たりのないメールに注意し、ブックマークや公式アプリから自分でログインして、注文の履歴や残高に覚えのない取引がないかを確かめておくと安心です。パスキーと多要素認証がまだの方は、同社の案内に沿って設定しておくことをおすすめします。

同じ時期の国内の事案を、当事者の発表で整理する

岩井コスモ証券のほかにも、9月下旬から10月にかけて、国内で大きな事案がいくつも公表されました。ここでは、当事者の発表や、発表を詳しく伝えた報道で確かめられた範囲で、代表的なものを並べます。繰り返しになりますが、これらの事案がJPCERT/CCの注意喚起のどのケースに当たるのかは公表されておらず、同じ攻撃者によるものかどうかも分かっていません。

焼肉きんぐ：ほぼ全会員の連絡先

焼肉チェーン「焼肉きんぐ」を運営する物語コーポレーションは、10月2日に公式アプリの会員管理システムへの不正アクセスを確認し、通信の遮断などの措置を取りました。翌3日に会員情報の漏えいを確認し、5日に公表しています。

漏えいしたのは1,078万8,963件で、アプリの登録数1,080万8,784件のほぼすべてにあたります。項目は会員番号、氏名（アプリの登録名）、メールアドレス、電話番号の4つで、ログイン用のパスワード、生年月日、性別、郵便番号、ポイントを含む店の利用履歴は漏れておらず、クレジットカードなどの決済情報はそもそも持っていない、と説明されています。

登録者の「ほぼ全員」が対象になったことは、攻撃者が会員のデータを一件ずつではなく、まとめて取得できる経路を見つけたことをうかがわせます。マクニカの解説が「管理者向けの一括取得機能が大量の情報取得に利用された可能性」に触れているのは、この種の事案を念頭に置いたものと考えられます。ただし、焼肉きんぐの件で実際に何が使われたのかは公表されていません。

infoQ：ポイントが現金同様に使われた

GMOリサーチ&AIが運営するアンケートサイト「infoQ」では、10月2日以降に第三者がサーバーに不正にアクセスし、会員の個人情報を外部に持ち出しました。報道によると、10月3日の午前に会員からの問い合わせを受けて調べたところ不正アクセスが見つかり、同日中に攻撃の経路を遮断してサービスを止めています。

10月14日の第2報で、持ち出しが確認された件数は89万4,082件と確定しました。これは記録の件数で、重複を除いた人数ではありません。

この件で特徴的なのは、ポイントの不正交換です。

• 本人の意思によらずに、611件、計286万9,500円分のポイントがAmazonギフトコードに交換されていました。
• 同社は全額を補填する方針です。
• 同社は10月7日に全会員のパスワードを無効にしました。

サイバーセキュリティクラウドの報告で、攻撃者が「ポイント制度のあるサイトでは他の利用者のポイントを窃取できないか探索していた」とあったのを思い出してください。情報を盗むだけでなく、お金に換えられる機能も狙われています。

なお、同社の公式の発表本文は、自分では直接確かめられておらず、ここでは報道に基づいて書いています。

大阪公立大学：委託先の再委託先から

大阪公立大学では、10月2日の未明にサーバーが次々と止まり、全キャンパスの授業が休講になりました。大学は10月5日の会見で、ランサムウェアによる攻撃と判断していると説明し、約500台のサーバーが止まり、バックアップの多くも暗号化されて使えない状態になったとしています。対面授業は10月9日に再開しました。

10月21日の第5報によると、大学の基盤システムの保守・運用を任されていたNECの、さらにその先の「再委託先」が9月下旬にサイバー攻撃を受け、攻撃者は再委託先が持っていた正規のアカウントを使って大学のシステムに入ったとされています。

NECが使っていたクラウドストレージにあった大学関連の個人情報やシステムの情報の漏えいも確認されましたが、その内容と件数はNECに確認中です。会見で発表された教務システム関連の約13万件は、これとは別に、大学の仮想化基盤の中の情報で、漏えいの有無を調べているところです。

この件はランサムウェアなので、JPCERT/CCの注意喚起が扱う型とは性格が違います。ただ、「委託先や再委託先が持つ正規のアカウントが入口になった」という点では、委託先のシステムの管理機能が悪用された岩井コスモ証券の件と共通しています。

自分たちのシステムを守るには、自分たちの設定だけでなく、保守を任せている会社のアカウントの管理まで目を配る必要があります。IPAが「国内外の拠点、ビジネスパートナー、委託先などを含むサプライチェーン全体」への目配りを経営者に求めているのは、このためです。

このほか、piyologには、10月だけでもskyticket、産婦人科向けシステム「アットリンク」、防災情報配信サービス「SpeeCAN RAIDEN」、Studio、ソースネクスト、お名前.comデスクトップクラウドなど、多数の国内の不正アクセスのまとめが並んでいます。ここではすべてを扱えませんが、業種を問わず被害が出ていることが分かります。

開発者・Web担当者が自社サービスで確かめること

最後に、Webサービスやスマホアプリを作っている人、会社のWebサイトを担当している人が、自分のサービスで確かめておきたいことを具体的に書きます。JPCERT/CCの注意喚起の対策、IPAの「速やかに実施すべき対策等」、マクニカ、サイバーセキュリティクラウド、NICTの推奨を、作る側の作業に置き換えたものです。

1. APIの認可を、サーバー側で毎回確かめているか

認証（ログインしているのは誰か）と認可（その人がこの操作をしてよいか）は別のものです。今回の事案で繰り返し出てくるのは、ログインはしているけれど、他人のデータや管理用の機能に手が届いてしまう、という認可の不備です。

NICTはこれを「IDOR/BOLA」と呼んでいます。BOLA（Broken Object Level Authorization）は、たとえばGET /api/users/1001/profileの数字を1002に変えるだけで他人の情報が見えてしまうような不備のことです。

確かめ方は難しくありません。

1. テスト用のアカウントを2つ作り、Aのアカウントのトークンを使って、Bのアカウントのデータを指すAPIを呼んでみます。
2. たとえばcurl -H "Authorization: Bearer (Aのトークン)" https://example.com/api/users/(BのID)のように送り、Bの情報が返ってきたら問題です。
3. 管理者だけが使えるはずのAPI（利用者の権限の変更、アカウントの作成、一覧の取得など）を、一般の利用者のトークンで呼べないかも確かめます。

画面にボタンがない機能こそ、念入りに試してください。もちろん、試すのは自分たちのサービスか、許可を得たテスト環境だけにします。

あわせて、APIが必要以上の情報を返していないかを見直します。画面には名前しか出していないのに、APIの応答には電話番号やメールアドレス、内部のIDまで入っている、ということはよくあります。

マクニカは「必要以上の情報を返すAPI」と「ゲストアクセスで不要なデータを返していないか」を確認項目に挙げています。応答を絞っておけば、仮に認可の不備があっても漏れる量を減らせます。

2. 入力をそのままデータベースの検索条件にしていないか

SQLを使うデータベースなら、プレースホルダー（値を後から安全に差し込む書き方）を使っているかを確かめます。文字列をつなげてSQLを組み立てている箇所があれば、優先して直します。

MongoDBなどのNoSQLを使っている場合は、送られてきたJSONをそのまま検索条件に渡していないかを見ます。Node.jsとExpressで書かれたAPIなら、User.findOne({ email: req.body.email, password: req.body.password })のような書き方が危険な例です。req.body.passwordに文字列ではなく{"$ne": null}のようなオブジェクトが入ってくると、条件の意味が変わってしまいます。

受け取った値が文字列であることを型で確かめる、$で始まるキーを取り除く、スキーマ（データの形の定義）で入力を検証する、といった対策を入れておきます。Mongooseを使っているなら、検索条件の中の想定外の演算子を取り除くsanitizeFilterという設定もあります。

自分のAPIが応答の違いを見せすぎていないかも確かめます。「このメールアドレスは登録されていません」と「パスワードが違います」を言い分けると、登録されているメールアドレスを調べる手がかりになります。ブラインド探索は、こうした小さな違いを積み重ねる攻撃です。

3. 回数の制限と、異常の検知を入れているか

JPCERT/CCは、単位時間あたりのリクエスト数を制限すること、そしてログイン、パスワードのリセット、SMSの送信、検索など、悪用されやすい機能には個別に制限を設けることを求めています。総当たり攻撃も、NoSQLインジェクションのブラインド探索も、何度も試すことが前提なので、回数の制限はどちらにも効きます。

ただし、サイバーセキュリティクラウドの報告にあったように、攻撃者が数百のIPアドレスを使い分けると、IPアドレスごとの制限だけでは足りません。アカウントごと、トークンごと、機能ごとの制限も組み合わせ、失敗が続いたときには一時的に止める、といった仕組みを考えておきます。監視では、IPアドレスごとの件数だけでなく、400番台や500番台のエラーが普段より増えていないか、認証のAPIで成功や失敗のときと応答の大きさが違うものがないか、を見ると手がかりになります。

4. 管理画面や管理用のAPIが、外から見えていないか

岩井コスモ証券の件で悪用されたのは「管理機能」でした。Metabaseのような社内向けの道具、Tomcatの管理画面、WSUSのような社内用のサーバーも、インターネットから届く場所に置かれると攻撃の対象になります。JPCERT/CCは「業務上不要な機能（管理機能など）がインターネットに公開されていれば、公開を停止する」ことを汎用的な対策に挙げています。

確かめ方としては、自社のドメインで動いているサーバーを一覧にし、社外のネットワーク（たとえばスマホのテザリング）から、/admin、/manager/html、/api/adminのような管理用のパスや、Metabaseの画面に届かないかを見てみます。届いてしまう場合は、VPNの内側に移す、アクセス元のIPアドレスを絞る、多要素認証を付ける、のいずれかを検討します。

管理者アカウントのパスワードが初期設定や弱いままになっていないかも、あわせて見直します。脆弱性診断を頼んでいる場合は、その範囲に管理機能など一般に公開しない機能が含まれているかを確かめておくよう、マクニカは勧めています。

5. 設定ファイルとバックアップを、公開の場所に置いていないか

ケースAとケースEのどちらにも、設定ファイルやバックアップファイルの窃取が含まれていました。自分のサイトについて、curl -I https://example.com/.envやcurl -I https://example.com/backup.zipのように、よくあるファイル名を外から取りに行ってみて、200の応答が返ってこないかを確かめます。Gitの管理フォルダ/.git/が公開されていると、ソースコードと過去の設定がまるごと読まれることがあるので、これも確認しておきます。

サーバーの中では、公開フォルダ（ドキュメントルート）の下に、.bak、.old、.sql、.zip、.tar.gzのようなファイルが残っていないかを探します。Linuxならfind /var/www -type f \( -name "*.bak" -o -name "*.sql" -o -name "*.zip" -o -name ".env" \)のようにして一覧にできます。バックアップは公開フォルダの外か、別のストレージに置き、Webサーバーの設定で.envやドットで始まるファイルを返さないようにしておきます。

6. アプリに秘密の値を入れていないか、トークンに期限はあるか

スマホアプリやブラウザで動くJavaScriptに、管理用のAPIキーや、何でもできる強い権限のトークンを埋め込んでいないかを確かめます。アプリの中にある値は、解析すれば取り出せる前提で考えます。アプリに入れてよいのは、外に出ても困らない、権限を絞った値だけです。

JPCERT/CCは、利用者やトークンには必要最小限の権限だけを与え、トークンには適切な有効期限を設けて長く使えるものを避け、不要になったものや漏えいが疑われるものをすぐに無効にできるようにしておくよう求めています。「漏れたと分かったときに、どの画面で、誰が、何分で止められるか」を一度手順にしておくと、いざというときに慌てずに済みます。マクニカは、サービスを終えるときにサーバーを止めるだけでなく、APIキーも破棄するよう付け加えています。

7. ログを1〜3か月さかのぼって見ておく

IPAは、直近1か月のログから見始め、3か月へと広げるよう勧めています。注意喚起に載っているIPアドレスやUser-Agentと、自分のサーバーのアクセスログを照らし合わせるのも一つの方法です。たとえばgrep -F -f suspicious_ips.txt access.logのように、注意喚起のIPアドレスを書いたファイルを用意して検索できます。

ただし、各機関が繰り返し注意しているとおり、一致したからといって被害が確定するわけではありません。一致した通信の前後に、大量のエラーや、普段と違う大きさの応答がないかをあわせて見ます。

異常が見つかったら、ログを保全し、専門の会社に詳しい調査を頼むことをIPAは強く勧めています。自分たちだけで判断に迷う場合は、IPAが10月16日に開設した「不正アクセス特別相談窓口」や、JPCERT/CCのインシデント対応の相談窓口も使えます。

8. 持っているデータを減らす

JPCERT/CCとIPAの両方が、保存期間や利用目的を過ぎたデータを残さないことを挙げています。焼肉きんぐの件で生年月日や利用履歴が漏れなかったように、漏れた項目と漏れなかった項目の差は、被害の大きさを大きく変えます。

そもそも持っていないデータは、漏れようがありません。備考欄に書き込まれた想定外の個人情報のように、知らないうちにたまっているデータもあるので、一度棚卸しをしておくと安心です。

9. 委託先が持っている管理機能と、そのアカウントを把握する

岩井コスモ証券の件のように、自社のサービスでも、運用や開発を外部の会社に任せている部分には、自社の担当者が普段見ていない管理機能やアカウントがあることがあります。委託先が作った保守用の画面、検証のために一時的に作ったアカウント、契約が終わったあとも残っている接続の設定などです。こうしたものは、自社の脆弱性診断や棚卸しの範囲から外れやすく、気づかないまま外から届く状態になっていることがあります。

確かめることは、次の3つです。

• 委託先に、自社のサービスに対してどんな管理機能を持っているか、どこから接続しているか、どのアカウントを使っているかを一覧で出してもらう。
• その一覧のうち、いま使っていないものは止める。使っているものは、接続元のIPアドレスを絞り、多要素認証を付ける。
• 管理機能でできる操作のうち、送金や注文、個人情報の一括出力のように影響の大きいものは、操作の記録を自社でも見られるようにし、普段と違う時間帯や量の操作に気づける仕組みを用意する。

契約書や仕様書に書いてあるかどうかよりも、実際に何が動いているかを見ることが大切です。委託先との打ち合わせのたびに一覧を更新する習慣をつけておくと、担当者が替わっても把握が途切れません。

APIの守りを体系的に学ぶなら

今回の一連の事案で問題になった、APIの認可の不備、NoSQLインジェクション、回数制限の不備などを、攻撃する側の視点から順番に学べる本として、オライリー・ジャパンの『ハッキングAPI ―Web APIを攻撃から守るためのテスト技法』（Corey Ball 著、石川朝久 訳、2023年）を紹介します。出版社の紹介によると、次のような特徴があります。

• Web APIの基本から始めて、脆弱性があるかどうかをテストする方法を、攻撃者（APIハッカー）の視点で解説しています。情報セキュリティのエンジニアだけでなく、Webアプリケーションの開発チームも読者として想定されています。
• BOLA（他人のデータに手が届く不備）やBFLA（権限のない機能が使える不備）の見つけ方、マスアサインメント、レート制限のテストといった、この記事で取り上げた不備を章を立てて扱っています。
• インジェクション攻撃の章では、SQLインジェクションに加えてNoSQLインジェクションも扱っており、ケースBの手口を理解する助けになります。
• DockerでcrAPIやOWASP Juice Shopなどのわざと弱く作られたアプリを用意し、手元の検証環境で実際に試しながら学べる構成になっています。

ハッキングAPI ―Web APIを攻撃から守るためのテスト技法をAmazonで見る

本に書かれている手法は、自分のサービスか、許可を得たテスト環境でだけ試すようにしてください。他人のサービスに無断で試すと、それ自体が不正アクセスになります。

まとめ

JPCERT/CCの注意喚起は、9月前後から国内で相次ぐ不正アクセスを、既知の脆弱性の探索（A）、API経由の不正操作（B）、MetabaseのSQLインジェクション（C）、Webシェルの設置（D）、AIペネトレーションテスト基盤の悪用（E）の5つの型に整理しました。5つは同じ犯人の手口の一覧ではなく、どの被害事案がどの型に当たるのかも公表されていません。

それでも、並べてみると、狙われているのは最新の未知の欠陥よりも、画面にない内部API、外に出ている管理機能、置きっぱなしの設定ファイルやバックアップといった、基本的な作りと管理の不備だということが見えてきます。

岩井コスモ証券の件は、利用者のログインを多要素認証やパスキーで固めていても、委託先のシステムの管理機能に不備があれば、情報の漏えいだけでなく不正な取引まで起きうることを示しました。大阪公立大学の件も、再委託先の正規のアカウントが入口でした。自分たちの入口だけでなく、運営や保守のための裏口まで含めて守る必要があります。

AIについては、攻撃者がAIを使っていたことをJPCERT/CCが確認し、具体的な道具の名前も挙がりました。一方で、AIが新しい種類の攻撃を生み出したというより、基礎的な点検を大量に休みなく行っている、と見るのが現時点の情報に合っています。だからこそ、次の基本の対策が、そのまま効きます。

• APIの認可をサーバー側で確かめる
• 入力を検証する
• 回数を制限する
• 管理機能を外に出さない
• データを持ちすぎない

まずは自分のサービスの管理画面と.envが外から見えていないかを確かめるところから始めてみてください。

出典

• JPCERT/CC「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」（JPCERT-AT-2026-0030）
• JPCERT/CC Eyes「連続不正アクセス事案の攻撃手法に関する調査」（2026年10月15日）
• JPCERT/CC「MetabaseのSQLインジェクションの脆弱性（CVE-2026-72898）に関する注意喚起」
• NICT CYNEX「【注意喚起】相次ぐ情報漏洩、その原因の一つは「アプリ解析からのサーバ攻撃」」
• IPA「不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について」
• マクニカ セキュリティ研究センター「相次ぐWEBシステムからの情報漏洩事案について」
• サイバーセキュリティクラウド「国内で相次ぐ不正アクセス、AIエージェントによる攻撃の可能性」
• 岩井コスモ証券「外部委託先への不正アクセスに伴うお客様情報の漏洩について(第2報)」（2026年10月20日）
• 岩井コスモ証券「不正アクセスによる個人情報漏洩および不正取引に関するご報告」（2026年10月21日）
• トレードワークス「当社が提供するシステムへの不正アクセスに関するお知らせ」（2026年10月16日）
• INTERNET Watch「岩井コスモ証券」に関する記事（2026年10月21日）
• piyolog「不正取引も行われた岩井コスモ証券への不正アクセスについてまとめてみた」
• piyolog「国内で相次ぐ不正アクセスに対する注意喚起についてまとめてみた」
• piyolog「AIペネトレーションテストツール「ARTEX」についてまとめてみた」
• 大阪公立大学「本学情報基盤システムにおける障害の発生について【第5報】」
• piyolog「委託先経由で不正アクセスされた大阪公立大学のシステム障害についてまとめてみた」
• ASCII「焼肉きんぐに不正アクセス、1078万人分の情報流出」
• ScanNetSecurity「GMOリサーチ&AI 運営のアンケートサイト「infoQ」に不正アクセス、89万4,082件の個人情報外部持ち出しを確認」
• ＠IT「持っていた個人情報が「全件」流出対象 infoQでポイント286万円分も不正交換」
• BleepingComputer「CyberStrikeAI tool adopted by hackers for AI-powered attacks」
• オライリー・ジャパン『ハッキングAPI ―Web APIを攻撃から守るためのテスト技法』書誌情報

※この記事の内容は、2026年10月24日時点で公表されている情報をもとにしています。