第二次被打穿的，是上一次沒換的那幾把

發生了什麼

2026 年 10 月 15 日 13:56（UTC），平台收到使用者回報，啟動調查。這時候攻擊者已經在系統裡待了約 36 小時：第一次使用平台內部的 AWS 金鑰是 10 月 14 日 01:36，中間沒有任何告警響過。

這是同一個部署平台不到兩個月內的第二起資安事件。八月那次，攻擊者從一個使用者部署的應用程式一路走到平台的正式資料庫（拆解在這裡）；三天前我們也把這個平台三年來的公開紀錄排在一起，談「介面變簡單、危險不能跟著變輕」（那篇）。這篇接著寫第二次。

先講這份文件的性質。這篇根據的是平台在 10 月 19 日發布的初步報告，報告開頭就寫明調查還在進行、會隨進度更新。它有一個值得肯定的地方：每個主張都標了確定程度，「已確認」是有日誌直接記錄，「研判」是時間與內容吻合但缺直接紀錄，「推測」則集中放在獨立一節，並寫明不能當事實引用。我們沿用它的分法，報告標「推測」的，這篇一律標 inferred 或 gap。

報告公布的數字：平台資料庫裡的服務環境變數（名稱與值）3,218,965 筆、帳號 321,810 筆（電子郵件、使用者名稱、手機號碼等）、明文的郵件服務 API 金鑰 566 把、平台存取權杖 11,536 筆（只有雜湊值）。共享叢集 9 個區域的服務設定與機密，以及 865 個資料庫服務的容器內被執行過讀取指令。代管於 GCP 的專用伺服器 101 台被以 root 登入，涉及 92 位使用者。

10 月 17 日，創辦人發布停止營運公告：部分服務 12 月 1 日起陸續停止，所有專用伺服器與共享叢集 12 月 31 日前關閉。

2024-01-10
共享叢集的管理權杖建立，沒有期限，之後從未輪替
官方初步報告時間軸
2026-01-20
這把管理權杖以明文寫進平台的私有設定儲存庫
官方初步報告時間軸
2026-08-27
八月事件：平台的 GitHub App 私鑰遭讀取（8 月 31 日更換）；設定儲存庫裡的明文憑證沒有輪替
官方初步報告
2026-09-01 至 09-05
不明來源以 root 密碼登入約 98 台 GCP 專用伺服器；9 月 3 日發現初始化設定保存 root 密碼，事發前未修正
官方初步報告時間軸
2026-10-14 01:36
攻擊者首次使用平台的 AWS 金鑰；01:40 以管理權杖存取共享叢集；13:40 起登入 GCP 專用伺服器
官方初步報告
2026-10-15 13:56
收到使用者回報，啟動調查；16:10 至 16:47 攻擊者讀取平台資料庫
官方初步報告
2026-10-15 21:05
目前觀察到的攻擊者最後活動
官方初步報告
2026-10-17
停止營運公告：12 月 31 日前關閉所有專用伺服器與共享叢集
官方公告
2026-10-19
初步報告發布，更正八月報告「已輪替所有內部管理金鑰」的說法
官方初步報告、狀態頁

怎麼發現

不是平台自己發現的。報告寫明，10 月 14 日持續超過 16 小時的攻擊活動沒有觸發告警，團隊是隔天收到使用者回報才識別事件。

這和八月是同一個形狀：八月也是外部回報金鑰被盜用，平台才知道。報告對這段的解釋是，攻擊者用的是有效憑證、走的是平台的正式存取管道，所以每一筆請求在系統眼中都是合法的。這句話是事實，但也正是問題所在：只會擋「沒有憑證的人」的監控，對「拿著真鑰匙的人」是全盲的。

狀態頁的三次更新也值得看。第一則（10 月 15 日 16:08）只說舊共享叢集上的資料庫遭未授權存取，並寫「目前沒有證據顯示專用伺服器受影響」；4 小時 40 分鐘後的第二則更正為 GCP 專用伺服器也被存取、攻擊者有平台資料庫的讀取權限。範圍在一天內擴大，是調查進行中很常見的事；值得記住的是，第一則通報的範圍不能當成最終範圍。

攻擊者怎麼做到

到這裡，其實已經足夠理解整起事件。如果你關心的是該怎麼避免，可以直接往「如何避免」繼續閱讀。如果你想知道公開資料能還原到哪一步，下面開始進入技術拆解。

一句話：攻擊者沒有用任何漏洞，全程拿的是平台自己的鑰匙，而這些鑰匙都是長期有效、明文存放的。

用 SaaS 時你看得到什麼：上半部是平台內部，路徑 A 從 AWS 金鑰與叢集管理權杖進入 9 個區域的共享叢集，再經舊叢集備份取得機密管理服務金鑰、讀取約 53 筆正式環境機密；路徑 B 從舊 GCP 服務帳號金鑰讀取 root 密碼，取得 101 台伺服器的 root 權限；兩條路徑用內網管理憑證會合成一個帶正式環境權限的節點。中間一條線標示「你的視線只到這裡」，下半部是使用者看得到的部分：存放在平台的環境變數、帳號與專案資料。 — 兩條入侵路徑都發生在平台內部，使用者從後台完全看不到。依官方初步報告的攻擊路徑圖重繪。能看到的只有自己放進去的東西，所以只能假設平台有一天一定會出事：金鑰加用途限制、每個服務用自己的金鑰、設帳單上限、定期輪替。

深入閱讀路徑 A：共享叢集與 AWS

攻擊者先用平台內部的 AWS 金鑰，四分鐘後用共享叢集的管理權杖。兩者都以明文存在私有設定儲存庫。管理介面當時對公網開放、權杖沒有期限，所以攻擊者能從外部直接進入 9 個區域的共享叢集，先讀部分系統機密，12:39 起擴大到所有服務的設定與機密，包括環境變數。

13:40 起，攻擊者在使用者資料庫的容器裡執行讀取指令：先是少數 new-api／one-api，接著大量讀取 n8n，再逐表讀取部分 PostgreSQL。這一步有一個容易忽略的細節：讀取發生在容器內部，所以八月事件後使用者換過的資料庫密碼，擋不住這條路。

接著，攻擊者用叢集裡另一把權限過大的金鑰讀了舊叢集的備份（研判），備份中有一把能讀平台機密管理服務的金鑰。10 月 15 日，攻擊者讀了約 53 筆正式環境機密（已確認），其中有內網管理憑證、平台資料庫帳號、GitHub App 私鑰。

深入閱讀路徑 B：代管的 GCP 專用伺服器

這些伺服器的初始化設定以明文保存 root 密碼，攻擊者手上有一把能讀這些設定的舊 GCP 金鑰。報告研判攻擊者就是這樣拿到密碼，以 root 登入 101 台伺服器，之後在其中 50 台加入自己的 SSH 金鑰維持存取，並在平台的 GCP 專案裡建了 5 台虛擬機器，掛上 16 份客戶伺服器的磁碟複本。

深入閱讀兩條路會合：37 分鐘讀走平台資料庫

攻擊者在路徑 B 拿下的伺服器上，用路徑 A 取得的內網管理憑證加入平台內網。內網規則允許帶特定標籤的節點連線平台資料庫，而內部「唯讀」帳號能讀所有資料。10 月 15 日 16:10 到 16:47，攻擊者讀完了開頭那些數字。報告也特別註明：入侵客戶伺服器並不是加入內網的必要條件，拿到內網憑證就夠了。

還有一段讓應變變難的細節：叢集每日備份會保存所有機密，備份的存取金鑰又和其他機密放在同一個環境。平台在事件中 15:40 換上的新金鑰，被 16:00 的備份收錄，攻擊者 20:30 用了它。輪替後的新鑰匙，又被自動抄進了攻擊者讀得到的地方。

發生了什麼 · MITRE ATT&CK T1078.004

使用設定儲存庫中的平台 AWS 金鑰與叢集管理權杖；最初怎麼取得無法確認

當時留下的訊號

雲端金鑰從陌生來源使用

能擋下它的控制

管理憑證不以明文存放、要有期限、八月事件後全部輪替

報告觀察到攻擊者主要在找能直接用的 API 金鑰，特別是 AI 服務的金鑰：在平台資料庫中搜尋金鑰、大量讀 n8n 與 new-api／one-api 的憑證，也嘗試用平台的 AWS 金鑰呼叫 Amazon Bedrock（全部失敗，沒有產生費用）。10 月 16 日，一位使用者存在平台的 OpenAI 金鑰被用來發出約 1,107 次圖片生成請求，報告推測與這次外洩有關。

攻擊端的入侵指標，報告列了代表性 IP，例如首次使用 AWS 金鑰的 23.106.46.239、以管理權杖存取叢集的 103.237.102.191、9 月初以 root 密碼登入 GCP 的 31.57.201.201。完整清單（含遭植入程式的 PostgreSQL 回連位址）見官方報告；攻擊者大量使用輪替的代理，IP 只能當線索、不能當身分。

這次外洩了什麼

使用者交給平台的東西，和平台自己的鑰匙，這次都在範圍內。

leaked credentials這次外洩了什麼：服務、用途、存在形式

服務	憑證類型	用途	存在形式	放在哪	權限範圍	狀態
使用者存在平台的服務環境變數	名稱與值：AI 與第三方 API 金鑰、雲端金鑰、資料庫密碼、簽章與加密金鑰	使用者應用程式連外部服務	`明文環境變數，存於平台資料庫`	平台資料庫	3,218,965 筆；八月後已遷到自己伺服器的專案不在此範圍	官方要求全部更換，八月換過的也要再換
共享叢集上的使用者資料庫	n8n 第三方憑證、PostgreSQL 資料表、new-api／one-api 的 AI 金鑰與權杖	使用者服務的資料	`資料庫內容；n8n 607 個中有 602 個把加密金鑰放在環境變數，等同明文`	9 個區域共享叢集的容器內	865 個資料庫服務；實際讀走多少無法確認（只記指令不記輸出）	官方要求在資料庫內換密碼、換 n8n 加密金鑰並重建所有憑證
平台帳號資料	電子郵件、使用者名稱、手機號碼、專案與服務資料	平台帳號	`平台資料庫資料列`	平台資料庫	321,810 個帳號	已外洩，無法撤回
平台存取權杖與郵件服務 API 金鑰	平台存取權杖（雜湊）、郵件服務 API 金鑰（明文）	使用者以程式操作平台、寄信	`權杖只存雜湊；郵件金鑰明文`	平台資料庫	權杖 11,536 筆、郵件金鑰 566 把	已全部撤銷
平台內部憑證（AWS、GCP、叢集管理權杖、GitHub App 私鑰、登入簽章金鑰）	雲端存取金鑰、無期限管理權杖、應用程式私鑰、簽章金鑰	平台自身營運	`明文存於設定儲存庫、程式碼、叢集設定與備份`	平台私有設定儲存庫、機密管理服務、叢集備份	約 53 筆正式環境機密；停用 24 組 AWS 金鑰	已撤銷或輪替；GitHub App 私鑰目前未發現遭使用
代管專用伺服器	GCP 主機 root 密碼；Hetzner 與 DigitalOcean 的管理權杖	平台代管使用者的伺服器	`初始化設定中的明文密碼；寫在程式碼與環境變數中的權杖`	GCP 專案設定、平台資料庫	GCP 101 台已確認登入；Hetzner 359 台、DigitalOcean 48 台無法確認是否遭使用	root 密碼已重設、權杖已撤銷；官方建議 GCP 主機備份後重建

憑證本身已遮蔽或失效；這裡只說明它是哪個服務、拿來做什麼、以什麼形式存放，讓你能對照自己的環境。

最後一列特別要注意：持有 Hetzner 或 DigitalOcean 的管理權杖，就能重設密碼、重灌系統或複製磁碟，而兩家服務都沒有可用的操作稽核紀錄。這是報告裡「無法確認」最多的一塊。

證據等級

他們怎麼處理

啟動調查後約 4 小時，平台移除了攻擊者的內網節點。當天陸續做的事：管理介面只允許平台系統連線、撤銷並再次輪替管理權杖、停用攻擊者用的兩把 GCP 金鑰、刪除備份存取金鑰、輪替 GitHub App 私鑰與付款服務金鑰、移除初始化設定裡的 root 密碼、停用 24 組 AWS 金鑰並換上權限更小的、輪替登入簽章金鑰讓所有使用者登出、封鎖 GCP 伺服器的公網 SSH、撤銷全部郵件服務金鑰。隔天撤銷 Hetzner 與 DigitalOcean 的權杖。

之後完成的包括：撤銷所有使用者的平台存取權杖、限制只有指定服務能連平台資料庫、叢集備份不再保存明文機密且備份金鑰分開存放。進行中的是追查外洩來源，以及補上報告列出的五類告警：管理權限異常使用、容器內執行指令、大量讀取機密或資料庫、內網加入新節點、雲端金鑰從陌生來源使用。

對使用者的建議很明確：現在就處理，不要等通知信；八月換過的也要再換。 環境變數裡的所有憑證先到供應商撤銷再換新；共享叢集使用者要在資料庫裡面換密碼（只改平台上的環境變數不會改到資料庫）；n8n 要換加密金鑰並重建所有第三方憑證；GCP 專用伺服器當作已遭入侵，備份後重建。帳單回溯到 10 月 14 日，GCP 專用伺服器使用者回溯到 9 月 1 日。第三方服務因此多出的費用，可透過客服申請賠償。

哪裡做對，哪裡做錯

先講做對的。這份報告的寫法，是我們看過的平台事故報告裡最好的幾份之一：精確到分鐘的 UTC 時間、每個主張標確定程度、推測獨立成節並寫出反證（IP 沒有重疊）、主動更正自己上一份報告的錯誤說法、把無法確認的資料一律當作已外洩。另一件做對的事在八月：提供「把環境變數遷到自己伺服器」的指引與一鍵功能。這次證明它有效，照做的使用者避開了平台資料庫這一刀。

做錯的，報告自己列得很完整，我們只挑三件最值得帶走的。

輪替範圍畫錯了。 八月確認外洩的是 GitHub App 私鑰，平台換了私鑰。但這把私鑰能讀整個 GitHub 組織的所有儲存庫，設定儲存庫裡有明文的 AWS 金鑰與管理權杖；私鑰在被讀走後四天才換。只換私鑰，等於換了大門鎖，卻沒換鎖匠可能已經拷貝走的那串備用鑰匙。正確的範圍是：外洩的憑證在有效期間內碰得到的每一個地方，裡面的每一把憑證都要換。

已知的洞排在待辦裡。 root 密碼明文 9 月 3 日就發現，機密遷移 10 月 3 日啟動、事發時還沒合併。報告沒有說為什麼沒在一個月內處理，我們也不猜。但這件事提醒所有團隊：事件後的改善清單，要按「被利用時損失多大」排序，而不是按「改起來多麻煩」。

「唯讀」不等於「安全」。 內部唯讀資料庫帳號能讀所有資料；只需讀單一儲存空間的金鑰，實際能讀整個 AWS 帳號的儲存空間；停用四個月的服務，部署金鑰還有效。攻擊者這次幾乎沒有「寫」任何東西，光靠讀就拿走了一切。

如何避免

平台端的事，使用者只能要求。下面分兩邊寫。

站在平台的位置：第一，管理權杖與雲端金鑰一律有期限，管理介面不對公網；第二，事件後的輪替以「外洩憑證的可達範圍」畫，並把清單公開到使用者能核對的程度；第三，備份不存明文機密，備份金鑰與其他機密分開，否則每一次輪替都會被下一份備份收錄；第四，內部服務與使用者服務不放同一個叢集；第五，偵測要以「拿著真鑰匙的人」為假想敵，容器 exec、大量讀取、陌生來源用雲端金鑰都要告警。這五點報告都已列進改善項目，只是平台已經決定年底停止營運。

站在使用者的位置，這次事件給了一個很少見的對照組：同一個平台、同一次入侵，有把環境變數遷出平台保管的專案，避開了平台資料庫的外洩；沒遷的，被讀走了。 我們三天前寫的「讓每一把密鑰被讀走時都便宜」，這次有了實證。具體做法：

第一，把平台保管的密鑰當成「可能被讀走」的。能從密碼管理器或雲端機密服務在啟動時注入的，就不要長期明文存在平台的環境變數欄位。

第二，加密金鑰不要和被加密的資料放在同一個地方。n8n 這次 607 個中有 602 個把加密金鑰放在環境變數，加密就等於沒有。

第三，事件後的輪替，自己也要用「可達範圍」畫。平台說「確認外洩的請更換」時，你該問的是：存在那裡的還有什麼？

第四，如果你還在這個平台上，搬遷時不要把所有憑證原樣搬過去。換新平台是一次性換掉全部憑證最好的時機，舊的那一批就讓它在舊平台上一起作廢。

這篇提到的項目要花多少錢

報告沒有公開任何使用者端的損失金額；能算的是「換掉全部憑證」和「讓下一次便宜」的成本。

cost這次事件對一個小團隊的帳

項目	用量	單價	期間	US$	NT$	舉證
攻擊者嘗試以平台 AWS 金鑰呼叫 Amazon Bedrock 報告寫明全部失敗、沒有產生費用	全部失敗	—	2026-10-14 至 10-15	0.00	0	官方初步報告
使用者 OpenAI 金鑰被用於約 1,107 次圖片生成報告未公開金額，且這筆是否來自本次外洩屬推測	約 1,107 次請求	依模型與尺寸而定，報告未公開	2026-10-16 01:50 至 02:56	—	—	官方初步報告
換掉存在平台的全部憑證並重新部署估：取中間值 NT$27,500；先到供應商撤銷再建立新的	約 1 人日（10–30 把憑證）	顧問日費 NT$20,000–35,000（估）	一次性	859.38	27,500	本站假設值
代管 GCP 專用伺服器備份後重建估：只適用 101 台受影響主機的使用者；不含新主機費用	約 1 人日／台	顧問日費 NT$20,000–35,000（估）	一次性	859.38	27,500	本站假設值
AWS Secrets Manager：20 把密鑰改為啟動時注入估：讓密鑰不再長期明文存在平台	20 把	US$0.40／把／月（API 呼叫另計 US$0.05／萬次）	每月	8.00	256	AWS 公開定價
合計（僅可證明列）				0.00	0

匯率假設 1 USD ≈ NT$32。單價為公開牌價或帳單實付，來源：AWS Secrets Manager 公開定價（2026-10 查）；Zeabur 初步報告；本站人力日費假設。「舉證」欄標明每筆損失的證據來源與等級（可證明推論缺口）。

合計只加 proven：這次能確認的直接費用是 0 美元，因為報告沒公開任何一筆使用者端的金額。真正的帳在 gap 那一列，以及那 321 萬筆環境變數背後、每一把還沒換的金鑰。

你可以學到什麼

站在攻擊者的位置：他不需要找漏洞，只需要等。上一次事件的輪替清單告訴他哪些鑰匙已經失效，清單以外、同一個抽屜裡的，就是他接下來要試的。

lessons本案的 5 個教訓

01
輪替範圍要用「外洩憑證在有效期間碰得到什麼」來畫，不是「確認外洩的是哪幾把」。一把能讀整個組織儲存庫的私鑰外洩，要換的是那些儲存庫裡的每一把憑證。
02
備份會把機密一起備份，也會把你剛換上的新機密備份進去。備份金鑰和其他機密放在一起，輪替就追不上。
03
「唯讀」權限照樣能拿走一切。這次攻擊者幾乎只做讀取。
04
只擋沒有憑證的人的監控，對拿著真鑰匙的人是全盲的。要告警的是行為：容器內執行指令、大量讀取、陌生來源使用雲端金鑰。
05
使用者端的防線是有效的：把環境變數遷出平台保管的專案，避開了平台資料庫外洩。讓每一把密鑰被讀走時都便宜，不是口號。

keywords重點學習：最需要學習的 10 個關鍵字10 個

01
輪替範圍（rotation scope）
本篇核心：八月只換了確認外洩的，十月被用的是同一個儲存庫裡沒換的。
02
可達範圍（blast radius）
畫輪替範圍的方法：外洩憑證在有效期間能碰到哪些系統與機密。
03
長期有效憑證（long-lived credentials）
2024 年建立、從未輪替、沒有期限的管理權杖，是這次的入口之一。
04
明文機密（plaintext secrets）
設定儲存庫、初始化設定、備份、程式碼裡都有，攻擊者一路撿。
05
備份中的機密（secrets in backups）
事件中換上的新金鑰被下一份備份收錄，攻擊者照樣用上。
06
容器內執行（container exec）
在資料庫容器裡讀資料，繞過了使用者換過的資料庫密碼。
07
有效帳號濫用（valid accounts）
ATT&CK T1078：拿真鑰匙走正門，以請求是否合法為準的監控看不見。
08
加密金鑰與資料分離（key separation）
n8n 的加密金鑰和資料庫放同一個平台，加密等於沒有。
09
初步報告（preliminary report）
調查中的文件，範圍可能再擴大；第一則狀態頁通報後來就被更正過。
10
入侵指標（IOC）
報告列出的攻擊端 IP 可用來比對自己的雲端與 SSH 紀錄，但代理輪替，只能當線索。

下面五步全部唯讀，做完你會知道自己在這次事件裡還有哪些沒收尾。

try today今天就可以來試試約 15 分鐘

全部唯讀，不改任何設定；做完你會知道自己有沒有同樣的破口。

列出你存在這個平台（或任何 PaaS）環境變數裡、現在還有效的憑證，只列名稱與所屬服務，旁邊標上最後一次更換的日期
看到什麼代表什麼：最後更換早於 2026-10-15 的，全部都還要換一次，包括八月換過的那批。這張表我們叫「rotate-reach-map-p5」，往後每次事件都從它開始畫範圍。
確認你的 n8n 加密金鑰（N8N_ENCRYPTION_KEY）是否和 n8n 資料庫存在同一個平台
看到什麼代表什麼：是的話，n8n 裡的每一個第三方憑證都要當作明文外洩，換加密金鑰之外還要逐一重建。
到 AI 與雲端供應商後台，查 2026-10-14 起的 API 用量與帳單（代管 GCP 主機使用者回溯到 09-01）
看到什麼代表什麼：有不認得的高峰，先撤銷金鑰再查；第三方多出的費用可以向平台客服申請賠償。
如果你有代管的 GCP 專用伺服器，檢查 root 的 authorized_keys 有沒有不認得的公鑰
```
sudo cat /root/.ssh/authorized_keys
```
看到什麼代表什麼：看到註解為 @zeabur-pentest 或不認得的金鑰，代表這台已被植入後門，官方建議備份後重建。
用報告列出的攻擊端 IP 搜尋你自己的 SSH 登入紀錄與雲端稽核紀錄
```
sudo last -i | grep -E '23\.106\.46\.239|103\.237\.102\.191|31\.57\.201\.201|216\.98\.11\.198|45\.58\.38\.175'
```
看到什麼代表什麼：沒有結果不代表安全（攻擊者輪替代理），有結果就把這台主機上的所有憑證當作已外洩。

想看全部細節？

環境背景、時間線、攻擊鏈對照 ATT&CK、關鍵證據、根因、處置與檢討都在完整版，約 10 分鐘。

來源

本文為公開報導與官方公告的整理與拆解，非第一手鑑識；證據等級依來源可信度標註。

本文由 AI 團隊協助研究與撰寫，經隱私與事實檢查後發布；證據等級依來源可信度標註。

Zeabur PaaS 憑證輪替平台事故報告環境變數

看完的心情

ai prompt把這篇的切入點帶回你的環境

複製下面這段，貼給你在用的 AI 工具（Claude Code、Cursor、Copilot、ChatGPT 都可以）。它會用本篇的破口位置、自我檢測與學習重點，對你的專案或環境做一次資安掃描，列出潛在問題與建議的調整或加強方式。

允許 AI 直接修正（每項修改前仍會先問我）

預設是唯讀：只發現問題、提出建議，不會改你任何檔案或設定。

對應課程模組

M2 身分與金鑰 · M5 偵測與告警 · 想在自己的環境做一次同樣的盤點，從自我盤點開始。

← 上一份暗網說有 75 萬筆 LINE Pay 個資，公司說不是我們的：先別急著選邊下一份 →PHP 核心兩個 RCE 在修補前外洩，六成對外主機沒有官方修補版可裝