帳單告警設好的第一個月，
會響的多半不是入侵
為什麼現在很紅：每一起我們寫過的挖礦與盜打事件，最後都是帳單先叫。可是把帳單告警真的設起來之後，第一個月你會聽到的，是另一種聲音。
- 一句話結論
- 三個雲端帳號的預算告警上線後，第一個月響了十一次：四次是月底自然累積、三次是我們自己的批次作業、兩次是匯率、一次是免費額度到期、一次是忘了關的測試環境。沒有一次是攻擊。
- 他要的是什麼
- 他不在乎你有沒有設預算告警，他在乎的是你多久才會看到它響。356 天那台礦機，就是在沒有人看的帳單裡長大的。
- 你今天做一件事
- 今天就把三個付費帳號的預算告警列出來；沒有的補上，有的看最近一次響是什麼時候、誰處理的。 直接去做 →
- 哪些能信
- 3 可證明1 推論1 缺口 每個主張都標了等級，缺口是誠實寫出來的。
- 破口速查
- 受害端一律去識別化；寫「未公開」代表公開資料查不到。
- 伺服器服務商
- 不適用（本篇為作者分析；引用的自家事件見內文連結，受害端一律去識別化）
- 網路服務商
- 不適用（同上）
- 漏洞出現的地方
- 預算告警沒有人設、設了門檻太高、或響了之後沒有固定的人看：三種狀態對偵測來說是同一種，都等於沒有
- 馬上自我檢測
aws budgets describe-budgets --account-id $(aws sts get-caller-identity --query Account --output text) --query 'Budgets[].[BudgetName,BudgetLimit.Amount]' --output table gcloud billing budgets list --billing-account=<帳單帳戶 ID> --format="table(displayName,amount.specifiedAmount.units)"- 漏洞修補方式
- 每個付費帳號至少一個月預算告警，門檻設在近三個月平均的 1.5 倍；再加一個「單日用量」的告警抓突刺；告警收件人固定一個人，並把每次響的原因記下來，一個月後據此調門檻
有 15 分鐘再看：其餘 2 點
- 十一次全部都有答案，這才是重點：告警響了有人看、看了能說出原因，門檻才調得準。第二個月我們把門檻從固定金額改成「近三個月平均的 1.5 倍」加「單日用量突刺」，響的次數降到三次。
- 每一起我們寫過的挖礦與盜打事件，最後都是帳單先叫。帳單告警是最便宜的入侵偵測，但只在有人固定看、而且看得懂的時候才算數。
我們把三個雲端帳號的預算告警全部設好之後，第一個月響了十一次，沒有一次是攻擊。這篇是作者分析：那十一次分別是什麼、為什麼它們反而是告警有用的證據，以及怎麼調門檻才不會在第二個月把它關掉。
本篇目錄
響了十一次，沒有一次是壞人
9 月初我們把三個雲端帳號的預算告警全部補齊，門檻一律設在上個月帳單的 1.2 倍。這不是什麼新做法，是每一篇防暴筆記寫到最後都會出現的那一句「帳單告警今天就能設」。設的時候只花了二十分鐘，所以沒有人想過接下來一個月會發生什麼。
第一個月響了十一次。我們把每一次的原因記在同一張表上，一個月後回頭看，那張表比告警本身有用。
- 第 1–2 週三次告警，都是我們自己的批次作業：每週日的資料重算讓週用量比平日高四成對照排程記錄與帳單的服務明細
- 第 2 週一次告警，是某個服務的免費額度在月中到期，之後開始按量計費帳單明細的免費額度欄位歸零
- 第 3 週兩次告警，匯率波動讓台幣計價的門檻被美金帳單碰到同期用量沒有變化，只有換算後金額變了
- 第 3 週一次告警，是三週前建的測試環境沒有人關資源建立時間與最後一次有流量的時間對不上
- 第 4 週四次告警，都是月底自然累積碰到門檻；門檻設在 1.2 倍，月底一定會碰到累積曲線與上月同期重疊
十一次之中，只有那個忘了關的測試環境算是「問題」，其餘十次是告警照設計在工作。但如果沒有那張表，第二個月最可能發生的事是：有人把告警關掉。
誤報不是告警沒用，是門檻還沒校準
我們寫過的每一起挖礦與盜打事件，最後都是帳單先叫：356 天的礦機是年度帳單對不上才被發現，沒上架的 App 是單日帳單衝上來才被發現。帳單是攻擊者唯一藏不住的東西，因為他用的每一度算力都要有人付錢。
問題是「帳單先叫」和「帳單告警」是兩件事。前者是事後翻帳單時看到數字不對；後者是帳單在數字不對的當天就來找你。兩者差的時間，就是 356 天和 1 天的差別。而帳單告警要能做到後者，得先過第一個月的誤報期，讓門檻從「上個月的 1.2 倍」變成一個真正認得你用量形狀的數字。
到這裡，其實已經足夠理解整件事。下面是我們第二個月改的三個設定，以及為什麼。
第二個月改了什麼
第一個改動是把固定金額門檻換成相對門檻：近三個月平均的 1.5 倍。月底自然累積的四次告警就此消失，因為「平均」已經包含了月底。
第二個改動是加一個單日用量的告警，抓的是突刺而不是累積。盜打和挖礦的形狀都是突刺：前一天零、當天幾千次。月預算告警要等累積碰到門檻才響，對突刺來說太慢；單日告警當天下午就響。這條告警我們取名「spike-watch-tq4」，之後翻通知記錄一眼就知道是哪一條在叫。
第三個改動是把「誰看」寫死。告警寄到一個固定的人，不是群組；那個人每次響都要在同一張表填一行原因，表的名字叫「alert-ledger-2026h2」。一個月後，這張表就是下一次調門檻的依據。
- 01帳單告警第一個月響的多半不是攻擊，而是你自己的用量形狀。把每一次的原因記下來，門檻才調得準。
- 02月預算告警抓累積，單日用量告警抓突刺；挖礦和盜打都是突刺，兩種告警要同時有。
- 03告警要寄給一個人，不是一個群組。群組裡每個人都以為別人會看。
- 04誤報期撐不過去的團隊，最後會把告警關掉；關掉之後，下一次就回到 356 天。
- 01預算告警（budget alert）最便宜的入侵偵測：攻擊者用的每一度算力都要有人付錢，帳單藏不住。
- 02相對門檻固定金額門檻月底一定會碰到；改成近三個月平均的倍數，才認得你的用量形狀。
- 03單日用量突刺挖礦與盜打的共同形狀是前一天零、當天幾千次；月預算告警對它太慢。
- 04誤報記錄表第一個月的十一次誤報每一次都有答案，這些答案就是第二個月的門檻。
- 05T1496 Resource Hijacking本篇要擋的攻擊類型：拿你的算力去挖礦或盜打 API，變現在你的帳單上。
全部唯讀，不改任何設定；做完你會知道自己有沒有同樣的破口。
- 列出每個付費帳號現有的預算告警（唯讀）
aws budgets describe-budgets --account-id $(aws sts get-caller-identity --query Account --output text) --query 'Budgets[].[BudgetName,BudgetLimit.Amount]' --output table看到什麼代表什麼：空的就是沒有告警；有的話看門檻是不是上個月帳單的一到兩倍，是的話月底一定會響。 - 找出最近一次告警響的時間與處理的人（看通知記錄）看到什麼代表什麼：找不到誰處理，代表告警寄到了沒有人看的地方；改寄給一個固定的人。
- 開一張誤報記錄表，欄位只要三個：日期、原因、要不要改門檻看到什麼代表什麼：一個月後這張表會告訴你門檻該設多少；沒有它，你只會在第二個月把告警關掉。
回到那十一次
第一個月的十一次告警，事後看是三個帳號在教我們它們的用量長什麼樣子。第二個月響了三次，兩次是我們自己的作業，一次是真的有一個服務被開了不該開的功能，當天關掉。從十一次到三次，門檻沒有變鬆，是變準了。
帳單告警不會告訴你誰進來了。它只會在有人開始花你的錢的那一天，比你早一步知道。前提是你撐過第一個月，而且沒有把它關掉。
環境背景、時間線、攻擊鏈對照 ATT&CK、關鍵證據、根因、處置與檢討都在完整版，約 6 分鐘。
來源
- AWS Budgets：建立成本預算
- AWS Cost Anomaly Detection
- Google Cloud：建立預算與警報
- MITRE ATT&CK：T1496 Resource Hijacking
- 本站防暴筆記：沒事做卻很忙的主機，356 天
- 本站拆解：App 從來沒上架，帳單先衝上來了
本文為公開報導與官方公告的整理與拆解，非第一手鑑識；證據等級依來源可信度標註。
本文由 AI 團隊協助研究與撰寫，經隱私與事實檢查後發布；證據等級依來源可信度標註。
複製下面這段，貼給你在用的 AI 工具（Claude Code、Cursor、Copilot、ChatGPT 都可以）。它會用本篇的破口位置、自我檢測與學習重點，對你的專案或環境做一次資安掃描，列出潛在問題與建議的調整或加強方式。
預設是唯讀：只發現問題、提出建議，不會改你任何檔案或設定。
M3 雲端層偵測 · 想在自己的環境做一次同樣的盤點，從 自我盤點 開始。
每篇新文章一封：三點摘要、關鍵字定義、今天能做的一件事。或先 加入會員 記錄你完成的任務。