dYdX関連のnpm/PyPIパッケージが乗っ取られ、ウォレット窃取とRATを拡散—OSSレジストリ依存の開発現場が直ちに見直すべき前提

今日の深掘りポイント

• レジストリ上の「正規パッケージの改ざん」による供給連鎖リスクが再度顕在化し、暗号資産ウォレット窃取とRAT導入の二重被害が同時進行し得る局面です。
• 侵入手口は開発者アカウント乗っ取りと正規認証情報の悪用であり、技術的巧妙さよりも「アカウント防御の隙」を突いた典型的な手法です。
• メトリクスが示す実効性・即応性の高さは、技術的対策だけでなく“運用の足回り”（2FA/Passkey、発行トークン最小化、ミラーリングとゲート）を今日から締める意思決定の必要性を裏づけます。
• npm/PyPIの「インストール時に任意コードが実行され得る」という構造的リスクを直視し、CI/CDにおけるスクリプト実行の制限・ホワイトリスト化・ビルドの密閉化を標準運用に落とし込むことが必須です。
• Web3/金融だけでなく、Node/Pythonに依存する全ドメインが波及リスクに晒されます。SBOM活用・ロックファイル検査・レジストリミラーの隔離審査は、広範な業種での“即効薬”になります。

はじめに

「正規の依存関係を更新しただけで、資産と端末の両方が落ちる」。そんな悪夢を避けるために、私たちは何を捨て、何を新たに受け入れるべきか。今回のdYdX関連パッケージ侵害は、OSSレジストリへの信頼の置き方を、技術と運用の両輪でアップデートする好機でもあります。攻撃者は新奇なゼロデイに頼っていないからこそ、私たちの“日常の手順”を変えれば被害の相当部分は防げます。現場が明日から実装できる手当を中心に、立体的に整理します。

深掘り詳細

事実関係（確認できていること）

• npmおよびPyPIで、dYdXプロトコルに関連する正当なパッケージに悪意のあるバージョンが掲載され、暗号通貨ウォレット情報の窃取とRAT（リモートアクセス型マルウェア）配布が行われたと報じられています。攻撃者は開発者アカウントを侵害し、正規の認証情報を使って悪性コードを挿入したとされています。dYdXは影響ユーザーに対し、感染端末の隔離、新規ウォレットへの資金退避、APIキーの変更を促しています［参考：The Hacker Newsの報道］（The Hacker News）。
• 配布経路は公開レジストリ由来であり、依存関係の更新・導入時に利用者側で追加の操作なく取り込まれる可能性がある点が、被害拡大のリスク要因になっています（同報道）。

上記は外部公開情報に基づく事実であり、パッケージ名・バージョン・IOCなどの細部は記事時点で一般公開情報の範囲に依存します。個別の自組織影響調査では、当該報道と自社SBOM/ロックファイルの照合を前提にしてください。

編集部のインサイト（仮説と示唆）

• アカウント乗っ取りは“コスト対効果が高い”攻撃です。堅牢なCI/CDやコード署名を迂回し、正規パブリッシャーとして悪性更新を押し込めます。二要素認証や発行トークンの短期化・発行元制約（OIDC連携など）が未整備なプロジェクトは、守りが薄くなりがちです。今回も「技術的難易度が高い」より「運用の穴を突く」類型と見るのが妥当です。
• 「インストール＝実行」の構造的リスクを直視すべきです。npmのpreinstall/postinstall、PyPIのsdistビルド（setup/PEP 517フック）など、“導入時に任意コードが走る”設計は、公開レジストリ前提の開発スループットと引き換えに生じた負債です。CI/CDではスクリプトの既定無効化・ビルドの密閉化・ホワイトリスト例外承認という“逆流防止弁”を標準にすべきです。
• メトリクス全体像は「現実性・即応性が高く、手口は目新しくないが被害は広く深い」ことを示唆します。すなわち、技術的革新への投資より、当面は“足腰（アカウント・トークン・ミラー・ロックファイル）”を締めることが最大効果を生みます。特にWeb3や金融では、ウォレット即時窃取が損失直結で可逆性が低いため、反応時間（検知→資金退避）の短縮が最重要KPIになります。

仮説であることを明示しますが、攻撃者はレジストリの審査目線では検知困難な小さな追加通信・難読化ローダー・依存グラフ深部への埋め込みなどを活用した可能性が高いです。これは“レジストリ側の改善だけでは塞ぎ切れない”ことを意味します。

脅威シナリオと影響

• シナリオA（資産直撃型：ウォレット窃取）
  • 供給連鎖侵入（MITRE ATT&CK: T1195.001 Supply Chain Compromise: Software Dependencies and Development Tools）により、開発者端末やユーティリティ端末で悪性パッケージが実行。
  • 実行フェーズ（T1059 Command and Scripting Interpreter: JavaScript/Python）でブラウザストア・ウォレット拡張・クリップボード・ファイルシステムからシード/秘密鍵/キー保管情報を収集（T1552/T1555系の資格情報アクセス）。
  • 窃取データはHTTP/HTTPSで外送（T1041 Exfiltration Over C2 Channel / T1071.001 Web Protocols）。
  • 即時の資産移転が実行され、後追い防御が困難。
• シナリオB（足場拡大型：RAT→横展開）
  • 初期侵入後、永続化（仮説：T1053 Scheduled Task/Job、T1547 Boot or Logon Autostart Execution）とC2確立（T1071 Application Layer Protocol）によりRATが常駐。
  • 開発用シークレットの窃取（T1555 Credentials from Password Stores / Cloud Credentials）やリポジトリアクセス権濫用で、別プロジェクトやCI/CDへの横展開（T1087 Account Discovery、T1046 Network Service Discovery）。
  • 結果として、二次的なサプライチェーン汚染（別プロジェクトのパッケージやビルド成果物）に波及するリスク。
• シナリオC（検知回避・残存リスク）
  • 難読化やパッケージ分割（T1027 Obfuscated/Compressed Files and Information）でシグネチャ検知を回避。
  • アンインストール後も残るタスク/レジストリ/LaunchAgent等による残存（T1070.004 Artifact Deletion回避、Persist設定）。

影響評価の観点では、暗号資産の「即時・不可逆な損失リスク」に加え、RAT定着による「開発シークレットの継続流出」と「二次サプライチェーン汚染」の組み合わせが最悪です。暗号資産を扱わない組織でも、同様の初期侵入からソース窃取・署名鍵流出・顧客への二次被害につながるため、業種を問わず重大インシデントに直結します。

セキュリティ担当者のアクション

• いま直ちに（本日中～48時間）

  • 依存関係のインベントリと凍結
    • SBOM/ロックファイルを全リポジトリで収集し、「最近の更新」「dYdX関連名義」「不審な新規依存」を優先的に棚卸しします。暫定措置として、CIでの依存自動更新を一時停止します。
  • インストール時実行の抑止（破壊的変更に留意）
    • npm系はCIで一律スクリプト無効化を暫定適用（例：ignore-scriptsのポリシー運用）し、例外はセキュリティ承認制にします。
    • Python系はCIでsdistビルドを禁止し、wheel限定導入を徹底（例：only-binary指定などのポリシー運用）します。wheelが無いパッケージは隔離審査を経るまでビルド不可とします。
  • 端末・資産の緊急保全
    • 開発端末・ビルドエージェントで当該期間にパッケージ導入があったものを隔離・イメージ取得し、EDRでのプロセスツリーと外向き通信のハンティングを実施します。
    • 暗号資産の関与が疑われる場合、推奨に従い新規ウォレットへ即時退避・APIキー/トークンの再発行を行います（The Hacker Newsの報道に基づく対応）。
  • 監視の即席強化
    • ビルド/インストール工程からの外向き通信をブロックもしくはプロキシ経由に強制し、未知ドメイン・IPへのPOST/PUT/WS接続をアラート化します。

• 今週中（1～2週間）

  • アカウントと発行トークンの強化
    • npm/PyPIパブリッシャーの2FA/Passkeyを強制し、長期アクセストークンを廃止。可能な範囲でOIDCベースの“発行元制約”付き公開（いわゆるTrusted PublisherやCI起点の限定発行）へ移行します。
    • パブリッシャー権限を棚卸しし、共同メンテナの最小権限化・レビュー必須化を実施します。
  • レジストリミラーと隔離審査
    • 内部プロキシ（npm/PyPIミラー）を導入し、新規/更新パッケージはミラー上でマルウェア・メタデータ検査（難読化・不審スクリプト・リリースパターンの異常）を通過しないと社内で解決できない設計にします。
  • 変更ゲートの標準化
    • 依存更新はPR単位でSBOM差分・ロックファイル差分・メンテナ変更・権限変更を自動注釈し、セキュリティ承認を必須化します。
    • npmのスクリプト実行はパッケージ単位のホワイトリスト制とし、CIでは既定無効。Pythonはwheel限定導入を既定とします。
  • インシデント・ランブック整備
    • 「レジストリ改ざん検知→SBOM横断検索→端末隔離→鍵/トークンローテーション→顧客通知」の定型フローと責任分界を文書化し、演習します。

• 中期（四半期）

  • ビルドの密閉化と証跡性
    • ネットワーク遮断の再現ビルド（hermetic build）を段階導入し、依存取得はミラーのみ、CIランナーは短命・無人・秘密保持最小を徹底します。
    • 依存導入・ビルド・成果物に署名/アテステーションを付与し、署名検証と“誰が・どこで・何からビルドしたか”の由来検証をパイプラインに組み込みます。
  • 継続的ハンティング
    • npm実行時のchild_process呼び出し、Pythonビルド工程のネットワークI/O、暗号資産関連プロセスのAPIコールなど“導入工程に不相応な挙動”を振る舞い検知のルールに落とし込みます。

• ハンティングの具体視点（仮説ベース）

  • npm/yarn実行中にcurl/wget/PowerShell WebRequestを伴うスクリプト起動。
  • pipインストール工程からの外部HTTP接続・DNSクエリ（レジストリ以外）。
  • 開発端末からの新規生成SSHキー・クラウド認証情報の短期連続利用。
  • クリップボード監視や暗号資産関連ディレクトリ（例：ウォレット拡張のデータパス）へのアクセス増加。

最後に、今回の報道は“OSSとレジストリの信頼”の再構築を私たちに迫ります。信頼をやめるのではなく、「検証可能な信頼」に置き換えることが要諦です。ロックファイル、ミラー、署名、最小権限、そして人のレビュー——この地味な積み重ねが、最短の復旧と最小の損失をもたらします。現場の目線で、今日から変えられるところから変えていきます。

参考情報

• The Hacker News: Compromised dYdX npm and PyPI Packages Distribute Wallet Stealer and RAT（2026-02-06）: https://thehackernews.com/2026/02/compromised-dydx-npm-and-pypi-packages.html