ศูนย์ประสานการรักษาความมั่นคงปลอดภัยระบบคอมพิวเตอร์แห่งชาติ (ThaiCERT) ได้ติดตามสถานการณ์ภัยคุกคามทางไซเบอร์เกี่ยวกับเทคนิค MFA Prompt Bombing หรือ MFA Fatigue ด้วยการส่งคำขอยืนยันตัวตน (MFA) แบบ Push Notification ไปยังโทรศัพท์มือถือของเหยื่อซ้ำ ๆ อย่างต่อเนื่อง เพื่อสร้างความรำคาญและหลอกให้ผู้ใช้งานกด “ยอมรับ” (Approve) ซึ่งหากกดยอมรับไปแล้ว แฮกเกอร์ (ซึ่งมีรหัสผ่านที่ถูกต้องอยู่ก่อนแล้วจากการรั่วไหลของข้อมูล) จะสามารถเข้าสู่ระบบเครือข่ายภายในองค์กร และขโมยข้อมูลสำคัญได้ทันที การโจมตีมุ่งเป้าไปที่ผู้ใช้งานและหน่วยงานที่ใช้ระบบยืนยันตัวตนแบบกดปุ่มแจ้งเตือนผ่านแอปพลิเคชัน (Push-based MFA) เช่น ระบบ VPN, บริการ Cloud, Microsoft 365 หรือระบบ Single Sign-On ต่าง ๆ [1]
1. รายละเอียดภัยคุกคาม
การโจมตีแบบ MFA Prompt Bombing (หรือ MFA Fatigue) เป็นการโจมตีทางจิตวิทยา (Social Engineering) รูปแบบหนึ่ง ผู้โจมตีจะเริ่มต้นจากการหาบัญชีและรหัสผ่านที่ถูกต้องของเหยื่อ (เช่น จากรหัสผ่านที่เคยรั่วไหล หรือมัลแวร์ขโมยข้อมูล) เพื่อใช้ล็อกอินเข้าสู่ระบบขององค์กร
เมื่อระบบต้องการการยืนยันตัวตนชั้นที่ 2 แฮกเกอร์จะทำการกดยกเลิกและล็อกอินใหม่ซ้ำ ๆ ทำให้ระบบส่งแจ้งเตือน (Push Notification) ไปยังแอปพลิเคชันบนมือถือของเหยื่ออย่างต่อเนื่องจนเหยื่อเกิดความสับสน รำคาญ หรือคิดว่าระบบมีปัญหา บางกรณีแฮกเกอร์อาจโทรศัพท์หลอกลวง (Vishing) โดยอ้างตัวเป็นฝ่าย IT ขององค์กร เพื่อโน้มน้าวให้เหยื่อกดยืนยัน หากเหยื่อกด “ยอมรับ” เพียงครั้งเดียว แฮกเกอร์จะสามารถเข้ายึดระบบได้ทันที
2. ลักษณะการโจมตี
ผู้โจมตีจะเริ่มจากการนำข้อมูลบัญชีที่ถูกต้องไปทดลองเข้าสู่ระบบ เช่น VPN หรือบริการ Cloud ของหน่วยงาน เมื่อระบบส่งคำขอ MFA แบบ Push ไปยังอุปกรณ์ของผู้ใช้งาน ผู้โจมตีจะกดเข้าสู่ระบบซ้ำ ๆ เพื่อให้เกิดคำขออนุมัติจำนวนมาก หากเหยื่อกดยืนยันเพียงครั้งเดียว ผู้โจมตีจะสามารถเข้าสู่ระบบในฐานะผู้ใช้งานรายนั้นได้ และระบบรักษาความปลอดภัยอาจมองว่าเป็นการเข้าสู่ระบบที่ถูกต้องตามปกติ
ตัวอย่างของการโจมตีด้วยเทคนิคนี้คือ เหตุการณ์ Cisco ในปี พ.ศ.2565 กลุ่มแฮกเกอร์ Yanluowang ได้ใช้เทคนิคนี้ร่วมกับการโทรหลอกลวงพนักงานของ Cisco จนพนักงานเผลอกดยืนยัน MFA ส่งผลให้แฮกเกอร์เจาะเข้าสู่ระบบ VPN เคลื่อนย้ายเข้าสู่เซิร์ฟเวอร์ภายใน และขโมยข้อมูลออกไปได้ถึง 2.75 GB [2]
3. ผลกระทบ
3.1 ผู้โจมตีสามารถยึดบัญชีผู้ใช้งานได้ หากเหยื่อกดยืนยันคำขอ MFA ที่ไม่ได้เป็นผู้เริ่มต้นเอง
3.2 ผู้โจมตีอาจเข้าถึงระบบภายในหน่วยงาน เช่น VPN, ระบบ Cloud, อีเมลหน่วยงาน หรือระบบ Identity Provider
3.3 การเข้าสู่ระบบอาจถูกมองว่าเป็นกิจกรรมที่ถูกต้อง เนื่องจากใช้รหัสผ่านและ MFA ที่ผ่านการอนุมัติจริง ทำให้การตรวจจับทำได้ยากขึ้น
3.4 ผู้โจมตีอาจลงทะเบียนอุปกรณ์ MFA เพิ่มเติม เพื่อรักษาสิทธิ์เข้าถึงระบบในระยะยาว
3.5 อาจนำไปสู่การยกระดับสิทธิ์ การเคลื่อนย้ายภายในเครือข่าย และการขโมยข้อมูลสำคัญของหน่วยงาน
4. ระบบหรือบริการที่มีความเสี่ยง
4.1 ระบบ VPN ที่ใช้ MFA แบบ Push Notification
4.2 บริการ Cloud และระบบอีเมลหน่วยงาน เช่น Microsoft 365
4.3 ระบบ Identity Provider หรือ SSO เช่น Okta, Duo หรือระบบที่มีลักษณะใกล้เคียง
4.4 ระบบ Remote Access, RDP หรือระบบสำหรับผู้ดูแลระบบที่ยังใช้ Push-based MFA เป็นปัจจัยยืนยันตัวตนหลัก
4.5 หน่วยงานที่ยังไม่มีการตรวจจับรหัสผ่านที่รั่วไหล หรือยังไม่มีนโยบาย Conditional Access ที่พิจารณาความเสี่ยงจากตำแหน่งที่ตั้ง อุปกรณ์ เวลา และพฤติกรรมการเข้าสู่ระบบ
5. แนวทางการแก้ไขและป้องกัน
5.1 หลีกเลี่ยงการใช้ MFA แบบ Push-only กับระบบสำคัญ โดยพิจารณาใช้วิธีที่ต้านทาน Phishing และ MFA Fatigue มากขึ้น
5.2 เปิดใช้งาน Number Matching สำหรับแอป Authenticator เพื่อลดความเสี่ยงจากการกดยืนยันผิดพลาด
5.3 ใช้นโยบาย Conditional Access โดยพิจารณาจากปัจจัยเสี่ยง เช่น ประเทศหรือพื้นที่ที่เข้าสู่ระบบ สถานะอุปกรณ์ เวลาในการเข้าสู่ระบบ และพฤติกรรมที่ผิดปกติ
5.4 ตรวจสอบและบล็อกรหัสผ่านที่เคยรั่วไหล โดยเฉพาะบัญชีใน Active Directory และบัญชีที่ใช้เข้าถึงระบบสำคัญ
5.5 กำหนดให้ผู้ใช้งานรายงานทันทีเมื่อได้รับคำขอ MFA ที่ไม่ได้เป็นผู้เริ่มต้นเอง และห้ามกดยืนยันคำขอดังกล่าว
5.6 เฝ้าระวังเหตุการณ์ MFA ผิดปกติ เช่น การส่ง Push Notification จำนวนมากในช่วงเวลาสั้น ๆ การเข้าสู่ระบบจากประเทศที่ไม่เคยใช้งาน หรือการเพิ่มอุปกรณ์ MFA ใหม่โดยไม่ทราบสาเหตุ
5.7 จัดอบรมผู้ใช้งานให้รู้จักเทคนิค MFA Prompt Bombing และ Vishing โดยเน้นว่าฝ่าย IT ไม่ควรขอให้ผู้ใช้งานกดยืนยัน MFA ที่ไม่ได้เป็นผู้เริ่มต้นเอง
5.8 จำกัดสิทธิ์การเข้าถึงตามหลัก Least Privilege และตรวจสอบบัญชีผู้ดูแลระบบอย่างสม่ำเสมอ เพื่อลดผลกระทบหากบัญชีถูกยึด
แหล่งอ้างอิง