当社のAIエンジンNeutronが、UCバークレーのCyberGymベンチマークで97.1%のスコアを記録しました。 詳細を見る

すべての号

The Breach Brief 最新号

レシピを変えたのは誰か？

CursorのマーケットプレイスでClaude Code拡張機能の改ざん版が配信され、その数時間後にはPolymarketでベンダーのスクリプトが乗っ取られました。マーケットプレイスがパブリッシャー名以外に何を検証すべきか、そしてPolymarketのドレイナーのコードレベルの解説を収録しています。

Ostorlab Research 12分で読めます

CursorのマーケットプレイスでClaude Code拡張機能の改ざん版が配信され、その数時間後にはPolymarketでベンダーのスクリプトが乗っ取られました。

10月29日、まったく異なる二つの場所で、数時間のうちに相次いで二つの問題が起きました。

朝、Cursorの拡張機能マーケットプレイスがClaude Code拡張機能の改ざん版を配信し始めました。そのほぼすべてのバイトはAnthropicの本物のコードで、そこにSSHバックドアを仕込む小さなローダーが加えられていました。

同じ日の午後、PolymarketがベンダーのDebugBearから読み込んでいたパフォーマンス監視スクリプトが差し替えられました。そのスクリプトはページ速度を計測する代わりに、ログイン中のトレーダーのセッションを使ってポジションを売却し、資金を移動させました。アナリストは約257万ドルが攻撃者のウォレットに流れたことを突き止めています。

誰も怪しいものはインストールしていません。開発者は使い慣れた拡張機能のアップデートを受け入れただけです。トレーダーはいつも使っているサイトを開いただけです。ラベルは正しかったのです。変わっていたのはレシピでした。

そこで今号では、こう問いかけます。配信される中身を他人が変えられるとき、「信頼できる提供元」とは何を意味するのでしょうか。ディープダイブでは、マーケットプレイスがパブリッシャー名以外に何を確認すべきかを考え、技術研究では、Polymarketのドレイナーがページ自身のトレーディングクライアントをどのように再利用したかを解説します。

この号の内容

  • 🌡️ 脅威レベル：厳重警戒

  • ⚡ ニュース：FBIがBinanceの盗難を北朝鮮によるものと断定、LiteLLMとOVHcloud CLIのリリースが差し替え、Storm-0940がバックアップベンダー経由でMicrosoft 365テナントを標的に

  • 🔎 ディープダイブ：パブリッシャーは正規だった。アップデートは改ざんされていた。

  • 🎣 これはフィッシング？

  • 🔬 技術研究：ページ速度を計測していたスクリプトが、ポジションを売り払った

  • 🛠️ 今週のツール：osquery

  • 👏 今週の人物：Paul McCarty

  • 📅 今週のイベント：Open Source SecurityCon 2026

  • 📚 今週の本：『Software Supply Chain Security』

  • 😅 今週のミーム

  • ❓ 最後にひとつ質問

では、始めましょう。

🌡️脅威レベル

Article content

⚡セクション01：ニュース

暗号資産、過去最大級

FBI、63億ドルのBinance盗難を北朝鮮によるものと断定

Binanceは、暗号資産の盗難として記録上最大となる約63億ドルの盗難を認めました。ブロックチェーン分析企業のTRM LabsとChainalysisは、これを北朝鮮のグループTraderTraitorによるものとしました。10月31日にはFBIもこれを確認し、2025年に15億ドルのBybitハッキングを行ったのと同じアクターだと名指ししました。

当初の報道では、侵害されたノートPC一台が原因とされていました。その後Binanceは、調査で別の侵害箇所も見つかったと発表しており、侵入経路はまだ明らかになっていません。Binanceは盗まれた資金の約90%を自社資金で補填したとしており、Tetherは盗難に関連する約15.7億ドル相当の資産を凍結したと発表しています。

FBIによると、盗まれた資産の大半はイーサ（ether）に変換されつつあり、残りはDeFiプラットフォームやインスタントスワップサービスを経由して移動すると見られています。

なぜ重要か：これまでの記録であるBybitの事件は、二年足らず前に同じグループが起こしたものです。今回の盗難はその約四倍の規模です。TraderTraitorは一度だけ運よく成功した便乗型の集団ではありません。最も多くの資金を保有する企業に侵入し続ける国家の部隊です。

止められたものと止められなかったものを見てください。Tetherが15.7億ドルを凍結できたのは、Tetherが自ら発行するトークンを凍結できるからです。イーサには連絡すべき発行者がいません。攻撃者が盗んだトークンを誰にも凍結できない資産に変換するのに時間を費やすほど、回収できる額は減っていきます。だからこそ、変換はすでに始まっているのです。

侵入経路についての説明が変わってきたことも重要です。「侵害されたノートPC一台」はわかりやすい説明でしたが、誤りだったか、少なくとも不完全でした。大規模な侵害の初期の説明は、しばしばそうなります。全経路が判明するまでは、どの制御が機能しなかったのか誰にも言えません。

暗号資産やフィンテックの分野、またはその周辺で働いているなら、TraderTraitorの既知の手口を直接の脅威として扱ってください。偽のリクルーター、持ち帰り型のコーディングテスト、エンジニアを狙った悪意のあるパッケージです。署名インフラはエンジニアが日常的に使うノートPCから切り離し、ステーブルコインの発行者との連絡窓口は、凍結が必要になってからではなく、その前に整えておきましょう。

盗難を止めることが第一の防御線です。トークンがイーサに変わった時点で、第二の防御線が使える時間は終わります。

Article content

FBIによる特定（BleepingComputer） · TRM LabsとChainalysisによる特定 · Binanceの調査に関する続報（ITPro）

リリース、温め直し

LiteLLMとOVHcloud CLIのリリースがシークレット窃取ツールに差し替え

10月21日、攻撃者がGitHub CLIのOAuthトークンを入手した後、LiteLLMバージョン1.107.0の悪意あるビルドが、侵害されたコンテナイメージとともにPyPIに公開されました。LiteLLMは、アプリケーションとAIモデルプロバイダーの間をつなぐゲートウェイとして広く使われています。PyPIでの露出期間は約二時間でした。Microsoftの分析によると、ペイロードはPythonの起動フックを通じて実行されたため、パッケージをインストールしただけのマシンでも、一度もインポートすることなくシークレットが漏えいする可能性がありました。

その二日前の10月19日、攻撃者は乗っ取ったコントリビューターアカウントを使い、GitHub上のOVHcloud CLIの五つのリリース（v0.11.0からv0.15.0）のダウンロードファイルを、最大94分間にわたってシークレットを窃取するビルドに差し替えました。攻撃者はOVHcloudのビルドパイプラインには一切触れていません。リリースのイミュータビリティ（不変性）が無効になっていたため、ファイルを単純に差し替えることができたのです。OVHcloudはファイルを削除し、クリーンなv0.16.0をイミュータブルリリースとして公開し、この設定を有効にしました。

なぜ重要か：どちらのケースでも、攻撃は最後のステップ、つまり人々がダウンロードするリリースで起きました。OVHcloudの攻撃者はビルドパイプラインにまったく触れておらず、LiteLLMのビルドは盗まれたトークンで公開されました。ソースコードのレビューやCIの保護では、どちらも防げなかったでしょう。

短い時間枠は、思うほど安心材料にはなりません。二時間や94分は人間にとっては短い時間ですが、最新バージョンを取得するCIパイプラインは絶えず動いています。しかもLiteLLMの場合は、インストールするだけで十分でした。1.107.0を取得したすべてのビルドランナーとノートPCが、保持していたシークレットを渡してしまいました。AIゲートウェイが管理するために存在するAPIキーも含めてです。

OVHcloudのケースは、攻撃者がどれほど長く待つかも示しています。Paul McCartyが突き止めたように（詳しくは今号の「今週の人物」で）、リリースの差し替えに使われたアカウントは七か月前から侵害されていました。盗まれた開発者の認証情報は、まだ誰も使っていないからといって失効するわけではありません。

依存関係はバージョンだけでなくハッシュで固定し、可能な場合はリリースされたばかりのバージョンの採用を数日待ちましょう。プロジェクトをメンテナンスしているなら、イミュータブルリリースを有効にし、有効期間の短い公開用トークンを使ってください。いずれかのツールを該当期間中にインストールした場合は、クリーンなマシンから、そのマシンがアクセスできたすべてのシークレットをローテーションしてください。

クリーンなリポジトリが教えてくれるのは、メンテナーが何を書いたかです。自分が何をダウンロードしたかまでは教えてくれません。

LiteLLMの侵害（SecurityWeek） · OVHcloud CLIの侵害（SecurityWeek） · GlassWormとの関連（Dark Reading）

Article content

バックアップ、アクセス添え

Storm-0940、バックアップベンダーのアプリのアクセス権を使い2,250のMicrosoft 365テナントを標的に

ConnectWiseは10月16日、同社のCloud Backupサービス（旧SkyKick）の侵害を公表しました。10月21日、Microsoftはその後の活動を、中国系のグループStorm-0940によるものとしました。

Cloud Backupは、ITサービスプロバイダーが顧客のMicrosoft 365データをバックアップするためのサービスで、そのアプリはすでにそれらのテナントで同意を得ていました。攻撃者はこれらのアプリのIDを使い、2,250を超えるテナントへのサインインを試みました。Microsoftによると、大半の試みは失敗しましたが、このグループは複数の組織で特権を伴う永続的なアクセスを獲得しており、中には最初に標的にしてから三時間足らずで獲得したケースもありました。中国はこの主張を否定しています。

なぜ重要か：フィッシングされたユーザーはおらず、スキップされたMFAプロンプトもありませんでした。どちらも関与していなかったからです。アプリは独自のシークレットや証明書でサインインしますが、多くのテナントではサインインポリシーやアラートが人間を前提に設計されています。アプリのサインインは、そのどちらの対象からも外れていることがよくあります。

狙いはアクセスそのものでした。バックアップアプリはテナント全体のメール、ファイル、サイトを読み取る必要があり、それはまさに攻撃者が求めるアクセスです。管理者が一度だけ付与した一つの同意が、すべてをカバーしてしまうこともあります。

「大半の試みは失敗した」も、あまり慰めにはなりません。サービスプロバイダーモデルでは一つのベンダーが何千ものテナントに接続するため、成功率が低くても積み重なります。しかも、最初の試みから永続化まで三時間足らずでは、対応する時間はほとんどありません。

永続化こそ、修正後も残る部分です。攻撃者が特権アクセスを握った時点で、独自の認証情報、アプリ、ロール割り当てを追加できました。ベンダーのアプリを削除しても、それらは何一つ削除されません。

自社のテナントでどのサードパーティアプリが同意を得ていて、どのような権限を持っているかを確認してください。アプリのサインインログを確認し、10月中旬以降に追加された認証情報、アプリ、ロール割り当てを探してください。サービスプロバイダーがテナントを管理しているなら、Cloud Backupを使っていたかどうかを直接尋ねてください。

ベンダーのアクセスを取り消すのは簡単なステップです。本当に問うべきは、そのアクセスがあった間に何が追加されたかです。

Microsoftによる特定（Dark Reading）

Article content

🔎セクション02：ディープダイブ

パブリッシャーは正規だった。アップデートは改ざんされていた。

10月29日にCursorのマーケットプレイスからClaude Code拡張機能をインストールした開発者は、推奨されているとおりのことをしていました。エディターに組み込まれたストアを使い、よく知られたパブリッシャーの拡張機能を選び、アップデートを受け入れたのです。約11時間にわたり、それだけでSSHバックドアを仕込まれてしまう状態でした。

パブリッシャーは本物でした。ストアも本物でした。変わったのはその間にあるパッケージで、改ざんされたパッケージは、配布の仕組みに制御があったにもかかわらずユーザーに届きました。

Article content

何が起きたか

Cursorによると、悪意のある攻撃者が「Cursorのマーケットプレイスへのアクセスを利用し、Cursorのユーザーを狙った改ざん済みの拡張機能を公開した」とのことです。改ざんされたビルド（Windows版とmacOS版のバージョン2.1.312と2.1.313）は、太平洋時間の午前2時27分頃から午後1時35分まで公開されており、最大5,000人のユーザーに届きました。Cursorはこれらを削除し、拡張機能マーケットプレイス全体を一時停止したうえで、アクセスを監査し、鍵をローテーションしました。

Anthropicは、公式チャネルのバージョンは影響を受けていないこと、2.1.313はOpen VSX、Microsoft Visual Studio Marketplace、その他の公式ホストのいずれにも公開されたことがないこと、そして今回のインシデントは「Anthropicのシステムや従業員のノートPCが侵害されたものではない」ことを明らかにしました。同社はクリーンな2.1.314をリリースしています。攻撃者がどのように公開権限を得たのかについては、どちらの企業も明らかにしていません。

改ざんされたビルドの挙動

StepSecurityの分析によると、攻撃者はAnthropicのクリーンな2.1.312ビルドを取得し、その拡張機能のextension.jsの先頭に7,386バイトのローダーを付け加えました。ファイルの残りの部分はオリジナルと一致していました。ローダーは難読化されておらず、拡張機能が読み込まれるとすぐにプレーンなNode.js上で実行され、Claudeとの会話は一切必要ありませんでした。

ローダーは六つの段階で、ホストの詳細情報と、KEY、TOKEN、AWSといったパターンに一致する環境変数の名前を収集し、svc-telemetryというラベルのSSH鍵を~/.ssh/authorized_keysに追加し、SSHを有効にし、134.209.82.225へのリバーストンネルを開き、永続化を設定し（macOSではcom.apple.sysmondという名前のLaunchAgent、WindowsではSysMonというスケジュールタスク）、攻撃者のサーバーにステータスを報告しました。

拡張機能を削除しても、これらは何一つ削除されません。

Article content

マーケットプレイスがパブリッシャー名以外に検証すべきこと

リスティングからわかるのは、元のコードを誰が書いたかです。この特定のパッケージを誰がビルドし、アップロードしたかまではわかりません。Cursorのケースは、名前だけでは代わりにならない三つのチェックを示しています。そのうち二つはバージョン番号を確認するだけのもので、偽の2.1.313を検出できたはずです。中身を確認するのは三つ目だけであり、本物のバージョン番号を持つ改ざん済みの2.1.312まで検出できたのもこのチェックです。

1. このバージョンは提供元に存在するか？バージョン2.1.313は、Anthropicの公式チャネルのどこからもリリースされていませんでした。他者の拡張機能のコピーを配信するストアは、パブリッシャーが一度もリリースしていないバージョンを拒否できます。これで2.1.313は検出できますが、実在するバージョンである2.1.312の改ざん版は検出できません。

2. パッケージの内容に矛盾はないか？「2.1.313」のバンドルは、内部では依然としてversion:”2.1.312”と報告していました。より大きい番号を持っていたのは再パッケージ化されたマニフェストだけで、エディターにアップデートとして扱わせるにはそれで十分でした。マニフェストと内部のコードの不一致は低コストで検出でき、再パッケージ化の強い兆候です。ただし、これも攻撃者がバージョンを上げた場合にしか役立ちません。

3. これはパブリッシャーの実際のアーティファクトか？これが両方のバージョンをカバーするチェックです。改ざんされた2.1.312とAnthropicの本物の2.1.312との違いは、一つのファイルの先頭にある一つのブロックだけで、そのブロックがsshを起動し、authorized_keysに書き込み、スタートアップ項目を作成していました。各パッケージのハッシュをパブリッシャー自身のリリースと比較し、アップデートを前のバージョンと差分比較して新たなプロセス実行、ネットワークトンネル、永続化がないかを確認すれば、パッケージの名前ではなく、パッケージの実体を見ることができます。

Article content

この三つ目のチェックを最も確実に行う方法はパブリッシャーの署名ですが、それは署名がパブリッシャー自身によるものである場合に限ります。ストアがパッケージを自ら再署名したり再ホストしたりする場合、有効な署名が証明するのは、そのストアが配信したということだけです。

競い合う二つのタイムライン

攻撃者に必要だったのは数分でした。自動アップデートがローダーを届け、読み込み時に実行されたのです。防御側は該当バージョンを取り下げるのに約11時間を要し、影響を受けた開発者はそれぞれ、今も永続化の除去、クリーンなマシンからのすべての認証情報のローテーション、再構築するかどうかの判断を行わなければなりません。自動アップデートのおかげで大半の開発者はパッチが適用された状態を保てているので、無効にすることは答えではありません。答えは、それが何をインストールするかを確認することです。

四つの優先事項

  • セキュリティチーム向け：開発者がどのエディターを使っていて、それぞれがどのマーケットプレイスから拡張機能を取得しているかを把握してください。本番環境へのアクセス権を持つマシンでは拡張機能を許可リストで管理するか固定し、それらのノートPCを本番アクセス端末として扱い、それに見合った監視を行ってください。拡張機能のインシデント対応プレイブックを用意しておきましょう。永続化を確認し、クリーンなマシンからローテーションし、迷ったら再構築します。

  • マーケットプレイス運営者向け：パッケージを配信する前に、バージョン番号だけでなく、その中身をパブリッシャー自身のリリースと照合してください。パブリッシャーがリリースしていないバージョンやマニフェストの不一致は拒否し、新たな機能を追加するアップデートはレビューしてください。公開権限は本番環境のデプロイ鍵と同じように保護してください。

  • 拡張機能のパブリッシャー向け：公式の配布チャネルの明確なリストを、ストアやユーザーが照合できるハッシュまたは署名とともに公開してください。改ざんされたコピーが現れたら、今回Anthropicが行ったように、本物がどこにあるかを迅速かつ明確に伝えてください。

  • 開発者向け：拡張機能のインシデントが起きたら、インストール済みのバージョンをパブリッシャー自身のリリースノートや変更履歴と比較し、実際にインストール元となったマーケットプレイスを確認してください。自分のバージョンがパブリッシャーの一覧にない場合は、そのマシンが影響を受けたものとして扱ってください。

問題の核心にある緊張関係

それらのマシンで実行されたコードのほぼすべては、Anthropicのものでした。名前、ストア、見慣れたアップデートの通知など、開発者が信頼するよう教えられてきたシグナルはすべて、正しい方向を指していました。

配信しているものがパブリッシャーが実際にリリースしたものであるとストアが示せるようになるまでは、「公式マーケットプレイスから入手した」という言葉が示すのはパッケージの入手元にすぎません。それが何であるかまでは教えてくれません。

🎣セクション03：これはフィッシング？

Article content

正規か、フィッシングか？

🔬セクション04：技術研究

ページ速度を計測していたスクリプトが、ポジションを売り払った

10月29日、PolymarketがベンダーのDebugBearから読み込んでいたパフォーマンス監視スクリプトが差し替えられました。新しいファイルはパスワードや鍵を盗んだわけではありません。ログイン中の各トレーダーのブラウザーですでに動いていたトレーディングクライアントを見つけ出し、それを使ってアカウントから資金を抜き取ったのです。

研究者が回収したスクリプトは、難読化されていないプレーンなJavaScriptでした。そのため、仕組みが異例なほど簡単にわかります。この解説は、ohey.ca、Report URI、Dancho Danchevによる分析をもとにしています。

事実関係

Polymarketのページは、DebugBearのリアルユーザーモニタリング（RUM）スクリプトをcdn.debugbear[.]comから整合性チェックなしで読み込んでいました。UTC 16:54頃、そのURLに応答するサーバーが変わりました。レスポンスヘッダーがGoogle Cloud Storageのものからnginx形式のものに切り替わり、ファイルはウォレットドレイナーになったのです。DebugBearは後に、攻撃者が同社のDNSレコードを侵害していたと発表しました。PolymarketはUTC 17:59のビルドでスクリプトを削除し、その数分後にキャンセル専用モードに移行しました。

Article content

BleepingComputerは約257万ドルが攻撃者のウォレットに流れたことを突き止め、GoPlus Securityは影響を受けた入金用ウォレットを約700個と数えました。Polymarketは「当社のサードパーティプロバイダーの一つが侵害された」と述べ、影響を受けたトレーダーに全額を補償するとしています。

ドレイナーの仕組み

1. ログイン中のトレーダーを見つける：スクリプトは、Polymarket自身のアプリがlocalStorageに書き込む三つのキーを読み取りました。polymarket.auth.params（ログインの種類とウォレット）、polymarket.auth.proxyWallet（入金用ウォレット）、poly_clob_api_key_map（トレーディングAPIの認証情報）です。セッションがなければ、攻撃もありません。また、Polymarket自身の/api/geoblockエンドポイントを呼び出し、取引をブロックされている訪問者はスキップしました。

2. ページのトレーディングクライアントを借りる：スクリプト自体は鍵を一切持っていませんでした。その代わりに、ReactがDOM要素に付与する__reactFiber$プロパティを通じてReactの内部コンポーネントツリーをたどり、postOrderメソッドと、createOrderまたはcreateMarketOrderメソッドを持つオブジェクトを探しました。そのオブジェクトこそ、ユーザーの署名者（signer）まで備えたPolymarketの稼働中の注文クライアントでした。簡略化すると、探索は次のようなものでした。

// Simplified illustration of the technique, not the attacker's exact code
for (const el of document.querySelectorAll("*")) {
  const key = Object.keys(el).find(k => k.startsWith("__reactFiber$"));
  // walk el[key] and its parents, return the first object that has
  // postOrder() and createOrder(), plus a signer
}

クライアントがまだ存在しない場合は、250ミリ秒間隔で15回再試行し、それでも見つからなければページを再読み込みして、アプリにクライアントを作成させました。

3. 設定を読み込む：スクリプトはdata.debugbear[.]com/metrics/initに指示を問い合わせました。攻撃の間、このエンドポイントは404を返していたため、ハードコードされたデフォルト値が使われました。

return{recipient:N,minimalPerPosition:10,minimalToProcess:10,priorityToken:"POL"}

Nは攻撃者のPolygonアドレス0x3F99139F1C5854bb628c2e576Aaf638e99dFfc18です。価値が10ドル未満のアカウントは放置されました。

4. まずアカウントを報告する：何かを移動させる前に、ポートフォリオの価値、現金残高、すべてのポジションを、ウォレット、ログインの種類、OS、IP、国とともに/metrics/submitに送信しました。

5. 二つの方法で資金を抜き取る：ブラウザーウォレットのユーザーに対しては、10ドルを超えるすべてのポジションを一回のsafeBatchTransferFrom呼び出しで攻撃者に移すEIP-712バッチを一つ作成し、Polymarket自身のリレイヤーを通じて送信しました。このバッチはウォレットの署名リクエストとして表示されたため、これらのユーザーは承認する必要がありました。メールログインのアカウントは、ウォレットのプロンプトが出ない別の経路をたどりました。価格の97%、次に50%、さらに最小ティックでのフィル・アンド・キル注文でポジションを売却し、現金を回収したのです。

6. 現金化する：Polymarket自身のフロントエンドのAPIキーを使い、受取人を攻撃者にして、fun.xyzを通じて現金をPOLにスワップしました。各送金は、そのトランザクションハッシュとともに/metrics/updateまたは/metrics/handleに報告されました。

Article content

境界が破られた場所

どのステップも、Polymarketのページが正当に持っていたものを使っていました。ストレージのキー、注文クライアント、リレイヤー、スワッププロバイダーのAPIキーです。サードパーティスクリプトは読み込んだページの全権限で実行されるため、監視スクリプトとトレーディングインターフェースは事実上同じプログラムでした。

PolymarketのContent Security Policy（CSP）は役に立ちませんでした。ドレイナーが使ったホストはすべて、すでに許可されていたからです。script-src-elemはcdn.debugbear[.]comを許可し、connect-srcはdata.debugbear[.]com、*.polymarket.com、*.alchemy.com、*.fun.xyzを許可していました。Report URIの言葉を借りれば、「どのみち何もブロックされることはなかった」のです。

Article content

ページが信頼していたのはファイルではなくURLでした。URLは一度も変わらなかったため、攻撃が成功するためにPolymarket側で何かを変える必要はありませんでした。

攻撃チェーンのステップごとの流れ

[DebugBear URL now serves drainer] -> [polymarket.com loads it, no SRI]
   -> [Reads localStorage: login, wallet, CLOB keys] -> [Finds React order client + signer]
   -> [Reports portfolio to /metrics/submit] -> [Sells or batch-transfers positions]
   -> [Swaps cash to POL via fun.xyz] -> [Attacker wallet]

防御側が学ぶべきこと

  • サードパーティスクリプトをSubresource Integrityで固定する：改ざんされたファイルは、クリーンなファイル（0525f046…）とは異なるハッシュを持っていました。scriptタグにintegrity属性があれば、ブラウザーはその実行を拒否していたはずです。ベンダーのスクリプトが頻繁に変わって固定できない場合は、レビュー済みのコピーをセルフホストしてください。

  • CSPの許可リストを整合性の保証とみなさない：CSPが制御するのはコードの読み込み元であり、コードの中身ではありません。ハッシュベースの制御とレポート用エンドポイントを追加し、ホストが許可されていてもスクリプトが変更されたらアラートが上がるようにしてください。

  • 資金を動かせるページに監視スクリプトを置かない：RUMやアナリティクスが、ユーザーが取引や出金を行える場所で動く必要はほとんどありません。マーケティングページで読み込むか、アプリの状態にアクセスできないサンドボックス化されたiframe内で読み込んでください。

  • 高額な操作にはユーザーによる新たな操作を必須にする：すべてを売却する、資金を移動するといった操作には、ユーザーが能動的に行う確認を必須にすべきです。理想的にはパスキーやハードウェアセキュリティキーなどのフィッシング耐性のある認証器を使い、ページ内にすでにあるコードが黙って実行できないようにします。

  • ありえない挙動にアラートを出す：数百のアカウントが数分のうちに清算されるのは明確なシグナルです。Polymarketがキャンセル専用モードで行ったように、高額な操作を素早く停止できる手段を用意しておきましょう。

🛠️セクション05：今週のツール

すべての開発者のノートPCで、同じバックドアを数分でチェックできるか？

Cursorの拡張機能のようなインシデントが起きたとき、問題は「インストールしたか？」だけではありません。「それが残していったものが、まだ生き残っていないか？」です。osqueryは、そうした問いに多数のマシンで一度に答えてくれます。

Article content

osqueryは、もともとFacebookで開発され、現在はLinux Foundationがホストしているオープンソースのツールで、オペレーティングシステムを一連のデータベーステーブルとして公開します。OSごとに異なるスクリプトを書く代わりに、SQLで問いかけることができます。どのSSH鍵が認可されているか、どのLaunchAgentやスケジュールタスクが存在するか、どのプロセスが動いていて、どこに接続しているか、といった問いです。

# Quickstart (macOS)
brew install --cask osquery
osqueryi
-- macOS: look for the LaunchAgent named in the Cursor incident
SELECT label, path, program_arguments FROM launchd WHERE label = 'com.apple.sysmond';

-- Windows: look for the SysMon scheduled task and the Startup folder fallback
SELECT name, action, path, enabled FROM scheduled_tasks WHERE name LIKE '%SysMon%';
SELECT name, path FROM startup_items WHERE name LIKE '%sysmon%';

-- macOS and Linux: list authorized SSH keys for every local user, and look for svc-telemetry
SELECT u.username, k.key_file, k.comment
FROM users u JOIN authorized_keys k USING (uid);

-- Windows: no authorized_keys table, so find the key files and open them
SELECT path, mtime FROM file
WHERE path LIKE 'C:\Users\%\.ssh\authorized_keys'
   OR path = 'C:\ProgramData\ssh\administrators_authorized_keys';

authorized_keysテーブルはWindowsには存在しません。Windowsでは、上のクエリは鍵ファイルを見つけるだけなので、それぞれにsvc-telemetryの鍵がないか確認するか、構成管理のインベントリから取得してください。

何がわからないかを知っておく：osqueryが示すのは、今この瞬間にマシン上にあるものです。攻撃者が盗んだ認証情報ですでに何をしたかまではわかりませんし、クリーンアップ後にクリーンな結果が出ても、何も盗まれていないことを意味するわけではありません。影響を受けたマシンを素早く見つけるために使い、その後で認証情報のローテーションを行い、トンネルが接続されていた場合は再構築を行ってください。

👏セクション06：今週の人物

Paul McCarty

今週取り上げるのはPaul McCartyです。彼はOpenSourceMalwareの創設者です。OpenSourceMalwareは、npm、PyPI、RubyGems、Open VSXなどのレジストリで見つかった悪意のあるパッケージを集めた、コミュニティ主導のオープンなデータベースです。

パッケージや拡張機能が悪意あるものに変わったとき、防御側はすぐに知る必要があります。どのバージョンか、どの侵害指標（IoC）か、同じ攻撃者が以前にも同じことをしたか。OpenSourceMalwareはそうした脅威インテリジェンスを公開しているため、誰でもベンダーのレポートを待たずに疑わしいパッケージを調べられます。

彼の仕事は今号のニュースにも登場しました。OVHcloud CLIの侵害の後、McCartyは、以前のGlassWormの作戦で使われたSolanaのウォレットアドレスをもとにこの攻撃をGlassWormキャンペーンと結びつけ、さらにリリースの差し替えに使われた開発者アカウントが七か月前から侵害されていたことを突き止めました。

すべての防御者が成果を活用できるよう、悪意のあるパッケージをオープンに追跡し続けていることから、Paul McCartyを今週の人物に選びました。 👏

📅セクション07：今週のイベント

Open Source SecurityCon 2026

Open Source SecurityConは、Cloud Native Computing FoundationとOpen Source Security Foundation（OpenSSF）が共催する一日のイベントで、KubeCon + CloudNativeCon North Americaと併催されます。

トラックは、サプライチェーンセキュリティ、セキュアなソフトウェア開発、アイデンティティとアクセス、アーキテクチャとポリシー、オープンソースの公共政策をカバーしています。OpenSSFとCNCFは、TUF、in-toto、Sigstoreなど、インストールするものを検証するためのツールの多くの本拠地です。そのため、パッケージ署名やビルド検証を構築している人々が知見を交換する場となっています。

📍 Salt Palace Convention Center、米国ユタ州ソルトレイクシティ 📅 2026年11月9日

Article content

📚セクション08：今週の本

自分で書いてはいないが、それでも出荷しているすべてのもの

『Software Supply Chain Security: Securing the End-to-End Supply Chain for Software, Firmware, and Hardware』（著：Cassie Crossley）は、組織が依存しているものの自らは構築していないコード、コンポーネント、サービスを扱った本です。

Crossleyは、依存しているコンポーネントやツールから、ソフトウェアがどのようにビルド、署名、配布、更新されるか、そして攻撃者がその過程のどこで入り込めるかまで、チェーン全体を順を追って解説します。ソフトウェア部品表（SBOM）、ビルドの完全性、ベンダーリスクといった実践的な制御を扱い、それらの制御について語るだけでなく、実際に導入しなければならない人々に向けて書かれています。

自分で書いていないのに出荷しているコードを把握するなら、『Software Supply Chain Security』は格好の出発点です。

Article content

😅セクション09：今週のミーム

Article content

もし今朝、ベンダーのスクリプトの一つや開発者の拡張機能の一つが変更されていたら、どうやって気づきますか？

今号は以上です。拡張機能を確認し、サードパーティスクリプトを洗い出しておいてください。それでは、また次号でお会いしましょう。

The Breach Brief、Ostorlabチーム