CodeNote.net

Vercel 侵害は Roblox チート検索から始まった — 個人と会社で考える Lumma Stealer 対策

#security
重岡 正 ·  Fri, April 24, 2026

2026 年 4 月 20 日に Vercel が公表した侵害は、攻撃の発端を辿ると一人の社員が個人 PC でやった「Roblox のチート検索」に行き着く、というかなり生々しいインシデントでした。技術的に高度なゼロデイ攻撃ではなく、情報窃取マルウェア（インフォスティーラー）の Lumma Stealer と、サードパーティ SaaS 連携の過剰な権限が組み合わさって起きた、現代的な SaaS サプライチェーン侵害の典型例です。

公開情報は HackRead の解説記事 と CyberScoop の報道 でまとまっています。本記事では事実関係をおさらいしたうえで、個人として業務 PC で気をつけること、会社として組織的に打てる対策案を整理しておきます。

インシデントの全体像 — 個人の検索から SaaS サプライチェーン侵害へ

時系列を整理すると、以下のような流れになります。

  1. 2026 年 2 月: Context.ai の社員が Roblox のチート（exploit）を検索し、悪意あるスクリプト経由で Lumma Stealer に感染
  2. 同時期以降: Lumma Stealer がブラウザの認証情報、セッショントークン、OAuth トークンを収集し、攻撃者が Context.ai の AWS 環境と OAuth トークンを入手
  3. その後: 攻撃者は、Vercel 社員が Context.ai に対して付与していた Google Workspace の「Office Suite フルアクセス」OAuth トークンを悪用し、その社員の Google Workspace アカウントを乗っ取り
  4. 2026 年 4 月 19 日: 攻撃者を名乗る人物が BreachForums 上で「Vercel のデータを 200 万ドルで売る」と投稿（実在の ShinyHunters は関与を否定）
  5. 2026 年 4 月 20 日: Vercel が侵害を公表し、Mandiant と CrowdStrike に対応を依頼

注目すべきは、攻撃の起点が「Vercel への直接攻撃」ではなく、Context.ai 社員の個人的な検索行動だったことです。Roblox のチートを探していて踏んだスクリプトが、最終的には Vercel の環境変数や内部ログを露出させたわけです。

被害範囲について Vercel は、社員情報、内部ログ、「機微フラグが付いていない一部の環境変数」へのアクセスを認めています。同社 CEO の Guillermo Rauch のコメントでは、攻撃者は Vercel の内部構造をかなり理解した上で行動していたとされています。一方で攻撃者を名乗るアカウントはソースコードやデータベースへの侵入も主張していますが、Vercel はそれを確認していません。

flowchart LR
    A[Context.ai 社員<br/>Roblox チート検索] --> B[Lumma Stealer 感染]
    B --> C[ブラウザ認証情報<br/>OAuth トークン窃取]
    C --> D[Context.ai AWS<br/>環境侵入]
    C --> E[Vercel 社員の<br/>Google Workspace 乗っ取り]
    E --> F[Vercel 内部システム<br/>環境変数、ログ流出]

この構図のポイントは 2 つです。第 1 に、個人の何気ない検索行動が、勤務先だけでなく取引先まで巻き込んで侵害される時代になった ということ。第 2 に、SaaS 連携で安易に渡した「フルアクセス」OAuth トークンが、最終的にラテラルムーブメントの踏み台になった ということです。

以降、この 2 つに対応する形で、個人としての対策、会社としての対策を整理します。

個人として気をつけること

ここでいう「個人」は、業務利用するエンドポイント、すなわち会社支給 PC や BYOD で業務にアクセスする端末を扱う一人ひとりを指します。

業務に使う端末で「グレーな検索とダウンロード」を完全に分ける

今回のインシデントの本質的な教訓は、「個人的に怪しいダウンロードをするときは、業務に使う端末で絶対にやらない」 という線引きの徹底です。

Roblox のチートに限らず、以下のようなキーワードでの検索 → ダウンロードは、Lumma Stealer 系のインフォスティーラー配布ルートとして昔から定番です。

  • ゲームのチート、MOD、トレーナー
  • 商用ソフトウェアのクラック、ライセンスキー生成ツール
  • 「無料の◯◯」「◯◯ Premium 無料化」系のツール
  • 海賊版動画、楽曲のダウンロードリンク
  • YouTube などからのダウンロードを謳う出所不明な変換ツール
  • 「インストール手順」と称する PowerShell や bash のワンライナー

Hudson Rock や Malwarebytes が報告している通り、Lumma Stealer や RedLine Stealer などのインフォスティーラーは、SEO ポイズニングや偽 GitHub リポジトリ、Discord 配布、YouTube 動画の概要欄など、多様なルートで配られています。「公式っぽいリンク」「人気動画のコメント欄に貼られている URL」も安全とは限りません。

ここでの行動原則はシンプルです。

  • 上記のようなグレーな調達は、業務端末ではなく完全に分離した私用環境（別 PC、別アカウント）で行う
  • できればその私用環境でも、認証情報を一切保存しないクリーンなプロファイル、もしくは仮想マシン上で実行する
  • 業務端末では、社内で承認されていないソフトウェアを「とりあえずインストールしてみる」をやらない

「業務端末ではやらない」の徹底は、本人だけでは完結しません。家族や同居人が同じ端末を触る前提があるなら、その時点で業務端末との分離は崩れます。子供のゲーム用 PC を借りて業務に使う、業務 PC を子供に貸す、といった運用は、今回のインシデントのリスク再現性が非常に高い構造です。

ブラウザに保存した認証情報とセッションを過信しない

Lumma Stealer のようなインフォスティーラーが盗むのは、パスワードだけではありません。

  • ブラウザ（Chrome、Edge、Firefox）に保存された ID / パスワード
  • ブラウザの Cookie、セッショントークン
  • OAuth リフレッシュトークン
  • パスワードマネージャーが解錠状態のときのボルト
  • ローカルに保存された SSH 鍵、AWS のアクセスキー、.env ファイルなど

ここで効くのが、「ブラウザの組み込みパスワード保存機能を業務用途で使わない」 という割り切りです。代わりに 1Password、Bitwarden などの専用パスワードマネージャーで集中管理し、ブラウザにはオートフィルだけを許可するか、コピー＆ペースト運用にする。マスタパスワード + Passkey または FIDO2 の組み合わせでボルトを保護することで、感染端末からボルトをそのまま吸い出されるリスクを下げられます。

セッションについては、感染すると「現在ログイン中のセッショントークン」がそのまま盗まれます。これは MFA を通った後の状態なので、攻撃者は MFA を再度突破する必要すらありません。長期間ログインしっぱなしになっている SaaS（特に Google Workspace、Slack、Notion、開発系プラットフォーム）は、定期的に強制ログアウト → 再認証を回す運用を組織として組み込むべきです。

Passkey、ハードウェアセキュリティキーへの移行

フィッシング耐性のある認証手段への移行は、個人の手の届く範囲で最も効く対策です。

  • 個人アカウント（Google、Apple ID、GitHub、X など）に Passkey を設定
  • 業務アカウントでも Passkey に対応している SaaS は順次移行
  • 重要度の高いアカウントには YubiKey などのハードウェアセキュリティキーを併用

Passkey はサイト識別子に紐づくため、偽サイトに誘導されてもそもそも認証できないという仕組み上の強さがあります。SMS や TOTP の MFA は依然としてフィッシングで突破される事例が多く、Passkey 移行の優先度はかなり高めに置いていいと考えています。

自分のサードパーティ連携を棚卸しする

業務で使っている Google Workspace、Microsoft 365、GitHub などには、過去に許可したサードパーティアプリの OAuth 連携が積み上がっています。

「もう使っていないが連携だけ残っている」アプリは、今回の Vercel のケースのように、ベンダー側が侵害されたときの侵入経路になります。少なくとも半年に 1 度は棚卸ししたいところです。

会社としてできる対策案

ここからは、組織として打てる対策を整理します。今回のインシデントは、Context.ai に「Office Suite フルアクセス」を許可していたという OAuth 権限設計が決定的に効いています。組織側でできることは、まさにこの「許可の設計」と「異常の検知」「ベンダーの管理」に集約されます。

サードパーティ SaaS 連携の権限を最小化する

最も効果が大きいのが、サードパーティ SaaS 連携への OAuth 権限の絞り込みです。今回の Vercel の事例では、Vercel 社員が Context.ai に対して Google Workspace の「Office Suite フルアクセス」を許可していたとされています。これは、Gmail、Drive、Calendar すべてを攻撃者が掌握できる権限です。

組織として打てる対策は以下です。

  • OAuth スコープの管理者承認制を有効化する: Google Workspace のアプリアクセス管理 で「機密」スコープを管理者承認制にし、エンドユーザーが勝手にフルアクセスを許可できない設定にする
  • 連携先を許可リスト方式にする: 必要なベンダーだけをホワイトリスト化し、業務上不要なアプリは Workspace 全体で連携不可にする
  • 必要最小スコープを明文化する: 「Office Suite フルアクセス」のような広いスコープは原則禁止、必要な API に絞ったスコープのみ許可
  • OAuth 連携の棚卸しを定期化: 半年〜1 年に 1 度、全社の OAuth 連携を棚卸しし、利用実態のない連携を取り消す

OAuth トークン、サービスアカウントを「秘密情報」として扱う

サードパーティ SaaS が発行する OAuth トークンや、CI / CD で使うサービスアカウント鍵は、しばしば「便利な接続情報」として扱われがちですが、実態は API キーや SSH 鍵と同じ秘密情報です。

  • トークンの保管場所を統一する: HashiCorp Vault、AWS Secrets Manager、Google Secret Manager などに集約
  • ローテーションを自動化する: 短命トークン + 自動更新を基本にし、永久に有効なトークンを禁止する
  • 送信元 IP / デバイスを制限する: 可能な API は、社内 IP やマネージドデバイスからの呼び出しに限定する
  • 検知ルールを敷く: 通常と違う IP、地域、ユーザーエージェントからの OAuth トークン利用は SIEM でアラート

特に「短命トークン + 自動更新」は、感染端末から OAuth リフレッシュトークンが盗まれたときの被害期間を強制的に短くするうえで効果が大きいです。今回の Vercel の事例では、2 月の感染から 4 月の公表まで攻撃者は内部で動き続けていたわけで、ここを短くできるかどうかは大きな分かれ目になります。

エンドポイントを「最後の砦」と思わず、複層で守る

EDR や MDM の導入は、規模問わずほぼ必須と考えていいフェーズに入っています。Lumma Stealer は商用 IDS / IPS のシグネチャをすり抜けるバージョンが継続的に出ており、シグネチャベースのアンチウイルスだけでは検知しきれません。

組織として最低限揃えたい構成は次のあたりです。

業務端末で「Roblox のチート配布サイト」へのアクセスが DNS レイヤで止まる、というのは今回のケースでは決定的に効きます。エンドポイントだけに頼らず、ネットワーク層でも防げる仕組みを重ねるのが現代的なアプローチです。

個人利用を業務端末から物理的に切り離す

技術的な制御に加えて、運用ルールとして「業務端末で個人利用をしない」線引きをハッキリさせるのも重要です。

  • 業務端末では業務利用のみと明文化する: 個人 SNS、個人ゲーム、家族との共用は禁止
  • 私用端末向けの代替を用意する: 家族と共用しない個人 PC、もしくはモバイル端末を別途用意できるよう、必要に応じて手当や購入補助を出す
  • VDI / リモートデスクトップ環境の選択肢: 高リスクな業務（金融、医療、行政データ取り扱い）では、ローカルにデータを残さない VDI や 仮想ブラウザ を検討

「業務端末では業務だけ」をルールとして書くのは簡単ですが、それを現実的に守れる物理的代替がない限り、現場では破られます。手当や購入補助とセットで設計する必要があります。

フィッシング耐性のある MFA を組織標準にする

組織標準の MFA を、SMS や TOTP からフィッシング耐性のあるものに移行することは、Lumma Stealer 系の侵害が広がる時代において優先度の高い投資です。

  • Passkey、FIDO2 を標準化: Google Workspace、Microsoft 365、GitHub、Slack など主要 SaaS で Passkey を有効化
  • 管理者アカウントにはハードウェアキー必須: 特権アカウントは YubiKey や Google Titan セキュリティキー などのハードウェアキー必須に
  • デバイス証明書ベースの認証: Chrome Enterprise Premium のようなゼロトラストアーキテクチャで、「マネージドデバイスからのみアクセス可能」というポリシーを敷く

セッショントークンが盗まれた場合の対策として、短いセッション寿命 + デバイス Posture チェック を組み合わせるのも有効です。たとえば「マネージドデバイスかつ EDR が稼働している状態」を条件にしたアクセス制御は、感染端末からの再ログインを構造的に難しくします。

ベンダーリスク管理とインシデント通知契約

最後に、自分たちが攻撃を受ける側ではなく、サードパーティ侵害の影響を受ける側に回るケースへの備えも必要です。

  • ベンダー評価プロセス: 業務システムに接続する SaaS ベンダーに対し、セキュリティ評価（SOC 2、ISO 27001 など）を必須化
  • インシデント通知契約: 契約書に「重大なセキュリティインシデントは X 時間以内に通知する義務」を明記
  • ベンダー OAuth 連携の継続監視: 連携先ベンダーから定期的に侵害発生状況を確認、または公開侵害情報を Have I Been Pwned などでモニタリング
  • 緊急時のトークン取り消し手順を準備: ベンダーが侵害された際に、全社の OAuth トークンを即時失効できる手順を整備、訓練

ここで重要なのは、「自社が一切ミスをしなくても、信頼して接続している取引先が侵害されたら、自分たちも同じ事象に巻き込まれる」という前提を経営層と共有することです。今回の Vercel のケースはまさにそれで、Vercel 自身に脆弱性があったわけではなく、信頼して OAuth 連携していた Context.ai の社員の個人 PC が起点でした。

まとめ — 「個人の検索ひとつ」がサプライチェーンを揺らす時代

今回の Vercel / Context.ai インシデントを整理すると、教訓は以下に集約されます。

  • 個人の何気ない検索とダウンロードが、勤務先と取引先まで連鎖的に巻き込む時代になった
  • インフォスティーラーは MFA を突破する必要すらない（セッショントークンごと持っていかれる）
  • SaaS 連携で渡した「フルアクセス」OAuth は、長期的にラテラルムーブメントの踏み台になる
  • エンドポイントだけでは守りきれず、ネットワーク、認証、SaaS 権限、ベンダー管理を複層で組む必要がある

個人の側では、業務端末でグレーな検索とダウンロードをしないという最低ラインを引いた上で、ブラウザ任せの認証情報管理から脱却し、Passkey とハードウェアキーへの移行を進める。組織の側では、サードパーティ SaaS 連携の OAuth スコープを最小化し、エンドポイント、ネットワーク、認証の複層防御を組み、ベンダー侵害を前提とした OAuth トークン失効の運用を整える。

「個人の検索ひとつでサプライチェーンが揺れる」という前提を、個人、組織、経営層それぞれで共有しておくことが、今回のインシデントから引き出せる一番大きな学びだと考えています。

以上、SaaS サプライチェーンセキュリティの設計を組み立てている、現場からお送りしました。