Knight Office: เมื่อผู้ใช้ผ่าน MFA แล้ว แฮกเกอร์ยังขโมยเซสชัน Microsoft 365 ได้อย่างไร

Knight Office เป็นตัวอย่างสำคัญว่า MFA ยืนยันการลงชื่อเข้าใช้ครั้งหนึ่ง แต่ไม่ได้ปกป้องทุกเซสชันที่ถูกสร้างขึ้นหลังจากนั้นโดยอัตโนมัติ ในเหตุการณ์ที่ Huntress ตรวจสอบ ผู้โจมตีใช้ฟิชชิงแบบ adversary-in-the-middle (AiTM) เพื่อขโมยข้อมูลเซสชันของ Microsoft 365 ก่อนมีการลงทะเบียนอุปกรณ์ใน Microsoft Entra ID โดยไม่ได้รับอนุญาต จึงควรมองเหตุการณ์ลักษณะนี้ว่าเป็น การบุกรุกตัวตนดิจิทัล (identity compromise) ไม่ใช่เพียงรหัสผ่านรั่ว 640

ลำดับการโจมตีของ Knight Office

เหตุการณ์เริ่มจากอีเมลฟิชชิงที่ทำให้ดูเหมือนมาจาก DocuSign ลิงก์ในอีเมลถูกส่งต่อผ่านบริการติดตามของ Monday.com แล้วไปยังเว็บไซต์ Joomla ที่ถูกยึด เพื่อซ่อนปลายทางฟิชชิงจริงจากระบบตรวจสอบชื่อเสียงของลิงก์และการตรวจสอบอีเมลเบื้องต้น 6

จากนั้นหน้าเว็บหลอกอาจนำเหยื่อเข้าสู่ขั้นตอนการทำงานร่วมกันหรือการลงชื่อเข้าใช้ของ Microsoft ที่ดูน่าเชื่อถือ รวมถึงการป้อนรหัสแบบ device code เป้าหมายคือทำให้ผู้ใช้อนุมัติการยืนยันตัวตนที่เข้าใจว่าเป็นคำขอปกติ

ส่วน AiTM ทำหน้าที่เป็น reverse proxy คั่นระหว่างเหยื่อกับบริการลงชื่อเข้าใช้ Microsoft ของจริง โดยมีลำดับหลักดังนี้

1. เหยื่อกรอกข้อมูลล็อกอินและผ่านคำขอ MFA ตามปกติ
2. proxy ส่งต่อการโต้ตอบนั้นไปยัง Microsoft แบบเรียลไทม์
3. เมื่อยืนยันตัวตนสำเร็จ ผู้โจมตีดักจับ session cookie หรือข้อมูลโทเค็นที่ส่งกลับมายังเบราว์เซอร์
4. ผู้โจมตีใช้ข้อมูลสถานะที่ยืนยันตัวตนแล้วนั้นซ้ำจากโครงสร้างพื้นฐานของตน เพื่อเข้าถึงบัญชี

นี่ไม่ใช่การทำลายการเข้ารหัสของ MFA แต่เป็นการขโมยสถานะการอนุญาตที่ออกให้ หลัง MFA สำเร็จ Microsoft ให้นิยาม token theft ว่าเป็นการบุกรุกและนำโทเค็นที่ออกให้ผู้ใช้ไปใช้ซ้ำ แม้ผู้ใช้นั้นจะผ่านการยืนยันหลายปัจจัยแล้วก็ตาม 40

เหตุใดเปลี่ยนรหัสผ่านอย่างเดียวอาจยังไม่จบ

เซสชันเบราว์เซอร์ที่ถูกขโมย หรือการเข้าถึงที่ได้จาก refresh token อาจเปิดทางให้ผู้บุกรุกทำงานต่อโดยไม่ต้องกรอกรหัสผ่านหรือผ่าน MFA อีก จนกว่าโทเค็นที่เกี่ยวข้องจะถูกเพิกถอน แนวทางของ Microsoft ระบุให้บล็อกผู้ใช้หรืออุปกรณ์ที่ได้รับผลกระทบ และเพิกถอนโทเค็นปัจจุบัน 40

สิ่งที่ทำให้ Knight Office มีความรุนแรงมากขึ้น คือกิจกรรมหลังการบุกรุกที่รายงานไว้ ได้แก่ การนำโฮสต์ที่ไม่ได้รับอนุญาตเข้าลงทะเบียนใน Microsoft Entra ID และตั้งค่า Windows Hello for Business ที่ผู้โจมตีควบคุม 6 นั่นอาจกลายเป็นเส้นทางยืนยันตัวตนอีกทางหนึ่ง ดังนั้นแม้จะเพิกถอนเว็บเซสชันหรือรีเซ็ตรหัสผ่านแล้ว ทีมป้องกันยังต้องตรวจสอบว่าไม่มีอุปกรณ์หรือวิธีรับรองตัวตนใหม่ที่ไม่ได้รับอนุญาตหลงเหลืออยู่

แนวคิด persistence แบบเดียวกันเคยปรากฏในงานวิจัย device-code phishing โดย Microsoft รายงานว่า refresh token ที่ได้จากการละเมิด device-code flow อาจนำไปขอโทเค็นสำหรับบริการลงทะเบียนอุปกรณ์ และลงทะเบียนอุปกรณ์ที่ผู้โจมตีควบคุมใน Entra ID ได้ 28

Device-code phishing เกี่ยวข้องกับ AiTM แต่ไม่ใช่สิ่งเดียวกัน

AiTM phishing ทำหน้าที่เป็นตัวกลางในการล็อกอินสด แล้วขโมยเซสชันที่เกิดขึ้น ส่วน device-code phishing เป็นการนำ OAuth device authorization flow ที่ถูกต้องตามระบบมาใช้ในทางมิชอบ ผู้โจมตีเริ่มขอ device code แล้วหลอกให้เหยื่อป้อนรหัสและยืนยันตัวตน หากเหยื่ออนุมัติ ไคลเอนต์ที่ผู้โจมตีควบคุมจะได้รับโทเค็นสำหรับทรัพยากรและขอบเขตสิทธิ์ที่ร้องขอ 22

ทั้งสองวิธีสะท้อนการเปลี่ยนเป้าหมายของผู้โจมตี จากการเก็บรหัสผ่าน ไปสู่การได้มาซึ่งวัตถุยืนยันสิทธิ์ที่ใช้งานได้จริง โปรแกรมตรวจจับจึงควรครอบคลุมทั้งสองเส้นทาง โดยแนวทางของ Elastic ชี้ให้ตรวจหาการลงชื่อเข้าใช้ Entra แบบ interactive ที่ใช้ device-code protocol ผ่าน Microsoft Authentication Broker และร้องขอทรัพยากรของ Microsoft เช่น Exchange Online, Microsoft Graph หรือ SharePoint 17

กิจกรรมที่พบ และบริบทของตลาด PhaaS

การตรวจสอบของ Huntress ยืนยันลำดับการบุกรุก Knight Office ที่ประกอบด้วยเหยื่อล่อธีมเอกสาร การเปลี่ยนเส้นทางหลายทอด การขโมย session token และการลงทะเบียนอุปกรณ์ Entra โดยไม่ได้รับอนุญาต Huntress ยังเชื่อมโยงการนำโทเค็นกลับมาใช้ซ้ำหลายครั้งใน telemetry กับ IP เดียวกัน แต่ข้อสังเกตนี้ไม่ควรถูกตีความเป็นจำนวนเหยื่อทั้งหมดทั่วโลก 6

Knight Office ยังสอดคล้องกับตลาดฟิชชิงแบบบริการ (phishing-as-a-service หรือ PhaaS) ที่มุ่งโจมตีเซสชัน Microsoft 365 มากขึ้น เช่น

• Mirage2FA ใช้โครงสร้างพื้นฐาน AiTM เพื่อขโมยข้อมูลรับรองและเซสชันที่ยืนยันตัวตนแล้ว ANY.RUN รายงานเหตุการณ์ที่อาจเป็นการบุกรุก 9,332 ครั้งระหว่างปี 2024–2026 ซึ่งรวมเหตุการณ์ขโมยคุกกี้ 4,561 ครั้ง ตัวเลขเหล่านี้เป็นข้อมูล telemetry ของเหตุการณ์ที่เป็นไปได้ ไม่ใช่จำนวนเหยื่อที่ยืนยันแล้ว 4
• Kali365 ถูกพบครั้งแรกในเดือนเมษายน 2026 และเผยแพร่เป็นหลักผ่าน Telegram โดย FBI ออกคำเตือนถึงความสามารถในการได้มาซึ่ง OAuth access token และ refresh token ของ Microsoft 365 1

บทเรียนร่วมกันชัดเจน: องค์กรต้องป้องกัน ตรวจจับ และตอบสนองต่อการใช้เซสชันและโทเค็นในทางมิชอบ ด้วยระดับความจริงจังไม่ต่างจากกรณีรหัสผ่านถูกขโมย

สิ่งที่ควรตรวจจับใน Entra ID และ Microsoft 365

ควรเน้นการเชื่อมโยงหลักฐานหลายแหล่ง มากกว่าพึ่งพา alert เพียงรายการเดียว

1. ค้นหาการใช้เซสชันซ้ำที่น่าสงสัย

ตรวจสอบการลงชื่อเข้าใช้ที่บัญชีหรือเซสชันเดียวกันปรากฏจาก IP เครือข่าย ภูมิศาสตร์ เบราว์เซอร์ หรือคุณสมบัติอุปกรณ์ที่ต่างกันอย่างมีนัยสำคัญในช่วงเวลาสั้น ๆ โดยเฉพาะทันทีหลัง MFA สำเร็จ Microsoft ระบุการตรวจจับการใช้โทเค็นผิดปกติและคุณสมบัติการลงชื่อเข้าใช้ที่ไม่คุ้นเคยสำหรับ session cookie 38

2. ล่าหา device-code activity ที่ผิดปกติ

ทบทวนการยืนยันตัวตนผ่าน device code ที่สำเร็จ แล้วพิจารณาว่าไคลเอนต์ IP ต้นทาง ทรัพยากรที่ร้องขอ และพฤติกรรมของผู้ใช้สมเหตุสมผลหรือไม่ ใน Entra sign-in logs กิจกรรมแบบนี้อาจระบุได้จากฟิลด์ เช่น authenticationProtocol: deviceCode และ originalTransferMethod: deviceCodeFlow 26

3. เฝ้าระวังการเปลี่ยนแปลงที่สร้าง persistence

ให้ความสำคัญกับ Entra audit events ที่เกี่ยวข้องกับ:

• การลงทะเบียนหรือ join อุปกรณ์ใหม่ การเปลี่ยนเจ้าของอุปกรณ์ หรือ device identifier ที่ผิดปกติ
• วิธีรับรองตัวตนที่เพิ่งเพิ่ม เช่น Windows Hello for Business, FIDO2/passkey, MFA หรือวิธีกู้คืนบัญชี
• การอนุมัติแอป การเปลี่ยน enterprise application, service principal หรือการมอบบทบาทสิทธิ์สูง
• การเปลี่ยน Conditional Access, named location, federation, การส่งต่อเมล และกฎในกล่องจดหมาย

การลงทะเบียนอุปกรณ์ที่ไม่ได้รับอนุญาตไม่นานหลังการยืนยันตัวตนที่น่าสงสัย ควรถูกยกระดับเป็นสัญญาณ identity persistence ที่มีความสำคัญสูง 2628

4. เชื่อมโยงหลักฐานจากอีเมลกับข้อมูลตัวตน

อีเมลธีม DocuSign เพียงฉบับอาจเป็นสแปม และอุปกรณ์ Entra ใหม่เพียงเครื่องอาจเป็นเรื่องปกติ แต่หากพบร่วมกันระหว่างอีเมลน่าสงสัย หลักฐาน redirect chain เหตุการณ์ MFA สำเร็จ การใช้เซสชันซ้ำที่ผิดปกติ และการเปลี่ยนอุปกรณ์หรือวิธีรับรองตัวตน จะเป็นสัญญาณที่นำไปปฏิบัติได้มากกว่า

การตอบสนองเหตุการณ์: กักกันตัวตน ไม่ใช่แค่เปลี่ยนรหัสผ่าน

เมื่อสงสัยว่าเกิด AiTM หรือ device-code token theft ควรใช้ขั้นตอนกักกันในระดับ identity ดังนี้

1. บล็อกหรือปิดใช้งานตัวตนที่ได้รับผลกระทบตามความจำเป็น ปิดใช้งานบัญชีผู้ใช้และอุปกรณ์ที่เกี่ยวข้องระหว่างกำหนดขอบเขตเหตุการณ์ 40
2. เพิกถอนเซสชันและ refresh token ปัจจุบัน ใช้กระบวนการเพิกถอน sign-in session ของ Entra แล้วบังคับยืนยันตัวตนใหม่ Microsoft ระบุให้เพิกถอน refresh token ด้วย revokeSignInSessions สำหรับการตอบสนอง device-code phishing 27
3. รีเซ็ตรหัสผ่าน แต่ห้ามหยุดเพียงเท่านั้น การเปลี่ยนรหัสผ่านเป็นมาตรการเสริม ไม่ใช่หลักฐานว่าผู้โจมตีหมดสิทธิ์เข้าถึงแล้ว 4042
4. ลบ persistence ระบุและลบอุปกรณ์ Entra ที่ไม่ได้รับอนุญาต ตรวจสอบ ownership ของอุปกรณ์ ลบ Windows Hello for Business, FIDO2, MFA, วิธี recovery และข้อมูลรับรองแอปที่เพิ่งเพิ่ม รวมทั้งตรวจสอบ consent grant 628
5. ล่าหาทั้ง tenant ค้นหา URL เหยื่อล่อ โครงสร้าง redirect, IP ต้นทางที่น่าสงสัย, device-code event, ความผิดปกติของการลงชื่อเข้าใช้หลัง MFA และการลงทะเบียนอุปกรณ์ใหม่ในผู้ใช้ทุกคน
6. ประเมินผลกระทบต่อธุรกิจ ตรวจสอบกิจกรรมใน Exchange, SharePoint, OneDrive, Teams, Microsoft Graph, OAuth และ audit ฝั่งผู้ดูแลระบบ เพื่อหาการเข้าถึงข้อมูล กฎ mailbox การส่งต่อเมล การแชร์ภายนอก การใช้ consent ในทางมิชอบ การเพิ่มสิทธิ์ และการเข้าถึงแอปที่เชื่อมต่อผ่าน SSO
7. เก็บหลักฐานก่อนล้างระบบ เก็บอีเมลฟิชชิงและ header, mail trace, redirect chain, Entra sign-in/audit logs, ข้อมูลอุปกรณ์, OAuth-consent record และ telemetry จากเบราว์เซอร์หรือ endpoint

ลดความเสี่ยงก่อนถึงเหยื่อล่อครั้งถัดไป

การใช้วิธียืนยันตัวตนที่ทนต่อฟิชชิงมีความสำคัญ โดยเฉพาะผู้ใช้ความเสี่ยงสูง แต่ควรเป็นส่วนหนึ่งของการป้องกันหลายชั้น Microsoft แนะนำวิธีอย่าง FIDO2 security key, Windows Hello for Business และ certificate-based authentication ควบคู่กับการควบคุมเพื่อลดอายุการใช้งานของเซสชันบนอุปกรณ์ที่องค์กรไม่จัดการ 39

องค์กรควรประเมินด้วยว่า device-code flow จำเป็นต่อสภาพแวดล้อมหรือไม่ จำกัดการลงทะเบียนอุปกรณ์ที่ไม่ได้รับอนุญาต ใช้ Conditional Access ตามความสอดคล้องของอุปกรณ์และระดับความเสี่ยง และทำให้ทีมปฏิบัติการสามารถเพิกถอนเซสชันและตรวจสอบการเปลี่ยนแปลงวัตถุด้าน identity ได้อย่างรวดเร็ว

บทเรียนสำคัญจาก Knight Office ไม่ใช่ว่า MFA ล้มเหลว แต่คือ เหตุการณ์ MFA สำเร็จอาจเป็นจุดเริ่มต้นของการบุกรุก หากผู้โจมตีขโมยเซสชันที่ตามมา การตอบสนองจะถือว่าสมบูรณ์ก็ต่อเมื่อได้ตรวจสอบและกักกันทั้งเซสชัน อุปกรณ์ วิธีรับรองตัวตน และสิทธิ์ที่มอบหมายภายใน tenant แล้ว