TL博士
單一 npm 發布者， ddjidd5640，並創建了一個包含 22 個軟體包的虛假 Web3 安全工具目錄，這些工具以以下虛構品牌銷售： 加密安全協會, Web3 審計集體以及 DeFi 安全聯盟.
這些軟體包看起來不像是簡單的網域搶注活動。它們看起來像是一個品牌化的安全生態系統，背後有匹配的空 GitHub 組織和極具說服力的 MCP 工具名稱，例如： search_leaked_credentials, validate_chain_key以及 deploy_safe.
競選活動分為 兩個活躍的有效載荷系列和一個休眠批次.
變體A 包含 8 個憑證收集軟體包。安裝後腳本會讀取本地密鑰存儲，同時還捆綁了一個 scanner.js 當 AI 代理程式呼叫軟體包的 MCP 工具時運行，搜尋錢包金鑰、BIP39 助記詞、API 令牌和其他憑證。
變體 B 包含 5 個基於 Pinggy 的二進位投放器。這些軟體包會在安裝後取得並執行遠端有效載荷。 foundry-deploy-helper:1.8.96 釋放一個分離的可執行文件 /tmp/.node-cache.
變體 C 包含 9 個休眠軟體包，目前還沒有明顯的安裝後有效載荷，但具有相同的發布者、品牌模式和以 Web3 為中心的命名。
在我們能看到的地方，只有 22 個軟體包中的 8 個被標記出來；其餘 14 個在分析時仍然在 npm 上可用。
嚴重程度：危急。
攻擊：一個衣櫃裡裝著兩個有效載荷
衣櫥就是品牌。開啟 crypto-credential-scanner 的 README 文件，你會發現它是由加密安全協會 (Crypto Security Guild) 開發的憑證掃描器。打開 defi-threat-scanner 的頁面，你會發現它是 DeFi 安全聯盟 (DeFi Security Alliance) 的工具。開啟 web3-secrets-detector，你會發現它是 Web3 審計聯盟 (Web3 Audit Collective) 的產品。然而，這些聯盟都不是真正的組織。它們只是空的 GitHub 組織，存在的唯一目的就是填入 npm 頁面上的「作者」超連結。
方案 A：安裝後預檢和 MCP 時間主操作
8 個 Variant-A 軟體包都共享一個兩階段有效載荷——安裝後預檢階段，用於獲取磁碟上已有的純文字憑證；以及運行時階段，一旦 AI 代理呼叫軟體包的 MCP 工具之一，該階段就會啟動。
“第一階段，飛行前準備” 它以單行命令 `node -e` 的形式內聯儲存在 package.json 檔案中。它會開啟七個常用的點文件，並將每個文件的前 200 位元組傳送到 C2 伺服器：
200 位元組 〜/.ssh / id_ed25519 它本身不會將你的私鑰直接透露給攻擊者，但它會提供… 檔案名稱、註釋以及 PEM 頭部的前幾行 ——足以確認那裡儲存的是哪種密鑰，這足以啟動後續步驟。 200 位元組 ~/.env 通常情況下，200 位元組的資料足以洩漏完整的 API 令牌。 ~/.git-credentials 通常是一整套 OAuth 令牌。
“第二階段，主舞台”，是 scanner.js它由軟體包載入。 index.js 當 AI 代理程式呼叫任何已發佈的工具時，該檔案會在 MCP 請求處理程序內部被呼叫。 8 個 Variant-A 軟體包中的檔案完全相同（b461106e47a1f5966159cd6e92541505它坦誠地說明了自己的工作內容。開頭的評論部分原文如下：
| javascript // wallet-scanner.js — 嵌入式 MCP 套件主動掃描器 // 當 AI 代理呼叫任何 MCP 工具時靜默運行，掃描環境中的錢包/金鑰 // 僅使用 Node.js 內建函數，無外部依賴 |
接下來是深度為 3 的遞迴遍歷：
主目錄本身
…篩選檔名包含以下任何內容 金鑰庫, wallet.json, 錢包.dat, 。秘密, 種子文件, metamask, 幻象, 拉比, 信任錢包, Coinbase, 私鑰, 助記符, 金鑰, api_key 也就是說，這是一份精心整理的列表，列出了加密用戶保存金鑰的所有位置。對於每個匹配項，都會開啟該文件，並使用六個正規表示式進行掃描：
| 類型 | 信號模式 | 它捕獲的 |
|---|---|---|
| 私鑰 | (?:0x)?[a-fA-F0-9]{64} | 以太坊私鑰和通用的 32 位元組十六進位金鑰。 |
| 助記符 | \b([a-z]+\s+){11,23}[a-z]+\b | BIP39 助記詞種子短語，長度為 12 到 24 個單字。 |
| api_key | (api[_-]?key\|API_KEY)\s*[:=]\s*["']?([A-Za-z0-9_\-]{20,}) | 在設定檔中嵌入了通用 API 令牌和憑證值。 |
| 秘密 | (?:secret\|private).{0,10}[:=]\s*["']?([A-Za-z0-9+/=]{20,}) | 金鑰和私有值通常以 YAML、JSON 和 INI 設定格式儲存。 |
| eth_address | 0x[a-fA-F0-9]{40} | 使用以太坊錢包地址來識別和標記受害者。 |
| 密碼 | (?:PASSWORD\|PASSPHRASE)\s*=\s*["']?(\S{4,64}) | Shell 匯出風格的密碼和密碼短語環境變數。 |
然後，scanner.js 會完整讀取另外六個點檔案——每個檔案最多 500 個位元組，分別是 ~/.env、~/.bash_history、~/.zsh_history、~/.npmrc、~/.gitconfig 和 ~/.git-credentials——並掃描 process.enpmrc、~/.gitconfig 和 ~/.git-credentials——並掃描 process.enpmrc、~/.gitconfig 和 ~/.git-credentials——並掃描 process.envv.的變數。最後，它會呼叫 execSync('whoami') 以及 os.hostname() 和 process.cwd() 來標記轉儲文件，使其包含受害者的身分資訊。整個有效載荷以及最多 100 個單獨的發現結果，會以單一 JSON 物件的形式 POST 發送。
匯出目標位置並非直接硬編碼。該軟體包會在運行時從以下位置取得：
https://ddjidd564.github.io/defi-security-best-practices/config.json
— 攻擊者控制的 GitHub Pages 文件。當前的 config.json 返回
如果獲取失敗， scanner.js 又回到了原點 webhook.site URL被硬編碼為一個常數。這種間接方法是該攻擊活動中唯一體現操作複雜性的地方：它允許攻擊者在不重新發佈軟體包的情況下輪換資料外洩目標，並且將實際的收集器URL隱藏在npm工件之外，這使得基於特徵碼的偵測更加困難。
變體 B：一個 Pinggy 隧道、一個二進位檔案和一個持久化變體
另一批上線的軟體包規模小得多——只有五個——而且遠不如前者巧妙。作者完全放棄了 MCP 的偽裝。這些軟體包聲稱是合法的以太坊和 Solana 工具的配置助手（truffle-config-helper, chainlink-價格資訊聚合器, ganache-cli-provider, solana-pda-helper, 鑄造廠部署助手有效載荷是一個單獨的 https.get和EXEC 行中 安裝後
C2 是免費的 平吉 tunnel－攻擊者使用的一種通用開發者隧道服務，作為臨時 C2 伺服器。該軟體包會下載 tunnel 返回的所有內容並將其推送到… child_process.exec沒有完整性檢查，沒有簽字確認，也沒有第二道防線。營運商的隧道今天服務什麼，就運作什麼。
最具競爭力的方案 foundry-deploy-helper:1.8.96，替換內聯 https.get - 捲曲 以及一個持久化技巧：
方案C：光鮮亮麗的外觀，暫無引爆裝置
剩下的九個包裹—— 錢包備份驗證器, 環境安全掃描器, Foundy 工具包 （故意拼字錯誤，冒用 Foundry 的網域） solna-web3 （Solana 的一個拼字錯誤） 錢包安全檢查器, 硬帽氣體分析插件, ethers-multicall-utils, defi-env-auditor, etherjs-utils - 有 沒有安裝後腳本 乍一看，這些惡意軟體似乎沒有明顯的運行時資料外洩。它們與活躍的變種共享發布者、品牌標識、Web3命名模式，在某些情況下甚至擁有完全相同的README模板。我們將其視為相同攻擊活動的一部分，並建議提前移除，但我們尚未完全列出其運行時觸發機制。這些休眠的惡意軟體可能是攻擊者為未來再次攻擊而保留的立足點——這與PhantomBot在5月中旬使用的模式相同，當時攻擊者用一個憑證竊取程式替換了一個殭屍網路成員，而沒有重新發佈軟體包名稱。
時間軸和產品目錄
該活動中最早發布的軟體包版本最低： 鏈鍵驗證器：0.2.3 以及 defi-env-auditor:0.3.2 看起來像是早期實驗性版本。當發行商達到 truffle-config-helper:1.7.0 以及 foundry-deploy-helper:1.8.96版本號的膨脹是故意的——選擇的數字看起來像是某個已建立軟體包的版本傳承。這 22 個版本中，沒有一個在 npm 上以完全相同的名稱出現過任何合法的歷史記錄。
完整目錄，依版本分組：
### 變體 A — 憑證收集器（postinstall + MCP 時間掃描器.js，MD5 b461106e47a1f5966159cd6e92541505）
| 小包裝 | 版本 | 已在偵測資訊流中標記 |
|---|---|---|
mnemonic-safety-check | 0.5.2 | 「有」。 |
solidity-deploy-guard | 0.4.4 | 「有」。 |
web3-secrets-detector | 1.2.6 | 「有」。 |
eth-wallet-sentinel | 1.0.9 | 「有」。 |
deployment-key-auditor | 0.7.3 | 「有」。 |
defi-threat-scanner | 2.1.2 | 「有」。 |
crypto-credential-scanner | 2.0.2 | 「有」。 |
chain-key-validator | 0.2.3 | 「有」。 |
### 變體 B — Pinggy 隧道 https.get → exec（在此報告之前無法偵測到）
| 小包裝 | 版本 | 安裝後風味 |
|---|---|---|
truffle-config-helper | 1.7.0 | https.get → exec(stdout) |
chainlink-price-feed-aggregator | 1.1.12 | https.get telemetry call |
ganache-cli-provider | 1.7.51 | https.get telemetry call |
solana-pda-helper | 1.0.46 | https.get telemetry call |
foundry-deploy-helper | 1.8.96 | curl + chmod +x /tmp/.node-cache & |
### 變體 C — 休眠狀態，懷疑執行時間觸發（在此報告之前未偵測到任何異常）
| 小包裝 | 版本 | 筆記 |
|---|---|---|
wallet-backup-verifier | 1.0.1 | |
env-security-scanner | 1.6.0 | |
foundy-toolkit | 1.5.79 | 鑄造廠的拼字錯誤 |
solna-web3 | 1.5.98 | solana 的 typosquat |
wallet-security-checker | 1.0.3 | |
hardhat-gas-profiler-plugin | 1.7.86 | |
ethers-multicall-utils | 1.3.15 | |
defi-env-auditor | 0.3.2 | |
etherjs-utils | 1.0.39 |
「變體 A」和「變體 B」欄並非隨機選擇。 「變體 A」的名稱本身就很有吸引力。 安全審計工具 ——「安全檢查」、「部署衛士」、「金鑰偵測器」、「錢包哨兵」、「金鑰審計器」、「威脅掃描器」、「憑證掃描器」、「鏈密鑰驗證器」。它們的目標使用者是尋求評估 Web3 專案安全性的工具的開發者或人工智慧代理。 Variant-B 的所有名稱都旨在吸引用戶。 建置和部署助手 對於同一個 Web3 生態系統——Truffle、Chainlink、Ganache、Solana PDA 工具、Foundry 等——來說，這種分裂反映了普通 Web3 開發者「審核階段」與「部署階段」的思維模式。無論你選擇哪個階段，發布商都為你設置了陷阱。
妥協指標
網路和檔案
| 國際奧林匹克委員會 | 變種 | 目的 |
|---|---|---|
https://ddjidd564.github.io/defi-security-best-practices/config.json | A | 透過 GitHub Pages 託管的動態 webhook 解析器。 |
https://webhook.site/8d334534-1c63-4f4f-a0d7-95c446c8b233 | A | 目前滲漏收集器端點，也嵌入作為備用方案。 |
rqnyz-2605-7280-7--2000-c51.run.pinggy-free.link/npm/-/binary/telemetry | B | Pinggy隧道用於分發遠端二進位有效載荷。 |
scanner.js MD5 b461106e47a1f5966159cd6e92541505 | A | 所有 8 個 Variant-A 軟體包均重複使用相同的掃描器有效載荷。 |
/tmp/.node-cache | B | 分離的可執行檔被丟棄 foundry-deploy-helper:1.8.96. |
出版者
- npm 使用者名稱： ddjidd5640
- 1623682356@qq.com （未經證實）
- 電子郵件和 SCM 驗證：無
- 帳戶下包裹數量：22，全部列於上述目錄。
- 最早可見的活動： 鏈鍵驗證器：0.2.3 （變體 A）
- 最新可見活動：chain-key-validator:0.2.3 和 crypto-credential-scanner:2.0.2（皆在撰寫本文前 24 小時內）
品牌正面（用於 作者 / README / fake GH org)
- 「加密安全公會」—由一個空的 GitHub 組織支持 加密安全公會
- 「Web3 審計聯盟」—由一個空的 GitHub 組織支持 w3audit
- 「DeFi 安全聯盟」—由一個空的 GitHub 組織支持 Defi 安全
- 參考 GH 帳號 ddjidd564 — 動態 Webhook 設定 config.json 的主機
行為的
- 節點 -e 安裝後讀取任何內容 .ssh, 以太坊, .比特幣, .ENV, .bash_歷史記錄, .zsh_history, .git-credentials - .slice(0, 200) 並與 | 分隔符號是變體 A 的一個近乎唯一的指紋。
- 輸入 ./scanner.js 來自一個註冊為 MCP 的軟體包 伺服器 使用名為 搜尋洩漏的憑證 或類似表述的「安全審計」動詞是變體 A 的確認。
- 無論包裝器如何，從任何 *.run.pinggy-free.link 主機獲取並將回應透過管道傳遞給 child_process.exec 的 node -e postinstall 都是 Variant-B 確認。
歸因與動機
桌面上的資訊足以勾勒出出版商的部分特徵，但遠遠不足以進行真正的識別。電子郵件 1623682356@qq.com 這是一個 QQ 郵箱地址——騰訊的免費網路郵箱，在中國大陸很流行——其中的數字部分是 QQ 用戶 ID；我們僅將其視為軟信號，因為 QQ 格式的地址很容易註冊。該 npm 帳戶沒有啟用雙重認證，沒有驗證郵箱，也沒有驗證資訊。 SCM 鏈接。 「加密安全公會」、「Web3 審計聯盟」和「DeFi 安全聯盟」這三個品牌完全是捏造的——這三個品牌在此次活動之外根本不存在——而支持的 GitHub 組織也只是空殼，用來填充 npm 頁面連結。
有兩種模式值得一提，因為它們在相鄰的戰役中都會出現。第一種是： 品牌預製作為一種社會認同經營者並沒有選擇現有的項目名稱進行域名搶注；他們從零開始構建了一個完整的信任故事，並且他們知道… AI代理構建 pipeline 或者，匆忙瀏覽 npm 頁面的開發者會匹配「看起來像安全組織」而不是「就是安全組織」。這與那些關於網域搶注的文獻所警告的做法如出一轍——軟體包的名稱經過精心調整，以迎合 LLM（法律管理專家）的喜好。 發明 如果被要求提供 Web3 安全工具，要夠巧妙，讓 LLM 不會進行二次檢查。 懶散蹲坐 是最近創造的術語，指的是名稱與 LLM 在權威軟體包不存在時產生的佔位符相匹配的惡意軟體包；這種攻擊活動是其更具攻擊性的版本，攻擊者還會捏造佔位符所屬的組織。
第二種模式是 MCP 時間激活。 到......的時候 scanner.js 程式運行完畢，安裝完成，開發者已繼續下一步。觸發條件是人工智慧代理呼叫某個工具—— 搜尋洩漏的憑證在 Variant-A 案例中，代理人絕對會這樣做，因為這就是它收到該軟體包的全部原因。惡意操作發生在… 好 在工作流程中，開發者最有可能看到他們的 AI 助理成功完成他們要求的任務。這與以往的「導出」方式相比，只是一個小小的行為轉變。 npm安裝這種模式巧妙地規避了安裝時沙盒機制。
我們不會指明具體的攻擊者。這些訊號（QQ郵件、單一帳號攻擊、單日22個資料包的突襲、兩個並行的C2伺服器堆疊）同樣適用於單一持續攻擊者、小型團隊，或在2025-2026年期間在npm遙測資料中可見的某個資料包泛洪攻擊團隊。我們 能夠 也就是說，該運營商有明確的首選生態系統（以太坊 + Solana + Foundry/Hardhat 工具），明確的首選受害者（Web3 開發人員和從事 Web3 專案的 AI 代理），以及明確的首選持久化模型（MCP 時間運行時觸發加上分離的二進制回退）。
影響、趨勢以及防守者可以做什麼
我們的早期預警 pipeline 抓 8 22的 在整個活動期間，共發布了 14 個軟體包——最初掃描時發布了 6 個，當天晚些時候在活動集群分析階段又發布了 2 個。其餘 14 個軟體套件在 npm 上已上線數日。 從未出現在我們監測的任何檢測資訊流中。截至撰寫本文時，這些軟體仍然可以安裝。這一差距之所以重要，是因為：
- 版本 A 在安裝過程中保持靜默. 讀取點檔案的操作會執行，但批次匯出操作只有在 AI 代理呼叫軟體包的 MCP 工具時才會觸發。 standard 安裝後監視沙箱將會看到 節點 -e 將其阻擋並判定為體積小且明顯無生命。
- 變體 B 為單行。 惡意軟體分類器無法從中學習到任何東西——沒有混淆，沒有編碼的有效載荷，也沒有可疑的域名。 Pinggy 隧道是一個合法的開發者服務。唯一可疑之處在於，一個「配置助手」竟然需要向伺服器發送資料。
- 變體C看起來完全乾淨。 它無需安裝 hooks任何靜態訊號都是正常的。
MCP工具時代的簡短防禦者檢查清單
以下三項具體措施本來可以更早阻止這項運動：
- 要看出版社，而不是包裝。 一個註冊僅一年的QQ信箱帳號下，竟然有22個包裹，而且沒有任何關聯。 SCM 驗證比任何軟體包本身的特性更具說服力。我們的早期預警工作流程之所以能攔截到首批軟體包，是因為發布者指紋特徵非常突出——它建議的發布者信譽評分會被任何一個安全、不確定或惡意軟體的軟體包分類器降低權重。
- 在證明並非惡意行為之前，應將動態配置間接操作視為惡意行為。 如果軟體套件在運行時從第三方文件（GitHub Pages、GitHub Gist、Pastebin、S3 物件或其他任何地方）解析其出站端點，那麼它沒有正當理由這樣做來進行遙測。真正的遙測端點是硬編碼的，並且有文件記錄。
- 透過其宣傳的工具介面審核 MCP 伺服器軟體包。 Variant-A 軟體包都宣傳名為「工具」的軟體包。
search_leaked_credentials,validate_chain_key,deploy_safe以及類似的「審計」動詞。如果 MCP 主機提供了一個工具，其描述聲稱可以掃描專案目錄以查找憑證，則在代理程式對實際程式碼庫呼叫該工具之前，應要求操作員明確選擇加入。 MCP 的關鍵在於，代理程式循環無法知道是否search_leaked_credentials這是憑證搜尋還是憑證竊取？
對於可能已經安裝了這 22 個軟體包之一的開發人員：假設任何明文金鑰 ~ / .ssh, ~/.以太坊, ~/.bitcoin, ~/.solana, ~/.env， 或者 ~/.git-credentials 如果系統遭到入侵，請輪換所有名稱與上述環境變數篩選清單相符的憑證；在 Linux/macOS 系統上，請檢查是否有執行檔。 /tmp/.node-cache （以及由此啟動的任何孤立過程）。重新安裝被冒充工具的合法版本（鑄造廠, 松露, 安全帽, 伽納徹等等）不會刪除丟棄的二進位。
休眠的 Variant-C 版本是這個故事中最令人擔憂的部分。九個軟體包，擁有乾淨的安裝設定檔和已建立的發布者，正是運營商通常會保留的儲備。如果它們日後引爆——就像 PhantomBot 那樣—— 軸子工具 重新打包的惡意軟體已從竊取憑證轉變為招募殭屍網路成員——任何在今天到下架期間鎖定 Variant-C 軟體包的註冊表用戶都將遭到攻擊。即使鎖定了惡意軟體的版本，也無法保護您免受控制所有版本的發布者的侵害。
參考
- [npm 發布者頁面 ddjidd5640](https://www.npmjs.com/~ddjidd5640）— 此帳戶下目前列出了 22 個包裹。截至撰寫本文時，該目錄的權威來源。
- [npm 套件頁面 加密憑證掃描器](https://www.npmjs.com/package/crypto-credential-scanner）—範例 Variant-A 工件；README、版本歷史記錄和作者連結在此處可見。
