Claude Codeのパッケージングエラーを悪用した誘導キャンペーン：守るべき実務的対策と検知手順

Claude Codeのパッケージングエラーを悪用した誘導キャンペーン：守るべき実務的対策と検知手順

冒頭文
Anthropicの「Claude Code」におけるnpmパッケージングの誤配置（ソースマップ漏洩）をきっかけに、攻撃者がその“流出”を装ったGitHubリポジトリを誘い文句にして情報窃取型マルウェアを配布するキャンペーンが確認された。本稿は事象の概略、攻撃方法の特徴、組織が直ちに取るべき対応、検知／追跡に有効な観点を整理し、現場で使える具体的アクションを示す。The Verge+1

• 背景：何が起きたか
• 攻撃の特徴と使われたマルウェア
• 攻撃インフラと主要指標（表）
• なぜこの手口が有効か（心理的／技術的理由）
• 組織が直ちに取るべき即効対応（実務）
• 検知と追跡：実用的なシグネチャ／観測点
• 中長期的な対策とサプライチェーンの姿勢
• インシデント対応チェックリスト（簡潔）
• まとめ：注目が“武器”になる時代のリスク管理

背景：何が起きたか

2026年3月末から4月初旬にかけて、Anthropicが提供する開発支援ツール「Claude Code」のリリースパッケージに誤ってソースマップなど内部コードが含まれ、約50万行に及ぶコードが外部に流出したと報告された。パッケージングミスとして公表されたこの事象は短時間で注目を集め、多数の開発者や研究者が該当ファイルを探索・共有した。この“注目”を悪用して、攻撃者は流出を装う形で悪意あるアーカイブをGitHubのリリース機能へ配置し、ダウンロードを誘導した。The Verge+1

攻撃の特徴と使われたマルウェア

攻撃者は“流出したClaude Code”を名目にしたGitHubリポジトリを作成し、そこから7z形式のアーカイブを配布した。アーカイブ内部にはRustで作られた実行ファイル（例：ClaudeCode_x64.exe）が含まれ、実行後に情報窃取（stealer）やプロキシ機能を持つ二次ペイロードを展開する挙動が観測されている。報告された主要ペイロードにはVidar（認証情報・ウォレット窃取）、GhostSocks（プロキシ・ネットワーク中継）、PureLog Stealer（ログ／セッション情報収集）などがあり、被害はWindows環境を主対象としている。これらの観察結果は複数のセキュリティベンダーによって確認されている。Zscaler+1

攻撃インフラと主要指標（表）

以下は調査で明らかになった攻撃者識別子や配布アーティファクトの主要値であり、検知ルールやIOC（Indicator of Compromise）作成時の初期データとして利用できる。

（表の情報は公開分析に基づく初期IOCであり、タイムスタンプやダウンロード数は変動する可能性がある。）。www.trendmicro.com

なぜこの手口が有効か（心理的／技術的理由）

攻撃者がこの手法で成功する主因は「信頼の武器化（weaponizing trust signals）」である。具体的には、注目を集めたソフトウェアブランドの“流出”というニュース性と、GitHubの正規機能（リポジトリ、リリース）という信頼できるプラットフォームを組み合わせることで、被害者に疑念を抱かせない点にある。さらに、アーカイブに含まれる実行ファイルが一見合法的なファイル名や説明を持つため、初動での手作業検査に引っかかりにくい。過去にも同種の窃取型マルウェア配布でGitHubを悪用する事例が観測されているため、ソフトウェア供給連鎖における“人為ミス”や“注目の瞬間”を狙う攻撃は今後も繰り返されやすい。www.trendmicro.com+1

組織が直ちに取るべき即効対応（実務）

まず外部からの「流出」アーカイブをダウンロード・実行した痕跡がないかを確認する。ダウンロードログ、プロキシ／ウェブゲートウェイログ、EDRのファイル作成イベント、メール添付履歴を横断的に検索し、上記のファイル名やドメインに該当する物を優先的に調査する。次に、開発者ワークステーションやCI/CD環境がGitHubの“未知の”リリースを自動取得する設定になっていないかを点検し、不要な自動依存取得は無効化する。最後に、認証情報やシークレットの即時ローテーションを検討する。これらは短時間で実行可能な封じ込め策であり、初動被害の拡大を抑えるうえで効果的である。www.trendmicro.com+1

検知と追跡：実用的なシグネチャ／観測点

EDR／XDRルールでは、次の観測点が有用である。ダウンロード元がGitHubのリリース資産であることを示すHTTPリファラーやUser-Agentの突合、7zやexeが一時ディレクトリで実行されるプロセス生成イベント、Rust製バイナリに典型的なライブラリや構成要素のファイルハッシュ（可能であればベンダー提供のハッシュを利用）での検知、外部プロキシへの不審な持続接続（GhostSocksのようなプロキシ機能）と認証情報送信の兆候（ブラウザプロファイルやウォレットファイルへのアクセス）での相関検出を推奨する。検知ルールの優先度は、公開されているIoCの確度と組織固有のリスク（開発者のGitHub利用頻度など）に応じて調整する。Zscaler+1

中長期的な対策とサプライチェーンの姿勢

組織は単発のインシデント対応に留まらず、ソフトウェア供給チェーンと開発流通経路の耐性強化を進めるべきである。具体的には開発者端末の最小権限化、依存管理の中央集約（社内プロキシ／アーティファクトリポジトリ経由での取得）、リリース検証プロセス（署名検証・サンプル実行環境でのサニティチェック）、そして開発チーム向けのセキュリティ教育（信頼できるソースの見極め、外部リリースの扱い方）を必須化する。加えて、サードパーティ製ツールやOSSの急速な注目時に発生しやすい“フェイク流出”や“タイポスクワット”の監視ルールを導入することで、次の“ブランドを悪用した誘導”に備えることができる。www.trendmicro.com+1

インシデント対応チェックリスト（簡潔）

事務的な手順は可能な限り標準化しておき、発見から封じ込め、根絶、復旧、教訓化までをワークフロー化する。初動では（1）対象アカウント／リポジトリのアクセス遮断、（2）ダウンロードした端末の隔離、（3）EDRでのファイル及びプロセス痕跡の収集、（4）認証情報の検証と必要に応じたローテーション、（5）法務・広報と連携した対外対応の順を基本とする。これらの工程は組織のインシデントレスポンス計画に事前に組み込んでおくことが重要だ。www.trendmicro.com+1

まとめ：注目が“武器”になる時代のリスク管理

今回の件は、単なる“パッケージングのミス”が大規模な注目を生み、その注目を攻撃者が素早く収益化する好例である。開発者・セキュリティチーム双方が「ニュース性のある流出」「見慣れたプラットフォーム上の公表物」に対して自動的に信頼を与えない運用を設計すること、ならびに短時間でのIOC展開やプロアクティブな監視体制を整備することが、今後の同種攻撃の被害最小化につながる。外部で報告されている指標は変化しうるため、脅威情報の追跡とルール更新を習慣化してほしい。www.trendmicro.com+1

（参考：報告の一次分析や追加の技術詳細は、公開された複数のセキュリティベンダーブログおよび調査報告を参照のこと。本稿は公開情報を整理した実務向け