Roblox のチート、OAuth の許可、そして $2M の Vercel 情報漏えい
今週公表された Vercel の侵害は、Context.ai の従業員が私物 PC に Roblox のエクスプロイトをダウンロードしたことに始まり、攻撃者が Vercel の顧客の環境変数を読み取るに至りました。今週出荷した Bromure Enterprise は、まさにこの連鎖のために作られています。
ある従業員が私物のノート PC で Roblox のチートを検索する。2 か月後、 攻撃者は BreachForums で Vercel の顧客データベースを 200 万ドルで 売りに出す。この 2 つの出来事の間にあるのは、ごく普通の判断の連鎖 ——私物の端末、OAuth の「すべて許可」クリック、support@ アカウントを 持つサードパーティの AI ツール——であり、今週、すべての企業 IT チームが 見つめるべきものです。昨日出荷した Bromure Enterprise は、 その連鎖の中盤のために作られました。
4 月 20 日、Vercel は「高度に洗練された」攻撃者が Context.ai という サードパーティの AI ツールを介して社内システムに侵入し、一部の顧客 プロジェクトに属する機微でない環境変数にアクセスしたことを 公表しました。 CEO の Guillermo Rauch 氏は攻撃者を「AI によって大幅に加速された」と 表現し、 機微でないとマークされていた認証情報はすべてローテーションするよう 顧客に求めました。ShinyHunters を名乗るグループは現在、盗み出した データを BreachForums で $2M で販売しようとしています。
身代金の額が見出しです。しかし学ぶべきは攻撃の連鎖のほうです。 Hudson Rock は感染を 2026 年 2 月まで遡り、Context.ai の従業員が Roblox の 「オートファーム」スクリプトとゲームエクスプロイト実行ツールを検索して ダウンロードし、Lumma Stealer——ブラウザーの Cookie、保存された認証情報、 OAuth トークンを収集するコモディティ型のインフォスティーラー——を 拾ったことを突き止めました。その後の展開は CyberScoop と SpecterOps が再構築しています。Lumma が抜き出したのは Context.ai のパスワード だけではありません。ブラウザーにキャッシュされた社内認証情報一式 ——Google Workspace のセッション、Supabase のキー、Datadog のログイン、 Authkit のトークン——でした。
そこから攻撃者は Context.ai の AWS 環境にピボットし、Context.ai が その顧客 のために保持していた OAuth トークンを読み取り、社用の Google アカウントで Context.ai の「AI Office Suite」にかつて登録し、 「すべて許可」スコープ ボックスをクリックした Vercel の従業員を 見つけました。数か月前に行われたそのたった 1 回の同意が、攻撃者が 必要とした唯一のプリミティブでした。彼らはその従業員としてセッションを 発行し、Vercel の Google Workspace に入り、そこから Vercel の社内 プロダクト API へ進み、顧客が機微として明示的にマークしていなかった すべての環境変数を列挙・復号しました。
この連鎖のうち 4 点は特筆に値します。なぜなら、それぞれが 今週 Bromure Enterprise で出荷した特定の制御に対応する からです。リリースがこの侵害を完全に阻止できたと主張するつもりは ありません——できませんでした。できたのは、連鎖を 4 つの別々の点で 断ち切ることで、そのいずれか 1 つでも十分なのです。
私物のノート PC が要だった
公表された報告の中で最も過小評価されている詳細は、感染した端末が 私物だったことです。Context.ai の従業員は Roblox のエクスプロイトを 探していました——典型的な業務タスクではありません——そして感染は 業務と私用の両方の閲覧に使われていたと思われる端末に着地しました。 Lumma Stealer は Cookie がどのプロファイルに属するかなど気にしません。 見つけたすべての Chrome と Edge の認証情報ファイルを読み、まとめて 送信します。
これは BYOD 時代の中心的なパターンです。ホストは非管理。業務用の Cookie は、ユーザーがたった今ダウンロードした Roblox のチートと 同じ Cookie ジャーに入っています。EDR エージェントはインストール されているかもしれないし、いないかもしれない。私物の端末では、 入っている可能性は非常に低い。そしてたとえ入っていても、 Lumma は市販の AV を日常的に回避していると観察されています。
Bromure Enterprise の答えは、非管理ホスト上の管理対象 VM です。 IT 部門は Bromure の業務プロファイルを発行します。従業員は私物の ノート PC に Bromure をインストールし、社内の IdP(Google Workspace、 Okta、Entra、Authentik)でサインインすると、業務プロファイルは それ自身の Linux 仮想マシンとして起動します。この VM には独自の カーネル、独自のファイルシステム、独自の Chromium プロファイル ディレクトリがあります。社内の Cookie、社内の保存パスワード、 社内の OAuth リフレッシュ トークンはすべてこの VM の中に存在します。 ホストの macOS や Windows 上で動く stealer——Roblox のダウンロード 経由でも他の経路でも収集されるもの——はそれらを列挙することも、 読み取ることも、持ち出すこともできません。共有された Chrome プロファイルがディスク上に存在しないので、盗みようがないのです。 Cookie ジャーは、ホスト OS が不透明なディスク ファイルとして扱う VM イメージの中にあります。
これは理論的な分離ではありません。アーキテクチャの根幹です。 ホストは一日中乗っ取られても構いません。業務ブラウザーは別の コンピューターの中にあるのです。
「すべて許可」のクリックこそが真のトロフィーだった
攻撃者の経路をよく見てください。Stealer は Google Workspace、 Supabase、Datadog、Authkit の認証情報を収集しました。これらは Context.ai 内部でピボットするのに有用でした。しかし Vercel に 届いたのは盗まれたパスワードではなく——OAuth トークンでした。 具体的には、Vercel の従業員が Context.ai の AI Office Suite に 登録し、Google の同意画面をクリックして進み、「すべて許可」スコープ バンドルを承認したときに発行されたトークンです。その同意は数か月前の ものでした。再評価はされませんでした。そこに有効なまま、待ち続けて いたのです。
これが SpecterOps が指摘した OAuth の可視性のギャップです——個々の従業員が同意画面をクリックして 作成した信頼エッジは、IT のプロビジョニング ワークフローの完全に 外で動作します。誰かが探そうと思う前から、経路は開いていたのです。
Bromure Enterprise は、この表面を同時に 2 つの方向から狭めます。
許可 SaaS タイル一覧は、入り口での絞り込みポイントです。 管理者は 承認された業務アプリの集合を、登録された各ユーザーの Work ホーム ページに公開します。従業員は、そのタイルをクリックして新しいツールに オンボードします。Vercel では Context.ai はその一覧に入っていません でした——入りようがなかったのです。個々の従業員の実験でしたから。 タイルがなければ、管理された業務プロファイル内にワンクリック登録の フローは存在しません。もちろん従業員は手動で Context.ai に移動する ことはできます。そこで 2 つ目の制御が効いてくるのです。
業務プロファイルは SSO で管理され、その同意画面は可視です。 管理された Bromure の業務プロファイルから開始された OAuth 同意は、 社内の IdP を介し、管理者ポリシーの下で行われます。どのサードパーティ アプリが Google Workspace スコープを受け取れるかを管理者が制限したい 場合——これはすべての Google Workspace 管理者が行うべきで、実際には ほとんど誰も行っていないことですが——その強制ポイントは Bromure の ポリシー エンジン内にあり、各従業員が数週間前にたまたまクリックした もののあちこちに散らばってはいません。「すべて許可」のチェック ボックスは、 18 か月後のインシデント対応で突然浮上してくる驚きではなくなります。
これは、従業員が Bromure に移行する前に発行された OAuth 付与を 遡って取り消すものではありません。しかし今後、「従業員が聞いた こともない SaaS アプリに広範な Google スコープを付与した」という カテゴリーは、可視化され、ゲート可能になります。
事後には、監査ログだけが被害範囲を絞り込む唯一の手段
Vercel の公開された告知は、調査で判明したことに正直です——攻撃者が 一部の顧客プロジェクトの環境変数を列挙・復号した。範囲は現在も 精緻化中です。その理由は、「3 月下旬から 4 月中旬にかけて、その 従業員アカウントは実際に何を 読んだ のか?」を Google Workspace の 監査ログと Vercel の社内プロダクト ログから再構築するのが、クエリでは なく法科学的な再構築プロジェクトだからです。
これこそ Bromure Enterprise のリクエスト単位の監査ログが閉じる ために設計されたギャップです。登録されたすべての端末で、すべての 業務セッションから送信されたすべての HTTP リクエスト——ユーザー、 URL、動詞、タイムスタンプ——が中央にログされます。「昨日の 8 時から 8 時 15 分の間に evil.com に認証情報を送信したのは誰か」は、 ローンチ時に使った例です。今週のより良い例——「Vercel プロダクト API の各環境変数エンドポイントに、過去 90 日間で、誰が、どこから、 いつアクセスしたか」。プロジェクトではなくクエリです。
これが EDR と Web 監査ログが交わる部分です。EDR はネイティブ プロセスに対して同じ質問に答えます——このプロセスは何に触れたのか? Bromure はブラウジングに対してそれに答えます——このユーザーの ブラウザーは何に触れたのか? Vercel のようなインシデント——攻撃者の 足跡が侵害されたブラウザー セッション内に完全に収まっているもの ——では、EDR の答えは空で、Bromure の答えはインシデントのタイム ラインそのものになります。
データ漏えい制御はここでは限定的——それは正直に言うべきです
Bromure Enterprise が役立つ場所と役立たない場所については慎重で
ありたい。コピー & ペースト、ファイル ダウンロード、スクリーン
ショット、ローカル ネットワーク制御は本物で、データ漏えい全般に
対する本物の成果です——管理されたプロファイル内の侵害されたタブは、
顧客の env vars をホスト上の scp にドラッグすることも、スクリーン
グラブすることも、LAN のピアにアップロードすることもできません。
しかし Vercel の連鎖に関して言えば、漏えいのステップは完全に
Vercel 自身のバックエンドから攻撃者が管理するエンドポイントへの
通信越しに起きました。攻撃者は認証済みの API 呼び出しを行って
いたのであり、ブラウザー ウィンドウからファイルをドラッグして
いたわけではありません。ペースト / ダウンロード / LAN の制御では
捉えられなかったでしょう。
役に立ったであろう のは、上述のリクエスト単位の監査ログに並ぶ API 呼び出し自体の記録です。データ漏えい制御は 2 番目の防衛線です。 1 番目の防衛線は、そもそも攻撃が管理されたブラウザーでセッションを 発行するところまで到達しないようにすることです。
Bromure Enterprise にできないこと
この話が正直に値する、3 つの限界です。
非管理の私物ホスト上のマルウェアは止められません。 Bromure の VM の外でダウンロードされた Roblox のチートは、依然としてユーザーの 個人 OS にインフォスティーラー マルウェアをインストールする Roblox の チートです。Bromure はそれを片付けません。できるのは、攻撃者にとって マルウェアの収穫がユーザーの個人の Cookie だけにとどまるようにする ことです——社内のものではなく。
OAuth スコープを遡って取り消すことはできません。 Bromure Enterprise を 展開する数か月前に発行された同意は、弊社ではなく Google Workspace の 付与一覧にあります。Bromure を展開した後の正しい運用上の次の一手は、 依然として既存のサードパーティ アプリ付与の監査です——次の付与を防ぐ 手助けはしますが、過去のものを書き直すことはしません。
スコープを決める規律の代わりにはなりません。 Vercel の従業員は 「すべて許可」をクリックしました。将来の従業員が許可済みタイル上で 「すべて許可」をクリックしたとしても、付与は依然として広範です。 Bromure は表面を可視化し、登録経路を狭めます。しかし、特定のカテゴリーの アプリに対してどの Google スコープを許可し、許可しないかを決める 管理者の代わりにはなりません。
ブラウザー第一の主張は「どんな攻撃も起きない」ではありません。 ユーザーのブラウザー セッションを経由する攻撃のカテゴリー全体に 対して、最も効果的な制御ポイントはブラウザー自身であり——そして ブラウザーは、非管理端末において適切な管理機構をこれまで一度も 持たなかった唯一のエンタープライズ ソフトウェアなのです。
解決策のかたち
SaaS の OAuth 付与を経由するサプライ チェーン侵害は、10 年前の VPN 認証情報スタッフィング攻撃の現代版です。どちらも、作成は安価、 棚卸しは困難、そして相手側が乗っ取られたときに即座に取り消すのは 不可能な信頼エッジの帰結です。Vercel の告知は慎重で正直です。 そこに記された連鎖は Vercel のせいではありません。これは、同じ 私物のノート PC 上の同じブラウザーが、従業員の社内セッション、 Roblox のダウンロード履歴、そして先四半期に彼らが試したあらゆる AI ツールに対して積み上がった「すべて許可」同意を同時に保持する ときに起こることなのです。
構造的な答えは、業務セッションに自分専用のコンピューターを与える ことです。2 台目のノート PC ではなく——同じノート PC の上に実体化した、 独自のカーネル、独自のファイルシステム、独自の Cookie ジャー、 独自のポリシー エンジン、中央ログへの独自の監査タップを備えた、 2 つ目の マシン です。それが Bromure Enterprise です。従業員が日常的にサードパーティの SaaS アプリに OAuth スコープを 付与している企業——つまりすべての企業——で IT を運営しているなら、 今週の Vercel の告知は、検討リストに入れるべき理由です。
一次情報