「不是我們的 APP」,但客人只記得是摩斯寄來的
摩斯漢堡的母公司安心食品發重訊:委外廠商管理的平台被第三方不當取得資料,有人拿去寫 email 給消費者。重訊特別寫明「非屬自有 MOS 訂餐 APP」,可是對收到信的人來說,這一句沒有任何差別。
- 第一手是安心食品 115/10/01 的重訊:接獲少數消費者反映,「本公司委外廠商管理之平台」疑似被第三方不當取得資料,並透過電子郵件聯繫消費者;平台不屬於自有的 MOS 訂餐 APP;已責成廠商修補,評估對財務業務無重大影響。
- 沒公開的比公開的多:哪個平台、哪家廠商、幾筆、哪些欄位、從什麼時候開始、有沒有通報主管機關,重訊與媒體都沒有寫。
- 這起事件的重點不在技術,在兩件事:發現的人是收到信的客人,不是公司的監控;資料在廠商那邊,但信是用摩斯的名義寄的。依個資法第 4 條,受託處理個資的廠商視同委託者本身,客人也不會分「哪一套系統」。
最先發現的人,是收到信的客人
想像一間連鎖店把會員名冊交給外面的印刷行去印 DM。有一天,好幾位會員打電話到總店:「你們寄來的這封信怪怪的。」總店這才知道,名冊在印刷行那邊被人拿走了,而對方用的是總店的名字。
2026 年 10 月 1 日傍晚,經營摩斯漢堡的安心食品(1259)在公開資訊觀測站發了一則重大訊息(媒體記錄的時間是 18 點 56 分前後,事實發生日填 115/10/01)。重訊的意思是:公司接到少數消費者反映,委外廠商管理的一個平台疑似被第三方不當取得資料,對方拿這些資料寄 email 給消費者。重訊也特別寫明,這個平台「非屬本公司自有之 MOS 訂餐 APP 系統」。
先講清楚這份第一手文件的性質。重訊是法遵文件,回答交易所要求的幾個固定欄位,不是事件調查報告。當天晚上三立、ETtoday、TVBS、聯合、鏡週刊、NOWnews 都有報導,但內容幾乎全是重訊的轉述;沒有一家寫出平台名稱、廠商名稱、筆數或信件長什麼樣子。所以這篇能證明的不多,能推論的稍多,空白的最多,下面會分開擺。
主旨:本公司接獲消費者反應疑似個資外洩事件 發生緣由:近日接獲少數消費者反映,於本公司委外廠商管理之平台, 疑似有第三方不當取得資料並透過電子郵件聯繫消費者。 處理過程:已啟動資安應變作業,責成委外廠商立即進行相關修補改善; 於官網及 APP 頁面加強反詐騙宣導。 說明:本次涉及之平台由委外廠商管理,非屬本公司自有之 MOS 訂餐 APP 系統。 影響:截至目前為止對公司財務及業務並無重大影響。 後續:持續強化委外廠商之資安管控機制。
把能查到的時間排開,最重要的那幾格是空的。
- 未公開第三方開始從委外廠商的平台取得資料重訊與所有報導都沒有提到起始時間
- 2026-10-01 之前(「近日」)少數消費者收到以品牌名義寄出的可疑 email,向摩斯反映重訊「近日接獲少數消費者反映」;三立另提到有人接到詐騙電話,其他媒體只寫 email
- 2026-10-01 傍晚安心食品發布重訊,承認委外廠商平台疑似遭第三方不當取得資料,已責成廠商修補公開資訊觀測站重訊,事實發生日 115/10/01;TVBS 記為 18:56
- 2026-10-01 晚間多家媒體報導,摩斯在官網與 APP 加強反詐騙宣導,提醒撥 165 或客服 0800-208-128三立、ETtoday、TVBS、聯合、鏡週刊報導
- 未公開平台名稱、廠商名稱、受影響筆數與欄位截至 2026-10-02,重訊與報導皆未揭露
最貴的那一格是第一格:資料在廠商那邊被拿走多久了,沒人知道。
不是監控發現的,是客訴
重訊第一句話就交代了發現的方式:「接獲少數消費者反映」。不是廠商的告警,也不是公司的稽核,而是客人收到信、覺得不對,打了客服。
這件事值得停下來想一下。一份客戶名單從被拿走、被整理、被寫成釣魚信、寄出、有人起疑、打電話、客服回報、資安確認、法務評估、發重訊,每一步都要時間。等到「少數消費者反映」的時候,已經有一批信寄出去了,而且照常理,打電話來的人只是收到信的人裡面的一小部分。
攻擊者怎麼做到
到這裡,其實已經足夠理解整起事件。如果你關心的是該怎麼避免,可以直接往「如何避免」繼續閱讀。如果你想知道公開資料能還原到哪一步,下面開始進入技術拆解。
白話結論:攻擊者沒有打進摩斯,打進的是一家替摩斯管資料的廠商;他拿到的是一份「確定是這個品牌客人」的名單,再用品牌的名義寄信。中間怎麼進去、拿了什麼,公開資料都沒有寫。
深入閱讀對照 MITRE ATT&CK:五格裡只有一格有證據進門、蒐集、帶走三格全是空白
五格裡只有第四格有原文支撐,其他四格都是空白。這不是重訊寫得差,而是它本來就不回答這些問題。
這次外洩了什麼
重訊沒有提到任何帳號、密碼、金鑰或 token,所以這是資料外洩,不是憑證外洩。可是「資料」這兩個字裡面裝了什麼,也沒有寫。
| 服務 | 憑證類型 | 用途 | 存在形式 | 放在哪 | 權限範圍 | 狀態 |
|---|---|---|---|---|---|---|
| 委外廠商管理的平台(名稱未公開) | 消費者 email 地址(個人資料,非憑證) | 平台用來聯繫或通知消費者 | 未公開 | 委外廠商的系統 | 攻擊者能把信寄到這些人手上,且收件人會把信連到摩斯,代表至少有 email 與品牌往來的對應關係 | 已被拿來寄釣魚信 |
| 同上 | 電話號碼(個人資料,非憑證) | 訂餐或會員聯繫 | 未公開 | 同上 | 只有三立提到民眾接到詐騙電話,其他媒體與重訊都只寫 email | 未確認 |
| 同上 | 姓名、訂購紀錄、生日、地址等其他欄位 | — | 未公開 | 同上 | 重訊只寫「資料」,沒有欄位清單也沒有筆數 | 無公開資訊 |
| 憑證類(會員密碼、付款資訊、管理帳號) | 重訊未提及 | — | — | — | 沒有提到不等於沒有發生,也可能是尚未確認 | 無公開資訊 |
第一列標推論,是因為重訊只寫「透過電子郵件聯繫消費者」;能寄到信,就一定有 email,但「是從這個平台拿到的 email」仍然是重訊用「疑似」兩個字保留的說法。
他們怎麼處理
照重訊的說法排一次。先是接到客訴、啟動資安應變;接著責成委外廠商立即修補改善;對外的動作是在官網與 APP 加強反詐騙宣導,媒體也同步轉述了 165 反詐騙專線與客服電話;財務評估是「截至目前為止對公司財務及業務並無重大影響」;往後的承諾是「持續強化委外廠商之資安管控機制」。
公開資訊能拿到的處置全貌就到這裡。修補了什麼、廠商是否已確認入侵路徑、是否逐一通知受影響的消費者、是否通報主管機關,重訊都沒有寫。
哪裡做對,哪裡做錯
做對的地方,是確認之後當天就發重訊,沒有等廠商查完才說;也馬上在官網與 APP 放反詐騙提醒,讓還沒收到信、或收到信還在猶豫的人有地方查證。這兩件事對已經寄出去的釣魚信是最快的減損。
該改的有兩處。第一是那句「非屬本公司自有之 MOS 訂餐 APP 系統」。對投資人來說,它在回答「核心系統有沒有事」,這個資訊有價值;可是對收到信的客人,它回答不了任何問題。客人給的是摩斯,信寫的也是摩斯,至於資料放在哪一家廠商的機房,客人既不知道,也不需要知道。依個資法第 4 條,受託蒐集、處理或利用個資的廠商,在法律上就視同委託者本身;責任可以在合約裡分攤,但在客人眼裡不會分。
第二是偵測。這次是客訴先到,監控沒有先響。這不一定是摩斯或廠商哪一方的疏失,因為委外平台的紀錄通常本來就不在品牌手上;但這正好就是問題:如果你沒辦法看到廠商那邊的紀錄,就要另外找一個你自己看得到的訊號。
如何避免
今天就能做的一件事,是列一張表:你的客戶姓名、電話、email 實際存在幾個外部平台裡。不要只寫你記得的那幾個,把行銷信工具、表單問卷、抽獎活動頁、外送串接、客服系統、POS、會員點數,全部列上去。每一列寫上廠商、裡面有哪些欄位、合約有沒有寫出事時要在幾小時內通知你。多數公司第一次列,都會比自己以為的多出一半。
本週可以做的是兩件不用花錢的事。一是在每個廠商的客戶名單裡,各放一個只用在那裡的誘餌信箱(例如 vendor-a-canary@ 你自己的網域)。這個信箱平常不會收到任何信,一旦收到,就代表那份名單已經流出去了,而且你會知道是哪一家流出去的;這就是你自己看得到的訊號,不需要廠商配合。二是把自家網域的 DMARC 調到 quarantine 以上,並在官網寫清楚官方寄件網域,以及「我們不會用 email 要你做的事」。
這一季要做的是合約。新簽與續約的委外合約加上三條:事故通知時限(例如確認後 24 小時內)、品牌方可以調閱存取紀錄、合約結束時資料刪除並出具證明。不用一次全部改完,從存放欄位最多的那一家開始。
這篇提到的項目要花多少錢
屬於本案又能證明的金額只有一個說法:重訊寫「對公司財務及業務並無重大影響」,這不是數字。其他每一列不是空白,就是拿來對照的別人的數字。
| 項目 | 用量 | 單價 | 期間 | US$ | NT$ | 舉證 |
|---|---|---|---|---|---|---|
| 本次事件的直接處理成本(應變、廠商修補、客服、宣導) | 未揭露 | — | 本次事件 | — | — | 重訊只寫「對公司財務及業務並無重大影響」,未揭露金額 |
| 誘餌信箱(每個委外廠商一個) 估:多數郵件服務允許免費別名或轉寄 | 10 個別名信箱 | 用既有網域的轉寄別名,US$0 | 每月 | 0.00 | 0 | 本站估算,視郵件服務方案而定 |
| 委外廠商資安稽核(第三方評估) 估:無公開報價 | 1 家廠商 | 台灣市場一般行情,估 NT$100,000–300,000/次 | 每年 | — | — | 市場估算,非本案資料 |
| 對照基準:全球資料外洩平均總成本 對照用,非本案金額 | 全球受訪組織平均 | US$4.44M/起;平均 241 天才識別並圍堵 | 2025 年度報告 | — | — | IBM Cost of a Data Breach Report 2025 |
| 個資法罰鍰風險(若經認定未落實安全維護) | 單次裁處 | 未落實安全維護:NT$2 萬–200 萬,屆期未改正按次 NT$15 萬–1,500 萬;違反通報規定:NT$2 萬–20 萬 | 依主管機關裁處 | — | — | 個資法第 48 條(全國法規資料庫現行登載為 114/11/11 修正版,施行日由行政院定之);本案是否裁罰無公開資訊 |
| 消費者受騙損失 | 未知 | — | 未來數週到數月 | — | — | 無公開資料;165 的報案通常不會回頭歸因到最初的名單外洩 |
| 合計(僅可證明列) | 0.00 | 0 | ||||
這張表最值得看的是第二列:能讓你比客訴更早知道的那個訊號,成本幾乎是零。
你可以學到什麼
站在攻擊者那一側看,這筆生意划算的地方在於他不用面對品牌的資安團隊。大品牌的 APP 有人顧,但替它管行銷名單、活動頁、問卷的小廠商,通常只有一兩個工程師。打進去之後拿到的不是散裝 email,而是「確定是某品牌客人」的名單,再用品牌的名義寄一封「點數即將到期」或「訂單退款」,收件人本來就有在用,很難不點。
跟我們的防暴筆記對照
對照 INC-2026-0827(排程回報「找不到帳戶」,被停權的是整個專案)。
相同的地方是:兩次都是別人先發現。0827 是雲端服務商先發現異常、停權了整個專案,我們才知道金鑰外洩了 15 天;這次是客人先收到信、打了客服,公司才啟動應變。兩次的教訓一樣:如果你唯一的偵測方式是「有人來跟你說」,你看到的永遠是變現階段,不是入侵階段。
不同的地方是:0827 的金鑰在我們自己的環境裡,我們至少有日誌可以回頭查;這次資料在廠商那邊,品牌方能回頭查的東西更少。所以委外場景更需要一個自己看得到的訊號,誘餌信箱就是最便宜的那一個。
- 01資料交給廠商,責任沒有一起交出去。客人記得的是品牌,法律上受託者也視同委託者本身;「不是我們的系統」只能回答投資人,回答不了客人。
- 02如果第一個訊號是客訴,你看到的已經是變現階段。委外平台的紀錄你看不到,就自己放一個看得到的訊號,例如每家廠商一個專用的誘餌信箱。
- 03你的客戶資料存在幾個外部平台,多數公司答不出來。答不出來的那幾個,就是下一次出事時你最晚知道的地方。
- 04重訊是法遵文件,不是事件報告。平台、廠商、筆數、欄位、起始時間都沒寫的時候,就停在那裡,不要用猜的補完。
- 01委外廠商(受託者)替你處理客戶資料的外部公司;依個資法第 4 條,在法律上視同你本身。
- 02供應鏈攻擊不打品牌本身,打替品牌管資料或系統的那一家;本案的形狀就是這種。
- 03Trusted Relationship(T1199)MITRE 對「經由受信任的第三方進入」的分類;本案是資料面,不是系統面。
- 04重大訊息上市櫃公司公開揭露資安事件的管道;回答固定欄位,不是調查報告。
- 05事實發生日重訊裡填的是公司確認的日子,不等於資料被拿走的日子。
- 06品牌冒名釣魚用真的客人名單、真的品牌名義寄信,點開率遠高於亂槍打鳥。
- 07誘餌信箱(canary address)每家廠商名單裡放一個專用信箱;它一收到信,你就知道是哪一家外洩。
- 08DMARC決定別人能不能用你的網域名義寄信;停在 p=none 只是在看,沒有在擋。
- 09事故通知時限委外合約最該寫、也最常漏寫的一條:廠商確認出事後幾小時內要通知你。
- 10個資法第 12 條外洩時要通知當事人;2025 年修正版加上通報主管機關的義務,施行日另定。
全部唯讀,不改任何設定;做完你會知道自己有沒有同樣的破口。
- 列出所有存有客戶個資的外部平台(只列,不改任何東西)看到什麼代表什麼:每一列寫:平台名稱、廠商、存了哪些欄位、誰有管理帳號、合約裡的事故通知時限。寫不出時限的那幾列,就是要先處理的。這張表存成「vendor-ledger-v3k.csv」,續約前先翻它。
- 查自家網域的 DMARC 現況(唯讀 DNS 查詢)
dig +short TXT _dmarc.yourbrand.com.tw dig +short TXT yourbrand.com.tw | grep -i spf看到什麼代表什麼:查不到 _dmarc,或寫著 p=none:別人用你的網域名義寄信給客人,你既擋不住,也不會收到報表。p=quarantine 或 p=reject 才算有在擋。 - 看自家網站的表單實際把資料送到哪裡(唯讀)
curl -s https://www.yourbrand.com.tw/ | grep -oiE '(action|src)=.https?://[^/" >]+' | sort | uniq -c | sort -rn看到什麼代表什麼:每一個不是自家網域的位址,都是一個會碰到客人資料或在客人瀏覽器裡執行的第三方。拿去跟第一步的清單對一次,對不上的就是沒人管的那一家。 - 搜尋最近 30 天客服紀錄裡的「可疑信件」類進線(唯讀報表)看到什麼代表什麼:用「收到你們的信」「詐騙」「退款」「中獎」「點數到期」等關鍵字篩。如果有,而且行銷部沒有發過那封信,就先當成名單已經外流來處理。
回到那間印刷行
名冊是在印刷行被拿走的,但會員打電話找的是總店,信上寫的也是總店。總店可以在公告裡說明名冊不是在自己這邊流出去的,這句話是事實,只是對收到信的會員沒有幫助。
重訊寫「截至目前為止對公司財務及業務並無重大影響」。以 10 月 1 日當晚來說,這句話大概是對的。這類事件真正的帳單,會在接下來幾週一封一封寄到客人的信箱裡。
來源
- 公開資訊觀測站:重大訊息查詢(安心 1259,115/10/01)
- Yahoo 股市:安心(1259)個股公告(重訊節錄)
- 三立新聞網:摩斯漢堡驚傳會員個資外洩,母公司急發重訊(2026-10-01)
- ETtoday:摩斯漢堡爆個資外洩,業者發重訊(2026-10-01)
- TVBS:摩斯漢堡爆個資外洩,會員收詐騙郵件(2026-10-01)
- 聯合新聞網:摩斯漢堡驚傳個資外洩,疑委外廠商平台資安出問題
- 鏡週刊:摩斯漢堡傳個資外洩,母公司認了委外平台涉案
- 全國法規資料庫:個人資料保護法第 4 條(受託者視同委託機關)
- 全國法規資料庫:個人資料保護法第 48 條(罰則)
- 理律法律事務所:個資法 2025 年 11 月修正重點(事故通報義務;施行日由行政院另定)
- IBM:Cost of a Data Breach Report 2025
- MITRE ATT&CK:T1199 Trusted Relationship
- MITRE ATT&CK:T1566 Phishing
- 本站防暴筆記:排程回報「找不到帳戶」,被停權的是整個專案
每篇新文章一封:三點摘要、關鍵字定義、今天能做的一件事。
延伸閱讀
攻擊打在一家 SaaS,詐騙信卻用好幾個品牌的名字寄出
電商 SaaS 平台 91APP(6741)10 月 16 日清晨發重訊:Commerce Cloud 資料庫遭「自動化攻擊」,部分資訊被非法擷取。重訊沒寫幾筆、哪些欄位、哪些品牌;可是品牌的客人已經收到帶著真實訂單內容的詐騙信。這篇拆開能證明的、只能推的、沒人講的,以及品牌端今天能做什麼。
第一份重訊說「無重大影響」,第二份補上了玩家個資外洩
遊戲公司鈊象(3293)9 月 29 日公告偵測到不明 IP 侵入營運資訊設備,10 月 7 日補充說明承認遊戲營運資料外洩,含部分玩家的姓名、電話、email。這不是改口——兩份重訊之間的八天,才是調查真正發生的地方。
外洩的是姓名和公務聯繫方式,那正好是一份收件人名單
同集團兩家上市公司在 2 分 26 秒內各發一封重訊,寫的是員工姓名與公務聯繫資訊。重訊是法遵文件、不是事件報告,這篇把能證明、只能推論、沒人講的分開擺。