เวลาที่ทีม Cybersecurity ไปประเมินความเสี่ยงและให้คำปรึกษากับลูกค้าธุรกิจ เราพบว่าหลายองค์กรมักจะมีความเข้าใจที่ว่า “ถ้าหน้า Login เป็นโดเมนของ Microsoft ของจริง แล้วเราบังคับใช้ MFA (Multi-Factor Authentication) ด้วยเนี่ย ระบบเราก็จะปลอดภัยจากการถูกฟิชชิง (Phishing) 100% แล้ว”
แต่โลกของความปลอดภัยไซเบอร์มันไม่ได้ง่ายแบบนั้นเสมอไปครับ วันนี้ผมจะมาเจาะลึกถึงภัยคุกคามที่เรียกว่า OAuth Consent Phishing (ทางเทคนิคเรามักเรียกว่า Illicit Consent Grant) ซึ่งเป็นการโจมตีที่หลบหลีกเกราะป้องกันอย่าง MFA ไปได้อย่างแนบเนียน และถือเป็นประเด็นด้าน Cloud Identity Security ที่ผู้บริหารและทีม IT ต้องรีบกลับไปทบทวนระบบของตัวเองโดยด่วนครับ
1. OAuth Consent Phishing คืออะไร? (และมันต่างจากฟิชชิงปกติยังไง)
ในการทำ Microsoft 365 Phishing แบบที่เราคุ้นเคยนั้น แฮกเกอร์จะสร้างเว็บปลอมเพื่อหลอกเอา Username และ Password ของเรา (เปรียบเหมือนการหลอกขโมยกุญแจหน้าบ้าน)
แต่เป้าหมายของ OAuth Consent Phishing นั้นล้ำกว่านั้นครับ เพราะผู้โจมตีนั้น พวกเขาจะใช้วิธีหลอกให้ผู้ใช้มอบ "สิทธิ์การเข้าถึง" (Authorization) ให้กับแอปพลิเคชันอันตรายที่พวกเขาสร้างขึ้นมาเอง (Malicious OAuth App) เปรียบง่ายๆ คือ คุณไขกุญแจเข้าบ้านตัวเองอย่างถูกต้อง แต่ดันไปเซ็นเอกสารยินยอมให้คนแปลกหน้าเดินเข้าออกบ้านเพื่อมาค้นของได้ตลอดเวลานั่นเองครับ
2. ทำไมหน้า login.microsoftonline.com ของจริงยังอันตราย?
เรามาดูลำดับการขั้นตอนของการโจมตีที่มักจะใช้กัน วิธีการนี้ยังคงถูกนำมาใช้ซ้ำได้เรื่อยๆ โดยมีสเต็ปการโจมตีคร่าวๆ ประมาณนี้
หลอกด้วยอีเมล - ยูซเซอร์ มักจะได้รับอีเมลที่แอบอ้างว่าเป็นฝ่าย HR ฝ่าย IT หรือแม้แต่แฝงมาในรูปแบบแจ้งเตือนจากตัว Microsoft Teams เองเลยแต่ปลอมมา
Login ตามปกติ - พอกดลิงก์ ระบบก็มักจะพาผู้ใช้ไปยังหน้า login.microsoftonline.com ของจริง! จากนั้นผู้ใช้ก็กรอกรหัสผ่านและกดรับ MFA ตามความเคยชิน
จุดสลบ - พอผู้ใช้ Login ผ่านเท่านั้นแหละครับ ระบบก็จะปรากฎหน้าต่าง Pop-up ขึ้นมาถามว่าคุณต้องการ “Accept” (ยอมรับ) สิทธิ์การเข้าถึงจากแอปพลิเคชัน Third-party หรือไม่
จุดพลาดท่า - ด้วยความที่พนักงานชินกับการกด Accept ไปเรื่อยๆ เพื่อให้ได้เข้าใช้งานระบบ (ซึ่งตรงนี้แหละครับที่เป็นความเสี่ยงอย่างมาก) จึงกดยอมรับไปโดยไม่ทันได้อ่านรายละเอียดสิทธิ์ที่แอปนั้นร้องขอ
3. เมื่อแอปอันตรายแฝงตัวเข้ามา ผลกระทบทางธุรกิจคืออะไร?
ถ้าองค์กรปล่อยปละละเลยเรื่อง OAuth Application Security แอปพลิเคชันเหล่านี้อาจจะเนียนขอสิทธิ์ระดับสูงได้ (เช่น Mail.ReadWrite, Files.ReadWrite.All หรือ offline_access) ซึ่งจะนำไปสู่ความเสียหายมหาศาลได้ครับ ขอยกตัวอย่างให้เห็นภาพเช่น
โดนสวมรอยส่งอีเมล (BEC) - แฮกเกอร์สามารถอ่านและส่งอีเมลในนามพนักงานคนนั้นได้เลย ซึ่งมักจะถูกนำไปใช้หลอกคู่ค้าให้เปลี่ยนเลขบัญชีโอนเงิน หรือปลอมเป็นผู้บริหาร
ข้อมูลความลับรั่วไหล - แฮกเกอร์สามารถเข้าถึงเอกสารใน OneDrive และ SharePoint รวมถึงล้วงข้อมูลการประชุมต่างๆ ไปได้
งานเข้าเรื่องกฎหมาย (PDPA Impact) - หากอีเมลและไฟล์ที่โดนล้วงไปมีข้อมูลส่วนบุคคลของลูกค้าหรือพนักงาน องค์กรของคุณในฐานะ "ผู้ควบคุมข้อมูล" (Data Controller) จะถือว่าเกิดเหตุละเมิดข้อมูลส่วนบุคคลขึ้น ซึ่งต้องเตรียมกระบวนการแจ้งเหตุต่อคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (สคส.) ภายใน 72 ชั่วโมงตามกฎหมายด้วยครับ
4. ทำไม MFA ถึงเอาไม่อยู่ แล้วการเปลี่ยน Password ช่วยได้ไหม?
เวลาเกิดเหตุ (Incident) สิ่งแรกที่หลายองค์กรสั่งให้พนักงานทำคือ "เปลี่ยนรหัสผ่านทันที" แต่เชื่อไหมครับว่ามันแก้ปัญหาไม่ได้! เพราะ OAuth Consent Phishing ทำงานผ่าน Access Token และ Refresh Token
ตราบใดที่คุณยังไม่ได้เข้าไป ถอนสิทธิ์ (Revoke Consent/Token) แฮกเกอร์ก็ยังคงดึงข้อมูลจากระบบของคุณได้อย่างต่อเนื่องครับ ไม่ว่าพนักงานจะเปลี่ยนรหัสผ่านกี่รอบ หรือมี MFA ที่แข็งแกร่งแค่ไหนก็ตาม นี่คือเหตุผลสำคัญที่เรา ไม่เพียงแค่ต้องควบคุมเรื่อง Identity ของผู้ใช้ แต่ยังต้องจัดการเรื่อง Application Consent ควบคู่กันไปด้วยเสมอ ครับ
5. แผนปฏิบัติการที่องค์กรควรทำ (Microsoft 365 Security Checklist)
ในมุมมองของการบริหารจัดการความเสี่ยง (Risk-Based Approach) ผมขอแนะนำ Action Plan ที่ System Administrator และผู้บริหาร IT ควรนำไปปรับใช้ดังนี้ครับ
Phase 1 - การจำกัดสิทธิ์ (Prevention)
จำกัด User Consent ปิดไม่อนุญาตให้พนักงานทั่วไปกดยอมรับ Consent แอปพลิเคชันได้เองใน Microsoft Entra (หรือตั้งค่าให้กดได้เฉพาะแอปที่ Verified หรือมีความเสี่ยงต่ำเท่านั้น)
ใช้ Admin Consent Workflow หากพนักงานจำเป็นต้องใช้แอปพลิเคชันใหม่ๆ ให้ระบบส่งคำร้อง (Request) มาให้ IT Admin เป็นผู้ตรวจสอบและอนุมัติก่อนเสมอครับ
Phase 2 - การตรวจสอบและเฝ้าระวัง (Detection & Monitoring)
อัพเดตแอปเก่า หมั่นเข้าไปตรวจสอบเมนู Enterprise Applications และ OAuth Apps ในระบบ หากพบแอปพลิเคชันที่ไม่รู้จักหรือไม่ได้ใช้งานแล้ว ให้ระงับ (Disable) ทันที
ตรวจสอบสิทธิ์ (Scope) ที่เกินความจำเป็น ค้นหาแอปที่มีสิทธิ์ประเภท Mail, Files, Teams และ Offline Access ว่าจำเป็นต่อการดำเนินธุรกิจจริงหรือไม่
เฝ้าระวังผ่าน Log ตรวจสอบ Sign-in Log และ Audit Log ของ Service Principal อย่างสม่ำเสมอ (ซึ่งการเก็บ Log เหล่านี้ยังช่วยให้สอดคล้องกับ พ.ร.บ. คอมฯ ด้วยครับ) พร้อมตั้ง Alert หากมีแอปพลิเคชันใดขอสิทธิ์ผิดปกติ
Phase 3 - การรับมือเมื่อเกิดเหตุ (Incident Response)
เตรียม Playbook ไว้ล่วงหน้า หากสงสัยว่าผู้ใช้เผลอกดอนุญาตแอปอันตรายไปแล้ว ต้องมีขั้นตอนที่ชัดเจน คือ 1. ถอน Consent และลบแอป 2. Revoke Token ของผู้ใช้รายนั้นทันที และ 3. ตรวจสอบ Audit Log ย้อนหลังเพื่อประเมินระดับความเสียหายครับ
Phase 4 - การสร้างความตระหนักรู้ (Security Awareness)
ปรับเนื้อหาการอบรมพนักงาน: การสอนเรื่องฟิชชิงแบบเดิมๆ ที่ให้ดูแค่โดเมนเนมของเว็บไซต์อาจจะไม่พอแล้วครับ เราต้องสอนให้พนักงานรู้จักสังเกตหน้าจอขอสิทธิ์ (Permission Screen) และฉุกคิดก่อนที่จะกดยอมรับแอปพลิเคชันแปลกหน้าด้วย
(ข้อสังเกต ข้อมูลแคมเปญโจมตีอ้างอิงจากรายงานของ Microsoft รายงานนี้ไม่ได้ให้ทุกองค์กรที่ไทยโดนทั้งหมดนะครับ เพราะบริบทการตั้งค่า และ License ของแต่ละที่นั้นต่างกัน การป้องกันและตรวจสอบเชิงรุกจึงเป็นทางออกที่ดีที่สุดครับ)
หากองค์กรของคุณกำลังมองหาที่ปรึกษาด้านการตั้งค่า Cloud Identity Security หรือต้องการวางสถาปัตยกรรมความปลอดภัยที่ครอบคลุมทั้งประเด็นด้านเทคนิคและข้อกฎหมาย (PDPA / พ.ร.บ. ไซเบอร์ฯ) ทีมงาน Cybernetics+ ยินดีให้คำปรึกษาและพร้อมดูแลระบบของคุณครับ
