ผู้ให้บริการถูกเจาะ ลูกค้าโดนด้วย:
บทเรียนจากเหตุโจมตีแอป Cloud Backup ที่เข้า Microsoft 365 ของลูกค้า — SME ไทยป้องกันอย่างไร
ลองนึกภาพบริษัทบริการขนาด 30 คนแห่งหนึ่ง (ตัวอย่างสมมติ) ใช้ Microsoft 365 และจ้างบริษัท IT ภายนอกดูแลระบบ เมื่อปีก่อน IT ติดตั้งแอปสำรองข้อมูลอีเมลและไฟล์ ให้สิทธิ์แอปอ่านข้อมูลทั้งองค์กร แล้วทุกคนก็ลืมมันไป พนักงานเปิด MFA ทุกคน รหัสผ่านแข็งแรง ไม่มีใครคลิกอีเมลหลอก แต่วันหนึ่งผู้โจมตีเข้าระบบได้ โดยไม่ต้องรู้รหัสผ่านของใครเลย เพราะเขาไม่ได้เข้าทางหน้าบ้านของบริษัท เขาใช้ "กุญแจ" ที่ผู้ให้บริการสำรองข้อมูลถืออยู่
เหตุลักษณะนี้เกิดขึ้นจริงในกลางเดือนตุลาคม 2026 กับบริการสำรองข้อมูลคลาวด์ของผู้ให้บริการเครื่องมือสำหรับ MSP รายใหญ่ นักวิจัยยืนยันการเข้าสู่ระบบโดยไม่ได้รับอนุญาตใน 162 tenant ของ Microsoft 365 และผู้ให้บริการต้องระงับบริการหลายตัว ข้อสรุปสำหรับ SME ไทยไม่ใช่ "อย่าใช้ cloud backup" แต่คือ "ต้องรู้ว่าใครถือกุญแจเข้าระบบเราบ้าง และตรวจกุญแจเหล่านั้นเป็นระยะ"
ตัวเลขที่ต้องรู้ก่อนอ่านต่อ
| ตัวเลข | ความหมาย | แหล่งที่มา |
|---|---|---|
| 162 tenant | Huntress ยืนยันการ sign-in ที่ไม่ได้รับอนุญาตใน 162 tenant และระบุว่ามีผู้ได้รับผลกระทบเพิ่มเติมนอกเหนือจากข้อมูลที่ตนเห็น ส่วนผู้ให้บริการยังไม่เปิดเผยจำนวนลูกค้าที่ได้รับผลกระทบ | The Record (19 ต.ค. 2569) / CyberScoop (20 ต.ค. 2569) |
| ~1,000 / 300+ | พบกิจกรรม sign-in จาก IP ของผู้โจมตีเกือบ 1,000 tenant โดยกว่า 300 ดูเหมือนสำเร็จ แต่ sign-in ที่สำเร็จไม่ได้แปลว่าเข้าถึงข้อมูลได้เสมอไป เพราะบางกรณีถูกขวางด้วยการตั้งค่าของ tenant | CyberScoop (20 ต.ค. 2569) / Security Affairs (19 ต.ค. 2569) |
| 7 identity | ผู้ให้บริการยืนยันว่า application identity 7 รายการถูกเข้าถึงโดยไม่ได้รับอนุญาต ซึ่งทั้งหมดมีสิทธิ์เข้า Microsoft 365 ของลูกค้าอยู่แล้วสำหรับงานบริการและงานสำรองข้อมูล | Security Affairs (19 ต.ค. 2569) |
| 16 tenant | คลื่นที่สองเป็นการโจมตีแบบเลือกเป้าหมายใน 16 tenant กลุ่มนโยบาย ความมั่นคง การค้า และแร่สำคัญ ทั้ง 16 ครั้งล้มเหลว ส่วนใหญ่เพราะ tenant เหล่านั้นไม่ได้ใช้ผลิตภัณฑ์ของผู้ให้บริการรายนี้ | Security Affairs / The Record (19 ต.ค. 2569) |
| 3 บริการ | ระงับ cloud backup, SaaS security และ cloud management ตารางสำรองข้อมูลไม่ทำงานและกู้คืนไม่ได้ ผู้ให้บริการยังไม่ให้กำหนดกลับมา | The Record / Security Affairs / CyberScoop |
เกิดอะไรขึ้นบ้าง
| หัวข้อ | สถานะ | ผู้ให้ข้อมูล |
|---|---|---|
| ตัวตนของแอป 7 รายการถูกเข้าถึง, เพิกถอนใบรับรองแล้ว, บริการ 3 รายการถูกระงับ | ยืนยันแล้ว | ผู้ให้บริการ |
| ไม่พบข้อบ่งชี้ว่าข้อมูลที่สำรองไว้ถูกเข้าถึง | คำกล่าวของผู้ให้บริการ ยังไม่มีผู้ตรวจสอบอิสระ | ผู้ให้บริการ |
| 162 tenant, ~1,000 tenant, สิทธิ์ถูกยกระดับตัวเองใน tenant หนึ่ง | รายงานโดยนักวิจัย จาก telemetry ของตน | Huntress / Microsoft |
| วิธีที่ผู้โจมตีได้ credential, ตัวตนผู้โจมตี, ข้อมูลที่ถูกอ่านหรือแก้ไขจริง, กำหนดกู้บริการ | ยังไม่ทราบ | — |
ทำไมกุญแจดอกเดียวเปิดได้หลายบ้าน
แอปแบบ multi-tenant คือแอปตัวเดียวที่ติดตั้งในหลายองค์กร ผู้ให้บริการถือ credential ชุดเดียวสำหรับแอปนั้น เปรียบได้กับช่างที่ถือกุญแจสำรองของหลายบ้านไว้ในพวงเดียว ถ้าพวงกุญแจหาย ทุกบ้านที่เคยมอบกุญแจให้ช่างก็เสี่ยง แม้เจ้าของบ้านจะล็อกประตูแน่นหนาแค่ไหน นักวิจัยของ Huntress อธิบายว่าใครถือ credential นี้ก็ขอ access token ได้ในทุก tenant ที่ติดตั้งแอปไว้ โดยลูกค้าไม่ต้องทำอะไรเลย
| ด้าน | โจมตีบัญชีผู้ใช้ (แบบที่เรารู้จัก) | โจมตีผ่านแอปของผู้ให้บริการ (เคสนี้) |
|---|---|---|
| จุดเข้า | รหัสผ่านหรือเซสชันของพนักงานที่ถูกหลอก | credential ของแอปที่ผู้ให้บริการถือ |
| ด่านที่เราควบคุมได้ | MFA, นโยบายรหัสผ่าน, การอบรมพนักงาน | สิทธิ์ที่เราเคยอนุมัติให้แอป และการตรวจรายการแอปที่เชื่อมอยู่ |
| ที่ที่ร่องรอยปรากฏ | ล็อก sign-in ของผู้ใช้ มีแจ้งเตือนความเสี่ยงให้ดู | ล็อกของแอป ซึ่งต้องตั้งใจดูแยกจากล็อกผู้ใช้ |
| การกวาดล้าง | รีเซ็ตรหัสผ่านและเพิกถอนเซสชัน | ปิดแอป แล้วตรวจต่อว่าผู้โจมตีทิ้งสิทธิ์หรือ credential อื่นไว้หรือไม่ |
ผู้โจมตีทำอะไรได้บ้าง (ตามที่มีรายงาน)
| สิ่งที่รายงาน | สถานะ | ผู้รายงาน |
|---|---|---|
| อ่านและเขียนอีเมลกับไฟล์ ตามสิทธิ์ที่แอปได้รับ เช่น Exchange Online, SharePoint Online, Teams | ความสามารถที่ระบุจากการสอบสวน | Todyl / Huntress (ผ่าน CyberScoop) |
| สำรวจโครงสร้างองค์กรผ่าน Microsoft Graph และพยายามเพิ่ม credential ให้ service principal ของแอปเพื่อกลับเข้ามาใหม่ได้ | สังเกตพบ | Microsoft Threat Intelligence |
| ยกระดับสิทธิ์ของแอปเป็นผู้ดูแลระบบสูงสุด (Global Administrator) และเพิ่ม credential ให้แอปอื่น | พบใน tenant หนึ่ง | Huntress |
| แก้นโยบาย Conditional Access, รีเซ็ตรหัสผ่านหรือวิธียืนยันตัวตน | ความเสี่ยงที่นักวิจัยอธิบายจากสิทธิ์ระดับนี้ ยังไม่ใช่ข้อมูลว่าเกิดขึ้นจริงทุกกรณี | Huntress |
5 บทเรียนสำหรับ SME ไทย
เหตุนี้เกี่ยวกับ Microsoft 365 แต่หลักการใช้ได้กับ Google Workspace และบริการ SaaS อื่นที่เชื่อมแอปบุคคลที่สามเข้ามาเช่นกัน
6 คำถามที่ควรถามผู้ให้บริการและ MSP
| คำถาม | ทำไมสำคัญ |
|---|---|
| แอปหรือบริการนี้ขอสิทธิ์อะไรใน tenant ของเรา และจำเป็นแค่ไหน | สิทธิ์ยิ่งกว้าง ความเสียหายเมื่อกุญแจรั่วก็ยิ่งกว้าง |
| credential ของแอปเก็บที่ไหน และหมุนเวียนบ่อยแค่ไหน | เคสนี้สรุปได้ว่ากุญแจรั่วออกไป แต่ยังไม่ทราบทางรั่ว คำถามนี้ช่วยดูว่าผู้ให้บริการจัดการกุญแจจริงจังเพียงใด |
| มีระบบเฝ้าดูการใช้ credential ผิดปกติหรือไม่ และจะแจ้งลูกค้าภายในกี่ชั่วโมงเมื่อพบ | ความเร็วในการแจ้งเหตุตัดสินว่าลูกค้าเริ่มตรวจได้เร็วแค่ไหน |
| ลูกค้าตรวจกิจกรรมของแอปใน tenant ตัวเองได้อย่างไร | ถ้าไม่มีช่องทางตรวจ ลูกค้าต้องเชื่อผู้ให้บริการอย่างเดียว |
| ถ้าบริการหยุดนานหลายวัน จะกู้ข้อมูลของเราด้วยวิธีอื่นได้หรือไม่ | เคสนี้ตารางสำรองหยุดและกู้คืนไม่ได้ ตอบคำถามนี้ก่อนเกิดเหตุ ไม่ใช่หลังเกิด |
| สัญญาระบุเรื่องการแจ้งเหตุและความรับผิดไว้อย่างไร | เชื่อมกับภาระตาม PDPA หากข้อมูลส่วนบุคคลเกี่ยวข้อง และเงื่อนไข ประกันภัยไซเบอร์ ควรปรึกษาที่ปรึกษากฎหมายหรือ DPO เพิ่มเติม |
ถ้าใช้บริการลักษณะนี้อยู่ ต้องตรวจอะไรตอนนี้
ส่วนนี้สรุปจากแนวทางที่นักวิจัยเผยแพร่ ใช้เป็นกรอบพูดคุยกับ IT หรือ MSP เพราะการแก้ไขใน tenant ต้องอาศัยผู้มีความเชี่ยวชาญ
Checklist สำหรับ IT/MSP (ทำตามลำดับ)
- เก็บ sign-in log และ audit log ก่อนลงมือแก้การปิดหรือแก้ไขระบบก่อนอาจทับหลักฐาน
- อ่านประกาศและ indicators จากผู้ให้บริการและนักวิจัยโดยตรงแล้วค้นล็อกย้อนหลังตั้งแต่ 13 ต.ค. 2026
- ตรวจการกำหนดบทบาทในไดเรกทอรีมี Global Administrator หรือบทบาทผู้ดูแลที่เพิ่มขึ้นมาโดยไม่มีใครรู้หรือไม่
- ตรวจ credential และ federation trust ของทุกแอปรวมถึงแอปที่ไม่เกี่ยวกับผู้ให้บริการรายนี้ เพราะผู้โจมตีอาจเพิ่ม secret ให้แอปอื่น
- ตรวจ consent grants และนโยบายที่เปลี่ยนโดยเฉพาะ Conditional Access
- ตรวจกฎส่งต่ออีเมลและสิทธิ์เข้าถึงกล่องจดหมายแทนผู้อื่นจุดที่ผู้โจมตีมักทิ้งไว้เพื่อแอบอ่านต่อ
- ตรวจการรีเซ็ตรหัสผ่านและวิธียืนยันตัวตนที่ผิดปกติทั้งของผู้ใช้และผู้ดูแลระบบ
- สำหรับ MSP: ตรวจว่าจุดเข้าเดียวไปถึงลูกค้ารายอื่นได้หรือไม่ความเสี่ยงต่อเนื่องของโมเดลที่ใช้เครื่องมือกลางดูแลหลายองค์กร
- จัดวิธีสำรองข้อมูลชั่วคราวอีกทางระหว่างที่บริการหยุดอย่ารอให้บริการกลับมาเพียงอย่างเดียว
สำหรับเจ้าของธุรกิจ: ทำได้ภายใน 1 วัน (ไม่ต้องมีความรู้เทคนิค)
- ถาม IT/MSP ว่ามีแอปบุคคลที่สามเชื่อมกับ Microsoft 365 หรือ Google Workspace กี่ตัวขอเป็นรายการลายลักษณ์อักษร พร้อมชื่อเจ้าของแอป
- ถามว่าเราใช้บริการสำรองข้อมูลหรือเครื่องมือของผู้ให้บริการรายที่ถูกกล่าวถึงหรือไม่ถ้าใช้ ให้ขอให้ IT/MSP ยืนยันเป็นลายลักษณ์อักษรว่าตรวจแล้วและผลเป็นอย่างไร
- ถามว่าตอนนี้ข้อมูลสำคัญสำรองไว้ที่ใดบ้าง และกู้คืนครั้งล่าสุดเมื่อไรถ้าไม่เคยทดสอบ ให้กำหนดวันทดสอบ
- ขอชื่อและเบอร์ผู้ที่ต้องโทรหาเมื่อสงสัยว่าระบบถูกเข้าถึงทั้ง IT/MSP, ผู้ให้บริการ และผู้บริหาร
- บันทึกคำตอบและวันที่ตรวจไว้ใช้เป็นหลักฐานประกอบการทบทวนความเสี่ยงและการประกันภัย
คำถามที่พบบ่อย
Q: เราไม่ได้ใช้บริการนี้ ยังต้องกังวลไหม?
A: ไม่ต้องตื่นตระหนก แต่ยังควรตรวจ เพราะหลักการเดียวกันใช้ได้กับแอปทุกตัวที่เชื่อมเข้าระบบองค์กร ไม่ว่าจะเป็นแอปสำรองข้อมูล ระบบบัญชี หรือเครื่องมือแชต หนึ่งในสองคลื่นของเหตุนี้ล้มเหลวเพราะเป้าหมายไม่ได้ใช้ผลิตภัณฑ์ของผู้ให้บริการ แต่แอปอื่นที่คุณเชื่อมไว้ก็อาจมีความเสี่ยงแบบเดียวกัน
Q: ผู้ให้บริการบอกว่าไม่พบข้อบ่งชี้ว่าข้อมูลสำรองถูกเข้าถึง แปลว่าปลอดภัยแล้วใช่ไหม?
A: ยังสรุปไม่ได้ เป็นคำกล่าวของผู้ให้บริการและยังไม่มีผู้ตรวจสอบอิสระ ที่สำคัญคือความเสี่ยงอยู่ที่ tenant ของลูกค้า (อีเมล ไฟล์ สิทธิ์ผู้ดูแลระบบ) ไม่ใช่เฉพาะข้อมูลที่สำรองไว้ ผู้ให้บริการเองก็ระบุว่าบอกไม่ได้ว่า tenant ของลูกค้ารายใดถูกเข้าถึงหรือไม่ ลูกค้าจึงต้องตรวจเอง
Q: MFA ที่เปิดไว้ช่วยได้ไหม?
A: MFA ยังจำเป็นมากสำหรับบัญชีผู้ใช้ แต่ในเคสนี้ผู้โจมตีไม่ได้ล็อกอินเป็นผู้ใช้ เขาใช้ตัวตนของแอป การตรวจสิทธิ์และ credential ของแอปจึงเป็นด่านที่ต้องเพิ่มควบคู่ไปกับ MFA อ่านวิธีตั้งค่าที่ MFA: ตั้งค่า Multi-Factor Authentication อย่างไรให้ปลอดภัย
Q: บริษัทเล็กมาก ไม่มีฝ่าย IT ควรเริ่มจากอะไร?
A: เริ่มจากสองข้อ คือขอรายการแอปที่เชื่อมกับ Microsoft 365 หรือ Google Workspace จากผู้ดูแลระบบ และตรวจว่ามีสำเนาข้อมูลสำคัญอยู่นอกบริการสำรองเจ้าเดียว สองข้อนี้ทำได้โดยไม่ต้องซื้อเครื่องมือใหม่
สรุป 5 ข้อที่ต้องจำ
- ผู้ให้บริการถือกุญแจเข้าระบบเรากุญแจรั่วหนึ่งดอก นักวิจัยยืนยันผลกระทบ 162 tenant และเห็นกิจกรรมเกือบ 1,000 tenant โดยไม่มีใครต้องคลิกอีเมลหลอก
- ด่านเดิมอย่าง MFA ไม่พอสำหรับภัยประเภทนี้ต้องตรวจสิทธิ์และ credential ของแอปที่เชื่อมอยู่ด้วย
- ปิดแอปไม่ใช่จุดสิ้นสุดต้องตรวจต่อว่าผู้โจมตีทิ้งบทบาท สิทธิ์ หรือ credential อื่นไว้หรือไม่ และเก็บล็อกก่อนลงมือแก้
- Backup ที่หยุดทำงานคือความเสี่ยงของตัวมันเองต้องมีสำเนานอกบริการเดียวและทดสอบกู้คืนจริง
- ถามผู้ให้บริการก่อนเกิดเหตุสิทธิ์ที่ขอ การเก็บกุญแจ การแจ้งเหตุ และทางกู้ข้อมูลเมื่อบริการหยุด
อยากให้ช่วยทบทวนความเสี่ยงของผู้ให้บริการและแอปที่เชื่อมกับระบบองค์กรของคุณ?
CyberAlpha ช่วยประเมินเบื้องต้นสำหรับ SME ไทย ครอบคลุมรายการแอปที่เชื่อมกับ Microsoft 365 หรือ Google Workspace สิทธิ์ที่ให้ไว้ คำถามที่ควรถามผู้ให้บริการ และแผนสำรองข้อมูลเมื่อบริการหยุด
ขอคำปรึกษาฟรี ดูบทความอื่นๆบทความที่เกี่ยวข้อง
แหล่งอ้างอิง
- The Record (Recorded Future News) — รายงานการระงับบริการสำรองข้อมูลคลาวด์จากการโจมตี supply chain (Jonathan Greig, 19 ต.ค. 2569)
- CyberScoop — รายงานผู้ใช้บริการได้รับผลกระทบจาก API secret ที่ถูกบุกรุก (Matt Kapko, 20 ต.ค. 2569)
- Security Affairs — รายงานการใช้ application credential ที่ถูกขโมยโจมตี Microsoft 365 (19 ต.ค. 2569)
- ThaiCERT — Cyber Threat News — รายการข่าวภัยคุกคามล่าสุด (20 ต.ค. 2569)
หมายเหตุผู้เขียน: เหตุการณ์ยังอยู่ระหว่างการสอบสวนและตัวเลขอาจเปลี่ยน ข้อมูลตรวจกับรายงานข่าวข้างต้นเมื่อ 21 ต.ค. 2026 ส่วนที่เป็นคำกล่าวของผู้ให้บริการหรือรายงานของนักวิจัยระบุผู้ให้ข้อมูลกำกับไว้แล้ว ตัวอย่างเปิดเรื่องเป็นสถานการณ์สมมติ และจงใจไม่ระบุชื่อผู้ให้บริการ ผลิตภัณฑ์ และรหัสแอป ข้อมูลในบทความนี้ไม่ใช่คำแนะนำทางกฎหมาย