背景

近日，MistEye 安全監控系統捕獲到關於 Red Hat Cloud Services 組織下多款 npm 包出現異常版本的情報。本次事件共涉及該組織下 32 個 npm 包、96 個版本。本文選取其中 3 個本地樣本進行深入離線分析：這些樣本並非仿冒命名空間或 typo-squatting 包，而是使用 @redhat-cloud-services scope 的真實包版本；從樣本原始碼可以確認，其 tarball 中被植入了會在安裝階段自動觸發的多層混淆惡意 loader。

完整還原後可以確認：這 3 個樣本的核心載荷具備 GitHub Actions Runner 記憶體讀取、多雲與本地憑證採集、GitHub API 外傳與 dead-drop、GitHub workflow 注入、npm 自傳播、Claude Code / VS Code / systemd / LaunchAgent 持久化、Harden-Runner / StepSecurity 對抗、EDR / 安全產品探測等源碼能力。從能力覆蓋面看，潛在影響對象包括開發者主機、CI/CD Runner、構建容器、GitHub 倉庫、GitHub Actions workflow、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

三個樣本的攻擊入口完全一致：package.json 中均存在 scripts.preinstall = "node index.js"。這意味著只要開發者主機或 CI/CD 環境安裝到這些版本，根目錄 index.js 就會在安裝階段被自動執行，無需用戶顯式 import 或運行業務代碼。

三個樣本共享同一個核心惡意載荷，但外層包裝參數不同。也就是說，三個樣本使用了不同的 ROT/Caesar 位移值和 AES-GCM key / iv / tag；這會使基於外層包裝 hash、固定 key 或固定 shift 的靜態特徵難以直接跨包複用。但解密後的 Bun 運行環境引導器與核心惡意載荷 hash 完全一致：一個是用於準備 Bun 運行環境的啟動輔助模組，另一個是真正包含惡意功能的核心載荷。本文將兩者分別稱為 "Bun 運行環境引導器（源碼變量名 _b）" 和 "核心惡意載荷（源碼變量名 _p）"。

還原後的攻擊鏈如下：

技術分析

三個樣本均透過 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 字段，因此不將該異常泛化至所有樣本。

三個樣本的根目錄 index.js 都是超大的單行 JavaScript 檔案，結構一致，主體為 try { eval(...) } catch (...) 包裝器：

該包裝器先使用 String.fromCharCode 將巨大的數字陣列還原為字串，再對字串中的英文字母執行 ROT/Caesar 位移，最後將解碼結果交給 eval 執行。異常處理僅輸出 wrapper: 前綴，以降低安裝失敗時的顯著異常暴露。

三個樣本的外層位移值和 Stage 2 hash 如下：

frontend-components-config@6.11.3

index.js 大小：4,294,798 bytes

ROT/Caesar 位移：10

第二階段 SHA-256：b19c2fd48535c8c40aeb3e627ce92775f33ef9292611767bb1236c238e6f90cc

types@3.6.1

index.js 大小：4,135,588 bytes

ROT/凱撒移位：4

第二階段 SHA-256：9c0425aa6e6d7792ac38d24f3e7245f42fcaa553ddfeb6bd97677017f10c3b75

rule-components@4.7.2

index.js 大小：4,294,336 bytes

ROT/凱撒移位：11

第二階段 SHA-256：d590bd375d95e4ac072b7ebc1fc4489bcaf5f20a939e92486267aa398bcf1e5d

ROT/Caesar 解碼後的 Stage 2 代碼使用 Node.js crypto.createDecipheriv 執行 AES-128-GCM（Advanced Encryption Standard - Galois/Counter Mode）解密，並通過 setAuthTag 設置認證標籤。解密目標為兩個後續組件——Bun 運行環境引導器與核心惡意載荷。

其中，Bun 運行環境引導器負責檢測、定位或準備 Bun 運行環境，使後續代碼能夠通過 Bun 執行；核心惡意載荷則是攻擊鏈的主體，包含後續憑證採集、GitHub/npm 傳播、持久化、防護對抗和嵌入資源解密等主要惡意能力。

三份樣本分別使用不同的 AES-128-GCM 密鑰、初始向量和認證標籤來加密這兩個組件，但解密後三份 Bun 運行環境引導器的 SHA-256 均為 ac2a2208e1726e008be6c73dc0872d9bba163319259dff1b62055ac933ca46b6，三份核心惡意載荷的 SHA-256 均為 0dc06ecdaa63fe24859cfd955053c23245c536e4733480239d14bebf12688e35。這表明攻擊者在不同的 npm 套件中更換了外層包裝參數，但重複使用了同一套核心惡意組件。

解密後，Stage 2 會將核心惡意載荷寫入 /tmp，再透過 Bun 執行，最後刪除暫存檔案。三份樣本還原出的實際邏輯如下：

因此，三份樣本中可驗證的暫存檔案模式是：

/tmp/p.js

Bun 運行環境引導器大小為 898 bytes，三個樣本 hash 完全一致：

ac2a2208e1726e008be6c73dc0872d9bba163319259dff1b62055ac933ca46b6

Bun 運行環境引導器包含 child_process.execSync、fs.existsSync、fs.mkdtempSync、fs.chmodSync、os.platform()、os.arch()、getBunPath() 等邏輯，用於定位或準備 Bun 運行環境。也就是說，Stage 2 並非簡單假設系統已安裝全域 Bun；在非 Bun 運行時路徑中，它會先載入 Bun 運行環境引導器，再透過 getBunPath() 呼叫 Bun 執行核心惡意載荷。

解密出的核心惡意載荷並非可直接閱讀的明文 JavaScript，而是繼續經過 obfuscator.io 風格的字串表混淆。這一層會將大量字串集中放入陣列，並透過執行時索引與 rotation 邏輯還原，導致分析人員在未完成字串表還原前，無法直接檢索到後續關鍵 API、路徑和配置名。

還原 obfuscator.io 字符串表後，核心惡意載荷內仍存在一層 B5 自定義字符串加密。已確認參數如下：

• KDF：PBKDF2（Password-Based Key Derivation Function 2）
• 哈希函數：SHA-256
• 迭代次數：200000
• 密鑰長度：32 個位元組
• 解密輪數：3
• 密碼：ba2c6ddb3672bdd6a611e6850b4f700b52aed3dab2f1b3d5f8c839d4a157a709
• salt：5b26508dc0f1075a7c0b4d8aa464487e

解密後結果如下：

其中，B5 解密後可見多類關鍵明文字串。需要注意，部分字串原本位於 obfuscator.io 字串表中，只有在「字串表替換 + B5 解密」兩步都完成後才會直接可 grep：

核心惡意載荷內部還包含使用 AES-256-GCM 加密並 gzip 壓縮的嵌入資源。還原邏輯使用：

已解出的關鍵嵌入資源按功能分為三類：

跨平台記憶體讀取：

此類資源用於讀取正在運行的進程內存。普通文件中的密鑰和 token 可通過查閱文件發現，但 CI/CD Runner 或開發工具在運行時會將一些敏感值暫存於內存中。攻擊者嵌入了適用於 Linux、Windows 和 macOS 三個平台的內存讀取腳本，目的是在不同系統上盡可能從進程內存中抓取這些臨時出現的 secret。

持久化設定：

此類資源用於「留下後門觸發點」。也就是說，即使最初的 npm 安裝過程已經結束，攻擊者仍希望惡意代碼能在開發者後續打開項目、啟動編輯器、進入 Claude Code 會話，或系統重新登入後再次運行。因此，這些資源分別針對項目級配置和用戶級自啟動機制：項目級配置更隱蔽，系統級服務更適合長期運行。

C2 與傳播：

此類嵌入資源用於後續控制鏈路與倉庫 secrets 的搬運。YZ 解密後為 GitHub commit search monitor，會週期性搜尋 firedalazer . 格式的 commit message，驗證簽名後下載並執行遠端 Python 內容；zZ 解密後為一段名為 Run Copilot 的 GitHub Actions workflow 模板，會將 ${{ toJSON(secrets) }} 寫入 format-results.txt 並上傳為 artifact。前者提供後續任務獲取/執行鏈路，後者提供藉由 GitHub Actions artifact 搬運 repository secrets 的模板；實際的 workflow 注入、運行等待與 artifact 下載由主載荷中的配套 GitHub API 邏輯完成。

核心惡意載荷能力分析

在完成多層解混淆後，樣本最終釋放並執行的是核心惡意載荷。以下所有分析均針對核心惡意載荷模組展開，按資料獲取、外傳、傳播、持久化、對抗五個環節逐一拆解。

樣本嵌入了 Linux、Windows、macOS 三個平台的記憶體讀取腳本，具備跨平台 dump 能力。其中 Linux 實現透過讀取目標進程的 /proc//maps 與 /proc//mem 完成記憶體抽取：

主動觸發核心惡意載荷的邏輯針對 GitHub Actions Linux runner：當 GITHUB_ACTIONS === "true" 且 RUNNER_OS === "Linux" 時，代碼會查找 Runner.Worker 進程並轉儲記憶體，隨後從轉儲資料中提取格式為 "":{"value":"","isSecret":true} 的 masked secrets。三份樣本中可確認的主動採集路徑集中於 Linux runner，但三種平台的腳本均已嵌入。

核心惡意載荷包含系統化的憑證採集模組，涵蓋雲廠商、CI 環境、開發者本地配置、GitHub CLI、密碼管理器和錢包文件。

雲廠商憑證採集目標如下：

AWS 模組還包含 ECS / IMDS（Instance Metadata Service）/ STS WebIdentity 相關邏輯。

開發者本地憑證收集涵蓋以下目標：

密碼管理器的邏輯在原始碼中以 runCommand(command, args) 數組形式實現，而非 shell 字符串拼接。

上述憑證採集模組涵蓋了從雲平台到開發者本地的廣泛目標；採集到的敏感資料透過以下機制外傳。

核心惡意載荷以 GitHub API 作為主要資料外傳通道。請求偽裝 User-Agent 為 python-requests/2.31.0，通過驗證 token 的 x-oauth-scopes（需包含 repo、public_repo 或 workflow）後執行外傳操作：建立 repository（description 固定為 Miasma: The Spreading Blight），將竊取資料經 base64 編碼後透過 PUT /repos///contents/results/ 寫入。

此外，載荷實現了基於 GitHub commit 搜尋的 dead-drop 機制，透過搜尋 marker "thebeautifulmarchoftime "（或 "thebeautifulsnadsoftime"）獲取 C2 指令：

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

嵌入資源 YZ.bin 是一個獨立的 GitHub commit 監控器，以 3600 秒為間隔輪詢搜索 firedalazer . 格式的 commit message，簽名校驗通過後下載並執行遠端 Python 內容。這構成了一條獨立於主外傳通道的後續控制鏈路。

源碼中還包含一個以 api.anthropic.com 和 v1/api 為目標端點的 HTTP POST sender 配置體。該配置體的 noop 字段被設為 true，意味著在未被外部修改的情況下，該 sender 不會發起實際網絡請求。因此，靜態分析只能確認該代碼結構存在，無法證明存在活躍的 Anthropic API 外傳行為。

核心惡意載荷可透過 GitHub REST / GraphQL API 操作倉庫的 git 物件：

以 release 為名的惡意工作流程，請求 id-token: write 權限，透過 OIDC（OpenID Connect）路徑交換 npm 發布 token。OIDC 路徑的環境變數與介面為 ACTIONS_ID_TOKEN_REQUEST_TOKEN、ACTIONS_ID_TOKEN_REQUEST_URL，audience 設定為 npm:registry.npmjs.org。從原始碼層面可確認 payload 具備向 GitHub 倉庫注入工作流程、利用 OIDC / npm 受信發佈獲取發布權限的能力。

除了上述通過 git refs 注入 workflow 的方式外，載荷還嵌入了一套更隱蔽的 secrets 搬運機制：偽裝成 Run Copilot 的 GitHub Actions workflow 會將 ${{ toJSON(secrets) }} 寫入 format-results.txt 並上傳 artifact。與直接將 secrets 寫入倉庫內容相比，這種方式更傾向於透過 workflow 運行產物搬運資料，常規程式碼 diff 審查未必能直接看到最終導出的 secrets 內容。

嵌入資源 zZ.bin 是偽裝成 Copilot 的 GitHub Actions 工作流程，將 ${{ toJSON(secrets) }} 寫入 format-results.txt 並上傳為 artifact。

配套的 GitHub API 行為包括：建立/更新臨時 branch → 寫入 workflow blob → 等待 workflow run → 下載 artifact zip → 讀取 format-results.txt → 刪除 workflow run 和臨時 branch。相關 hunting 關鍵詞包括 Run Copilot、VARIABLE_STORE、format-results、chore/add-codeql-static-analysis、.github/workflows/codeql.yml

核心惡意載荷具備兩條獨立的 npm 發佈 / 傳播路徑。

npm token 路徑：透過 GET /-/npm/v1/tokens 列出當前使用者的 npm token，篩選 bypass_2fa === true 且具有 package write 權限的 token，並利用這些 token 實現自動化發佈。bypass_2fa 是 token metadata 欄位，而非 publish body 參數。

GitHub Actions OIDC 路徑：讀取 ACTIONS_ID_TOKEN_REQUEST_TOKEN 和 ACTIONS_ID_TOKEN_REQUEST_URL 環境變數，請求 audience 為 npm:registry.npmjs.org 的 OIDC token，透過 npm OIDC token exchange 接口換取發佈權限。

污染目標 tarball 的操作流程為解包 → 寫入惡意 index.js → 修改 package.json：

這裡區分兩類入口：三份本地上傳樣本自身使用 preinstall: "node index.js"——此時安裝環境無需預先安裝 Bun，以 Node.js 作為初始入口更隱蔽；自傳播污染其他套件時則寫入 preinstall: "bun run index.js" 並新增 bun 依賴——因為核心惡意載荷的後續邏輯依賴 Bun 運行時提供的 API（如 Bun.gunzipSync 和 Bun.file），在自傳播場景中需要確保目標環境已具備 Bun。

核心惡意載荷包含四種持久化方式，覆蓋項目目錄和系統級自啟動。

Claude Code SessionStart hook：嵌入資源 S8.bin 將 SessionStart hook 寫入 .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 token 監控服務，檔案分佈於 /.local/bin/gh-token-monitor.sh、/.config/gh-token-monitor/ 目錄及對應的 systemd / LaunchAgent 路徑。該 monitor 檢測 GitHub token 是否返回 40x 狀態碼，以及 npm 包 @cap-js/openapi@1.4.1 的 metadata 是否異常，觸發後執行 handler：

這意味著，當 monitor 檢測到 GitHub API 傳回 40x 狀態碼時，例如 token 被撤銷、失效或權限狀態異常，惡意腳本將執行傳入的 handler。本文三份樣本中還原出的 handler 為 rm -rf ~/; rm -rf ~/Documents。處理時不可直接在可能仍運行 payload 的主機上撤銷 token——應先隔離主機，清理持久化項目與運行中的進程，再從乾淨環境輪換憑證。

核心惡意載荷內置針對 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 環境進行了適配。

核心惡意載荷偵測多種 EDR（Endpoint Detection and Response）/ 安全產品的進程名和安裝路徑：

載荷還包含區域避讓邏輯：檢測 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 安裝階段的單次執行。其實際風險可分為四層：

在開發者主機層面。樣本會收集環境變數、.npmrc、.pypirc、SSH 金鑰、Docker 設定、.env、GitHub CLI 令牌、密碼管理器資料和錢包檔案，並透過 Claude Code、VS Code、systemd 使用者服務或 macOS LaunchAgent 維持後續觸發能力。

在 CI/CD Runner 層面。樣本會識別 GitHub Actions Linux runner，讀取 Runner.Worker 進程記憶體並提取已遮罩的密鑰；同時具備 StepSecurity Harden-Runner 對抗邏輯，試圖破壞或繞過 CI/CD 防護組件。

在 GitHub 組織與倉庫層面。樣本可使用 GitHub API 建立倉庫、寫入 contents/results/、操作 git refs/blobs/trees/commits、注入惡意 workflow，並透過 Run Copilot workflow + artifact 傳送 secrets。

在 npm 生態系統的傳播層面，可篩選具有 package 寫入權限且 bypass_2fa === true 的 npm token，或利用 GitHub Actions OIDC / npm 受信發布路徑獲取發布權限；隨後下載目標 tarball、寫入惡意 loader、修改 preinstall、新增 Bun 依賴、提升 patch 版本並發布，從而形成 npm 自我傳播鏈條。

總結

三份樣本的原始碼證據顯示，本次惡意套件並非簡單的安裝期竊密腳本，而是一個多階段 loader 與完整 implant 的組合：外層隨機化，Bun 運行環境引導器與核心惡性載荷保持一致；主 implant 涵蓋憑證採集、CI secret 提取、GitHub / npm 傳播、持久化與防護對抗等多個環節。

高隱蔽性的入口設計。攻擊者不在業務代碼中植入惡意邏輯，而是在 npm 生命週期腳本中掛載混淆 loader。該 loader 自身主要負責解密並執行內嵌載荷，使得僅靠業務源碼審查很難發現真實能力。

多層嵌套的解混淆鏈。惡意載荷經過數字陣列 + ROT 字母替換、AES-128-GCM 加密、obfuscator.io 混淆、B5 自研字串加密、AES-256-GCM + gzip 嵌入層，共五層包裝。每一層的密鑰或參數可在不同封包中獨立變化，使基於靜態特徵的批量檢測更加困難。

完整的組織級攻擊能力。該 implant 具備 GitHub Actions Runner 記憶體讀取、多雲與本地憑證採集、GitHub API 外傳與 dead-drop、GitHub 倉庫與 workflow 感染、npm 自傳播、持久化和防護對抗等能力。從原始碼結構看，它已具備從單點安裝觸發進一步擴散至倉庫、CI/CD 和 npm 發布鏈路的程式碼路徑；真實擴散範圍仍需結合安裝日誌、倉庫審計和平台側遙測確認。

從源碼證據可以確認：三個樣本均透過 preinstall 自動觸發，並解密執行同一主 implant。至於真實事件中初始權限如何獲得，僅憑這三份 tgz 樣本無法證明。

處置建議

1. 在專案依賴、lockfile、私有 registry 緩存和建置緩存中排查並移除惡意版本。
2. 檢查安裝日誌中是否出現 preinstall、node index.js、bun run、/tmp/p*.js、tmp.0987654321.lock。
3. 不要在仍可能運行 payload 的受影響主機上直接吊銷 token。建議先隔離受影響主機，清理正在運行的進程和持久化項目，再從乾淨環境輪換 GitHub、npm、雲端憑證、Kubernetes、Vault、SSH、Docker 倉儲、密碼管理器相關的 token。
4. 檢查 GitHub 倉儲最近的 branch、commit、workflow、artifact 和新建 repository，重點關注 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 歷史，確認是否存在未經授權的 patch 版本發布；同時審計 npm token 元資料，重點關注可繞過 2FA（Two-Factor Authentication）且具備 package write 權限的 token。
8. Conduct an integrity audit on downstream artifacts built in a contaminated environment.

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