新聞稿拆解

攻擊打在一家 SaaS,詐騙信卻用好幾個品牌的名字寄出

電商 SaaS 平台 91APP(6741)10 月 16 日清晨發重訊:Commerce Cloud 資料庫遭「自動化攻擊」,部分資訊被非法擷取。重訊沒寫幾筆、哪些欄位、哪些品牌;可是品牌的客人已經收到帶著真實訂單內容的詐騙信。這篇拆開能證明的、只能推的、沒人講的,以及品牌端今天能做什麼。

30 秒看懂
  • 第一手是 91APP 在發重訊當天清晨 6 點 30 分公告的重訊:事實發生日 10 月 14 日,Commerce Cloud 資料庫遭「自動化攻擊」,部分資訊被非法擷取;已控制、已報案、已委第三方調查並依法通報主管機關,評估對營運無重大影響。
  • 重訊沒寫筆數、欄位、受影響品牌數,也沒寫入口。品牌端的公告(經媒體轉述)補上了一部分:客人收到的詐騙信帶著真實的姓名、電話、地址和訂單內容,品牌端最早的消費者反映,早於重訊寫的事實發生日。
  • 10 月 20 日天下雜誌訪到 91APP 公關總監:10 月初就陸續收到品牌反映可疑詐騙信,清查內部與物流、代操等第三方找不到原因,委請奧義智慧鑑識,10 月 14 日才確認資料庫遭入侵,再回溯出 10 月 3 日的攻擊紀錄。從攻擊到確認十一天、到重訊十三天,現在是 91APP 自己說的。
  • 這起事件的形狀是多租戶的爆炸半徑:攻擊打在一家 SaaS,詐騙信用的是好幾個品牌的名字。品牌把資料放上平台,責任沒有一起交出去;品牌今天能做的,是知道自己的資料放在哪、合約怎麼寫,並放一個自己看得到的訊號。

收到信的人,不知道 91APP 是誰

想像一棟商辦大樓,一樓的管理室替每一家進駐的店保管客人的取貨單。有一天管理室的櫃子被人打開,裡面幾十家店的取貨單被抄走。接下來幾天,客人陸續接到電話:「我是某某店客服,您的訂單重複扣款了。」客人認得那家店,不認得管理室。

2026 年 10 月 16 日清晨 6 點 30 分,電商 SaaS 平台 91APP(91APP*-KY,6741)在公開資訊觀測站發了一則重大訊息:公司「查知 Commerce Cloud 資料庫受到自動化攻擊,並對部分資訊非法擷取,目前已獲得控制,並已向警方報案」,事實發生日填 115/10/14。同一天,91APP 在官網發布同內容的說明。Commerce Cloud 是 91APP 給零售與餐飲品牌開自有官網商店、管會員與訂單的平台,前台掛的是品牌的名字。

先講清楚這份第一手文件的性質。重訊是法遵文件,回答交易所的固定欄位,不是事件調查報告;它告訴你「出事了、處理了、影響不重大」,不告訴你「幾筆、哪些欄位、從哪裡進來」。這篇能補上的部分,來自品牌自己的公告與媒體轉述,那些我會另外標出來,不和重訊混在一起。

重訊重點節錄(91APP*-KY 6741,發言時間依鉅亨網 06:30:09,經鉅亨網與 MoneyDJ 轉載)READ-ONLY
1. 事實發生日:115/10/14
2. 發生緣由:本公司 Commerce Cloud 資料庫受到自動化攻擊事件說明。
3. 處理過程:查知 Commerce Cloud 資料庫受到自動化攻擊,並對部分資訊非法擷取,
 目前已獲得控制,並已向警方報案。依個資事故通報及處理流程啟動應變會議,
 委請第三方資安公正單位協助調查,依法通報相關主管機關。
 透過電子郵件等相關管道進行反詐騙宣導。
4. 預計可能損失或影響:目前評估對公司營運無重大影響。
5. 可能獲得保險理賠之金額:不適用。
6. 改善情形及未來因應措施:
 (1) 強化監控防禦:升級全天候監控,全面提升系統防護層級。
 (2) 委外第三方公正單位調查:協同外部專家深入調查,並於相關主機全面部署防護機制。
 (3) 確實落實隔離:強化自研系統、第三方系統與辦公室之網路環境隔離降低滲透風險。
 (4) 持續防護優化。
 (5) 通報與客戶通知:依法通報主管機關,並主動透過電子郵件等方式通知受影響之客戶。

把能查到的時間排開。注意第二、三、四列:它們全部早於重訊寫的事實發生日,而且全部來自品牌端,不是 91APP。

  1. 2026-10-03 11:00(依品牌公告)
    合作品牌「你滋美得」公告寫:91APP Commerce Cloud 資料庫於此時遭受自動化攻擊
    蕃新聞(威傳媒)、天下雜誌轉述該品牌公告;91APP 重訊沒有這個時間,但公關總監受天下雜誌訪問時說,10/14 確認入侵後「往前回溯出 10 月 3 日的攻擊紀錄」
  2. 2026-10 月初
    91APP 陸續收到品牌反映可疑詐騙郵件,清查內部與客戶端物流、代操等第三方環節,一開始找不到明確原因,之後委請奧義智慧協助鑑識
    天下雜誌 2026-10-20 引述 91APP 公關總監
  3. 2026-10-05(依品牌說法)
    有合作廠商表示異常狀況這天前後就已出現
    TVBS 2026-10-18 報導引述未具名合作廠商;天下雜誌 2026-10-20 寫明是快車肉乾對外表示;未說明是什麼異常
  4. 2026-10-12 下午起(依品牌公告)
    2nd STREET TAIWAN 陸續接獲消費者反映,收到冒用品牌名義、含真實訂單與個人資訊的可疑郵件
    蕃新聞(威傳媒)轉述該品牌防詐公告
  5. 2026-10-14
    重訊填寫的事實發生日;依 91APP 受訪說法,是鑑識確認資料庫遭入侵的日子
    公開資訊觀測站重訊(鉅亨網、MoneyDJ 轉載全文);「確認日」的解釋來自天下雜誌引述 91APP 公關總監
  6. 2026-10-16 06:30(台北時間)
    91APP 發布重訊:Commerce Cloud 資料庫遭自動化攻擊、部分資訊遭非法擷取,已控制、已報案、已通報主管機關
    公開資訊觀測站重訊;同日官網聲明
  7. 2026-10-16
    電商頒獎典禮上,多個同時經營品牌官網的業者互問「你有被駭嗎」;有人當天早上才收到通知,有人不知道自己外洩多少資料
    天下雜誌 2026-10-20 報導
  8. 2026-10-18
    媒體報導多個合作品牌各自發防詐公告
    TVBS 報導(標題寫「竟沒主動通知」;內文為未具名廠商稱 10/5 已有異常、91APP 16 日才公告;快車肉乾稱將通知半年內下過單的客人)
  9. 2026-10-19 前(本站取得日)
    合作品牌 CY JOYCE 喜悅發「重大訊息公告」:引用 91APP 10/16 消息、向會員致歉,重申不會在 LINE 或電話要求刷卡、解除分期或操作 ATM
    品牌公告原文(讀者提供,本站未取得公告網址與發布時間)
  10. 2026-10-19
    數位發展部到 91APP 總部進行行政調查;同日 91APP 股價盤中最低 48.2 元,收 49.2 元,跌 8.04%
    鏡週刊報導(三立新聞轉載)、天下雜誌 2026-10-20 報導;檢查項目未公開
  11. 2026-10-19
    服飾公司滿心(2916)發重訊:接獲消費者反映個資疑似外洩,原因是委外服務平台廠商的資料庫遭自動化攻擊、部分資訊遭非法擷取;已要求廠商釐清是否涉及滿心資料與受影響範圍,評估對財務與業務無重大影響
    iThome 2026-10-20 報導;重訊沒有寫出廠商名稱,iThome 依滿心官網的反詐騙警示指出與 91APP 電商系統有關
  12. 2026-10-21 09:00 前後
    生技醫療公司立康(6242)發重訊:10-20 接獲消費者反映,疑似有第三方從委外廠商管理的購物平台不當取得資料,並以 email 聯繫消費者;已啟動應變、要求委外廠商做資安檢視,原因與範圍仍在調查,評估對財務與業務無重大影響
    iThome 2026-10-21 報導;立康重訊沒有寫出平台名稱,與 91APP 的關聯是 iThome 依時間與手法相近所做的聯想,本站未取得立康的公開確認
  13. 未公開
    外洩筆數、欄位清單、受影響品牌數、入侵途徑
    截至 2026-10-20,重訊、官方聲明與報導皆未揭露;天下雜誌寫,截至數發部進場調查,91APP 仍未公布受影響品牌總數、外洩筆數、全部欄位與完整攻擊入口

從攻擊開始到重訊,中間隔了十三天;從客人收到詐騙信到重訊,隔了四天。這兩個數字最早只出現在品牌公告裡,10 月 20 日 91APP 公關總監接受天下雜誌訪問時,等於把第一個數字認了下來:10 月 3 日是事後回溯出的入侵時間,10 月 14 日是公司確認事故的時間。重訊上只填了後者。

先有動靜的,是品牌的客人

重訊寫的是「查知」,沒有寫怎麼查知、誰先查知。品牌端的公告則給了另一個起點:2nd STREET TAIWAN 的公告(經媒體轉述)寫,品牌「陸續接獲消費者反映」收到冒名的可疑郵件。品牌之後如何確認資料是從平台流出,公開資料看不到。

這個順序對品牌很殘酷。客人收到的信寫著品牌的名字,裡面的姓名、電話、地址、買過的東西都是真的,所以客人找的是品牌,不是平台。品牌這時候手上什麼都沒有:資料不在自己的機房,存取紀錄在平台那邊,連「這是不是我們這裡漏出去的」都得等平台回答。TVBS 報導引述一位未具名的合作廠商,說異常 10 月 5 日就已出現,91APP 到 16 日才公告;天下雜誌之後寫明這是快車肉乾的說法,但所說的異常是什麼,仍沒有細節。

天下雜誌訪到的一位品牌電商老闆,把這個順序講得更具體:他不是先從 91APP 得知,而是客人上門投訴後主動去問,才得到「確實有此事」的回覆;詐騙信裡的姓名、電話、住址,他估計七、八成是真的。之後是一連串的成本:客人打來要刪會員,客服加班到晚上 10 點、週末沒停,門市、LINE 與官網反覆發防詐公告,而透過平台系統發這些公告,平台還可能收費。另一位品牌主管則說,品牌得自己報案、準備通報資料,卻不清楚被擷取的資料期間與數量。

品牌公告的語氣也值得看。CY JOYCE 喜悅的公告(本站取得的是讀者轉來的原文)先交代「長期使用 91APP 之購物網站服務平台」,引用 91APP 10 月 16 日的說法,接著寫「無論發生在哪一個環節,守護會員的個人資料與權益,都是喜悅國際不能推卸的責任」,最後重申不會在 LINE 或電話中要求刷卡、補救、解除分期或操作 ATM,並列出官方 LINE 帳號與 165。這份公告沒有提到外洩欄位或期間,因為品牌自己也拿不到;它能給客人的,就只有道歉和「我們不會這樣聯絡你」。媒體點名發過公告的品牌另有快車肉乾、聯華食品、CAFE!N、摩曼頓、布朗博士、媽媽好、OB 嚴選等(TVBS 2026-10-18 報導,用的是「包含」,不是完整名單)。

品牌本身是上市櫃公司時,事情會再往前走一步:品牌自己也得發重訊。10 月 19 日服飾公司滿心(2916)、10 月 21 日生技醫療公司立康(6242)先後在公開資訊觀測站發布資安重訊(依 iThome 報導),兩份寫法幾乎一樣:接獲消費者反映、問題出在委外廠商管理的平台、已要求廠商釐清範圍並做資安檢視、評估對財務與業務無重大影響。兩份重訊都沒有寫出平台的名字。滿心的關聯有官網的反詐騙警示可以對上 91APP(依 iThome);立康則沒有,連到 91APP 是 iThome 依時間與手法做的聯想,本站同樣只能列為推論。

立康這份重訊多給了一個時間點:它是 10 月 20 日才「接獲消費者反映」,比 91APP 發重訊晚了四天。如果立康確實是同一起事件的受影響品牌,這代表平台的通知沒有比客人的投訴更早送到它手上,和上面那位電商老闆的經驗是同一個形狀。立康是生技醫療公司,購物平台上的購買紀錄可能涉及保健或醫療用品,這類紀錄本身就比一般零售敏感,詐騙信若能寫出「你上次買了什麼」,可信度只會更高。

攻擊者怎麼做到

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

白話結論:公開資料只證明了兩件事,一是有人用程式大量地從平台的資料庫拿走資料,二是這些資料被拿去寄詐騙信。從哪裡進來、用了誰的權限、拿了多久,全部空白。

「自動化攻擊」這四個字能推到哪裡

「自動化攻擊」不是一個技術分類,它描述的是「量」與「節奏」:不是一個人坐在電腦前一筆一筆查,而是程式在跑。符合這個描述的常見形狀至少有四種,下面只講形狀,不講做法。

第一種是憑證填充(credential stuffing),拿別處外洩的帳密批次去試平台的登入。第二種是 API 授權缺陷,例如查訂單的介面只檢查「有沒有登入」,沒檢查「這筆訂單是不是你的」,程式只要換編號就能一筆一筆讀,這類問題常被叫做 IDOR 或 BOLA。第三種是自動化掃描找到對外系統的已知漏洞,打進去之後再查資料庫。第四種是拿到一把有讀取權限的內部憑證,例如服務帳號或 API 金鑰,再用程式批次匯出。

哪一種都有可能,公開資料不足以排除任何一種。但重訊的措施欄有兩個字詞值得注意:(2) 寫的是「於相關主機全面部署防護機制」,(3) 寫的是「強化自研系統、第三方系統與辦公室之網路環境隔離降低滲透風險」。如果問題只是前台登入被撞庫,修補通常會講帳號保護、登入限制或強制改密碼;講主機防護與網路隔離,比較像是在處理「進到內部之後能走多遠」的問題。

深入閱讀對照 MITRE ATT&CK:五格裡兩格有證據入口、橫向移動、最終損失三格空白
發生了什麼 · MITRE ATT&CK T1190
入口未公開。候選至少有:對外應用程式漏洞(T1190)、有效帳號或憑證被濫用(T1078)、API 授權缺陷。重訊只寫「自動化攻擊」。
當時留下的訊號
WAF 與 API 閘道上,單一來源或單一帳號的請求量與失敗率異常。
能擋下它的控制
對外 API 逐筆檢查資料歸屬;登入與查詢加速率限制;管理介面不對外。

五格裡只有第二格與第四格有文字可以對上,而且第四格的文字來自品牌,不是平台。

為什麼是好幾個品牌一起出事

這是 SaaS 的本質,不是 91APP 特有的問題。品牌不用自己養工程團隊、不用自己顧機房,代價是資料跟其他品牌放在同一個平台裡。平台的程式碼、帳號體系、資料庫可能是共用的,即使資料在邏輯上分開,同一個缺陷也會同時打開每一個品牌的抽屜。

            攻擊者(程式化存取)
                    |
                    v
   +------------------------------------+
   |  SaaS 平台:Commerce Cloud 資料庫   |
   |  共用的程式、帳號體系、主機與網段   |
   +------------------------------------+
      |        |        |        |
   品牌 A   品牌 B   品牌 C   ...(數量未公開)
      |        |        |
   客人收到的詐騙信,署名是 A、B、C,不是平台

TVBS 報導列出七個品牌(以「等」收尾,未給總數),從肉乾、零食、咖啡到嬰幼兒用品;91APP 2017 年前後的技術報導寫它服務超過一萬家品牌企業。實際受影響的是其中多少家,目前沒有人公開。

天下雜誌訪到另一家同業 SaaS 的總經理,他明講沒有參與本案鑑識、不能斷言 91APP 的破口,但點出多租戶最該守的一條:最小使用範圍。一項服務如果只需要查單一商店,就不該有跨商店取用資料的能力。危險的不只是權限太大,而是公司可能根本不知道某段多年沒動的舊服務、或某個 AI Agent 握著這麼高的權限。這是設計原則,不是本案的結論;但它說明了為什麼同一個缺陷能一次打開很多個品牌的抽屜。

這次外洩了什麼

重訊只寫「部分資訊」,沒有提到任何帳號、密碼、金鑰或 token。下表第一列來自品牌公告與消費者描述,其餘都是空白。

leaked credentials這次外洩了什麼:服務、用途、存在形式
服務憑證類型用途存在形式放在哪權限範圍狀態
91APP Commerce Cloud 資料庫(多品牌)消費者姓名、電話、送貨地址、訂單與配送資訊(個人資料,非憑證)品牌官網商店的訂單處理與出貨未公開SaaS 平台資料庫依 2nd STREET TAIWAN 公告(經媒體轉述)與 TVBS 消費者描述;一家品牌估計三個月內下過單的客人可能受影響,更早的不確定已被用來寄冒名詐騙信
同上會員帳號、密碼(或雜湊)消費者登入品牌官網商店未公開同上重訊與官方聲明沒有提到,也沒有要求消費者改密碼無公開資訊
同上付款資訊(卡號等)結帳未公開未公開是否存放在此資料庫沒有提到不等於沒有發生,也可能根本不在這個資料庫無公開資訊
平台端存取憑證(資料庫帳號、服務帳號、API 金鑰、品牌後台管理帳號)未公開———攻擊者用什麼權限讀到資料庫,是本案最關鍵的缺口無公開資訊
憑證本身已遮蔽或失效;這裡只說明它是哪個服務、拿來做什麼、以什麼形式存放,讓你能對照自己的環境。

第一列標推論,是因為 91APP 自己沒有列出欄位;欄位是品牌公告與收到信的消費者說的,本站沒有看到公告原文,只看到媒體轉述。

他們怎麼處理

照重訊與官方聲明排一次。先是查知攻擊、啟動個資事故應變會議;接著宣稱「已獲得控制」,並向警方報案、委請第三方資安公正單位調查、依法通報主管機關;對外的動作是透過電子郵件等管道做反詐騙宣導,並主動以 email 通知受影響的客戶。往後的承諾是升級全天候監控、在相關主機部署防護、強化網段隔離、持續優化。財務評估是「目前評估對公司營運無重大影響」,保險理賠欄填「不適用」。

10 月 20 日天下雜誌的訪問補上了重訊沒寫的過程。91APP 公關總監說,10 月初陸續收到品牌反映可疑詐騙郵件,公司清查內部,也清查客戶端的物流、代操等第三方環節,一開始找不到明確原因,之後委請資安公司奧義智慧協助鑑識,到 10 月 14 日才確認資料庫遭入侵。對品牌抱怨用 91APP 系統發防詐訊息可能被收費,回應是仍在討論妥適做法;對補償,承認「這是我們的問題」,正研擬對品牌與消費者的配套。

這裡的「客戶」要讀仔細。91APP 的客戶是品牌,不是消費者。重訊說要通知「受影響之客戶」,指的很可能是品牌;消費者那一端,從報導看,是品牌自己在發防詐公告,至少有一家品牌自己寄信給半年內下過單的客人。

哪裡做對,哪裡做錯

做對的地方有三個。第一,發了重訊,而且把「自動化攻擊」「非法擷取」寫出來,沒有用「異常存取」這類更模糊的字。第二,同時做了報案、委外調查與通報主管機關,三條線都有。第三,措施沒有只寫「加強監控」,而是寫到主機防護與網段隔離,這代表調查方至少把內部擴散當成一個問題在看。

該改的地方,在品牌那一端感受最深。品牌端最早的消費者反映,早於重訊的事實發生日;TVBS 的標題寫品牌「竟沒主動通知」,內文則是一位未具名廠商的說法。91APP 的解釋是十一天都花在找原因:先查自己、再查物流與代操,最後才請外部鑑識。這可以理解,但它也說明了問題在哪:從「品牌陸續反映」到「確認」之間,平台沒有先告訴所有品牌「我們收到這類反映、正在查」。品牌在對消費者負責的那幾天裡手上沒有資訊,這是 SaaS 合約與事故通知流程的缺口,不只是一家公司的問題。另外,重訊沒有給品牌與消費者任何可以自己核對的東西:哪段期間的訂單、哪些欄位、要不要改密碼。這些就算還在調查,給一個「目前已知範圍」也比空白好。

如何避免

這一節寫給把電商開在 SaaS 平台上的品牌。平台內部怎麼修,你管不到;你管得到的是自己知不知道、多快知道、出事時合約站不站得住。

今天就能做的,是兩件只看不改的事。打開你用的每一個 SaaS 平台後台,看有哪些管理員帳號、哪些 API 金鑰或外部串接,最近 30 天誰登入過;認不得的帳號、離職同事的帳號、沒人記得為什麼建的金鑰,都先列下來。然後翻出合約,找「事故通知」那一條:平台確認出事後幾小時內要通知你、用什麼管道、要附哪些資訊。找不到,就是答案。

本週可以做兩件不花錢的事。一是在每個平台裡各放一筆誘餌資料:用只在那個平台出現的 email 地址下一張真的訂單或註冊一個會員。這個信箱平常只會收到那個平台的正常通知,一旦收到冒用你品牌的「訂單重複」信,你就比客服電話更早知道,而且知道是哪一個平台流出去的。二是把自家網域的 DMARC 調到 quarantine 以上,並在官網放一則常駐的公告:官方寄件網域是哪些、官方不會用電話或 LINE 要客人做的事。

這一季要做的是合約與法遵。新簽與續約的 SaaS 合約加上三條:事故通知時限(例如確認後 24 小時內,並附已知的期間與欄位)、品牌可以調閱與自己租戶相關的存取紀錄、出事時平台協助品牌履行對消費者的通知義務,而且這段期間透過平台發的防詐通知不另收費。天下雜誌的報導另外列了幾項值得一起寫進去的:外洩欄位與影響範圍、第三方鑑識摘要、資料隔離方式、稽核權、備援機制與賠償責任。客服話術、會員通知稿與停損流程,則是品牌自己要先備好的。同時確認自己適用哪一套個資安全維護辦法、72 小時通報要報給誰。資料放在平台上,個資法第 4 條仍把受託者視同委託者;在客人眼裡,寄信的是你。

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

屬於本案又能證明的金額是零:重訊寫「目前評估對公司營運無重大影響」,保險理賠填「不適用」,兩個都不是數字。下表其他列,是品牌端的估算與拿來對照的別人的數字。

cost一次 SaaS 平台外洩,平台與品牌各自的帳單
項目用量單價期間US$NT$舉證
91APP 本次事件直接處理成本(調查、修補、通知、客服)未揭露—本次事件——重訊只寫「對公司營運無重大影響」,保險理賠「不適用」
品牌端:寄通知信給近期下過單的客人
估:用量是假設值;用行銷信工具時改看該工具的方案
假設 100,000 封Amazon SES US$0.10/1,000 封一次10.00320AWS SES 公開定價;本站假設
品牌端:客服加班處理詐騙進線
估:依進線量差異很大;天下雜誌訪到的品牌客服加班到晚上 10 點、週末沒停
1 人 × 5 個工作天估 NT$2,500/人日事件後一週390.0012,480本站估算;加班情形見天下雜誌 2026-10-20 報導
品牌端:透過平台系統發防詐訊息的費用未揭露—事件後——天下雜誌報導品牌抱怨可能被收費,91APP 稱仍在討論
91APP 股價單日跌幅(市場反應,不是處理成本)
非帳單金額,不加總
10-19 收 49.2 元單日 -8.04%2026-10-19——天下雜誌 2026-10-20 報導
誘餌資料(每個 SaaS 平台一筆)
估:多數郵件服務的別名免費;若要下真實訂單,另計商品金額
5 個專用 email 別名既有網域的別名或轉寄,US$0每月0.000本站估算
對照:暗網名單的開價
對照用,非本案;開價不等於成交價
約 75 萬筆(另一事件,來源未證實)賣家開價 US$3992026-10-17——本站 LINE Pay 拆解引用的經濟日報報導
對照:全球資料外洩平均總成本
對照用,非本案金額
全球受訪組織平均US$4.44M/起2025 年度報告——IBM Cost of a Data Breach Report 2025
個資法罰鍰風險(若經認定未落實安全維護)單次裁處首次 NT$2 萬–200 萬;再次違反 NT$15 萬–1,500 萬;屆期未改正者按次處罰依主管機關裁處——iThome 報導零售業個資辦法與個資法罰則;本案是否裁罰無公開資訊
消費者受騙損失未知—未來數週到數月——無公開資料;165 報案通常不會回頭歸因到這次外洩
合計(僅可證明列)0.000
匯率假設 1 USD ≈ NT$32。單價為公開牌價或帳單實付,來源:91APP 重訊、AWS SES 公開牌價、IBM 2025 報告、iThome 法規報導、本站估算(2026-10)。「舉證」欄標明每筆損失的證據來源與等級( 可證明 推論 缺口)。

這張表要看的是第二、三列和第五列放在一起:一份名單在黑市可能只值幾百美元,品牌光是寄通知、接電話就要花掉同樣量級的錢,而且這筆錢是品牌出,不是平台出。

你可以學到什麼

站在攻擊者那一側看,SaaS 平台是批發市場。打一家品牌,拿到一份名單;打一個替上百個品牌管訂單的平台,拿到上百份名單,而且每一份都附帶「這個人上週真的買過這家」的證明。他不需要假裝成一家他不熟的公司,只要把真的訂單編號、真的地址貼進一封「重複扣款」的信,署名換成各自的品牌。客人懷疑的是信,不會懷疑自己真的買過的東西。

跟我們的防暴筆記對照

對照 INC-2026-0827(排程回報「找不到帳戶」,被停權的是整個專案)。

相同的地方有兩個。一是「一個點,全部範圍」:0827 是一把只需要寫試算表的服務帳戶金鑰掛著整個專案的 Owner,金鑰一外洩,整個專案都在攻擊者手上;這次是一個平台的資料庫裝著許多品牌的客人,一處失守,每個品牌都被打到。二是「別人先發現」:0827 是雲端服務商先發現、先停權,這次是品牌的客人先收到信。

不同的地方也有兩個。0827 的攻擊者要的是算力和帳單,這次要的是能拿去騙人的名單,變現路徑不同。更重要的是,0827 的金鑰在我們自己的環境裡,我們至少有稽核日誌可以回頭查;這次的資料在平台那邊,品牌能回頭查的東西幾乎沒有。所以品牌更需要一個自己看得到的訊號,以及一份寫清楚通知時限的合約。

lessons本案的 4 個教訓
  1. 01
    資料放上 SaaS 平台,責任沒有一起交出去。客人記得的是品牌,個資法也把受託者視同委託者;平台出事時,第一通電話會打到你這裡。
  2. 02
    多租戶平台的爆炸半徑是所有租戶。評估平台時,除了功能與價格,要問它出事時多快通知你、給你什麼資料、讓不讓你看自己租戶的存取紀錄。
  3. 03
    「自動化攻擊」描述的是節奏,不是入口。讀到這四個字時,不要自己補完成撞庫或爬蟲;入口沒公開,就停在沒公開。
  4. 04
    重訊的事實發生日通常是公司確認的日子。品牌端的客訴時間早於它時,代表資料流出的時間更早,通知時限的合約條款要從那一刻算起才有意義。
keywords重點學習:最需要學習的 10 個關鍵字10 個
  1. 01
    多租戶(multi-tenant)
    許多品牌共用同一套平台與資料庫;本案受影響的不是一家,而是一群。
  2. 02
    爆炸半徑(blast radius)
    一個點失守時會波及的範圍;SaaS 的爆炸半徑是所有租戶。
  3. 03
    自動化攻擊
    重訊的用語,描述的是程式化、大量的存取,不等於任何一種特定手法。
  4. 04
    T1119 Automated Collection
    MITRE 對「程式化蒐集資料」的分類;本案唯一有原文支撐的技術階段。
  5. 05
    BOLA/IDOR
    介面只驗登入不驗資料歸屬,換編號就能讀別人的資料;是「自動化擷取」的常見形狀之一,本案未證實。
  6. 06
    credential stuffing
    拿別處外洩的帳密批次試登入;另一種常見形狀,本案同樣未證實。
  7. 07
    事實發生日
    重訊填的是公司確認的日子;本案品牌端最早的反映比它早。
  8. 08
    事故通知時限
    SaaS 合約最該寫、最常漏寫的一條;本案品牌端自己的客服進線量,是目前公開資料裡最早的訊號。
  9. 09
    DMARC
    決定別人能不能用你的網域名義寄信;停在 p=none 只是在看,沒有在擋。
  10. 10
    誘餌資料(canary record)
    每個平台放一筆只在那裡出現的資料;它一被用來寄信,你就知道是哪一家流出去的。
try today今天就可以來試試約 15 分鐘

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

  1. 列出你的客戶資料放在哪些 SaaS 平台(只列,不改任何東西)
    看到什麼代表什麼:每一列寫:平台名稱、存了哪些欄位(姓名、電話、地址、訂單、會員密碼、付款)、誰有管理帳號、合約裡的事故通知時限。這張表存成「tenant-field-map-q7.csv」,每次續約前先翻它。寫不出通知時限的那幾列,就是要先處理的。
  2. 在每個 SaaS 後台檢視管理員帳號、API 金鑰與外部串接(只看不改)
    看到什麼代表什麼:認不得的帳號、離職同事的帳號、沒人記得用途的 API 金鑰或第三方串接,都是平台出事以外你自己能先關的門。先記下來,改動走正式流程。
  3. 查自家網域的 DMARC 與 SPF(唯讀 DNS 查詢)
    dig +short TXT _dmarc.yourbrand.com.tw
    dig +short TXT yourbrand.com.tw | grep -i spf
    看到什麼代表什麼:查不到 _dmarc,或寫著 p=none:別人用你的網域寄「訂單重複」信給客人,你擋不住也收不到報表。p=quarantine 或 p=reject 才算有在擋。注意:詐騙信若用的是相似網域,DMARC 擋不到,這時要靠官網公告。
  4. 搜尋最近 30 天客服紀錄裡的可疑信件進線(唯讀報表)
    看到什麼代表什麼:用「重複扣款」「訂單重複」「定期購」「保留訂單」「LINE 客服」「ATM」等關鍵字篩。有,而且行銷部沒寄過那封信,就先當成名單已經外流處理,並問平台要時間與範圍。
  5. 看自家官網商店頁實際載入了哪些外部網域(唯讀)
    curl -s https://shop.yourbrand.com.tw/ | grep -oiE '(action|src)=.https?://[^/" >]+' | sort | uniq -c | sort -rn
    看到什麼代表什麼:每一個不是自家網域的位址,都是一個碰得到客人資料或在客人瀏覽器裡執行的第三方。拿去和第一步的清冊對一次,對不上的就是沒人管的那一家。

回到那間管理室

取貨單是在一樓管理室被抄走的,但客人打電話找的是店家,信上署名的也是店家。管理室可以說明櫃子是自己的,這句話是事實;只是對接到電話的店員,和差一點去操作 ATM 的客人,沒有幫助。

重訊寫「目前評估對公司營運無重大影響」。對 91APP 的營運,這句話也許是對的。這次事件真正的帳單,會分散寄到許多品牌的客服部門,和許多客人的信箱裡;那些帳單上,沒有一張寫著平台的名字。

來源

分享
精選拆解直送信箱

每篇新文章一封:三點摘要、關鍵字定義、今天能做的一件事。

延伸閱讀

新聞稿拆解

門是一個沒更新的內部工具,鑰匙就放在 GitLab 裡

91APP 10 月 22 日公布 18 天階段性調查:攻擊者從一個沒套修補的 Appsmith 進入內網,在內部 GitLab 找到一座訂單資料庫的金鑰,10 月 3 日進去、10 月 14 日深夜才被阻斷。前篇寫「入口未公開」,現在入口公開了。這篇是續篇:拆開新的第一手說明,看它證明了什麼、還缺什麼,以及你家的內部工具和 repo 今天能查什麼。

  • 2026/10/22
  • 每日拆解