Red Hat Cloud Services のnpmパッケージがサプライチェーンポイズニング攻撃で侵害されました

iconMetaEra
共有
Share IconShare IconShare IconShare IconShare IconShare IconCopy
AI summary icon概要

expand icon
MetaEraのオンチェーンニュースによると、Red Hat Cloud Services組織の複数のnpmパッケージでセキュリティ侵害が報告されています。MistEyeのシステムは、32のパッケージにわたって96の悪意のあるバージョンを検出しました。そのうち3つを詳細に分析しました。@redhat-cloud-services/frontend-components-config@6.11.3などのパッケージに含まれる悪意のあるコードは、preinstallフック経由でインストール時に実行されます。このマルウェアはShai-Huludの変種で、資格情報の盗難とCI/CDの悪用を含んでいます。攻撃者は、ペイロードを隠すためにROT/Caesarシフト、AES-GCM、B5暗号化を使用しており、このマルウェアはnpmおよびGitHubワークフローを通じて拡散します。

背景

最近、MistEye セキュリティ監視システムは、Red Hat Cloud Services オーガニゼーション下の複数の npm パッケージに異常バージョンが存在するという情報を検出しました。今回の事件では、同オーガニゼーション下の 32 個の npm パッケージ、96 個のバージョンが関与しています。本記事では、そのうち 3 つのローカルサンプルを選び、オフラインで詳細に分析しました。これらのサンプルは、偽装されたネームスペースやタイポスクワッティングパッケージではなく、@redhat-cloud-services スコープを用いた真正なパッケージバージョンです。サンプルのソースコードから確認できたのは、インストール段階で自動的に起動される多層的に混淆された悪意のあるローダーが tarball に埋め込まれていることです。

完全復元後、以下のことが確認できる:この3つのサンプルの核心ペイロードは、GitHub Actions Runnerのメモリ読み取り、マルチクラウドおよびローカル資格情報の収集、GitHub APIによる外部送信とdead-drop、GitHubワークフローの注入、npmによる自己増殖、Claude Code/VS Code/systemd/LaunchAgentによる永続化、Harden-Runner/StepSecurityの対抗、EDRおよびセキュリティ製品の検出などのソースコード機能を備えている。機能のカバー範囲から見ると、潜在的な影響対象には開発者ホスト、CI/CD Runner、ビルドコンテナ、GitHubリポジトリ、GitHub Actionsワークフロー、npm配信チェーン、およびクラウド環境の資格情報が含まれる。実際の影響範囲は、インストールログ、リポジトリ監査、およびプラットフォーム側のテレメトリーを組み合わせて確認する必要がある。

コード構造、拡散経路、および能力の組み合わせから見ると、このマルウェアはShai-Huludマルウェアの変種です。

MistEye への応答

MistEyeは、SlowMistが自社開発したWeb3脅威インテリジェンスおよび動的セキュリティ監視システムで、セキュリティ監視とインテリジェンス集約機能を統合し、ユーザーにリアルタイムのリスク警告と資産保護を提供します。

Red Hat Cloud Services npm パッケージのサプライチェーンポイズニング事件および関連する悪意のあるサンプルを検出後、MistEye システムは高リスクアラートをトリガーし、この攻撃チェーンの混淆構造、ペイロードの復号、機能の復元、およびIOCを体系的に分析しました。

(https://enterprise.misteye.io/threat-intelligence/SM-2026-378450)

攻撃チェーンの概要

本文の技術的分析部分は、3つのnpm tgzサンプルを展開、デコード、デオブスキュアして検証する、ローカルオフライン静的分析に基づいています。

本次の検証対象サンプルは以下の通りです:

@redhat-cloud-services/frontend-components-config

バージョン:6.11.3

tgz SHA-256:0c9c67ec40d5f23efa1ec3470d0ac88b4993ccc0e92be913fc29a337dfc4f060

@redhat-cloud-services/types

バージョン:3.6.1

tgz SHA-256:d543bb3cdf1569c2b3d38c8a4081ed746cfe78bf3236c2302704d79ab7fa9558

@redhat-cloud-services/rule-components

バージョン:4.7.2

tgz SHA-256:aaf00d06baa3c679b82452c50014e9824b8874e9ca2d150f19095f8de19ba90f

3つのサンプルの攻撃エントリポイントは完全に同一です:すべてのpackage.jsonにscripts.preinstall = "node index.js"が存在します。これは、開発者ホストまたはCI/CD環境でこれらのバージョンがインストールされた場合、ユーザーが明示的にimportしたり業務コードを実行したりすることなく、インストール段階でルートディレクトリのindex.jsが自動的に実行されることを意味します。

3つのサンプルは同じ核心的な悪意のあるペイロードを共有しているが、外層のパラメータは異なる。つまり、3つのサンプルはそれぞれ異なるROT/Caesarシフト値とAES-GCMのキー/IV/タグを使用しており、これにより外層パッケージのハッシュ、固定キー、または固定シフトに基づく静的特徴を直接的にパッケージ間で再利用することが困難になる。しかし、解読後のBunランタイムブートストラッパーと核心的な悪意のあるペイロードのハッシュは完全に一致している。一方はBunランタイム環境を準備するための起動補助モジュールであり、他方は真正な悪意のある機能を含む核心ペイロードである。本稿では、これらをそれぞれ「Bunランタイムブートストラッパー(ソースコード変数名 _b)」および「核心的な悪意のあるペイロード(ソースコード変数名 _p)」と呼ぶ。

復元された攻撃チェーンは以下の通りです:

テクニカル分析

1. エントリーポイント:npmライフサイクルスクリプトのハイジャック

3つのサンプルは、package.jsonのpreinstallライフサイクルフックを介して攻撃チェーンをトリガーします:

"scripts": {

"preinstall": "node index.js"

}

preinstall は npm インストール段階で自動的に実行されます。一般的なフロントエンドコンポーネント、型定義、またはルールコンポーネントパッケージの場合、インストール段階でルートディレクトリの大型 JavaScript ファイルを実行する必要は通常ありません。これは最も直接的な異常シグナルです。

サンプルレベルの証拠は以下の通りです:

@redhat-cloud-services/frontend-components-config@6.11.3

  • main:lib/index.js
  • files フィールド:["/lib", "/bin"]
  • ルートディレクトリ index.js SHA-256:545a1838c66e1771f58d84a17b3e1841e5eeab91a73f4ccc59c9492450a6d9c0

@redhat-cloud-services/types@3.6.1

  • main:index.d.ts
  • files フィールド:設定されていません
  • ルートディレクトリ index.js SHA-256:b86c5ae9e95bd841a595440faa3eb6317441e746f241ae8fd641ab59ed1d1966

@redhat-cloud-services/rule-components@4.7.2

  • main:index.js
  • files フィールド:設定されていません
  • ルートディレクトリ index.js SHA-256:1a30a9abe20bab121aaa75ed040565af14e6cdfb745609ee0e7b94a2d814fb9c

その中で、frontend-components-config@6.11.3 の files フィールドは "/lib" と "/bin" のみを宣言しているが、tarball のルートディレクトリには追加の index.js が存在し、preinstall によって呼び出されている。この異常はこのサンプルにのみ適用される;types@3.6.1 および rule-components@4.7.2 は files フィールドを設定していないため、この異常をすべてのサンプルに一般化することはできない。

2. 第1層:数字配列 + ROT/Caesar 文字置換

3つのサンプルのルートディレクトリにあるindex.jsはすべて超大規模な1行JavaScriptファイルであり、構造は同じで、本体はtry { eval(...) } catch (...) のラッパーです:

このラッパーは、巨大な数値配列をまず String.fromCharCode で文字列に復元し、次に文字列内の英字に対して ROT/Caesar シフトを適用した後、デコード結果を eval で実行します。エラー処理では、wrapper: プレフィックスのみを出力し、インストール失敗時の顕著なエラー露出を抑えております。

以下の3つのサンプルの外層変位値とStage 2ハッシュは以下の通りです:

frontend-components-config@6.11.3

index.js サイズ:4,294,798 バイト

ROT/Caesarシフト:10

ステージ2 SHA-256:b19c2fd48535c8c40aeb3e627ce92775f33ef9292611767bb1236c238e6f90cc

types@3.6.1

index.js サイズ:4,135,588 バイト

ROT/Caesarシフト:4

ステージ2 SHA-256:9c0425aa6e6d7792ac38d24f3e7245f42fcaa553ddfeb6bd97677017f10c3b75

rule-components@4.7.2

index.js サイズ:4,294,336 バイト

ROT/Caesarシフト:11

ステージ2 SHA-256:d590bd375d95e4ac072b7ebc1fc4489bcaf5f20a939e92486267aa398bcf1e5d

3. 第2層:AES-128-GCM で Bun ガイダーとコアペイロードを復号

ROT/CaesarでデコードされたStage 2コードは、Node.jsのcrypto.createDecipherivを用いてAES-128-GCM(Advanced Encryption Standard - Galois/Counter Mode)の復号を実行し、setAuthTagで認証タグを設定します。復号の対象は、Bunランタイムブートストラッパーとコアの悪意のあるペイロードの2つの後続コンポーネントです。

その中で、BunランタイムエージェントはBunランタイム環境を検出、特定、または準備し、後続のコードがBunを通じて実行できるようにします。核心的な悪意のあるペイロードは、攻撃チェーンの主体であり、資格情報の収集、GitHub/npmでの拡散、永続化、防衛回避、埋め込まれたリソースの復号化などの主要な悪意のある機能を含みます。

三つのサンプルは、それぞれ異なるAES-128-GCM鍵、初期化ベクトル、認証タグを使用してこの二つのコンポーネントを暗号化しているが、復号後の三つのBunランタイムブートストラッパーのSHA-256ハッシュはいずれもac2a2208e1726e008be6c73dc0872d9bba163319259dff1b62055ac933ca46b6であり、三つのコアマルウェアペイロードのSHA-256ハッシュはいずれも0dc06ecdaa63fe24859cfd955053c23245c536e4733480239d14bebf12688e35である。これは攻撃者が異なるnpmパッケージで外装パラメータを変更したが、同じコアマルウェアコンポーネントを再利用したことを示している。

デコード後、Stage 2は核心的な悪意のあるペイロードを/tmpに書き込み、Bunを通じて実行し、最後に一時ファイルを削除します。3つのサンプルから復元された実際のロジックは以下の通りです:

したがって、3つのサンプルにおける検証可能な一時ファイルのパターンは:

/tmp/p.js

Bunのランタイムエントリポイントのサイズは898バイトであり、3つのサンプルのハッシュは完全に一致しています:

ac2a2208e1726e008be6c73dc0872d9bba163319259dff1b62055ac933ca46b6

Bun実行環境ゲーティングには、child_process.execSync、fs.existsSync、fs.mkdtempSync、fs.chmodSync、os.platform()、os.arch()、getBunPath()などのロジックが含まれており、Bun実行環境の位置特定または準備を行います。つまり、Stage 2はシステムにグローバルにBunがインストールされていることを単純に仮定するのではなく、Bun実行時パス以外では、まずBun実行環境ゲーティングを読み込み、その後getBunPath()を呼び出してBunを実行し、核心的な悪意のあるペイロードを実行します。

4. 第3層:obfuscator.io 文字列テーブル

解読された核心的な悪意のあるペイロードは、直接読み取れるプレーンテキストのJavaScriptではなく、obfuscator.ioスタイルの文字列テーブルの難読化がさらに施されている。この層では、多数の文字列が配列に集中して格納され、実行時のインデックスとローテーションロジックによって復元されるため、分析者は文字列テーブルの復元を完了するまで、後続の重要なAPI、パス、設定名を直接検索できない。

5. 第4層:B5 カスタム文字列暗号化

obfuscator.io の文字列テーブルを復元した後も、コアの悪意のあるペイロードにはまだ1層のB5カスタム文字列暗号化が存在する。パラメータは以下のように確認された:

  • KDF:PBKDF2(Password-Based Key Derivation Function 2)
  • ハッシュ関数:SHA-256
  • 反復回数:200000
  • 鍵の長さ:32バイト
  • 解密ラウンド数:3
  • パスワード:ba2c6ddb3672bdd6a611e6850b4f700b52aed3dab2f1b3d5f8c839d4a157a709
  • salt:5b26508dc0f1075a7c0b4d8aa464487e

復号化後の結果は以下の通りです:

その中で、B5を復号すると複数の重要な明文文字列が表示されます。注意すべき点として、一部の文字列は元々obfuscator.ioの文字列テーブルに存在しており、「文字列テーブル置換+B5復号」の両方の手順を完了した後にのみ、直接grep可能になります:

6. 追加の埋め込み層:AES-256-GCM + gzip

コアの悪意のあるペイロードには、AES-256-GCMで暗号化され、gzipで圧縮された埋め込みリソースが含まれています。復元ロジックは次の通りです:

機能ごとに三つのカテゴリに分類された解読されたキーエンベッディングリソース:

クロスプラットフォームメモリ読み取り:

この種のリソースは、実行中のプロセスのメモリを読み取るために使用されます。通常のファイル内のキーまたはトークンはファイルを検索することで発見できますが、CI/CDランナーや開発ツールは実行中に一部の機密情報をメモリに一時保存します。攻撃者は、Linux、Windows、macOSの3つのプラットフォーム向けにメモリ読み取りスクリプトを組み込み、さまざまなシステム上でプロセスメモリからこれらの一時的なシークレットを可能な限り取得することを目的としています。

永続化設定:

この種のリソースは「バックドアトリガー」を残すために使用されます。つまり、最初のnpmインストールプロセスが終了した後でも、攻撃者は開発者が後でプロジェクトを開いたり、エディタを起動したり、Claude Codeセッションに入ったり、システムを再ログインした際に悪意のあるコードが再実行されることを望んでいます。そのため、これらのリソースはプロジェクトレベルの設定とユーザーレベルの自動起動メカニズムをそれぞれ標的にしています。プロジェクトレベルの設定はより隠蔽性が高く、システムレベルのサービスは長期的な実行に適しています。

C2 と拡散:

これらの埋め込みリソースは、後続のコントロールリンクとリポジトリシークレットの転送に使用されます。YZを復号すると、GitHubコミット検索モニターとなり、firedalazer . 形式のコミットメッセージを定期的に検索し、署名を検証した後、リモートのPythonコンテンツをダウンロードして実行します。zZを復号すると、「Run Copilot」という名前のGitHub Actionsワークフローテンプレートとなり、${{ toJSON(secrets) }} を format-results.txt に書き込み、アーティファクトとしてアップロードします。前者は後続タスクの取得/実行リンクを提供し、後者はGitHub Actionsアーティファクトを通じてリポジトリシークレットを転送するテンプレートを提供します。実際のワークフローインジェクション、実行待ち、アーティファクトダウンロードは、メインペイロードに含まれる対応するGitHub APIロジックによって実行されます。

主要悪意のあるペイロード機能分析

複数のデコンフリケーションステップを完了した後、サンプルが最終的に放出して実行するのはコアのマルウェアペイロードである。以下すべての分析は、コアのマルウェアペイロードモジュールを対象とし、データ取得、外部送信、拡散、永続化、対抗の5つの段階に分けて解説する。

1.GitHub Actions Runner のメモリ読み取り:

サンプルには、Linux、Windows、macOSの3つのプラットフォーム向けのメモリ読み取りスクリプトが組み込まれており、クロスプラットフォームでのダンプ機能を備えています。Linux版は、対象プロセスの/proc//mapsおよび/proc//memを読み取ることでメモリを抽出します:

核心悪意のあるペイロードのアクティブなトリガー論理は、GitHub Actions Linuxランナーを対象としている:GITHUB_ACTIONS === "true" かつ RUNNER_OS === "Linux" の場合、コードはRunner.Workerプロセスを検索し、メモリをダンプした後、ダンプから"":{"value":"","isSecret":true}形式のマスクされたシークレットを抽出する。3つのサンプルにおいて確認されたアクティブな収集パスはLinuxランナーに集中しているが、3つのプラットフォーム用スクリプトはすべて埋め込まれている。

2. 曇りと開発者のローカル資格情報収集:

主要悪意のあるペイロードには、クラウドプロバイダー、CI環境、開発者ローカル設定、GitHub CLI、パスワードマネージャー、ウォレットファイルをカバーする体系的な資格情報収集モジュールが含まれています。

クラウドプロバイダーの資格情報収集目標は以下の通りです:

AWSモジュールには、ECS/IMDS(インスタンスメタデータサービス)/STS WebIdentity関連のロジックも含まれています。

開発者のローカル資格情報収集は以下のターゲットをカバーします:

パスワードマネージャーのロジックは、シェル文字列の連結ではなく、ソースコード内で runCommand(command, args) 配列形式で実装されています。

上記の証拠収集モジュールは、クラウドプラットフォームから開発者のローカル環境までの広範なターゲットをカバーしており、収集された機密データは以下のメカニズムを通じて外部に送信されます。

3.GitHub API 外伝とデッドドロップ:

主要な悪意のあるペイロードは、GitHub APIを主要なデータ漏洩チャネルとして使用します。リクエストはUser-Agentをpython-requests/2.31.0と偽装し、x-oauth-scopes(repo、public_repo、またはworkflowを含む必要あり)を検証した後、データ漏洩操作を実行します:リポジトリを作成(descriptionは固定でMiasma: The Spreading Blight)、窃取したデータをbase64でエンコードし、PUT /repos///contents/results/を通じて書き込みます。

また、ペイロードはGitHubのコミット検索に基づくdead-dropメカニズムを実装しており、マーカー「thebeautifulmarchoftime」(または「thebeautifulsnadsoftime」)を検索してC2コマンドを取得します:

const result = await X9("thebeautifulmarchoftime ", xZ);

埋め込みリソース YZ.bin は、3600秒間隔で firedalazer . の形式のコミットメッセージをポーリングする独立した GitHub コミットモニターであり、署名検証が成功した後、リモートの Python コンテンツをダウンロードして実行します。これは、メインの外伝チャネルとは独立した後続制御チャネルを構成します。

ソースコードには、api.anthropic.com および v1/api をエンドポイントとする HTTP POST センダー構成が含まれています。この構成の noop フィールドは true に設定されており、外部によって変更されない限り、このセンダーは実際のネットワークリクエストを発行しません。したがって、静的解析ではこのコード構造の存在を確認できますが、アクティブな Anthropic API の外部送信行為は証明できません。

4. GitHubリポジトリとワークフローの感染:

主要な悪意のあるペイロードは、GitHub REST / GraphQL API を使用してリポジトリのGitオブジェクトを操作できます。

リリースを名目とした悪意のあるワークフローが、id-token: write 権限を要求し、OIDC(OpenID Connect)経由で npm リリーストークンを取得します。OIDC 経路の環境変数とインターフェースは ACTIONS_ID_TOKEN_REQUEST_TOKEN、ACTIONS_ID_TOKEN_REQUEST_URL であり、audience は npm:registry.npmjs.org に設定されています。ソースコードレベルで、このペイロードが GitHub リポジトリにワークフローを注入し、OIDC / npm 信頼されたパブリッシングを利用してリリース権限を取得する能力を持つことが確認できます。

上記のgit refsを通じてワークフローを注入する方法に加え、ペイロードはより隠蔽されたシークレットの転送メカニズムも組み込んでいます。Copilotを実行するふりをしたGitHub Actionsワークフローが${{ toJSON(secrets) }}をformat-results.txtに書き込み、アーティファクトとしてアップロードします。シークレットをリポジトリのコンテンツに直接書き込む方法と比較して、この方法はワークフロー実行結果を通じてデータを転送する傾向があり、通常のコード差分レビューでは最終的にエクスポートされたシークレットの内容が直接確認されにくいです。

5. アーティファクトを通じてシークレットを搬送してCopilotワークフローを実行する:

埋め込みリソース zZ.bin は、Copilot に偽装した GitHub Actions ワークフローで、${{ toJSON(secrets) }} を format-results.txt に書き込み、アーティファクトとしてアップロードします。

対応するGitHub APIの動作には、一時ブランチの作成/更新→ワークフローブロブの書き込み→ワークフローランの待機→アーティファクトZIPのダウンロード→format-results.txtの読み取り→ワークフローランおよび一時ブランチの削除が含まれます。関連するハンティングキーワードには、Run Copilot、VARIABLE_STORE、format-results、chore/add-codeql-static-analysis、.github/workflows/codeql.ymlが含まれます。

6. npm 自己伝播:

主要恶意ペイロードは、2つの独立したnpm公開/拡散パスを備えています。

npmトークンのパス: GET /-/npm/v1/tokens を使用して、現在のユーザーのnpmトークンを列挙し、bypass_2fa === true かつパッケージ書き込み権限を持つトークンをフィルタリングして、これらのトークンを利用して自動公開を実現します。bypass_2faはトークンのメタデータフィールドであり、publishボディパラメータではありません。

GitHub Actions OIDC パス: ACTIONS_ID_TOKEN_REQUEST_TOKEN および ACTIONS_ID_TOKEN_REQUEST_URL 環境変数を読み取り、audience が npm:registry.npmjs.org である OIDC トークンを要求し、npm OIDC トークン交換インターフェースを通じて公開権限を取得します。

汚染対象のtarballの操作手順は、展開 → 悪意のあるindex.jsを書き込む → package.jsonを変更する:

ここでは2つのエントリーポイントを区別します。3つのローカルアップロードサンプル自身が preinstall: "node index.js" を使用する場合、環境のインストール前にBunを事前にインストールする必要はなく、Node.jsを初期エントリーポイントとして使用することでより隠蔽性が高まります。一方、他のパッケージを自己伝播して汚染する場合は、preinstall: "bun run index.js" を書き込み、bun依存関係を追加します。これは、核心的な悪意のあるペイロードの後続ロジックがBunランタイムが提供するAPI(Bun.gunzipSyncやBun.fileなど)に依存しているため、自己伝播シナリオではターゲット環境にBunが既に備わっていることを確実にする必要があります。

7. パーシステンスメカニズム:

主要な悪意のあるペイロードは、プロジェクトディレクトリとシステムレベルの自動起動をカバーする4つの永続化手法を含みます。

Claude Code セッション開始フック:S8.bin リソースを .claude/settings.json に埋め込み、Claude Code セッションが起動するたびに自動的に node .claude/setup.mjs を実行します。悪意のあるペイロードは、.claude/setup.mjs と .claude/index.js(パスは ".claude/" + M0 で結合、M0 = "index.js")に同時に書き込まれます。

VS Code folderOpen タスク: 埋め込みリソース EZ.bin を使用して folderOpen タスクを .vscode/tasks.json に書き込み、感染したプロジェクトフォルダーを開くときに同じスクリプトを自動実行します。同時に .vscode/setup.mjs も書き込みます。

kitty-monitor(systemd / LaunchAgent): 埋め込まれたリソース RZ.bin を使用して永続化サービスをインストールし、ファイルは /.local/share/kitty/cat.py、/.config/systemd/user/kitty-monitor.service(Linux)および ~/Library/LaunchAgents/com.user.kitty-monitor.plist(macOS)に分散している。悪意のあるペイロードは /tmp/kitty- ディレクトリを作成し、YZ.bin(GitHub commit monitor)を cat.py に書き込んだ後、RZ.bin を通じてインストールする。

gh-token-monitor(systemd / LaunchAgent): 埋め込まれたリソース jZ.bin を使用して GitHub トークン監視サービスをインストールし、ファイルは /.local/bin/gh-token-monitor.sh、/.config/gh-token-monitor/ ディレクトリおよび対応する systemd / LaunchAgent パスに配置されます。このモニターは、GitHub トークンが 40x ステータスコードを返すかどうか、および npm パッケージ @cap-js/openapi@1.4.1 のメタデータに異常があるかどうかを検出し、トリガーされた場合にハンドラーを実行します。

これにより、monitor が GitHub API から 40x ステータスコード(例:トークンが取り消された、無効化された、または権限状態が異常である場合)を検出すると、悪意のあるスクリプトが渡されたハンドラーを実行します。本記事で分析された3つのサンプルから復元されたハンドラーは、rm -rf ~/; rm -rf ~/Documents です。ペイロードがまだ実行されている可能性のあるホスト上でトークンを直接取り消すのではなく、まずホストを隔離し、永続化要素と実行中のプロセスを削除した後、クリーンな環境で資格情報をローテーションする必要があります。

8. Harden-Runner / StepSecurity 対抗:

主要な悪意のあるペイロードには、StepSecurity Harden-Runner を検出し破壊するロジックが組み込まれており、以下の手順でCI/CD保護を回避します:

  1. Dockerソケット/var/run/docker.sockが利用可能かどうかを検出する;
  2. Dockerコンテナを列挙し、名前またはイメージにharden-runner / stepsecurityというキーワードを含むものを抽出する;
  3. POST /containers//kill で一致するコンテナを終了します;
  4. privileged alpine コンテナを作成し、sudoers を runner ALL=(ALL) NOPASSWD:ALL に書き換える;
  5. /etc/hosts に StepSecurity 関連のドメインの無効なレコードを書き込む;
  6. /etc/resolv.conf を 8.8.8.8 と 1.1.1.1 で上書きしてください。

この対抗ロジックは、サンプルがStepSecurityで保護されたCI/CD環境に特化して調整されていることを示しています。

9. EDR / セキュリティ製品の検出、環境判断および回避:

主要な悪意のあるペイロードは、複数のEDR(エンドポイント検出と対応)/セキュリティ製品のプロセス名とインストールパスを検出します:

ロードには地域回避ロジックも含まれています:LC_ALL、LC_MESSAGES、LANGUAGE、LANG の環境変数を検出し、小文字に変換した後に ru で始まる場合は実行をスキップします。CI 環境の認識は GitHub Actions、GitLab CI、Travis CI、CircleCI、Jenkins、AWS CodeBuild、Buildkite、AppVeyor、Bitbucket、Drone、TeamCity、Cirrus CI などをサポートしています。実行中に使用されるステータスマーカーには tmp.0987654321.lock、__IS_DAEMON(detached daemon サブプロセスを示す)、SKIP_DOMAIN(domain sender パスをスキップ)、/tmp/kitty-*、cat.py、/var/tmp/.gh_update_state が含まれます。

影響分析

ソースコードの能力から見ると、これらのサンプルの影響はnpmインストール段階での一回限りの実行にとどまらない。その実際のリスクは4段階に分けられる:

開発者ホストレベル。サンプルは環境変数、.npmrc、.pypirc、SSHキー、Docker設定、.env、GitHub CLIトークン、パスワードマネージャーデータ、ウォレットファイルを収集し、Claude Code、VS Code、systemdユーザーサービス、またはmacOS LaunchAgentを通じて継続的なトリガー機能を維持します。

CI/CDランナー層。サンプルはGitHub Actions Linuxランナーを識別し、Runner.Workerプロセスのメモリを読み取ってマスクされたシークレットを抽出する。また、StepSecurity Harden-Runnerの対抗ロジックを備えており、CI/CD保護コンポーネントの破壊または回避を試みる。

GitHubの組織レベルおよびリポジトリレベル。サンプルはGitHub APIを使用してリポジトリを作成し、contents/results/に書き込み、git refs/blobs/trees/commitsを操作し、悪意のあるワークフローを注入し、Run Copilot workflow + artifactを通じてシークレットを転送できる。

npmエコシステムの拡散層。サンプルは、package書き込み権限を持ち、bypass_2fa === true のnpmトークンをフィルタリング可能であり、GitHub Actions OIDC / npm信頼されたパブリッシングパスを用いて公開権限を取得することもできる。その後、対象のtarballをダウンロードし、悪意のあるローダーを書き込み、preinstallを変更し、Bun依存関係を追加してパッチバージョンを昇格させ、公開することで、npm内での自己増殖チェーンを形成する。

要約

3つのサンプルのソースコード証拠によると、今回の悪意のあるパッケージは単なるインストール時の情報窃取スクリプトではなく、多段階のローダーと完全なインプラントの組み合わせである。外層はパッケージごとにランダム化され、Bunランタイムガイドとコア悪意のあるペイロードは一貫している。メインインプラントは、資格情報収集、CIシークレットの抽出、GitHub/npmでの拡散、永続化、および防御回避の複数の段階をカバーしている。

高隠蔽性のエントリーポイント設計。攻撃者は業務コードに悪意のあるロジックを埋め込むのではなく、npmライフサイクルスクリプトに混淆ローダーを埋め込む。このローダーは、組み込まれたペイロードを復号して実行することを主な目的としており、業務ソースコードのレビューだけでは真の機能を発見するのが難しい。

多重ネストされたデオブファスケーションチェーン。悪意のあるペイロードは、数字配列+ROT文字置換、AES-128-GCM暗号化、obfuscator.ioによる混淆、B5独自文字列暗号化、AES-256-GCM+gzipの埋め込み層という合計5層でラッピングされている。各層の鍵またはパラメータは、異なるパッケージで独立して変更可能であり、静的特徴に基づく一括検出をより困難にしている。

完全な組織レベルの攻撃能力。このインプラントは、GitHub Actions Runnerのメモリ読み取り、マルチクラウドおよびローカル資格情報の収集、GitHub APIを介したデータ転送とデッドドロップ、GitHubリポジトリおよびワークフローの感染、npmによる自己増殖、永続化、および防衛回避機能を備えている。ソースコードの構造から、これは単一ポイントのインストールをトリガーとして、リポジトリ、CI/CD、npm公開チェーンへの拡散を可能にするコードパスを既に有している。実際の拡散範囲は、インストールログ、リポジトリ監査、およびプラットフォーム側のテレメトリーを組み合わせて確認する必要がある。

ソースコードの証拠から確認できるのは、3つのサンプルすべてがpreinstallを通じて自動的にトリガーされ、同じメインimplantを復号して実行しているということである。実際のイベントにおいて初期権限がどのように取得されたかについては、この3つのtgzサンプルのみでは証明できない。

対応案

  1. プロジェクトの依存関係、lockfile、プライベートレジストリキャッシュ、およびビルドキャッシュ内で悪意のあるバージョンを特定して削除してください。
  2. インストールログに preinstall、node index.js、bun run、/tmp/p*.js、tmp.0987654321.lock が含まれているか確認してください。
  3. ペイロードがまだ実行されている可能性のある被害ホスト上で直接トークンを無効化しないでください。まず被害ホストを隔離し、実行中のプロセスと永続化項目をクリーンアップした後、クリーンな環境からGitHub、npm、クラウド資格情報、Kubernetes、Vault、SSH、Dockerレジストリ、パスワードマネージャー関連のトークンをローテーションしてください。
  4. GitHubリポジトリの最近のブランチ、コミット、ワークフロー、アーティファクト、および新規リポジトリを確認し、Run Copilot、format-results、chore/add-codeql-static-analysis、.github/workflows/codeql.yml、OIDC_PACKAGESなどのキーワードに注目してください。
  5. プロジェクトディレクトリに新しいファイルが追加されたか、変更があったかを確認してください:.claude/settings.json、.claude/setup.mjs、.vscode/tasks.json、.vscode/setup.mjs。
  6. ユーザーレベルの永続化を確認:/.local/share/kitty/cat.py、/.config/systemd/user/kitty-monitor.service、~/Library/LaunchAgents/com.user.kitty-monitor.plist、gh-token-monitor 関連ファイル。
  7. npm publish 履歴を確認し、無許可のパッチバージョンの公開が存在するかを確認する。同時に、npm トークンのメタデータを監査し、2FA(2段階認証)をバイパスでき、パッケージ書き込み権限を持つトークンに注目する。
  8. 汚染された環境で構築されたダウンストリームアーティファクトの整合性監査を行います。

IOC

悪意のあるファイル

ファイル名: redhat-cloud-services-frontend-components-config-6.11.3.tgz MD5: 633ad8849a59e2bfb7a0fe589e816a07 SHA1: 675294612f455fe6a9acb195f0cbe3687d8e2e34 SHA256: 0c9c67ec40d5f23efa1ec3470d0ac88b4993ccc0e92be913fc29a337dfc4f060

ファイル名: redhat-cloud-services-types-3.6.1.tgz MD5: 9e6c5af01438b52c9a411686c1f1b8ff SHA1: 88d098c8d96e9ae17550e9798c3b62c420464b8c SHA256: d543bb3cdf1569c2b3d38c8a4081ed746cfe78bf3236c2302704d79ab7fa9558

ファイル名: redhat-cloud-services-rule-components-4.7.2.tgz MD5: f1ffdbf5e639899f26a6ebab2eec408d SHA1: f3c5c21274045ae02fef11e931de6dcf8462a067 SHA256: aaf00d06baa3c679b82452c50014e9824b8874e9ca2d150f19095f8de19ba90f

SHA256

ac2a2208e1726e008be6c73dc0872d9bba163319259dff1b62055ac933ca46b6

0dc06ecdaa63fe24859cfd955053c23245c536e4733480239d14bebf12688e35

悪意のある依存

npm:@redhat-cloud-services/topological-inventory-client@3.0.10

npm:@redhat-cloud-services/topological-inventory-client@3.0.11

npm:@redhat-cloud-services/topological-inventory-client@3.0.13

npm:@redhat-cloud-services/compliance-client@4.0.3

npm:@redhat-cloud-services/compliance-client@4.0.4

npm:@redhat-cloud-services/compliance-client@4.0.6

npm:@redhat-cloud-services/rbac-client@9.0.3

npm:@redhat-cloud-services/rbac-client@9.0.4

npm:@redhat-cloud-services/rbac-client@9.0.6

npm:@redhat-cloud-services/insights-client@4.0.4

npm:@redhat-cloud-services/insights-client@4.0.5

npm:@redhat-cloud-services/insights-client@4.0.7

npm:@redhat-cloud-services/frontend-components@7.7.2

npm:@redhat-cloud-services/frontend-components@7.7.3

npm:@redhat-cloud-services/frontend-components@7.7.5

npm:@redhat-cloud-services/frontend-components-utilities@7.4.1

npm:@redhat-cloud-services/frontend-components-utilities@7.4.2

npm:@redhat-cloud-services/frontend-components-utilities@7.4.4

npm:@redhat-cloud-services/remediations-client@4.0.4

npm:@redhat-cloud-services/remediations-client@4.0.5

npm:@redhat-cloud-services/remediations-client@4.0.7

npm:@redhat-cloud-services/frontend-components-notifications@6.9.2

npm:@redhat-cloud-services/frontend-components-notifications@6.9.3

npm:@redhat-cloud-services/frontend-components-notifications@6.9.5

npm:@redhat-cloud-services/patch-client@4.0.4

npm:@redhat-cloud-services/patch-client@4.0.5

npm:@redhat-cloud-services/patch-client@4.0.7

npm:@redhat-cloud-services/host-inventory-client@5.0.3

npm:@redhat-cloud-services/host-inventory-client@5.0.4

npm:@redhat-cloud-services/host-inventory-client@5.0.6

npm:@redhat-cloud-services/rule-components@4.7.2

npm:@redhat-cloud-services/rule-components@4.7.3

npm:@redhat-cloud-services/rule-components@4.7.5

npm:@redhat-cloud-services/frontend-components-advisor-components@3.8.2

npm:@redhat-cloud-services/frontend-components-advisor-components@3.8.4

npm:@redhat-cloud-services/frontend-components-advisor-components@3.8.6

npm:@redhat-cloud-services/notifications-client@6.1.4

npm:@redhat-cloud-services/notifications-client@6.1.5

npm:@redhat-cloud-services/notifications-client@6.1.7

npm:@redhat-cloud-services/sources-client@3.0.10

npm:@redhat-cloud-services/sources-client@3.0.11

npm:@redhat-cloud-services/sources-client@3.0.13

npm:@redhat-cloud-services/integrations-client@6.0.4

npm:@redhat-cloud-services/integrations-client@6.0.5

npm:@redhat-cloud-services/integrations-client@6.0.7

npm:@redhat-cloud-services/frontend-components-config@6.11.3

npm:@redhat-cloud-services/frontend-components-config@6.11.4

npm:@redhat-cloud-services/frontend-components-config@6.11.6

npm:@redhat-cloud-services/frontend-components-config-utilities@4.11.2

npm:@redhat-cloud-services/frontend-components-config-utilities@4.11.3

npm:@redhat-cloud-services/frontend-components-config-utilities@4.11.5

npm:@redhat-cloud-services/hcc-pf-mcp@0.6.1

npm:@redhat-cloud-services/hcc-pf-mcp@0.6.2

npm:@redhat-cloud-services/hcc-pf-mcp@0.6.4

npm:@redhat-cloud-services/frontend-components-remediations@4.9.2

npm:@redhat-cloud-services/frontend-components-remediations@4.9.3

npm:@redhat-cloud-services/frontend-components-remediations@4.9.5

npm:@redhat-cloud-services/eslint-config-redhat-cloud-services@3.2.1

npm:@redhat-cloud-services/eslint-config-redhat-cloud-services@3.2.2

npm:@redhat-cloud-services/eslint-config-redhat-cloud-services@3.2.4

npm:@redhat-cloud-services/javascript-clients-shared@2.0.8

npm:@redhat-cloud-services/javascript-clients-shared@2.0.9

npm:@redhat-cloud-services/javascript-clients-shared@2.0.11

npm:@redhat-cloud-services/quickstarts-client@4.0.11

npm:@redhat-cloud-services/quickstarts-client@4.0.12

npm:@redhat-cloud-services/quickstarts-client@4.0.14

npm:@redhat-cloud-services/config-manager-client@5.0.4

npm:@redhat-cloud-services/config-manager-client@5.0.5

npm:@redhat-cloud-services/config-manager-client@5.0.7

npm:@redhat-cloud-services/hcc-feo-mcp@0.3.1

npm:@redhat-cloud-services/hcc-feo-mcp@0.3.2

npm:@redhat-cloud-services/hcc-feo-mcp@0.3.4

npm:@redhat-cloud-services/entitlements-client@4.0.11

npm:@redhat-cloud-services/entitlements-client@4.0.12

npm:@redhat-cloud-services/entitlements-client@4.0.14

npm:@redhat-cloud-services/tsc-transform-imports@1.2.2

npm:@redhat-cloud-services/tsc-transform-imports@1.2.4

npm:@redhat-cloud-services/tsc-transform-imports@1.2.6

npm:@redhat-cloud-services/hcc-kessel-mcp@0.3.1

npm:@redhat-cloud-services/hcc-kessel-mcp@0.3.2

npm:@redhat-cloud-services/hcc-kessel-mcp@0.3.4

npm:@redhat-cloud-services/frontend-components-testing@1.2.1

npm:@redhat-cloud-services/frontend-components-testing@1.2.2

npm:@redhat-cloud-services/frontend-components-testing@1.2.4

npm:@redhat-cloud-services/types@3.6.1

npm:@redhat-cloud-services/types@3.6.2

npm:@redhat-cloud-services/types@3.6.4

npm:@redhat-cloud-services/chrome@2.3.1

npm:@redhat-cloud-services/chrome@2.3.2

npm:@redhat-cloud-services/chrome@2.3.4

npm:@redhat-cloud-services/frontend-components-translations@4.4.1

npm:@redhat-cloud-services/frontend-components-translations@4.4.2

npm:@redhat-cloud-services/frontend-components-translations@4.4.4

npm:@redhat-cloud-services/vulnerabilities-client@2.1.8

npm:@redhat-cloud-services/vulnerabilities-client@2.1.9

npm:@redhat-cloud-services/vulnerabilities-client@2.1.11

免責事項: 本ページの情報はサードパーティからのものであり、必ずしもKuCoinの見解や意見を反映しているわけではありません。この内容は一般的な情報提供のみを目的として提供されており、いかなる種類の表明や保証もなく、金融または投資助言として解釈されるものでもありません。KuCoinは誤記や脱落、またはこの情報の使用に起因するいかなる結果に対しても責任を負いません。 デジタル資産への投資にはリスクが伴います。商品のリスクとリスク許容度をご自身の財務状況に基づいて慎重に評価してください。詳しくは利用規約およびリスク開示を参照してください。