工程師思路系列・事出必有因

一個早上被刷三萬台幣，原因在八個月前的一次點擊：單層防禦為什麼高機率被擊穿

最近臉書上有一位醫師兼資工背景的工程師，公開分享了自己的遭遇：Google Cloud 帳號在一個凌晨被大量呼叫 Vertex AI，帳單暴增約三萬台幣。他花了好幾天追查，結論很反直覺：不是 API Key 外洩，不是密碼被盜，也不是 AI Agent 失控，而是八個月前就躺在他 Mac 裡的一隻資訊竊取木馬。

我看完的第一個念頭不是「這個人好倒楣」，而是：這條攻擊鏈，把 Mac 換成 Windows、把 Google Cloud 換成公司信箱或雲端 ERP，一模一樣走得通。

一般人聽到這種事，會想到兩招：裝防毒軟體、調瀏覽器設定。這兩招都對，但我建議再加上第三層：資安閘道器。這篇文章想說的其實很簡單：人都有疏失的時候；惡意威脅不斷提高攻擊層級、增加方法與管道；被利用的機器與程式又不休息。所以單層防禦被擊穿的機率很高。我們用這個案例，再借用資安界兩套偏理論的工具，看清楚攻擊走到哪一步、每一層守什麼，以及為什麼需要多層防護。

一、事件經過（三分鐘版）

時間點	發生的事
約八個月前	為了安裝 Claude Code 上網搜尋，點進排名很前面、長得像官方的仿冒網站，疑似下載並執行了惡意檔案
之後數個月	電腦裡多了幾個隱藏檔與一個開機自動執行的設定，電腦照常使用，沒有任何異狀
事發前約兩週	雲端專案裡出現陌生的 Service Account：先有人盤點專案，幾秒內啟用十幾個 AI 相關 API，接著建立帳號並下載金鑰。當天活動紀錄有一筆來自美國的 IP
事發當天凌晨	多個專案同時大量呼叫 Vertex AI。約一小時後 Google 異常偵測來信，自己設的預算提醒晚了約五小時才到，而且只通知、不會停
結果	關閉帳務與專案止血，向 Google 申訴後，大部分費用獲得調整減免

先講清楚：以上是當事人的自述與推論。木馬的主程式已經不在機器上，所以「木馬家族」「仿冒網站就是感染途徑」「登入狀態被重放」都屬於推論，並非鑑識確認的結論。但「釣魚下載 → 竊取登入狀態 → 延遲數週才變現」這個模式，和資安業界已記錄的雲端 AI 資源盜用（LLMjacking）手法吻合。

這個時間軸有一個值得先記住的觀念：感染、憑證被偷、憑證被使用、損失發生，可能是四個不同的時間點，中間隔著數週甚至數月。所以只在帳單異常時才開始調查，往往已經錯過最容易阻止的時機。

二、為什麼單層防禦，高機率會被擊穿

資安攻防本來就是矛與盾的競賽，而這場競賽有四個不對等的事實：

✔

人都有疏失的時候。疏忽不是「會不會」，而是「何時」。累了、趕時間、剛好信了一個長得像官網的網站。

✔

矛不斷升級。攻擊者的層級不斷提高，方法與管道也持續增加：仿冒下載、竊取登入狀態、冒用雲端身分、盜用 AI 資源……

✔

機器不休息。被惡意利用的機器與程式（包括 AI 與自動化工具）全天候反覆嘗試，不累、不分心、不嫌煩。

✔

所以單層防禦被擊穿，是機率問題，不是運氣問題。

用簡單的算術感受一下（數字僅為示意）

人：假設你每次判斷「這個下載安不安全」，失誤率只有 0.1%，已經比多數人謹慎。一年做 365 次這種判斷，至少失誤一次的機率仍有約 3 成。

機器：假設某道防線單次被穿透的機率只有 1%，自動化程式反覆嘗試 500 次，至少穿透一次的機率超過 99%。

多層：假設有三道彼此獨立的防線，各自漏掉 10%，三道同時漏掉的機率只剩 0.1%。

實際情況比這複雜：各層未必真的彼此獨立，攻擊也不是每次都獨立嘗試。這組數字只用來說明方向：單層靠不住，疊層才有機會把「同時漏掉」變得很難。

這起事件正是這四件事的縮影。接下來，我們看攻擊具體是怎麼一步步走的。

三、用兩張理論地圖，找出可以攔截的位置

前面講的是原則。接下來借用資安界兩套偏理論的工具，把原則落到這個案例上。它們的用處不是背誦，而是幫你找出「可以攔截的位置」：

Cyber Kill Chain（網路攻擊鏈）：把一次入侵拆成七個先後順序的階段，像一條鎖鏈。重點是只要在某個必要環節成功阻止，這條攻擊路徑就會失敗（攻擊者可能改走別條路，所以不能只靠單一關卡）。它回答的是「攻擊走到哪一步了？我能在哪一步攔？」

MITRE ATT&CK：一本攻擊者「招式」的編號字典，每一招都有編號（例如 T1539）。它回答的是「這一步攻擊者具體用了哪一招？別人怎麼偵測、怎麼防？」

簡單說：Kill Chain 看流程，ATT&CK 查招式。兩套框架的分段方式不同（例如 SEO Poisoning 在 ATT&CK 屬於「資源開發」戰術，Kill Chain 並沒有同名階段），所以下表是「大致對應」，不是一對一。

四、本案七個階段逐環比對

Kill Chain 階段	本案發生什麼	ATT&CK 招式
1 偵察 Reconnaissance	攻擊者鎖定「想裝 AI 工具的開發者」，把仿冒網站推到搜尋結果前段（此為合理推測）	疑似 T1608.006 SEO Poisoning（也可能是搜尋廣告，手法未確認）
2 武器化 Weaponization	把竊取程式包成看起來像正常的安裝檔	（發生在攻擊者那端，你看不到）
3 傳遞 Delivery	受害者點進仿冒網站、下載檔案	（誘導手法同上，未確認）
4 利用 Exploitation	受害者自己執行了檔案，不需要任何漏洞（「利用」不一定是軟體漏洞，也可能是利用使用者的信任）	T1204.002 User Execution: Malicious File
5 安裝 Installation	寫入隱藏檔，並用開機自動執行設定常駐，一躺八個月	T1543.004 Launch Daemon
6 指揮與控制 Command & Control	竊取瀏覽器裡的登入狀態與密碼，往攻擊者的主機回傳	蒐集：T1539 Steal Web Session Cookie、T1555.003 Credentials from Web Browsers 外傳：T1041 Exfiltration Over C2 Channel
7 達成目標 Actions on Objectives	冒用登入狀態進雲端，盤點專案、建立 Service Account（雲端上給程式使用的「服務身分」，不是一般員工帳號）與金鑰（這是雲端那邊自己的「安裝」，兩週後才出手），最後大量呼叫 AI API 變現	T1550.004 Web Session Cookie T1580 Cloud Infrastructure Discovery T1136.003 Create Cloud Account T1098.001 Additional Cloud Credentials T1496.004 Cloud Service Hijacking

讀完這張表，有兩件事值得停下來想：

✔

前兩環你根本插不上手。防守要從第 3 環開始，而第 3、4 環都需要「人」做一個動作（點、執行），這也是為什麼人的習慣永遠是第一道防線，同時也是最脆弱的一道。

✔

第 5 環到第 7 環之間隔了好幾個月。「潛伏」不是攻擊失敗，是攻擊的一部分。症狀（帳單）出現時，原因已經在好幾環之前。這就是我說的「事出必有因」。

五、這起事件裡，人的作為與疏漏點

Kill Chain 看的是攻擊者的動作。換個角度也可以問：鏈條的每一環，人原本有哪些機會做出不同的選擇？這不是要責怪誰，下表的每一項，幾乎每個人、每間公司都有。

環節	人的作為或疏漏	本質
3 傳遞	信任搜尋結果前段、長得像官網的網站，沒有用網域或官方連結交叉確認	便利性優先於驗證
4 利用	疑似直接執行了下載的檔案	同上
5–7 潛伏期	木馬與常駐設定存在約八個月無人察覺；依當事人描述，平時也不太會巡視雲端的 API 與憑證頁面	缺少定期盤點
環境	同一台電腦同時用於日常開發、嘗試新工具與管理雲端帳號	工作環境沒有隔離
6 外傳	依當事人事後的說法，免費防毒軟體就能抓出這隻木馬，代表當時機器上沒有持續運作的偵測	「習慣好就夠了」的想法
7 變現	預算只設了通知，沒有設上限	以為通知等於保護

但不全是人的問題。平台端也有侷限：依當事人所述，Google 剛推出的硬上限只涵蓋部分服務，無法對整個專案一鍵設限；而竊取登入狀態的攻擊本來就不會觸發「新裝置登入」通知。換句話說，就算人很小心，系統也沒有替他多擋一道。

另外值得注意：當事人是資工所畢業、從小自學寫程式、十年以上的雲端使用者。這說明這些疏漏不是技術能力的問題，而是「便利性優先於持續驗證」這個人性預設。正如第二節所說，人的疏忽近乎必然。沒有人能靠每天都不犯錯來防守，所以需要的是流程與工具，替人層層補位。這就接到下一節。

六、三層防線，各守哪幾環

第一層：防毒軟體（端點防護）

守在哪：你的電腦本機，看檔案與程式的行為。

主要守第 4、5 環：惡意檔案被執行前掃描、常駐設定被偵測。當事人事後也說，連免費的防毒軟體都掃得出他的那隻木馬。

限制：要裝、要開、要更新；全新變種可能漏掉；它跑在「可能已被感染的那台電腦」上；NAS、攝影機、老舊設備這些裝不了防毒的東西，它管不到。

你可以做：Mac 也裝，開即時防護，每月做一次全機掃描。

第二層：瀏覽器設定

守在哪：你每天上網的入口，也是「登入狀態」存放的地方。

主要守第 3 環：安全瀏覽與下載警告能攔下一部分已知的壞站；把官網加書籤、不點搜尋結果第一名（尤其是廣告），就是在第 3 環斬鏈。

限制：要老實講，瀏覽器設定擋不住「已經裝進電腦的竊取程式」。獨立的瀏覽器設定檔（Profile）降低的是「在同一個登入環境裡亂點」的風險，但如果木馬已經在機器上，其他設定檔的資料也可能被一併取走（能不能取到，要看它拿到的權限與瀏覽器的保護機制）。另外要注意：兩步驟驗證能大幅降低密碼被盜後直接登入的風險，卻無法保證「驗證完之後」的登入狀態不被偷走，所以重要帳號還要搭配 Session 管理與異常登入監控。

你可以做：開啟瀏覽器的增強型安全防護；雲端控制台、信箱、ERP 用專用的設定檔；用完登出敏感網站；重要帳號優先使用 Passkey 或安全金鑰，並定期檢視登入中的裝置與已授權的應用程式。若懷疑中招，光改密碼不一定夠，要確認舊的 Session、Token 與金鑰都已撤銷。

第三層：資安閘道器（網路出口）

守在哪：公司網路的出口，在所有電腦「之外」。與其說它是一台擋東西的設備，不如說它是企業網路活動的「觀察與稽核位置」。

主要守第 6 環，輔助第 3 環：木馬要把資料送出去，一定得經過出口。如果對方位址已在威脅情資裡，連線可以被攔下；就算沒攔到，日誌也會留下「哪一台電腦持續對可疑位址連線」的證據。

為什麼我建議加上這層，有三個理由：

✔

它在被感染的電腦之外。前兩層都跑在那台可能中毒的電腦上，閘道器是另一個獨立的觀察者。

✔

它看得到沒裝防毒的設備。老 Windows、NAS、攝影機、印表機，只要從出口走，就在視線內。

✔

它提供能見度與調查線索。本案木馬躺了八個月沒人知道。出口日誌本身不會自動發現異常，但事後有跡可循；搭配威脅情資、告警與定期檢視，才有機會縮短潛伏期。

限制：全新、還沒進資料庫的釣魚站不一定擋得住；加密的 HTTPS 內容沒做解密檢查就看不到裡面（看到連線不等於看到資料，可疑連線也不等於已證明外洩）；已被偷走的登入憑證收不回來；攻擊者是從他自己的機器連 Google 的，第 7 環根本不經過你的閘道器。而且它的觀察範圍取決於「設備有沒有經過這個出口」：員工的個人電腦、手機熱點、外出辦公，都在視線之外。它也不能取代防毒，兩者守的是不同關卡。

你可以做：如果公司網路還是「數據機接 IP 分享器」，出口其實沒有人在看。先建立能見度，比先追求完美重要。

七、疊在一起看：沒有任何一層是萬能的

Kill Chain 階段	防毒	瀏覽器	閘道器	雲端帳號設定
1–2 偵察、武器化	—	—	—	—
3 傳遞（點進壞站、下載）	○	●	○	—
4 利用（執行檔案）	●	—	○	—
5 安裝（常駐潛伏）	●	—	—	—
6 指揮控制（資料外傳）	○	○	●	—
7 達成目標（雲端變現）	—	○	—	●

● 主要作用位置　○ 可能輔助　— 幾乎管不到。此表為示意：實務上各層會重疊也有空隙，產品能力與設定不同，結果也不同。

看到第 7 列了嗎？前三層都幾乎管不到，只有雲端帳號自己的設定守得到。這就是為什麼我把「雲端身分與資源」視為第四個管理面：

✔

去看一次 IAM 裡的 Service Account 和已啟用的 API，不認得的就查清楚

✔

預算提醒只是通知，不是上限。API 配額、服務層級的限制與異常用量警報要搭配使用，但配額不一定涵蓋所有計費項目，不能假設單一設定就能守住金額

✔

Service Account 金鑰：不需要就不要建立，建立了要定期檢視與輪替

✔

懷疑憑證被盜時，撤銷 Session、Token 與金鑰，不是只改密碼

這就是「縱深防禦」，也就是安全工程常說的「瑞士起司模型」（Swiss Cheese Model）：每一片起司代表一層防護，每一片都有洞。這個模型原本來自事故分析：單一失誤不會釀成災難，要多層的洞剛好對齊，危害才會一路穿透。回到本案，每一層都有破洞，但破洞的位置不同。釣魚站太新，閘道器放行，防毒也許抓到；防毒沒抓到，木馬外傳時閘道器也許看見；前面都失守，雲端端的用量警報與限制，還有機會讓你更早發現、縮小損失規模（但不保證能守住特定金額）。你不需要某一層完美，你需要的是洞不要剛好對齊。

防守方的大廠，其實也在做同一件事。資安大廠像 Palo Alto Networks，產品從單點的防火牆，一路擴張到端點、雲端、身分與 AI 安全；瀏覽器與作業系統的巨頭，也持續把防護內建進去，例如瀏覽器的安全瀏覽、Windows 的 SmartScreen、macOS 的 Gatekeeper。借用動漫的說法，就是不斷「領域展開」：因為單一領域的防護一定有洞，只好把地盤往外擴，替彼此補位。企業的 IT 部門與個人，能做的是同一件事：疊多層，並且期待洞不要對齊。

提醒：層數多不等於洞不會對齊。如果幾層用的是同一套情資、同一種偵測邏輯，漏掉的東西往往也是同一批，洞反而容易對齊。所以挑選時，最好讓各層守不同的位置、用不同的原理：端點看行為、出口看連線、雲端看身分與用量。

換個角度，也可以用「預防、偵測、限制損失」三個目標，看四個防護面各自負責什麼：

防護面	預防	偵測	限制損失
端點防護	阻止惡意程式執行	偵測異常程序與常駐設定	隔離受感染的電腦
瀏覽器與使用者	降低釣魚與惡意下載	發現異常登入	撤銷登入中的 Session
網路出口	阻擋已知威脅	分析異常外連	阻斷特定通訊
雲端身分與資源	最小權限、金鑰管理	IAM 與 API 異常監控	撤銷憑證、限制配額與資源

八、最後一道底線：被打倒之後，還能站起來

前面講的，都是「降低被擊穿的機率」。但既然單層防禦高機率會被擊穿，多層防護也不是零風險，就該再多問一句：真的被打倒之後，能不能恢復？這是資安韌性的底層基礎，在預防、偵測、限制損失之外，是第四個目標：復原。也是所有 NAS 擁有者的核心思想：

✔

快照：定時保留資料的「時間點」，誤刪或被加密時，可以退回之前的狀態

✔

備份：資料要有獨立於原機器的另一份

✔

異地或異機備份：備份不放在同一台設備、同一個地方，火災、竊盜、同一次感染都不會一起波及

✔

不可刪除與變更的備份：設定保留鎖定期，期限內連管理者帳號也刪不掉、改不了。這點特別重要，因為攻擊者一旦拿到管理者的登入狀態，就等於拿到管理者的權限

✔

定期還原測試：備份「能還原」才算數，沒測過的備份只是心理安慰

要老實說：本案的損失是帳單，不是資料。備份救不回已經被刷掉的費用，所以雲端的用量警報與限制仍然是不可取代的另一道關卡。韌性針對的是資料被加密、被刪除（例如勒索軟體）這類傷害：它讓「被打倒」不等於「倒下就起不來」。

托爾斯泰在《安娜·卡列尼娜》的開頭寫過一句話：「幸福的家庭都是相似的，不幸的家庭各有各的不幸。」資安也是如此。做得好的公司，做法大多相似：分層、盤點、留紀錄。出事的公司，卻各有各的疏漏：這次是仿冒下載站，下一次可能是沒關掉的離職員工帳號、沒有備份的 NAS。所以與其追逐每一種新手法，不如先把各層的洞錯開。

事出必有因

三萬塊的帳單只是鎖鏈的最後一環。更前面是八個月的靜默、兩週的準備，再更前面是一次沒有多想的點擊。矛會不斷升級，機器不會休息，而人的疏忽近乎必然。所以防守不能押注在「人不犯錯」，而要設計成「人犯了錯，系統還撐得住」：把防毒、瀏覽器、閘道器、雲端設定這幾道關卡錯開排好，讓一次失誤不至於變成一場災難。

附錄、Mac 使用者：對照當事人找到的檔案

以下是當事人在他機器上發現的檔案名稱，僅供對照，沒找到不代表乾淨，不同變種的檔名不一定相同。如果真的找到，請先斷網，不要執行、刪除或修改任何東西；記下檔案路徑與時間，找專人鑑識處理。這份清單不是通用的木馬檢查工具，也不建議讀者自行清除。

# 家目錄下的隱藏檔
ls -la ~ | grep -E ‘ \.(mainhelper|pass|id|agent)$’
# 系統層級的開機自動執行設定
ls -la /Library/LaunchDaemons | grep -i finder

一個早上被刷三萬台幣，原因在八個月前的一次點擊：用 Kill Chain 看懂多層防護