Axios npm 供應鏈攻擊與假 Claude 應用程式，揭示軟體信任的新漏洞

受影響版本約存在三小時。Google Threat Intelligence Group 記錄到的活動時間為 3 月 31 日 00:21 至 03:20（UTC）；其他事件報告則描述為約兩至三小時的暴露窗口。 Axios 是影響範圍廣泛的依賴套件，多份報告估計其 npm 每週下載量約為 8,000 萬至超過 1 億次，但不同來源的數字並不一致。

維護者帳戶如何被利用？

目前較有力的公開報告支持「npm 帳戶遭接管」的說法，而不是 Axios 本身存在可被利用的程式漏洞。有報告稱，攻擊者使用了主要維護者持有、長期有效的 npm 存取權杖；另一些報告則較概括地描述為維護者帳戶或發布憑證遭到入侵。

這項區分相當重要。攻擊者跨越的是「維護者發布權限」與「npm 發布流程」之間的信任邊界。由於惡意版本是透過合法帳戶發布，下游開發者與自動化系統較難從發布身分判斷其可疑之處。

惡意依賴做了什麼？

plain-crypto-js@4.2.1 被偽裝成一般套件依賴，實際用途卻是執行 postinstall 腳本。腳本會連線至命令與控制伺服器，再下載針對主機作業系統準備的第二階段載荷。

換句話說，開發者不必主動下載一個明顯可疑的執行檔。只要在暴露期間進行一般依賴更新、執行 CI 建置，或由自動化流程執行

npm install

BlueNoroff 是否應為事件負責？

現有資料尚不足以定論。部分報告將這次行動與北韓相關的攻擊者連結，包括 BlueNoroff 或其他相關群組；Microsoft 則將這起入侵歸因於 Sapphire Sleet。

因此，這些評估不應被整理成單一且已獲確認的結論。程式碼、基礎設施與作戰方式的相似性，可以提供歸因線索，卻不能單憑這些因素證明是哪個群組發動攻擊。較為穩妥的結論是：Axios 事件涉及維護者帳戶遭劫持、惡意版本發布，以及跨平台 RAT；至於幕後攻擊者，公開評估仍存在分歧。

SilverFox 如何利用假 Claude 應用程式？

SilverFox 採取了不同的入侵路徑：散播適用於 Windows、macOS 與 Linux 的仿冒 Claude 應用程式。這場活動鎖定印度、印尼、南非與俄羅斯的組織，涵蓋工業、顧問、貿易及運輸等產業。

這些應用程式是冒充 Anthropic Claude 品牌的仿冒品，並非官方 Claude 安裝程式。其有效之處在於營造出合理的職場情境：員工搜尋 AI 生產力工具，下載看似熟悉的應用程式，結果安裝的卻是惡意程式。Kaspersky 的報告指出，這是 SilverFox 自 2025 年 12 月起分多個波次觀察到的活動之一。

從稅務釣魚轉向 AI 誘餌

這場活動也延續了 SilverFox 早期以稅務為主題的釣魚攻擊。研究人員在 2026 年 1 月與 2 月記錄到超過 1,600 封惡意電子郵件，內容冒充官方稅務稽查通知，或聲稱附有稅務違規名單。

傳遞方式雖然演變，利用的信任訊號卻十分相似。稅務通知帶來急迫感與權威感；品牌化的 AI 助理則訴諸相關性與便利性。兩者都可能促使使用者在尚未核實來源前，就開啟附件、下載壓縮檔或安裝軟體。

SilverFox 採用分階段傳遞模式，為入侵的不同階段配置不同基礎設施。這種分隔方式可能使防守方更難只依靠單一網域或指標，完整辨識或封鎖整條攻擊鏈。

共同教訓：信任本身就是攻擊面

Axios 與 SilverFox 瞄準的是不同的信任關係：

• 對維護者的信任： Axios 版本看起來是由獲授權的 npm 發布者推出。
• 對依賴管理機制的信任： 套件管理器將惡意依賴視為正常安裝流程的一部分。
• 對品牌的信任： 假 Claude 安裝程式借用了知名 AI 產品的身分。
• 對工作流程的信任： 開發者與員工只是執行日常操作，例如更新依賴或安裝生產力軟體。

Axios 事件說明，暴露時間短並不代表風險低。套件安裝與 CI 工作流程可以自動執行，因此受影響的系統數量不只取決於有多少人親自檢查版本。SilverFox 則從終端裝置角度呈現同一原理：快速普及的軟體類別，會為攻擊者提供可信的新誘餌。

組織現在應該怎麼做？

針對 Axios 事件，應檢查 lockfile、套件清單、建置記錄、快取、依賴清冊，以及 axios@1.14.1、axios@0.30.4 和 plain-crypto-js@4.2.1 是否曾出現在環境中。凡是在暴露期間安裝受影響版本的裝置，都應調查是否曾下載載荷、建立未授權的持久化機制，或暴露雲端金鑰、資料庫密碼與 API 權杖。相關公告明確建議，將受影響的安裝視為可能遭到入侵。

對 AI 軟體而言，企業應要求員工只透過核准管道取得桌面應用程式，並核對發布者與下載網域；未經核准的安裝程式則應封鎖或隔離。npm 發布方面，採用抗釣魚多因素驗證、短期或嚴格限權的憑證、發布來源證明、lockfile，以及對依賴變更進行審查，都能降低單一帳戶遭入侵後演變成供應鏈事件的機率。

更廣泛的防護原則，是在每個信任邊界重新驗證。熟悉的套件名稱，不代表每個版本都安全；熟悉的產品名稱，也不代表每個安裝程式都是真的。