暗号資産開発者が信頼で直面するリスクとは？500,000ドルの拡張案件から考える

Published on: 2026-03-22 | Last updated: 2026-03-22

你がさ、いつものノリでIDE開いて、拡張機能入れて、コーヒー一口飲んで、で、数日後にウォレットが空っぽ。こういうの、冗談じゃなく起きる。ほんとに。

結論だけ先に言うと怖い話

Cursor IDEのOpen VSX拡張「Solidity Language」偽装は、PowerShell→ScreenConnect→Quasar RAT→PureLogsで鍵情報を抜き、約50万ドル被害を出した（出典：Kaspersky GReAT 2025）。

引っかけ方：説明文コピペ、検索順位、DL数水増し、見分けにくい出版社名
動き方：拡張が機能しないのに裏でコード実行
刺さる理由：IDE拡張は実質「権限全部」
今すぐやること：VS Code公式マーケットで先に検証、怪しいのは隔離

で、ここからが嫌なところ。
「ちゃんとしてた人」が落ちるやつなんだよね。

何が起きたかを一行でまとめると地獄

偽のIDE拡張機能は、見た目は普通でもバックグラウンドで任意コード実行（任意のコマンドを実行できる仕組み）まで行けるため、開発PCがそのまま侵害される。

状況：2025年6月、Solidity（Ethereum系のスマートコントラクト言語）を書いてた開発者がCursor IDEで拡張を探した。
そしたら「Solidity Language」ってやつが上位に出てくる。DL数もそれっぽい。

こういう時ってさ、「まあ皆入れてるっしょ」ってなる。なるんだよ。
眠い朝とか特に。

偽装が上手かった点：

説明文：正規拡張の文章をそのままコピー
表示：検索で4位、正規が8位だった（原文の記述）
数字：「54,000ダウンロード」みたいな社会的証明を盛る
名前：「juanbIanco」みたいに I を l に見せる（フォント罠）

この l と I 問題、地味に刺さる。
「見た目同じじゃん」っていう、あれ。最悪。

「その拡張はスマートコントラクトと無関係で、やっているのは悪性コードのダウンロードと実行だけだった。」（出典：Kaspersky Security Researchers 2025）

拡張機能の中で走ってたやつ

悪性拡張はCursor起動時に`extension.js`を実行し、C2（指令サーバ）と通信してPowerShellを落とし、リモート操作と情報窃取に繋げた（出典：Securelist 2025）。

ステージ分解：これ、手口が「見えない」方向に寄せてあるのがイヤらしい。

Stage 1：外部サーバに連絡してスクリプト取得。C2が`angelic.su`（原文の記述）。
PowerShell（Windowsの自動化シェル）を“それっぽいコード”として落とす。

PowerShellって便利すぎて、便利すぎるんだよね。
現場で使うから余計に。

Stage 2：ScreenConnect（正規のリモートアクセス製品）をチェックして、無ければ攻撃者管理の版を入れて、永続化。
永続化（再起動しても戻ってくる居座り）って、これが始まると話が重くなる。

Stage 3：Quasar RAT（リモート操作型トロイの木馬）と、PureLogs stealer（情報窃取ツール）で、シードフレーズや秘密鍵を狙う。
シードフレーズ（ウォレット復元用の単語列）抜かれたら、もう“負け”が確定するやつ。

しかも、正規っぽいツール混ぜるから、アンチウイルスが気づきにくい。
やめて。

なんでこんなに簡単に刺さるのか

IDE拡張はサンドボックスが弱く、ファイル操作・コマンド実行・ネットワークアクセスまで届くため、ブラウザ拡張より「権限が強い」前提で扱う必要がある。

ここ、誤解されがち：ブラウザ拡張って、まだ“許可”の会話があるじゃん。位置情報とか通知とか。
でもIDE拡張は、体感「最初から全部OK」みたいな空気がある。

セキュリティ研究者のGeorgy Kucherinが言ってたやつ、刺さるんだよね。
「許可を求めない。だって許可は基本すべて」みたいな。

進階の見方：これは単なるマルウェア事件じゃなくて、供給網攻撃（Supply Chain Attack：配布経路や依存関係を汚して侵入する手口）の延長線。
npmやPyPIの話は有名だけど、IDEの拡張ストアも同じ土俵に来た。

自分用の自衛セットこれだけはチェックして

IDE拡張の安全確認は、公式マーケットでの事前検証・出版社の同一性確認・新規公開の様子見・非機能なら即削除・資産用途の分離で、被害確率を現実的に下げられる。

スクショ用自己チェックリスト：ここ、マジでそのまま使って。🙂

公式で先に試す：まずMicrosoftのVS Code Marketplaceで同名拡張を確認して、そこで入れて挙動を見る
出版社名を一文字ずつ見る：l / I、0 / O、rn / m を疑う。コピペして比較もアリ
新しすぎるのは寝かせる：公開直後・急に伸びたDL数は一旦スルー
動かない拡張は即アンインストール：機能しない＝バグか悪性、どっちでも要らない
隔離環境：大事な鍵を触る作業は別Windowsユーザー/別PC/VMに分ける。財布と開発机を一緒にしない
監視ツール：EDR（端末監視・検知）を入れるか、最低でもWindowsイベントログとPowerShell実行ログを追える設定に寄せる

「EDRとか無理」って人もいるのは分かる。
でも、少なくとも 鍵触る作業を分ける はコスパ良い。これはガチで。

日本の空気に寄せた話：会社なら情シスが拡張のホワイトリスト運用するの、わりと現実的。
個人でも、Discordとかで「その拡張大丈夫？」って聞ける場所を持ってる人ほど助かる。文化として。

あと、日本って梅雨とかで部屋じめじめしてさ、PCの前に長時間いると判断力落ちるんだよね。
…いや関係ない？でもあるんだよ。眠いとクリックが雑になる。

反対意見も分かるでもそこじゃない

「自己責任でしょ」と切るより、拡張配布の検証・ランキング耐性・署名や透明性の基準を整えるほうが、供給網攻撃のコストを上げられる（出典：CISA, Snyk）。

よくある反論：「そんなの引っかかる方が悪い」「DL数見て入れるの草」みたいなやつ。
気持ちは分かる。分かるけど。

攻撃者は「普通の行動」を狙ってる。
だから刺さる。

組織側の現実解：拡張の許可制（ホワイトリスト）と、端末側の検知。Snykは供給網攻撃がIDEやAI開発ツールにも広がるって言ってた（出典：Snyk Security Intelligence）。
CISAも供給網の侵害を継続的に警戒してる流れがある（出典：CISA Known Exploited Vulnerabilities）。

で、最後にこれ。