安裝腳本會連接由攻擊者控制的基礎設施，然後按主機作業系統下載遠端存取木馬（RAT），支援 Windows、macOS 及 Linux。換句話說，一次看似普通的套件安裝，可能成為更大規模入侵的第一步。

受影響版本在 npm 上大約存在三小時。Google Threat Intelligence Group 記錄到的活動時間為 3 月 31 日 00:21 至 03:20 UTC；其他事故報告亦形容暴露期約為兩至三小時。 Axios 是 JavaScript 生態系統中廣泛使用的依賴，多份報告估計其 npm 每星期下載量由約 8,000 萬至逾 1 億不等，數字因來源而異。

維護者帳戶如何被利用？

目前較可靠的公開資料支持「npm 帳戶遭接管」這個結論，而不是 Axios 本身存在漏洞。有報告指攻擊者利用主要維護者的一個長期有效 npm 存取權杖；亦有報告較概括地描述為維護者帳戶或發佈憑證遭入侵。

這個分別相當重要。攻擊者突破的是「維護者的發佈權限」與「npm 發佈流程」之間的信任邊界。由於惡意版本是透過合法帳戶推出，下游開發者及自動化系統較難從表面判斷它們有問題。

惡意依賴做了甚麼？

plain-crypto-js@4.2.1 被偽裝成普通套件依賴，但實際上是用來執行 postinstall 腳本。腳本會連接命令及控制伺服器，再按受害主機的作業系統下載第二階段載荷。

因此，攻擊不一定需要開發者主動下載一個明顯可疑的執行檔。只要在暴露期間進行一般依賴更新、執行 CI 建置，或者由自動化流程跑一次 npm install，都可能觸發惡意程式碼。安全通告建議，凡曾安裝兩個受影響 Axios 版本的系統，都應先視為可能已被入侵。

是否由 BlueNoroff 負責？

就目前材料而言，歸屬仍未有定論。部分報道將事件與被認為和北韓有關的行動者，包括 BlueNoroff 或相關組織連繫起來；Microsoft 則將這次入侵歸因於 Sapphire Sleet。

這些評估不應被包裝成單一、已確認的結論。程式碼、基礎設施及操作模式的相似之處，可以提供追蹤方向，但單憑這些資料並不足以證明是哪一個組織發動攻擊。

較穩妥的結論是：Axios 事件涉及維護者帳戶被劫持、惡意版本遭推出，以及針對多個作業系統的 RAT；至於幕後行動者，公開評估仍然存在分歧。

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

SilverFox 採用另一條入侵路線：散播適用於 Windows、macOS 及 Linux 的冒牌 Claude 應用程式。活動目標包括印度、印尼、南非及俄羅斯的工業、顧問、商貿和運輸企業。

這些程式冒充 Anthropic 的 Claude 品牌，並不是官方 Claude 安裝程式。攻擊的有效之處，在於它符合一個相當合理的職場情境：員工搜尋 AI 生產力工具，下載一個看似熟悉的應用程式，結果安裝的卻是惡意軟件。Kaspersky 的資料指，這次活動是 SilverFox 自 2025 年 12 月起分多個階段觀察到的行動之一。

由稅務釣魚電郵轉向 AI 誘餌

這次行動亦承接了較早前以稅務為主題的釣魚攻擊。研究人員在 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。凡在暴露期間安裝過受影響版本的電腦，都應調查有沒有下載載荷、未經授權的持久化機制，以及憑證外洩跡象。安全通告特別建議，將受影響安裝視為可能已被入侵。

至於 AI 軟件，企業應要求員工只透過已批准的渠道取得桌面應用程式，核對發佈者和下載網域，並封鎖或隔離未經批准的安裝程式。

npm 發佈方面，採用抗釣魚多重因素認證、短期或權限嚴格限制的憑證、版本來源證明、lockfile，以及對依賴變更進行審核，都有助降低單一帳戶被入侵後演變成供應鏈事故的機會。

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

安裝腳本會連接由攻擊者控制的基礎設施，然後按主機作業系統下載遠端存取木馬（RAT），支援 Windows、macOS 及 Linux。換句話說，一次看似普通的套件安裝，可能成為更大規模入侵的第一步。

受影響版本在 npm 上大約存在三小時。Google Threat Intelligence Group 記錄到的活動時間為 3 月 31 日 00:21 至 03:20 UTC；其他事故報告亦形容暴露期約為兩至三小時。 Axios 是 JavaScript 生態系統中廣泛使用的依賴，多份報告估計其 npm 每星期下載量由約 8,000 萬至逾 1 億不等，數字因來源而異。

維護者帳戶如何被利用？

目前較可靠的公開資料支持「npm 帳戶遭接管」這個結論，而不是 Axios 本身存在漏洞。有報告指攻擊者利用主要維護者的一個長期有效 npm 存取權杖；亦有報告較概括地描述為維護者帳戶或發佈憑證遭入侵。

這個分別相當重要。攻擊者突破的是「維護者的發佈權限」與「npm 發佈流程」之間的信任邊界。由於惡意版本是透過合法帳戶推出，下游開發者及自動化系統較難從表面判斷它們有問題。

惡意依賴做了甚麼？

plain-crypto-js@4.2.1 被偽裝成普通套件依賴，但實際上是用來執行 postinstall 腳本。腳本會連接命令及控制伺服器，再按受害主機的作業系統下載第二階段載荷。

因此，攻擊不一定需要開發者主動下載一個明顯可疑的執行檔。只要在暴露期間進行一般依賴更新、執行 CI 建置，或者由自動化流程跑一次 npm install，都可能觸發惡意程式碼。安全通告建議，凡曾安裝兩個受影響 Axios 版本的系統，都應先視為可能已被入侵。

是否由 BlueNoroff 負責？

就目前材料而言，歸屬仍未有定論。部分報道將事件與被認為和北韓有關的行動者，包括 BlueNoroff 或相關組織連繫起來；Microsoft 則將這次入侵歸因於 Sapphire Sleet。

這些評估不應被包裝成單一、已確認的結論。程式碼、基礎設施及操作模式的相似之處，可以提供追蹤方向，但單憑這些資料並不足以證明是哪一個組織發動攻擊。

較穩妥的結論是：Axios 事件涉及維護者帳戶被劫持、惡意版本遭推出，以及針對多個作業系統的 RAT；至於幕後行動者，公開評估仍然存在分歧。

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

SilverFox 採用另一條入侵路線：散播適用於 Windows、macOS 及 Linux 的冒牌 Claude 應用程式。活動目標包括印度、印尼、南非及俄羅斯的工業、顧問、商貿和運輸企業。

這些程式冒充 Anthropic 的 Claude 品牌，並不是官方 Claude 安裝程式。攻擊的有效之處，在於它符合一個相當合理的職場情境：員工搜尋 AI 生產力工具，下載一個看似熟悉的應用程式，結果安裝的卻是惡意軟件。Kaspersky 的資料指，這次活動是 SilverFox 自 2025 年 12 月起分多個階段觀察到的行動之一。

由稅務釣魚電郵轉向 AI 誘餌

這次行動亦承接了較早前以稅務為主題的釣魚攻擊。研究人員在 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。凡在暴露期間安裝過受影響版本的電腦，都應調查有沒有下載載荷、未經授權的持久化機制，以及憑證外洩跡象。安全通告特別建議，將受影響安裝視為可能已被入侵。

至於 AI 軟件，企業應要求員工只透過已批准的渠道取得桌面應用程式，核對發佈者和下載網域，並封鎖或隔離未經批准的安裝程式。

npm 發佈方面，採用抗釣魚多重因素認證、短期或權限嚴格限制的憑證、版本來源證明、lockfile，以及對依賴變更進行審核，都有助降低單一帳戶被入侵後演變成供應鏈事故的機會。

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