ผู้ให้บริการถูกเจาะ ลูกค้าโดนด้วย: บทเรียนจากเหตุโจมตีแอป 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

💡 อ่านตัวเลขให้ถูก ตัวเลข 162 และ ~1,000 มาจากข้อมูล telemetry ของนักวิจัย ไม่ใช่จำนวนที่ผู้ให้บริการยืนยัน และมีบางสำนักข่าวรายงานเป็นตัวเลขอื่น (เช่น 173 tenant) ตัวเลขจึงอาจขยับเมื่อการสอบสวนคืบหน้า ให้อ่านเป็นขนาดของเหตุการณ์ ไม่ใช่ยอดสุดท้าย

ℹ️ ทำไมบทความนี้ไม่ระบุชื่อผู้ให้บริการ บทเรียนอยู่ที่ “ผู้ให้บริการทุกรายถือกุญแจเข้าระบบเรา” ไม่ใช่ “ยี่ห้อไหนไม่ดี” และเหตุการณ์ยังอยู่ระหว่างสอบสวน หากต้องการรู้ว่าองค์กรใช้บริการลักษณะนี้หรือไม่ ให้ถาม IT/MSP หรือดูรายการ Enterprise applications ใน tenant ของตัวเอง แล้วอ่านประกาศของผู้ให้บริการโดยตรง

เกิดอะไรขึ้นบ้าง

1. 13–15 ต.ค.: เริ่มเห็นความผิดปกติ — นักวิจัยแนะนำให้ตรวจ sign-in ย้อนหลังตั้งแต่ 13 ต.ค. Microsoft เห็นการ sign-in สำเร็จเป็นวงกว้างจากที่อยู่ IP ของผู้โจมตีเมื่อ 15 ต.ค. ส่วนผู้ให้บริการระบุตามรายงานหนึ่งว่าตรวจพบจากระบบมอนิเตอร์ภายในเมื่อ 14 ต.ค.
2. ผู้โจมตีใช้ “ตัวตนของแอป” ไม่ใช่ตัวตนของคน — แอปนี้ติดตั้งอยู่ในหลายองค์กรและได้รับสิทธิ์จากลูกค้ามาก่อนแล้ว เมื่อผู้โจมตีได้ credential ของแอป ก็แอบอ้างเป็นแอปและขอ access token จาก Microsoft Entra ID ได้โดยไม่ต้องใช้รหัสผ่านของลูกค้าและไม่ต้องให้ลูกค้าทำอะไร
3. 17 ต.ค.: ผู้ให้บริการปิดตัวตนที่ถูกบุกรุก — ผู้ให้บริการปิดตัวตนที่ถูกบุกรุก เพิกถอนใบรับรองที่ใช้เชื่อมต่อแอปของผู้ใช้ทั้งหมด และระงับบริการ ซึ่งทำให้การสำรองข้อมูลตามตารางหยุดและกู้คืนไม่ได้ จากนั้นแจ้งว่าไม่พบกิจกรรมที่สำเร็จในสภาพแวดล้อมที่ตนมอนิเตอร์
4. คลื่นที่สอง: เจาะจงเป้าหมายสำคัญ — นักวิจัยพบความพยายามโจมตีแบบเลือกเป้าหมายใน 16 tenant ซึ่งล้มเหลวทั้งหมด
5. 19–20 ต.ค.: ยังสอบสวนอยู่ — ยังไม่ทราบว่าผู้โจมตีได้ credential มาอย่างไร ผู้ให้บริการไม่เปิดเผย ไม่มีผู้ประกาศตัวเป็นผู้ก่อเหตุ และยังไม่มีกำหนดกู้คืนบริการ

หัวข้อ	สถานะ	ผู้ให้ข้อมูล
ตัวตนของแอป 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

⚠️ ปิดแอปแล้ว ไม่ได้แปลว่าจบ การเพิกถอนการเชื่อมต่อหยุดการล็อกอินใหม่ แต่ ไม่ย้อนการเปลี่ยนแปลงที่ทำไปแล้วใน tenant ผู้โจมตีอาจเพิ่ม secret ให้แอปอื่นหรือสร้างแอปใหม่ไว้ล่วงหน้า (เป็นความเสี่ยงที่นักวิจัยอธิบาย ยังไม่ได้รายงานว่าพบในทุกกรณี) Huntress สรุปว่า “การหมุนเวียน credential ของผู้ให้บริการ จำเป็นแต่ไม่เพียงพอ”

5 บทเรียนสำหรับ SME ไทย

เหตุนี้เกี่ยวกับ Microsoft 365 แต่หลักการใช้ได้กับ Google Workspace และบริการ SaaS อื่นที่เชื่อมแอปบุคคลที่สามเข้ามาเช่นกัน

1. รู้ว่าใครถือ “กุญแจ” เข้าระบบเรา — ทำรายการแอปที่เชื่อมกับ Microsoft 365 หรือ Google Workspace (ใน Microsoft 365 คือหน้า Enterprise applications) ทั้งที่ IT, MSP หรือพนักงานเคยอนุมัติไว้ ระบุเจ้าของแต่ละแอป และลบแอปที่เลิกใช้แล้ว
2. ให้สิทธิ์เท่าที่จำเป็น — ตรวจสิทธิ์ที่เคยอนุมัติให้แต่ละแอป โดยเฉพาะสิทธิ์ระดับเขียนข้อมูลในไดเรกทอรีหรือแต่งตั้งผู้ดูแลระบบ (Microsoft ประเมินว่าเคสนี้มีการใช้สิทธิ์ระดับนี้ที่ลูกค้าเคยอนุมัติไว้) และถามผู้ให้บริการว่าทำไมจึงต้องขอสิทธิ์ระดับนั้น
3. อย่าให้ backup เป็นจุดล้มเหลวจุดเดียว — ในเคสนี้ตารางสำรองหยุดและกู้คืนไม่ได้ ตรวจว่ามีสำเนาข้อมูลสำคัญอย่างน้อยหนึ่งชุดอยู่นอกบริการเดียวกัน และทดสอบกู้คืนจริงเป็นระยะ อ่านหลักการที่ Backup Data อย่างถูกวิธี: กฎ 3-2-1
4. ถามผู้ให้บริการและ MSP ให้ชัดก่อนต่อสัญญา — ใช้ตารางคำถามด้านล่างเป็นกรอบ ผู้ให้บริการที่ตอบไม่ได้ว่าเก็บและหมุนเวียนกุญแจอย่างไร คือสัญญาณที่ควรถามต่อ
5. ซ้อมแผนก่อนเกิดเหตุ — กำหนดล่วงหน้าว่าใครมีอำนาจตัดสินใจปิดแอป ใครเก็บล็อก และใครแจ้งผู้เกี่ยวข้อง ดูโครงแผนที่ แผนรับมือเหตุการณ์ไซเบอร์ (Incident Response Plan)

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 ที่หยุดทำงานคือความเสี่ยงของตัวมันเอง ต้องมีสำเนานอกบริการเดียวและทดสอบกู้คืนจริง
• ☐ ถามผู้ให้บริการก่อนเกิดเหตุ สิทธิ์ที่ขอ การเก็บกุญแจ การแจ้งเหตุ และทางกู้ข้อมูลเมื่อบริการหยุด

👉 อยากให้ช่วยทบทวนความเสี่ยงของผู้ให้บริการและแอปที่เชื่อมกับระบบองค์กรของคุณ?

ติดต่อ Skysoft ได้เลย — ทีมงานพร้อมตอบทุกคำถามโดยไม่มีค่าใช้จ่าย
พร้อมประเมินความเสี่ยงด้านความปลอดภัยขององค์กรของคุณหรือยัง?
ติดต่อทีมผู้เชี่ยวชาญ WatchGuard เพื่อรับคำแนะนำเฉพาะสำหรับธุรกิจของคุณได้วันนี้
หากท่านสนใจทดลองใช้สามารถ  ลงทะเบียนเพื่อขอทดลองได้ฟรี 30 วัน

Credit https://www.watchguard.com

แหล่งอ้างอิง

• 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 ส่วนที่เป็นคำกล่าวของผู้ให้บริการหรือรายงานของนักวิจัยระบุผู้ให้ข้อมูลกำกับไว้แล้ว ตัวอย่างเปิดเรื่องเป็นสถานการณ์สมมติ และจงใจไม่ระบุชื่อผู้ให้บริการ ผลิตภัณฑ์ และรหัสแอป ข้อมูลในบทความนี้ไม่ใช่คำแนะนำทางกฎหมาย

แท็ก: Third-Party Risk · Supply Chain Attack · Microsoft 365 · Cloud Backup · Entra ID · MSP · Vendor Risk · SME Security