大和証券の問い合わせ情報約22万件。
その後、シチズン時計、損保ジャパンからも、同じ外部サービスをめぐる情報漏えいの可能性が相次いで公表された。
そしてサービスを提供するスカラコミュニケーションズ自身から、詳しい説明が出た。
そこで、先日書いた記事の「答え合わせ」が少しできた。
私は一つ、素直に読み違えていた。
しかし、それ以上に気になったのは、今回の攻撃が従来のランサムウェアとはかなり違うことだった。
OSのrootやAdministratorまで取らなくても、アプリの権限だけで十分な場合がある。
アプリの権限を取れば、そのアプリが持っているデータへ届く。
そして今、そのアプリ側にも「本丸」に近いデータが大量に置かれている。
今回の事案は、その変化をかなり分かりやすく見せている。
大和証券の事案を調べたとき、外形上は同じIPアドレス帯に複数企業向けのホストが見えていた。
それ自体は最初から分かっていた。
しかし、最初に公表したのは大和証券だった。
そのため私は、
大和証券向けの認証や環境だけが侵害され、そこで被害が止まったのではないか
と読んだ。
これは間違っていた。
スカラコミュニケーションズの続報では、同一サーバー上で稼働していた最大5社のシステム環境が対象となり、問い合わせ情報は延べ最大713,126件に上る可能性があることが明らかになった。
件数は問い合わせ単位で、同一人物による複数回の問い合わせも重複して含まれる。
つまり、大和だけに閉じた事象ではなかった。
ここは素直に読み違えた。
現在、公表している企業は少なくとも大和証券、シチズン時計、損保ジャパンだ。
大和証券では約11万人。
個人を特定できない問い合わせ等まで含めると約22万件。
シチズン時計では約10万人分。
対象はシチズン、ブローバ、フレデリック・コンスタントのブランドサイトから寄せられた問い合わせ情報で、氏名、住所、電話番号、メールアドレスなどが含まれる。
問い合わせ本文に銀行口座やクレジットカード情報を書いていた場合には、それらも対象となる可能性がある。
損保ジャパンでは、事業者向けドライブレコーダーサービス「SMILING ROAD」の問い合わせ延べ約6万件。
氏名や連絡先だけではない。
勤務先、ドライバーID、アラートの種類や発生日時、ドライブレコーダーのシリアル番号、申込番号、問い合わせ件名・本文なども対象となっている。
業種も、問い合わせ内容も全く違う。
共通していたのは、問い合わせ業務を同じ外部サービスに預けていたことだった。
一方、スカラは「最大5社」としている。
現在名前が出ているのは3社。
残る企業が今後公表するのか、個人情報の有無や影響調査によって公表内容が変わるのかは、まだ分からない。
ここは続報を待ちたい。
今回最も重要なのは、スカラが説明した攻撃の順番だ。
10月2日20時30分ごろから翌3日8時ごろにかけて、第三者によるi-ask管理サイトへの不正ログインが発生した。
その後、サーバーに不正なプログラムが設置され、同一サーバー上の複数企業のシステム環境のデータベースから、問い合わせ情報を取得された可能性が確認された。
ここで、前の記事で考えた順番と違うことが分かった。
私は、
公開Web
→ ファイル処理の脆弱性
→ ローカルファイル
→ 認証情報
→ DB
という経路を疑っていた。
しかし、ベンダーが最初に確認した事象は、
不正ログイン
だった。
その後に、
不正プログラム設置
→ DBアクセス
と続いている。
少なくとも観測された順番では、ログインが先だ。
ただし、ここは重要なので分けておきたい。
「不正ログイン」とは、
攻撃者が事前に正しいIDとパスワードを盗んでいた
ことまで意味しない。
パスワード漏えいかもしれない。
セッション窃取かもしれない。
Credential Stuffingかもしれない。
認証機能の脆弱性かもしれない。
別の場所で認証情報を取得したのかもしれない。
最初の認証がどう成立したのかは、まだ分からない。
では、前の記事で注目したファイルアクセスは関係なかったのか。
そうでもない。
スカラが実施した対策には、不正プログラムの隔離に加え、
アップロードされたファイルをプログラムとして実行できないようにする設定変更
が含まれている。
ここは非常に興味深い。
前回は、
ファイル機能の脆弱性から認証情報を取ったのではないか
と考えた。
今回見えてきたのは、むしろ逆だ。
何らかの方法で管理サイトへ不正ログイン
→ ファイルを置く
→ その実行環境から、より広いデータへ進む
という可能性だ。
つまり、ファイル機能は「最初の鍵を取る入口」ではなく、ログイン後に権限を広げる手段だった可能性が高い。
ここが今回かなり重要だと思う。
「権限を広げる」と聞くと、rootやAdministratorを取得するOSレベルの権限昇格を想像しやすい。
ランサムウェアなら典型的だ。
侵入する。
OS権限を上げる。
EDRを止める。
社内を横展開する。
バックアップを破壊する。
最後に暗号化する。
しかし、今回公表された被害を起こすために、そこまで必要だったとは限らない。
管理サイトへ入る。
不正なプログラムを設置する。
その実行環境から、同一サーバー上の複数企業のDBへ進む。
ここで重要なのは、
OS全体を支配したかどうかより、アプリケーション側からどこまで権限を広げられたのか
だ。
今回の攻撃は、
OSの権限昇格というより、アプリケーション権限の拡張と越境
として見る方が分かりやすい。
rootにならなくても、十分なデータに届く場合がある。
アプリになれればいい。
もちろん、OSを狙う攻撃がなくなったわけではない。
ランサムウェアも、OS権限昇格も、ネットワーク横展開も今後も続くだろう。
ただ、攻撃者から見れば、もっと簡単な道がある。
業務アプリは仕事をするために、最初から価値のある場所への権限を持っている。
問い合わせ管理なら顧客DB。
BIなら分析対象となる業務DB。
CRMなら営業・顧客情報。
採用システムなら履歴書や面接記録。
アンケートなら会員情報。
つまり、
OSを支配してからデータを探す必要がない。
業務アプリを取れば、そのアプリが既にデータの場所を知っている。
接続方法も知っている。
場合によっては資格情報まで持っている。
攻撃者から見れば、
OSのrootを取るより、アプリになりすます方が簡単で、静かで、見返りも大きい。
今回のi-ask侵害は、その攻撃像を考えさせる。
そして、もう一つ大きく変わったことがある。
重要なデータが置かれる場所だ。
昔なら、企業の最も重要なデータはSoR、System of Recordにあると考えるのが普通だった。
顧客マスタ。
契約。
取引履歴。
会計。
勘定。
企業にとっての「本丸」である。
攻撃者も、その本丸へ到達することを狙う。
しかし今は、SoE、System of EngagementやBIなど、SoRの外側にも大量の重要データが流れている。
問い合わせ。
CRM。
採用管理。
アンケート。
チャット。
サポート。
そしてBIなどの分析システム。
顧客や社員と接するために、本丸から必要なデータを持ってくる。
さらに利用者自身が自由文で情報を書き込む。
すると、SoRの外側にも本丸に近い価値を持つ情報が蓄積する。
大和証券は今回の変化を非常に分かりやすく示している。
侵害されたのは、証券取引システムではない。
問い合わせ管理システムだ。
それなのに、
口座番号まである。
なぜか。
問い合わせ対応をするために必要だからだ。
SoRにある情報の一部が、業務上必要な範囲で外側のシステムにも渡っている。
さらに問い合わせ本文には、
何について困っているのか。
何を相談したのか。
どんな手続きについて聞いているのか。
という、SoRにはない文脈まで入る。
場合によっては、SoEの方がその人を理解しやすい。
攻撃者から見れば、本丸を直接攻める必要がない。
本丸に近いデータが、もっと外側のシステムにも既にある。
ここが今回、一番重要な点だと思う。
企業側は、
「本丸の基幹システムは守れている」
と考える。
確かに今回、大和証券の証券取引基盤そのものが侵害されたわけではない。
シチズンの生産システムでもない。
損保ジャパンの保険契約基幹でもない。
しかし、攻撃者から見れば、
そこまで行く必要がない。
SoE側やその周辺に、
氏名。
住所。
電話番号。
メール。
口座番号。
勤務先。
機器番号。
行動情報。
問い合わせ内容。
がある。
十分だ。
しかもSoEは、SoRより外部に近い。
Webに公開される。
管理画面がある。
APIがある。
ファイルを扱う。
外部サービスとして委託される。
今回なら複数企業が同じサービス基盤を利用していた。
つまり、
SoRに近い価値を持つデータが、より外側のシステムにも広がっている。
しかし、そのシステムの接面は外部に近いままだ。
このギャップが大きくなっている。
前の記事では、最近の問い合わせ系の不正アクセスをまとめて、
問い合わせにはファイルアップロード機能があり、そこからローカルファイルや認証情報へ進みやすいのではないか
と考えた。
今回、その順番は外れた可能性が高い。
しかし、「問い合わせ」に注目したこと自体は無駄ではなかった。
理由が違った。
問い合わせシステムは、
公開Webがある。
管理画面がある。
ファイルを扱う。
顧客情報を保存する。
DBに接続する。
自由文を保存する。
そして外部委託されることも多い。
つまり、一つのアプリの中に攻撃面と価値のあるデータが近接している。
認証を破られた後に使える機能が非常に多い。
今回のi-askでは、不正ログイン後に不正プログラムが置かれ、さらに同一サーバー上の複数企業DBまで届いた可能性がある。
問い合わせだから狙われた、とは言えない。
しかし、
問い合わせシステムは、取られた後の見返りが思った以上に大きい。
これは今回かなりはっきりした。
スカラは被害拡大防止として、
パスワード変更。
攻撃元IPの遮断。
不正プログラムの隔離。
全環境の管理者パスワード変更。
アップロードされたファイルをプログラムとして実行できないようにする設定変更。
などを実施した。
さらに今後のセキュリティ体制再構築として、
管理者認証の強化。
多要素認証の導入。
環境間の分離。
監視体制の強化。
第三者による定期的な脆弱性診断。
などを挙げている。
ここも重要だ。
MFAと環境分離は、事件後に予定された対策である。
今回の侵害を考えると、
最初の認証境界
と、
認証後の企業環境間の境界
の両方が問題になったことが分かる。
最初の鍵をどう取られたかだけを調べても足りない。
その鍵で入ったあと、どこまで行ける設計だったのか。
そこまで見なければならない。
今回の事案を見て、攻撃のパターンが少し変わってきていると感じる。
もちろん、OSを狙う攻撃はこれからもある。
しかし、
OSまで行かなくても目的を達成できる攻撃
が成立する。
アプリの認証を取る。
アプリの中で権限を広げる。
アプリが持つDBアクセスを使う。
データを取る。
会社を止めなくてもいい。
暗号化しなくてもいい。
rootにならなくてもいい場合がある。
そして、SoRまで行かなくてもいい。
SoEやその周辺に、十分価値のあるデータがある。
攻撃者にとっては、その方が簡単で、静かで、見返りも大きいことがある。
今回のi-ask侵害で一番考えさせられたのは、そこだった。
企業が守るべき「本丸」の定義そのものが、変わってきているのかもしれない。
攻撃者は本丸を狙わなくなったのではない。
本丸に近いデータが、外側へ出てきた。
そして、その外側のアプリを取るだけで十分になってきた。
今回、本当に見るべきなのは、最初の鍵だけではない。
その鍵でどこまで行けるのか。
そして、
そこにどれだけ本丸に近いデータを置いているのか。
その二つだと思う。
Aikido Community Japan
公開日: 2026/10/7
最終更新: 2026/10/7
セキュリティの最新情報をお届けします。