Storm‑2949: แฮกเกอร์ใช้ช่องโหว่การรีเซ็ตรหัสผ่าน เจาะ Microsoft 365 และ Azure ได้อย่างไร

แนวทางนี้ทำให้กิจกรรมของผู้โจมตีดูเหมือนการใช้งานปกติของระบบ จึงยากต่อการตรวจจับด้วยเครื่องมือรักษาความปลอดภัยแบบเดิม

บทบาทของ Self‑Service Password Reset (SSPR)

ขั้นตอนสำคัญของการโจมตีคือการใช้ประโยชน์จาก Self‑Service Password Reset (SSPR) ใน Microsoft Entra ซึ่งปกติถูกออกแบบมาเพื่อให้ผู้ใช้รีเซ็ตรหัสผ่านเองได้โดยไม่ต้องติดต่อฝ่าย IT

Storm‑2949 ใช้ social engineering เพื่อหลอกเหยื่อผ่านขั้นตอนนี้ เช่น

• แฮกเกอร์แอบอ้างเป็นเจ้าหน้าที่ IT หรือทีมความปลอดภัยของบริษัท
• โทรหรือส่งข้อความให้พนักงานยืนยันคำขอที่ดูเหมือนขั้นตอนตรวจสอบปกติ
• คำขอนั้นแท้จริงคือ การอนุมัติ MFA ที่เกิดขึ้นระหว่างกระบวนการรีเซ็ตรหัสผ่าน

เมื่อเหยื่อกดอนุมัติ ผู้โจมตีจะสามารถดำเนินขั้นตอนรีเซ็ตรหัสผ่านต่อได้

หลังจากยึดบัญชีสำเร็จ ผู้โจมตีสามารถ:

• เปลี่ยนรหัสผ่านของบัญชี
• ลบวิธีการยืนยันตัวตนเดิมของผู้ใช้จริง
• ลงทะเบียนอุปกรณ์ยืนยันตัวตนของตนเอง เช่น Microsoft Authenticator

ผลลัพธ์คือ ผู้ใช้ตัวจริงถูกล็อกออกจากบัญชี ขณะที่ผู้โจมตีมีการเข้าถึงแบบ MFA เต็มรูปแบบ

จากบัญชีเดียวสู่การเจาะระบบทั้งคลาวด์

เมื่อควบคุมบัญชีได้ Storm‑2949 จะเริ่มขยายการเข้าถึงไปทั่วสภาพแวดล้อมคลาวด์ขององค์กร

เนื่องจากบัญชีที่ถูกโจมตีมักเป็นบัญชีของ ผู้ดูแลระบบ IT หรือผู้บริหารระดับสูง ผู้โจมตีจึงสามารถเข้าถึงบริการต่าง ๆ ได้จำนวนมาก

เป้าหมายที่ถูกเข้าถึง เช่น

• ข้อมูลใน Microsoft 365 เช่น SharePoint และ OneDrive
• ระบบ production ที่รันอยู่บน Azure
• Storage accounts และฐานข้อมูลบนคลาวด์
• ข้อมูลลับในบริการอย่าง Azure Key Vault

เหตุการณ์นี้ตอกย้ำความจริงสำคัญของระบบคลาวด์: ตัวตนผู้ใช้คือศูนย์กลางการควบคุมระบบ หากบัญชีที่มีสิทธิ์สูงถูกยึด ผู้โจมตีอาจเข้าถึงบริการจำนวนมากโดยไม่ต้องเจาะช่องโหว่ซอฟต์แวร์เลย

ทำไม Microsoft จึงเลิกใช้การยืนยันตัวตนด้วย SMS

พร้อมกับเหตุการณ์ด้านความปลอดภัยเหล่านี้ Microsoft ได้ประกาศว่า จะทยอยยกเลิกการส่งรหัสยืนยันผ่าน SMS สำหรับบัญชี Microsoft ส่วนบุคคล

เหตุผลหลักคือ SMS กลายเป็นหนึ่งในช่องทางที่เกิดการฉ้อโกงออนไลน์มากที่สุด

จุดอ่อนสำคัญของ SMS ได้แก่

• การโจมตีแบบ SIM‑swap ที่โอนหมายเลขโทรศัพท์ของเหยื่อไปยังซิมของผู้โจมตี
• การดักจับข้อความในโครงสร้างพื้นฐานของเครือข่ายโทรคมนาคม
• การหลอกให้ผู้ใช้เปิดเผยรหัส OTP

เนื่องจากรหัสผ่านแบบ SMS สามารถถูกฟิชชิงและส่งต่อได้ง่าย Microsoft จึงมองว่ามีความปลอดภัยต่ำกว่าวิธีใหม่ ๆ

ทางเลือกที่บริษัทกำลังผลักดัน ได้แก่

• Passkeys
• แอปยืนยันตัวตน เช่น Microsoft Authenticator
• อีเมลสำรองที่ผ่านการยืนยัน

ระบบเหล่านี้ใช้การเข้ารหัสและผูกกับอุปกรณ์ ทำให้ถูกฟิชชิงได้ยากกว่ามาก

แนวทางป้องกันที่ Microsoft แนะนำให้องค์กรใช้

เหตุการณ์ Storm‑2949 แสดงให้เห็นว่าการโจมตีด้าน identity สามารถหลบเลี่ยงการป้องกันแบบเดิมได้ Microsoft จึงแนะนำมาตรการหลักหลายข้อ

1. ใช้ MFA ที่ต้านการฟิชชิง

องค์กรควรใช้วิธีการยืนยันตัวตนที่ไม่สามารถถูกหลอกให้ส่งต่อได้ เช่น passkeys หรือฮาร์ดแวร์คีย์ที่รองรับมาตรฐานความปลอดภัยสมัยใหม่

2. ใช้หลัก Least‑Privilege

กำหนดสิทธิ์ตามบทบาท (RBAC) ให้ผู้ใช้มีสิทธิ์เท่าที่จำเป็นต่อการทำงานเท่านั้น เพื่อลดผลกระทบหากบัญชีหนึ่งถูกยึด

3. ป้องกันกระบวนการรีเซ็ตรหัสผ่าน

กระบวนการกู้คืนบัญชี เช่น SSPR ควรถูกมองว่าเป็น จุดเสี่ยงสูง และต้องมีการควบคุมและตรวจสอบอย่างเข้มงวด โดยเฉพาะสำหรับบัญชีที่มีสิทธิ์สูง

4. ตรวจสอบกิจกรรม identity และ control‑plane

องค์กรควรเปิด logging และ monitoring สำหรับ

• เหตุการณ์การล็อกอินและการยืนยันตัวตน
• กิจกรรมรีเซ็ตรหัสผ่าน
• การเข้าถึงข้อมูลใน Microsoft 365
• การดำเนินการบริหารระบบใน Azure

การมีข้อมูลเหล่านี้ช่วยให้ทีมความปลอดภัยตรวจจับพฤติกรรมผิดปกติได้เร็วขึ้นระหว่างการโจมตี

บทเรียนสำคัญ: ตัวตนคือพื้นผิวการโจมตีใหม่

Storm‑2949 แสดงให้เห็นการเปลี่ยนแปลงสำคัญของการโจมตีไซเบอร์สมัยใหม่ แทนที่จะโจมตีซอฟต์แวร์โดยตรง ผู้โจมตีหันมา โจมตีระบบยืนยันตัวตนและกระบวนการกู้คืนบัญชี มากขึ้น

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