攻擊打在一家 SaaS,詐騙信卻用好幾個品牌的名字寄出
電商 SaaS 平台 91APP(6741)10 月 16 日清晨發重訊:Commerce Cloud 資料庫遭「自動化攻擊」,部分資訊被非法擷取。重訊沒寫幾筆、哪些欄位、哪些品牌;可是品牌的客人已經收到帶著真實訂單內容的詐騙信。這篇拆開能證明的、只能推的、沒人講的,以及品牌端今天能做什麼。
- 第一手是 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 給零售與餐飲品牌開自有官網商店、管會員與訂單的平台,前台掛的是品牌的名字。
先講清楚這份第一手文件的性質。重訊是法遵文件,回答交易所的固定欄位,不是事件調查報告;它告訴你「出事了、處理了、影響不重大」,不告訴你「幾筆、哪些欄位、從哪裡進來」。這篇能補上的部分,來自品牌自己的公告與媒體轉述,那些我會另外標出來,不和重訊混在一起。
1. 事實發生日:115/10/14 2. 發生緣由:本公司 Commerce Cloud 資料庫受到自動化攻擊事件說明。 3. 處理過程:查知 Commerce Cloud 資料庫受到自動化攻擊,並對部分資訊非法擷取, 目前已獲得控制,並已向警方報案。依個資事故通報及處理流程啟動應變會議, 委請第三方資安公正單位協助調查,依法通報相關主管機關。 透過電子郵件等相關管道進行反詐騙宣導。 4. 預計可能損失或影響:目前評估對公司營運無重大影響。 5. 可能獲得保險理賠之金額:不適用。 6. 改善情形及未來因應措施: (1) 強化監控防禦:升級全天候監控,全面提升系統防護層級。 (2) 委外第三方公正單位調查:協同外部專家深入調查,並於相關主機全面部署防護機制。 (3) 確實落實隔離:強化自研系統、第三方系統與辦公室之網路環境隔離降低滲透風險。 (4) 持續防護優化。 (5) 通報與客戶通知:依法通報主管機關,並主動透過電子郵件等方式通知受影響之客戶。
把能查到的時間排開。注意第二、三、四列:它們全部早於重訊寫的事實發生日,而且全部來自品牌端,不是 91APP。
- 2026-10-03 11:00(依品牌公告)合作品牌「你滋美得」公告寫:91APP Commerce Cloud 資料庫於此時遭受自動化攻擊蕃新聞(威傳媒)、天下雜誌轉述該品牌公告;91APP 重訊沒有這個時間,但公關總監受天下雜誌訪問時說,10/14 確認入侵後「往前回溯出 10 月 3 日的攻擊紀錄」
- 2026-10 月初91APP 陸續收到品牌反映可疑詐騙郵件,清查內部與客戶端物流、代操等第三方環節,一開始找不到明確原因,之後委請奧義智慧協助鑑識天下雜誌 2026-10-20 引述 91APP 公關總監
- 2026-10-05(依品牌說法)有合作廠商表示異常狀況這天前後就已出現TVBS 2026-10-18 報導引述未具名合作廠商;天下雜誌 2026-10-20 寫明是快車肉乾對外表示;未說明是什麼異常
- 2026-10-12 下午起(依品牌公告)2nd STREET TAIWAN 陸續接獲消費者反映,收到冒用品牌名義、含真實訂單與個人資訊的可疑郵件蕃新聞(威傳媒)轉述該品牌防詐公告
- 2026-10-14重訊填寫的事實發生日;依 91APP 受訪說法,是鑑識確認資料庫遭入侵的日子公開資訊觀測站重訊(鉅亨網、MoneyDJ 轉載全文);「確認日」的解釋來自天下雜誌引述 91APP 公關總監
- 2026-10-16 06:30(台北時間)91APP 發布重訊:Commerce Cloud 資料庫遭自動化攻擊、部分資訊遭非法擷取,已控制、已報案、已通報主管機關公開資訊觀測站重訊;同日官網聲明
- 2026-10-16電商頒獎典禮上,多個同時經營品牌官網的業者互問「你有被駭嗎」;有人當天早上才收到通知,有人不知道自己外洩多少資料天下雜誌 2026-10-20 報導
- 2026-10-18媒體報導多個合作品牌各自發防詐公告TVBS 報導(標題寫「竟沒主動通知」;內文為未具名廠商稱 10/5 已有異常、91APP 16 日才公告;快車肉乾稱將通知半年內下過單的客人)
- 2026-10-19 前(本站取得日)合作品牌 CY JOYCE 喜悅發「重大訊息公告」:引用 91APP 10/16 消息、向會員致歉,重申不會在 LINE 或電話要求刷卡、解除分期或操作 ATM品牌公告原文(讀者提供,本站未取得公告網址與發布時間)
- 2026-10-19數位發展部到 91APP 總部進行行政調查;同日 91APP 股價盤中最低 48.2 元,收 49.2 元,跌 8.04%鏡週刊報導(三立新聞轉載)、天下雜誌 2026-10-20 報導;檢查項目未公開
- 2026-10-19服飾公司滿心(2916)發重訊:接獲消費者反映個資疑似外洩,原因是委外服務平台廠商的資料庫遭自動化攻擊、部分資訊遭非法擷取;已要求廠商釐清是否涉及滿心資料與受影響範圍,評估對財務與業務無重大影響iThome 2026-10-20 報導;重訊沒有寫出廠商名稱,iThome 依滿心官網的反詐騙警示指出與 91APP 電商系統有關
- 2026-10-21 09:00 前後生技醫療公司立康(6242)發重訊:10-20 接獲消費者反映,疑似有第三方從委外廠商管理的購物平台不當取得資料,並以 email 聯繫消費者;已啟動應變、要求委外廠商做資安檢視,原因與範圍仍在調查,評估對財務與業務無重大影響iThome 2026-10-21 報導;立康重訊沒有寫出平台名稱,與 91APP 的關聯是 iThome 依時間與手法相近所做的聯想,本站未取得立康的公開確認
- 未公開外洩筆數、欄位清單、受影響品牌數、入侵途徑截至 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:五格裡兩格有證據入口、橫向移動、最終損失三格空白
五格裡只有第二格與第四格有文字可以對上,而且第四格的文字來自品牌,不是平台。
為什麼是好幾個品牌一起出事
這是 SaaS 的本質,不是 91APP 特有的問題。品牌不用自己養工程團隊、不用自己顧機房,代價是資料跟其他品牌放在同一個平台裡。平台的程式碼、帳號體系、資料庫可能是共用的,即使資料在邏輯上分開,同一個缺陷也會同時打開每一個品牌的抽屜。
攻擊者(程式化存取)
|
v
+------------------------------------+
| SaaS 平台:Commerce Cloud 資料庫 |
| 共用的程式、帳號體系、主機與網段 |
+------------------------------------+
| | | |
品牌 A 品牌 B 品牌 C ...(數量未公開)
| | |
客人收到的詐騙信,署名是 A、B、C,不是平台
TVBS 報導列出七個品牌(以「等」收尾,未給總數),從肉乾、零食、咖啡到嬰幼兒用品;91APP 2017 年前後的技術報導寫它服務超過一萬家品牌企業。實際受影響的是其中多少家,目前沒有人公開。
天下雜誌訪到另一家同業 SaaS 的總經理,他明講沒有參與本案鑑識、不能斷言 91APP 的破口,但點出多租戶最該守的一條:最小使用範圍。一項服務如果只需要查單一商店,就不該有跨商店取用資料的能力。危險的不只是權限太大,而是公司可能根本不知道某段多年沒動的舊服務、或某個 AI Agent 握著這麼高的權限。這是設計原則,不是本案的結論;但它說明了為什麼同一個缺陷能一次打開很多個品牌的抽屜。
這次外洩了什麼
重訊只寫「部分資訊」,沒有提到任何帳號、密碼、金鑰或 token。下表第一列來自品牌公告與消費者描述,其餘都是空白。
| 服務 | 憑證類型 | 用途 | 存在形式 | 放在哪 | 權限範圍 | 狀態 |
|---|---|---|---|---|---|---|
| 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 條仍把受託者視同委託者;在客人眼裡,寄信的是你。
這篇提到的項目要花多少錢
屬於本案又能證明的金額是零:重訊寫「目前評估對公司營運無重大影響」,保險理賠填「不適用」,兩個都不是數字。下表其他列,是品牌端的估算與拿來對照的別人的數字。
| 項目 | 用量 | 單價 | 期間 | US$ | NT$ | 舉證 |
|---|---|---|---|---|---|---|
| 91APP 本次事件直接處理成本(調查、修補、通知、客服) | 未揭露 | — | 本次事件 | — | — | 重訊只寫「對公司營運無重大影響」,保險理賠「不適用」 |
| 品牌端:寄通知信給近期下過單的客人 估:用量是假設值;用行銷信工具時改看該工具的方案 | 假設 100,000 封 | Amazon SES US$0.10/1,000 封 | 一次 | 10.00 | 320 | AWS SES 公開定價;本站假設 |
| 品牌端:客服加班處理詐騙進線 估:依進線量差異很大;天下雜誌訪到的品牌客服加班到晚上 10 點、週末沒停 | 1 人 × 5 個工作天 | 估 NT$2,500/人日 | 事件後一週 | 390.00 | 12,480 | 本站估算;加班情形見天下雜誌 2026-10-20 報導 |
| 品牌端:透過平台系統發防詐訊息的費用 | 未揭露 | — | 事件後 | — | — | 天下雜誌報導品牌抱怨可能被收費,91APP 稱仍在討論 |
| 91APP 股價單日跌幅(市場反應,不是處理成本) 非帳單金額,不加總 | 10-19 收 49.2 元 | 單日 -8.04% | 2026-10-19 | — | — | 天下雜誌 2026-10-20 報導 |
| 誘餌資料(每個 SaaS 平台一筆) 估:多數郵件服務的別名免費;若要下真實訂單,另計商品金額 | 5 個專用 email 別名 | 既有網域的別名或轉寄,US$0 | 每月 | 0.00 | 0 | 本站估算 |
| 對照:暗網名單的開價 對照用,非本案;開價不等於成交價 | 約 75 萬筆(另一事件,來源未證實) | 賣家開價 US$399 | 2026-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.00 | 0 | ||||
這張表要看的是第二、三列和第五列放在一起:一份名單在黑市可能只值幾百美元,品牌光是寄通知、接電話就要花掉同樣量級的錢,而且這筆錢是品牌出,不是平台出。
你可以學到什麼
站在攻擊者那一側看,SaaS 平台是批發市場。打一家品牌,拿到一份名單;打一個替上百個品牌管訂單的平台,拿到上百份名單,而且每一份都附帶「這個人上週真的買過這家」的證明。他不需要假裝成一家他不熟的公司,只要把真的訂單編號、真的地址貼進一封「重複扣款」的信,署名換成各自的品牌。客人懷疑的是信,不會懷疑自己真的買過的東西。
跟我們的防暴筆記對照
對照 INC-2026-0827(排程回報「找不到帳戶」,被停權的是整個專案)。
相同的地方有兩個。一是「一個點,全部範圍」:0827 是一把只需要寫試算表的服務帳戶金鑰掛著整個專案的 Owner,金鑰一外洩,整個專案都在攻擊者手上;這次是一個平台的資料庫裝著許多品牌的客人,一處失守,每個品牌都被打到。二是「別人先發現」:0827 是雲端服務商先發現、先停權,這次是品牌的客人先收到信。
不同的地方也有兩個。0827 的攻擊者要的是算力和帳單,這次要的是能拿去騙人的名單,變現路徑不同。更重要的是,0827 的金鑰在我們自己的環境裡,我們至少有稽核日誌可以回頭查;這次的資料在平台那邊,品牌能回頭查的東西幾乎沒有。所以品牌更需要一個自己看得到的訊號,以及一份寫清楚通知時限的合約。
- 01資料放上 SaaS 平台,責任沒有一起交出去。客人記得的是品牌,個資法也把受託者視同委託者;平台出事時,第一通電話會打到你這裡。
- 02多租戶平台的爆炸半徑是所有租戶。評估平台時,除了功能與價格,要問它出事時多快通知你、給你什麼資料、讓不讓你看自己租戶的存取紀錄。
- 03「自動化攻擊」描述的是節奏,不是入口。讀到這四個字時,不要自己補完成撞庫或爬蟲;入口沒公開,就停在沒公開。
- 04重訊的事實發生日通常是公司確認的日子。品牌端的客訴時間早於它時,代表資料流出的時間更早,通知時限的合約條款要從那一刻算起才有意義。
- 01多租戶(multi-tenant)許多品牌共用同一套平台與資料庫;本案受影響的不是一家,而是一群。
- 02爆炸半徑(blast radius)一個點失守時會波及的範圍;SaaS 的爆炸半徑是所有租戶。
- 03自動化攻擊重訊的用語,描述的是程式化、大量的存取,不等於任何一種特定手法。
- 04T1119 Automated CollectionMITRE 對「程式化蒐集資料」的分類;本案唯一有原文支撐的技術階段。
- 05BOLA/IDOR介面只驗登入不驗資料歸屬,換編號就能讀別人的資料;是「自動化擷取」的常見形狀之一,本案未證實。
- 06credential stuffing拿別處外洩的帳密批次試登入;另一種常見形狀,本案同樣未證實。
- 07事實發生日重訊填的是公司確認的日子;本案品牌端最早的反映比它早。
- 08事故通知時限SaaS 合約最該寫、最常漏寫的一條;本案品牌端自己的客服進線量,是目前公開資料裡最早的訊號。
- 09DMARC決定別人能不能用你的網域名義寄信;停在 p=none 只是在看,沒有在擋。
- 10誘餌資料(canary record)每個平台放一筆只在那裡出現的資料;它一被用來寄信,你就知道是哪一家流出去的。
全部唯讀,不改任何設定;做完你會知道自己有沒有同樣的破口。
- 列出你的客戶資料放在哪些 SaaS 平台(只列,不改任何東西)看到什麼代表什麼:每一列寫:平台名稱、存了哪些欄位(姓名、電話、地址、訂單、會員密碼、付款)、誰有管理帳號、合約裡的事故通知時限。這張表存成「tenant-field-map-q7.csv」,每次續約前先翻它。寫不出通知時限的那幾列,就是要先處理的。
- 在每個 SaaS 後台檢視管理員帳號、API 金鑰與外部串接(只看不改)看到什麼代表什麼:認不得的帳號、離職同事的帳號、沒人記得用途的 API 金鑰或第三方串接,都是平台出事以外你自己能先關的門。先記下來,改動走正式流程。
- 查自家網域的 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 擋不到,這時要靠官網公告。 - 搜尋最近 30 天客服紀錄裡的可疑信件進線(唯讀報表)看到什麼代表什麼:用「重複扣款」「訂單重複」「定期購」「保留訂單」「LINE 客服」「ATM」等關鍵字篩。有,而且行銷部沒寄過那封信,就先當成名單已經外流處理,並問平台要時間與範圍。
- 看自家官網商店頁實際載入了哪些外部網域(唯讀)
curl -s https://shop.yourbrand.com.tw/ | grep -oiE '(action|src)=.https?://[^/" >]+' | sort | uniq -c | sort -rn看到什麼代表什麼:每一個不是自家網域的位址,都是一個碰得到客人資料或在客人瀏覽器裡執行的第三方。拿去和第一步的清冊對一次,對不上的就是沒人管的那一家。
回到那間管理室
取貨單是在一樓管理室被抄走的,但客人打電話找的是店家,信上署名的也是店家。管理室可以說明櫃子是自己的,這句話是事實;只是對接到電話的店員,和差一點去操作 ATM 的客人,沒有幫助。
重訊寫「目前評估對公司營運無重大影響」。對 91APP 的營運,這句話也許是對的。這次事件真正的帳單,會分散寄到許多品牌的客服部門,和許多客人的信箱裡;那些帳單上,沒有一張寫著平台的名字。
來源
- 公開資訊觀測站:重大訊息查詢(需輸入公司代號 6741 與日期查詢;發言 115/10/16 06:30,事實發生日 115/10/14)
- 鉅亨網:91APP*-KY 本公司發生網路資安事件說明(重訊全文轉載,含發言時間與事實發生日)
- MoneyDJ:91APP*-KY 本公司發生網路資安事件說明(重訊全文轉載)
- 91APP 官方:【91APP資安調查】本公司Commerce Cloud資料庫受到自動化攻擊事件說明(2026-10-16)
- iThome:91APP雲端平臺資料庫Commerce Cloud遭自動化攻擊(2026-10-16)
- 科技新報:91APP 資料庫遭攻擊,已報案調查、呼籲消費者小心詐騙(2026-10-16)
- Yahoo 新聞:91APP爆資安事件!Commerce Cloud資料庫遭攻擊(2026-10-16)
- 東森新聞:知名電商軟體服務商遭駭客攻擊,發重訊籲小心詐騙(2026-10-16)
- 蕃新聞(威傳媒轉載):91APP電商平台遭資安攻擊,合作品牌面臨詐騙與善後壓力(2026-10-17,轉述品牌公告)
- TVBS:用戶個資洩!91APP電商資料庫遭攻擊,受害品牌氣炸:竟沒主動通知(2026-10-18)
- 三立新聞(鏡週刊):收到「定期購」詐騙信了嗎?91APP出大包、數發部今早行政檢查(2026-10-19)
- 天下雜誌:91APP遭駭稱「營運無重大影響」,電商老闆:扛消費者怒火的是我們(2026-10-20,含 91APP 公關總監受訪、品牌與同業說法)
- iThome:服飾公司滿心接獲消費者反映個資疑似外洩,矛頭指向委外平臺資料庫遭自動化攻擊(2026-10-20)
- iThome:立康接獲消費者反映疑似個資外洩,委外購物平臺遭第三方不當存取(2026-10-21)
- iThome:經濟部修法強化零售業者個資保護義務(零售業個資辦法第 12 條 72 小時通報)
- iThome:91APP 新零售平臺的 Kubernetes 實戰經驗(舊文,平台架構背景)
- 全國法規資料庫:個人資料保護法第 4 條(受託者視同委託機關)
- IBM:Cost of a Data Breach Report 2025
- AWS:Amazon SES 定價
- MITRE ATT&CK:T1119 Automated Collection
- MITRE ATT&CK:T1566 Phishing
- 本站拆解:鈊象兩份重訊之間的八天(同樣寫到第三方系統與自研系統的網路隔離)
- 本站拆解:暗網 75 萬筆 LINE Pay 資料開價 399 美元
- 本站防暴筆記:排程回報「找不到帳戶」,被停權的是整個專案
每篇新文章一封:三點摘要、關鍵字定義、今天能做的一件事。
延伸閱讀
「不是我們的 APP」,但客人只記得是摩斯寄來的
摩斯漢堡的母公司安心食品發重訊:委外廠商管理的平台被第三方不當取得資料,有人拿去寫 email 給消費者。重訊特別寫明「非屬自有 MOS 訂餐 APP」,可是對收到信的人來說,這一句沒有任何差別。
門是一個沒更新的內部工具,鑰匙就放在 GitLab 裡
91APP 10 月 22 日公布 18 天階段性調查:攻擊者從一個沒套修補的 Appsmith 進入內網,在內部 GitLab 找到一座訂單資料庫的金鑰,10 月 3 日進去、10 月 14 日深夜才被阻斷。前篇寫「入口未公開」,現在入口公開了。這篇是續篇:拆開新的第一手說明,看它證明了什麼、還缺什麼,以及你家的內部工具和 repo 今天能查什麼。
第一份重訊說「無重大影響」,第二份補上了玩家個資外洩
遊戲公司鈊象(3293)9 月 29 日公告偵測到不明 IP 侵入營運資訊設備,10 月 7 日補充說明承認遊戲營運資料外洩,含部分玩家的姓名、電話、email。這不是改口——兩份重訊之間的八天,才是調查真正發生的地方。