感染鏈與初始執行機制

Phorion 分析指出，受感染的 extension.js 檔案開頭注入了一個立即執行的函數表達式（IIFE）。這段程式碼在 Node.js 載入檔案時即刻執行，早於擴充功能正常的 activate 回調函數。

注入的程式碼引入了標準的 Node.js 模組（如 child_process, fs, os, path, http, crypto），並開始執行後續的感染步驟。使用者無需與擴充功能互動，惡意負載即會觸發。

SSH 存取權限的建立與 macOS 上的邏輯錯誤

第一階段中，程式碼確保 ~/.ssh 目錄存在，並將攻擊者控制的 Ed25519 公鑰附加到 ~/.ssh/authorized_keys。該金鑰註解為 svc-telemetry，目錄權限設為 0700，檔案權限設為 0600。

程式碼會檢查 authorized_keys 中是否已存在 svc-telemetry 字串，而非檢查金鑰本身。這意味著在調查時應檢查公鑰指紋，僅依賴註解字串可能導致漏判。

接著，腳本嘗試啟用本地 SSH 守護進程。在 Linux 上嘗試使用 systemctl 或 service；在 Windows 上嘗試透過 PowerShell 安裝並啟動 OpenSSH Server；在 macOS 上則檢查遠端登入狀態。

Phorion 發現 macOS 上的邏輯存在缺陷：腳本以標準使用者權限執行 systemsetup -getremotelogin，該命令因缺乏管理員權限而輸出錯誤訊息並以狀態碼 0 退出，而非返回 'Off'。

由於輸出內容不包含 'Off'，正則表達式測試失敗，腳本跳過了啟用 SSH 的步驟（sudo -n systemsetup -setremotelogin on）。這導致若 Mac 原本未開啟遠端登入，後門無法成功建立入站存取路徑，儘管金鑰與持久化機制仍被植入。

此外，Windows 程式碼路徑也存在錯誤：它透過一個硬編碼 /bin/sh 的輔助函數傳遞 PowerShell 命令，這在標準 Windows 安裝中無法正常運作。

反向 SSH 通道與持久化機制

第二階段建立一個出站 SSH 連線至 IP 134.209.82[.]225，使用使用者名稱 tunnel。為了向攻擊者伺服器驗證身份，腳本解碼了一個內嵌的未加密 OpenSSH Ed25519 私鑰，註解為 svc-telemetry-tun。

需注意區分兩把金鑰：附加到 authorized_keys 的公鑰（svc-telemetry）讓攻擊者能登入受害者機器；內嵌的私鑰（svc-telemetry-tun）則讓受害者機器能連接到攻擊者的通道伺服器。

腳本將此通道私鑰寫入作業系統臨時目錄，檔名以 .stk_ 開頭，後接主機名稱與家目錄路徑 MD5 雜湊值的前十個字元。

SSH 命令使用 -R *:0:localhost:22 進行遠端埠轉送，要求攻擊者的 SSH 伺服器動態分配一個監聽埠，並將流量透過通道轉發回受害者機器的 localhost:22。

為了維持連線，腳本檢查是否安裝了 autossh，若有則使用，否則退回標準 ssh。它將連線包裹在分離的重試迴圈中，每次嘗試間隔 60 秒，並使用 pgrep 避免重複啟動初始通道。由於迴圈是分離的，即使使用者關閉 IDE，通道仍會保持運作。

第三階段設定平台特定的持久化機制以在重啟後存活：macOS 建立一個偽裝成 com.apple.sysmond.plist 的使用者 LaunchAgent；Linux 寫入 shell 腳本並添加 @reboot cron 條目（註：此處存在可能清除現有使用者 cron 作業的錯誤）；Windows 嘗試建立名為 SysMon 的 SYSTEM 排程任務，失敗則退回至啟動資料夾中的 sysmon.cmd。

主機偵察與數據外洩

第四階段收集基本的主機偵察資訊並向攻擊者伺服器發送一次性信標。收集的數據包括：主機名稱、使用者名稱、作業系統平台與架構、家目錄、當前工作目錄、全域 Git 電子郵件（git config --global user.email）。

腳本還查詢 ifconfig.me 或 api.ipify.org 以獲取公開 IP 地址，並記錄各設定階段的狀態旗標（例如 SSH 金鑰是否已添加、使用了哪種持久化方法）。

特別值得注意的是，腳本會抓取最多 40 個符合 /KEY|TOKEN|SECRET|PASS|AWS|GCP/i 正規表達式環境變數的「名稱」（而非值）。這讓攻擊者能快速盤點機器上存在哪些雲端憑證或 API 令牌，以決定優先處理的主機。

JSON 報告透過明文 HTTP POST 請求發送至 134.209.82[.]225:8099/beacon 以及 127.0.0.1:8099/beacon。腳本本身未在本地埠 8099 設定監聽器，因此向本地發送副本的原因尚不明確。

信標僅在初始設定執行後 1.5 秒透過 setTimeout 排程一次，並丟棄任何 HTTP 回應。這純粹是為了讓攻擊者知道主機已準備就緒，實際的存取由 SSH 通道處理。

偵測與補救建議

Phorion 指出，僅監控 shell 命令（如 echo 或 tee）無法捕捉此威脅，因為惡意程式直接使用 Node.js 的 fs.appendFileSync 修改 ~/.ssh/authorized_keys。應監控 IDE 輔助程序（如 Code Helper, Cursor Helper）對該檔案的寫入行為。

在 macOS 上，強烈的偵測信號包括：非 Apple 程序寫入標籤為 com.apple.* 的 plist 檔案，以及 LaunchAgent 執行隱藏目錄中的 shell 腳本。由於初始通道是分離進程，後續的 ssh 進程不會以 IDE 作為直接父進程，需透過檔案創建行為進行關聯。

網路層面應尋找帶有遠端埠轉送（-R *:0:localhost:22）且身份檔案來自 /tmp/.stk_* 或 ~/.config/.smtk 的 ssh 或 autossh 啟動記錄，以及連往 134.209.82[.]225 的出站 SSH 連線與 HTTP POST 請求。

補救時，僅卸載擴充功能不足以移除後門。必須終止連接至 134.209.82[.]225 的 ssh/autossh 進程與重試迴圈；刪除 macOS 上的 com.apple.sysmond.plist、Linux 上的 @reboot cron 條目或 Windows 上的 SysMon 排程任務與啟動腳本；移除 ~/.config/.smt 和 .smtk。

需從 ~/.ssh/authorized_keys 中移除 svc-telemetry 公鑰，刪除 /tmp/.stk_* 檔案，並確認遠端登入（SSH）未被意外啟用。若 SSH 曾被啟用或有入站登入證據，應輪替該使用者帳戶可存取的任何憑證或令牌，特別是符合上述環境變數過濾條件的項目。

事件範圍與官方回應

Anthropic 員工 Felix Rieseberg 在 Hacker News 上澄清，此事件並非 Anthropic 系統或員工筆電的洩密。惡意行為者利用 Cursor Marketplace 的存取權限發布了 Claude Code 擴充功能的篡改副本，該版本並非由 Anthropic 構建或發布。

Anthropic 官方管道上的版本未受影響，此事件僅影響 Cursor 使用者。Cursor 已從其市集移除相關發布版本，並從 NPM 和 VSCode 註冊表中拉取版本 2.1.313。

根據 Reuters 報導及社群討論，該惡意擴充功能在 Marketplace 上線時間約為太平洋時間週四凌晨 2:27 至下午 1:35。目前已知受影響的註冊表包括 Cursor Marketplace 和 Open VSX，關於 Microsoft 官方註冊表的狀態尚無明確說法，但多數報導集中於前兩者。