Mac 使用者別再以為自己不會中毒！最近一名開發者分享，他的 Google Cloud 帳號疑似因為 Mac 遭到惡意程式入侵，導致攻擊者大量使用 Vertex AI API，短時間內產生約新台幣三萬元的費用。更令人擔心的是，疑似木馬竟然早在八個月前就已經進入電腦。
CyberQ 提醒，即使沒有把 API Key 上傳到 GitHub、沒有安裝 Google Cloud CLI，也有使用兩步驟驗證，仍然可能因為電腦遭到入侵而失去雲端帳號的控制權。
尤其現在許多開發者都開始使用 Claude Code、Codex 等 AI Coding Agent，經常需要下載開發工具、安裝套件，甚至複製網路上的終端機指令。只要其中一個步驟出錯，就可能造成嚴重的資安風險。
CyberQ 帶大家用幾個簡單步驟，檢查自己的 Mac 是否出現可疑木馬檔案，以及如何確認 Google Cloud 有沒有遭到異常操作。
AMOS 是什麼？為什麼 Mac 也會中毒？
AMOS（Atomic macOS Stealer）是一種專門針對 macOS 設計的資訊竊取型惡意程式。
與一般會破壞檔案的病毒不同，這類木馬主要目的是偷偷取得使用者的敏感資料，例如瀏覽器 Cookie、登入階段憑證、儲存的密碼及其他機密資訊。
其中一個危險之處，就是攻擊者可能利用偷來的登入階段憑證冒用使用者身分。即使帳號已經開啟兩步驟驗證，仍然不代表能完全防止這種攻擊。
資安公司 Huntress 曾分析一種 AMOS 攻擊手法：攻擊者利用搜尋結果及看似可信的 AI 教學內容，引導使用者執行惡意指令，接著在 Mac 上安裝木馬，並利用系統背景服務持續執行。
我自己也是用 Mac ，雖然它內建的安全防護雖然有一定程度的保護能力，但不能保證所有惡意程式都會被攔截。
第一步：檢查 Mac 是否有可疑木馬檔案
這次事件中，當事人在 Mac 裡發現了幾個值得注意的檔案：
~/.mainhelper
~/.pass
~/.id
/Library/LaunchDaemons/com.finder.helper.plist而 Huntress 的 AMOS 分析也曾出現以下檔案名稱：
~/.agent
~/.helper
~/.username其中最值得留意的是：
/Library/LaunchDaemons/com.finder.helper.plist
這是一個利用 macOS LaunchDaemon 機制設定背景程式啟動方式的檔案。在已知攻擊案例中，它被用來啟動隱藏的惡意程式。
不過要特別注意，檔案名稱相同不代表一定是木馬，沒有找到這些檔案，也不代表電腦一定安全。
方法一：直接用 Finder 檢查
不熟悉終端機的使用者，可以先用 Finder 檢查。
開啟 Finder，按下：
Command + Shift + G
在「前往檔案夾」輸入以下路徑：
/Library/LaunchDaemons/檢查裡面有沒有：
com.finder.helper.plist接著按下 Command + Shift + G，輸入：
~/這會開啟自己的使用者主目錄。
按下 Command + Shift + .（句點），就能切換顯示隱藏檔案。
看看有沒有 .mainhelper、.agent、.helper 等可疑檔案。
請注意，找到後不要雙擊開啟或執行，也不要急著刪除。
方法二：用終端機一次檢查
如果熟悉一點終端機操作，也可以用下面這段簡單指令檢查。
開啟 macOS 的「終端機」，貼上：
for f in \
"$HOME/.mainhelper" \
"$HOME/.pass" \
"$HOME/.id" \
"$HOME/.username" \
"$HOME/.agent" \
"$HOME/.helper" \
"/Library/LaunchDaemons/com.finder.helper.plist"
do
if [ -e "$f" ]; then
echo "發現檔案：$f"
ls -ld "$f"
else
echo "未發現：$f"
fi
done這段指令只會檢查檔案是否存在，並列出基本檔案資訊，不會執行、修改或刪除任何檔案。
如果全部顯示未發現，表示目前沒有找到這幾個已知檔案名稱，但不能當作完整的防毒掃描結果。
如果出現發現檔案，尤其是 com.finder.helper.plist，則應該進一步確認。
可以使用以下指令讀取該設定檔：
plutil -p /Library/LaunchDaemons/com.finder.helper.plist檢查其中的 ProgramArguments 或 Program 是否指向不明程式，例如隱藏在使用者目錄內的 .agent。
plutil -p 只會解析並顯示設定內容，不會執行其中指定的程式。
這些檔案可能包含敏感資訊，因此不要將完整內容直接貼到公開網站。
第二步：檢查 Mac 有沒有可疑的背景程式
除了上述檔案，也建議檢查是否有不認識的背景啟動項目。
進入：
系統設定 → 一般 → 登入項目與延伸功能
查看登入項目以及允許在背景執行的 App。
如果發現不認識的程式，先確認開發者、安裝來源以及實際檔案位置。
但也不要看到陌生名稱就直接刪除，因為部分正常的系統工具、驅動程式與備份軟體，也會使用背景服務。
另外，macOS 本身具備 XProtect 惡意軟體防護功能。建議保持系統及安全性更新正常運作，也可以使用可信任的資安掃描工具進行額外檢查。
要特別提醒的是，防毒工具可以協助偵測已知威脅，但並非百分之百有效。
第三步：檢查自己的 Google 帳號是否有異常
如果平常會使用 Google Cloud、Gmail 或其他 Google 服務，建議接著進行帳號安全檢查。
開啟 Google 帳號安全性頁面：
https://myaccount.google.com/security
重點檢查最近的安全性活動、目前登入的裝置，以及具有帳號存取權限的第三方應用程式。
看看是否有不認識的裝置、可疑的安全性活動或不再使用的應用程式授權。
如果發現異常，應從可信任的裝置重新設定密碼，並登出不明或可疑的登入階段。
CyberQ 提醒，這裡有一個重要觀念：
沒有收到 Google 異常登入通知，不代表帳號一定沒有被入侵。
因為攻擊者未必使用密碼重新登入，也可能利用已經取得的有效登入階段憑證。
因此，只檢查是否有外國 IP 登入，並不足以判斷帳號是否安全。
第四步：檢查 Google Cloud 是否出現陌生的 Service Account
如果你有使用 Google Cloud，這個步驟非常重要。
登入：
https://console.cloud.google.com
選擇自己的 Google Cloud 專案，然後開啟：
IAM 與管理 → 服務帳戶（Service Accounts）
檢查是否出現自己從未建立、不認識的服務帳戶。
服務帳戶是供應用程式或工作負載存取 Google Cloud 資源的身分，不一定代表惡意行為，也不是所有服務帳戶都會有可下載的私人金鑰。
需要特別注意的是，是否有人新增了陌生服務帳戶，並替它建立私人金鑰或授予過大的存取權限。
也別忘記切換檢查其他專案，因為同一個 Google 帳號可能管理多個 Google Cloud 專案。
接著進入：
API 和服務 → 已啟用的 API 和服務
檢查是否有自己完全不使用，卻莫名其妙被啟用的高費用 API，尤其是 AI 模型、影片生成及運算服務。
如果已經確認有未經授權的服務帳戶或 API，應先保留必要的稽核紀錄，再依風險停用相關憑證與服務。
第五步：使用 Logs Explorer 查出誰建立了服務帳戶
想進一步確認 Google Cloud 是否曾遭到未授權操作，可以使用內建的 Logs Explorer。
進入 Google Cloud Console，搜尋並開啟：
Logging → Logs Explorer
選擇要檢查的專案與時間範圍，然後貼上以下查詢：
protoPayload.methodName="google.iam.admin.v1.CreateServiceAccount"
OR protoPayload.methodName="google.iam.admin.v1.CreateServiceAccountKey"執行查詢後，就可以檢查相關服務帳戶與金鑰的建立紀錄。
特別留意 principalEmail、callerIp、操作時間，以及建立的服務帳戶名稱。
也可以用以下查詢檢查 API 啟用紀錄：
protoPayload.methodName="google.api.serviceusage.v1.ServiceUsage.EnableService"
OR protoPayload.methodName="google.api.serviceusage.v1.ServiceUsage.BatchEnableServices"如果某天突然出現大量啟用 API、新增服務帳戶或建立私人金鑰的紀錄，而且完全不是自己操作的，就值得深入調查。
不過，IP 位址所顯示的國家並不能直接證明攻擊者的位置，單一紀錄也不足以證明某個操作必然是入侵。仍需要與其他證據交叉比對。
第六步：設定 Google Cloud 費用警示與支出上限
這次事件另一個重要教訓，就是不能把費用警示當成費用上限。
進入 Google Cloud Console：
Billing → Budgets & alerts
可以建立每月預算，例如 10 美元、30 美元或其他適合自己的金額。
再設定 50%、90%、100% 等通知門檻。
但要注意，傳統的 Alerts-only Budget 只會發出警示，並不會自動停止 API 使用。
截至 2026 年 11 月，Google Cloud 也已針對部分服務提供 Spend Cap 預算功能，支援的項目包括 Gemini API、Vertex AI、Cloud Run 與 Cloud Run functions。
如果符合適用條件，就可以針對特定專案及服務設定硬性支出限制。
但 Spend Cap 並不是整個 Google Cloud 帳單的全面上限，而且執行限制仍有延遲，實際費用仍可能超過設定金額。
建議同時搭配費用警示、限制不必要的 API 使用量，以及停用不再需要的服務。
如果真的找到疑似木馬，該怎麼辦？
如果 Mac 同時出現多個可疑檔案，而且發現未知的背景啟動設定，建議先將該電腦中斷網路連線，避免可能持續發生的資料外傳。
不要直接執行可疑檔案，也不要隨便複製網路上的移除指令，更不要在疑似遭入侵的 Mac 上重新輸入重要帳號密碼。
應該改用另一台可信任的裝置，檢查 Google 帳號、變更可能外洩的密碼、撤銷可疑登入階段，並停用或更換受影響的 API Key、Service Account Key 等憑證。
如果 Google Cloud 已經出現未授權請求或異常費用，應立即處理可疑服務帳戶和相關 API，必要時暫停專案計費，同時聯絡 Google Cloud 支援團隊。停用服務可能影響正常網站運作，因此需要先評估影響。
至於感染的 Mac，應先保存必要的證據，再交由可信任的資安工具或專業人員處理。若無法確認惡意程式已完整清除，應考慮從可信任來源重新安裝 macOS，並避免直接還原不明的程式與系統設定。
AI 開發時代，最需要防範的可能不是 AI
現在有了 AI Coding Agent，架網站、寫程式、建立雲端服務的門檻越來越低。但這也讓許多人開始習慣執行不熟悉的安裝指令，甚至直接把網路上找到的 curl、bash 或其他程式碼貼進終端機。
以 ISO 27001 資安相關的角度來看，我們需要建立的習慣不是停止使用 AI，而是確認工具來源、理解指令用途，帳號權限的使用與授權儘量也是符合權限最小化原則，不要因為教學看起來專業，就認定其中的命令一定安全。
Mac 並不是不會中毒，兩步驟驗證也不能完全防止登入階段遭竊。至於 Google Cloud，沒有設定適當的費用控管與權限限制，則可能讓單次入侵造成額外的金錢損失。
花幾分鐘檢查 Mac 的可疑檔案、Google 帳號及雲端服務權限，雖然不能保證完全安全，卻是降低風險很實際的第一步。
延伸閱讀
Huntress：AMOS Stealer 與 AI 搜尋結果投毒分析
Google Cloud：LLMJacking 攻擊手法與憑證盜用
Google Cloud：Spend Cap 費用上限官方說明
