ReliaQuest บริษัทด้าน Cybersecurity ชั้นนำ ยืนยันว่าพนักงานคนหนึ่งของบริษัทตกเป็นเป้าหมายของการโจมตีแบบ Social Engineering หลังผู้โจมตีปลอมตัวเป็นสมาชิกทีม Security ภายในและหลอกให้กรอกข้อมูลลงในหน้า Single Sign-On (SSO) ปลอม เหตุการณ์นี้เชื่อมโยงกับกลุ่มเรียกค่าไถ่ข้อมูล ShinyHunters ที่ออกมาอ้างว่าเจาะระบบของ ReliaQuest สำเร็จ อย่างไรก็ตาม ReliaQuest ยืนยันว่าการเข้าถึงที่เกิดขึ้นเป็นแบบ View-only เท่านั้น และสามารถสกัดการขโมยข้อมูลได้ทันก่อนเกิดความเสียหายจริง
รายละเอียดการโจมตี
เหตุการณ์เกิดขึ้นเมื่อวันที่ 22 สิงหาคม 2569 โดยผู้โจมตีโทรศัพท์หาพนักงานหลายคนของ ReliaQuest พร้อมใช้ชื่อของพนักงาน Security จริงเพื่อสร้างความน่าเชื่อถือ (Vishing) และพยายามหลอกให้เข้าถึง หน้า SSO ปลอมที่ซ่อนอยู่หลัง Content Delivery Network (CDN) ซึ่ง BleepingComputer ระบุว่า Lookalike Domain ที่ใช้คือ reliaquest[.]claims
พนักงานคนหนึ่งหลงเชื่อ กรอก Credential ลงในหน้า SSO ปลอม และกด อนุมัติ MFA Push Notification ทำให้ผู้โจมตีได้รับสิทธิ์เข้าถึง Identity Dashboard (Okta) ของ ReliaQuest แบบชั่วคราวและเป็น View-only เท่านั้น
จุดที่น่าสนใจคือ ก่อนหน้าเหตุการณ์เพียงไม่กี่วัน ทีม Threat Research ของ ReliaQuest เพิ่งเผยแพร่รายงานเตือนว่า ShinyHunters กำลังจดทะเบียน Domain รูปแบบ [ชื่อบริษัท].claims เพื่อใช้ปลอมเป็น Help Desk หรือ IT Team ขององค์กรเป้าหมายจำนวนมาก ซึ่งภายหลังบัญชี X ที่เชื่อว่าเชื่อมโยงกับ ShinyHunters ได้ตอบโต้กลับพร้อมโพสต์ภาพหน้าจอที่แสดงว่าเข้าถึงบัญชี Okta ของพนักงาน ReliaQuest ได้จริง ก่อนที่กลุ่มดังกล่าวจะเผยแพร่ภาพเดียวกันบน Data Leak Site ของตน
กลไกการสกัดกั้น
ตามคำแถลงของ ReliaQuest ระบบ Device-trust Controls สามารถสกัดความพยายามของผู้โจมตีในการเข้าถึง Application อื่น ๆ ผ่าน Dashboard ได้สำเร็จทุกครั้ง แม้จะมี Session ที่ถูกบุกรุกอยู่ก็ตาม บริษัทระบุว่า "การเข้าถึงเป็นแบบ View-only เท่านั้น ไม่มี Application หรือระบบใดของ ReliaQuest ถูกเข้าถึง และไม่มีข้อมูลลูกค้าถูกแตะต้องเลย"
ReliaQuest ดำเนินการตอบสนองทันที ได้แก่ ยุติ Session ที่ถูกบุกรุก เพิกถอนรหัสผ่านที่รั่วไหล และรีเซ็ต Authentication Token ทั้งหมด จากนั้นดำเนินการสอบสวนย้อนหลังตั้งแต่วันที่ 21 สิงหาคม ซึ่งไม่พบหลักฐานว่ามีบัญชี Application หรือข้อมูลอื่นถูกเข้าถึง และไม่พบสัญญาณว่าผู้โจมตีสร้างช่องทางเข้าถึงถาวร (Persistence) ไว้ในระบบ
ท่าทีของ ShinyHunters
ในโพสต์บน Data Leak Site ของตน ShinyHunters อ้างอิงถึงรายงานก่อนหน้าของ ReliaQuest เกี่ยวกับกลุ่มตนเอง พร้อมข้อความเชิงท้าทายว่า "ครั้งนี้เป็นเรื่องของคุณ ไม่ใช่เรื่องของเรา" อย่างไรก็ตาม เมื่อสื่อสอบถามเพิ่มเติม กลุ่มดังกล่าวยอมรับกับ BleepingComputer ว่าการเข้าถึงเป็นแบบ View-only จริง ไม่มีการเข้าถึง Application ทางธุรกิจ ไม่มีข้อมูลลูกค้าหรือข้อมูล ReliaQuest ถูกเข้าถึงนอกเหนือจาก Credential ของผู้ใช้ที่ถูกหลอก และไม่มีการสร้าง Persistence แต่อย่างใด ซึ่งสอดคล้องกับคำชี้แจงของ ReliaQuest
ระบบที่ได้รับผลกระทบ
- บัญชี Okta SSO ของพนักงาน ReliaQuest 1 ราย ที่ถูกหลอกให้กรอก Credential และอนุมัติ MFA บนหน้า Phishing
- Identity Dashboard ที่ผู้โจมตีเข้าถึงได้แบบ View-only ในช่วงเวลาสั้น ๆ ก่อนถูกยุติ Session
- ไม่มี Application ทางธุรกิจ ระบบ Production หรือข้อมูลลูกค้าของ ReliaQuest ที่ได้รับผลกระทบโดยตรง ตามการยืนยันของทั้งสองฝ่าย
ผลกระทบที่อาจเกิดขึ้น
- แม้ผลลัพธ์ครั้งนี้จะถูกจำกัดไว้ได้ แต่แสดงให้เห็นว่าแม้แต่บริษัท Cybersecurity ระดับแนวหน้าก็ยังตกเป็นเป้าของ Social Engineering ที่มีการเตรียมการอย่างดีได้ ผู้โจมตีใช้ชื่อพนักงานจริงและ Domain ปลอมที่ออกแบบมาเฉพาะเจาะจงเพื่อสร้างความน่าเชื่อถือ
- การอนุมัติ MFA Push Notification โดยไม่ตรวจสอบบริบทยังคงเป็นจุดอ่อนสำคัญ แม้จะมีการยืนยันตัวตนหลายชั้นแล้วก็ตาม
- Device-trust Controls และการจำกัดสิทธิ์ Session เป็นปราการด่านสำคัญที่ช่วยจำกัดความเสียหายได้จริง ในกรณีนี้ ป้องกันไม่ให้ผู้โจมตีขยับจาก View-only Access ไปสู่การเข้าถึง Application หรือข้อมูลจริง
- แคมเปญ
.claimsDomain ของ ShinyHunters มีแนวโน้มถูกใช้โจมตีองค์กรอื่นในวงกว้างต่อไป เนื่องจากรูปแบบการปลอม Domain ตามชื่อบริษัทเป้าหมายทำได้ง่ายและสร้างความน่าเชื่อถือสูง
สิ่งที่องค์กรควรทำ
- ตรวจสอบ Threat Intelligence เกี่ยวกับ Domain ที่จดทะเบียนภายใต้ TLD
.claimsหรือรูปแบบใกล้เคียงชื่อองค์กร และพิจารณาบล็อกเชิงรุกหากพบ Domain ต้องสงสัย - ให้ความรู้พนักงานเกี่ยวกับ Vishing ที่อ้างเป็นทีม Security หรือ IT ภายใน โดยเฉพาะการขอให้เข้าสู่ระบบผ่านลิงก์ที่ส่งมาทางโทรศัพท์
- ทบทวนนโยบาย MFA ให้ใช้ Phishing-resistant MFA เช่น FIDO2/Passkey แทน Push Notification แบบเดิม ซึ่งเสี่ยงต่อ MFA Fatigue และการอนุมัติโดยไม่ทันตรวจสอบ
- เสริมความเข้มแข็งของ Device-trust Controls เพื่อจำกัดไม่ให้ Session ที่ถูกบุกรุกสามารถเข้าถึง Application สำคัญได้ แม้ผ่านขั้นตอน Authentication มาแล้ว
แนวทางลดความเสี่ยงระยะยาว
1. เปลี่ยนผ่านสู่ Phishing-resistant MFA อย่างจริงจัง
ลดการพึ่งพา Push Notification เพียงอย่างเดียว และผลักดันการใช้ FIDO2/Passkey หรือ Hardware Security Key สำหรับบัญชีที่มีสิทธิ์สูง
2. สร้างกระบวนการ Verification สำหรับการติดต่อที่อ้างเป็นทีม Security/IT ภายใน
เช่น Callback Verification ผ่านช่องทางที่ตรวจสอบได้ ก่อนดำเนินการใด ๆ ตามคำขอทางโทรศัพท์
3. ลงทุนใน Device-trust และ Zero Trust Architecture
เพื่อให้ Session ที่ถูกบุกรุกแม้จะผ่าน Authentication มาแล้ว ก็ยังถูกจำกัดสิทธิ์การเข้าถึง Application ตาม Posture ของอุปกรณ์
4. ติดตาม Domain Registration ที่เข้าข่าย Brand Impersonation อย่างต่อเนื่อง
ผ่านบริการ Domain Monitoring เพื่อตรวจจับความพยายาม Phishing ก่อนถูกใช้โจมตีจริง
วิเคราะห์ในมุมมองจาก TXEC
กรณี ReliaQuest เป็นตัวอย่างที่มีคุณค่าในสองมิติ มิติแรกคือแม้แต่องค์กรที่เชี่ยวชาญด้าน Cybersecurity โดยตรงก็ยังสามารถตกเป็นเหยื่อของ Social Engineering ที่ออกแบบมาอย่างมีเป้าหมายชัดเจนได้ สะท้อนว่าปัจจัยมนุษย์ยังคงเป็นจุดอ่อนที่ยากจะขจัดให้หมดไปได้ทั้งหมด ไม่ว่าองค์กรจะมีความรู้ด้าน Security มากเพียงใด
มิติที่สองซึ่งสำคัญไม่แพ้กันคือ ผลลัพธ์ของเหตุการณ์นี้แสดงให้เห็นคุณค่าของการมี Defense-in-Depth ที่แท้จริง การที่ Device-trust Controls สามารถสกัดผู้โจมตีไม่ให้ขยับจาก Initial Access ไปสู่การเข้าถึงข้อมูลจริงได้ คือสิ่งที่แบ่งแยกระหว่าง "เหตุการณ์ความปลอดภัยที่ถูกควบคุมได้" กับ "การรั่วไหลของข้อมูลขนาดใหญ่" TXEC มองว่าองค์กรควรยึดหลักที่ว่า Initial Compromise มีโอกาสเกิดขึ้นได้เสมอ จึงต้องออกแบบ Control ชั้นถัดไปให้พร้อมจำกัดความเสียหายไว้เสมอ ไม่ใช่พึ่งพาการป้องกันชั้นแรกเพียงอย่างเดียว
รู้ก่อน ตรวจพบเร็ว ลดความเสียหายได้มากกว่า
[ แหล่งอ้างอิง: BleepingComputer, The Register, Help Net Security, SC Media, Infosecurity Magazine, SecurityWeek ]