สรุปสั้น
ชุดเครื่องมือฟิชชิงที่ชื่อ EvilTokens กำลังเป็นที่จับตาในวงการสืบสวนภัยฟิชชิง เพราะใช้เทคนิคเจาะการยืนยันตัวตนแบบ Microsoft Device Code ควบคู่กับการซ่อนส่วนสำคัญของขั้นตอนการโจมตีไม่ให้การวิเคราะห์ URL แบบ static มองเห็นได้ จากการวิเคราะห์ล่าสุดพบว่าหน้าฟิชชิงถูกเข้ารหัสไว้ในการตอบกลับ HTML ครั้งแรก และจะปรากฏก็ต่อเมื่อมีการถอดรหัสฝั่งเบราว์เซอร์แล้วเรนเดอร์ลงใน DOM เท่านั้น แคมเปญฟิชชิงแบบ device-code ที่ขับเคลื่อนด้วย EvilTokens ถูกเชื่อมโยงกับการเจาะระบบในหลายองค์กรแล้ว ความอันตรายจึงไม่ได้อยู่ที่ตัวชุดฟิชชิงเพียงอย่างเดียว แต่อยู่ที่ “จุดบอดการมองเห็น” ที่มันสร้างขึ้นระหว่างการสืบสวน
ปัญหาคือเมื่อนักวิเคราะห์เปิดดู URL ต้องสงสัย พวกเขามักเห็นหลักฐานการกระทำที่เป็นอันตรายน้อยมาก เพราะ workflow ฟิชชิงตัวจริงยังถูกซ่อนอยู่ EvilTokens ส่ง payload ที่เข้ารหัสแบบ AES-GCM มาแทน แล้วถอดรหัสหลังจาก JavaScript ฝั่งเบราว์เซอร์ทำงานเท่านั้น เนื้อหาฟิชชิงจึงถูกเรนเดอร์ลงใน DOM โดยตรง เผยให้เห็นหน้ายืนยันตัวตนที่ปลอมเป็นแบรนด์ Microsoft พร้อมรหัสผู้ใช้ (user code) และคำแนะนำที่แสดงต่อเหยื่อ การวิเคราะห์ URL แบบ static อาจเห็น source ของหน้า คำขอเครือข่าย และข้อมูล reputation แต่จะพลาดเนื้อหาที่ปรากฏหลังการ execute เท่านั้น ส่งผลให้การคัดกรอง (triage) ช้าลง การยืนยันความเสี่ยง account takeover ล่าช้า ต้องใช้แรงมือประกอบ flow การโจมตีขึ้นใหม่ และอาจพลาด IOC ที่ใช้ในการล่าภัยคุกคาม
รายละเอียดข่าว
เว็บไซต์ Cyber Security News รายงานเมื่อวันที่ 24 มิถุนายน พ.ศ. 2569 ว่าชุดเครื่องมือฟิชชิง EvilTokens กำลังได้รับความสนใจจากการนำเทคนิคซ่อนเนื้อหาในเบราว์เซอร์มาใช้เพื่อหลบเลี่ยงการวิเคราะห์แบบ static โดยอาศัยการเจาะกระบวนการ Microsoft Device Code authentication ซึ่งเป็นกลไกการล็อกอินที่ออกแบบมาสำหรับอุปกรณ์ที่ป้อนข้อความยาก ๆ ได้ลำบาก เช่น สมาร์ตทีวีหรืออุปกรณ์ IoT ผู้ใช้จะได้รหัสสั้น ๆ มากรอกบนหน้าเว็บของ Microsoft เพื่ออนุมัติการเข้าถึง
จุดเด่นของ EvilTokens คือการที่หน้าฟิชชิงไม่ได้ถูกส่งมาในการตอบกลับของเซิร์ฟเวอร์โดยตรง แต่ถูกห่อด้วย payload ที่เข้ารหัส AES-GCM ทำให้เครื่องมือสแกน URL อัตโนมัติหรือ sandbox ที่ดูเฉพาะ HTML ต้นทางมองไม่เห็นว่าเป็นหน้าหลอกลวง หน้าจริงจะถูกถอดรหัสและสร้างขึ้นใน DOM ก็ต่อเมื่อ JavaScript ทำงานในเบราว์เซอร์ของเหยื่อแล้วเท่านั้น นักวิเคราะห์จึงต้องอาศัยการมองเห็นระดับเบราว์เซอร์ (browser-level visibility) เพื่อยืนยันพฤติกรรมฟิชชิงแบบไดนามิก ดึงหลักฐาน และเร่งจาก triage ไปสู่การตอบสนอง
จุดบอดนี้นำไปสู่ปัญหาหลายอย่างสำหรับทีม SOC ได้แก่ การคัดกรองฟิชชิงช้าลงเพราะหน้าจริงไม่ปรากฏตั้งแต่แรก การยืนยันความเสี่ยง account takeover ล่าช้า ต้องใช้แรงมือมากขึ้นในการประกอบ flow การโจมตี หลักฐานสำหรับส่งต่อให้ทีม Tier 2 หรือ IR ไม่ชัดเจน พลาด IOC ที่จะใช้ในการ hunting และ detection และทำให้ช่วงเวลาตั้งแต่แจ้งเตือนครั้งแรกจนถึงการลงมือตอบสนองยาวนานขึ้น
วิธีการโจมตี
EvilTokens ใช้ขั้นตอนหลักคือการแสดงหน้ายืนยันตัวตนปลอมที่เลียนแบบ Microsoft เพื่อหลอกให้เหยื่อกรอก device code ของตน เมื่อเหยื่อกรอกรหัสและอนุมัติ ผู้โจมตีก็จะได้ token สำหรับเข้าถึงบัญชีโดยไม่ต้องรู้รหัสผ่าน และในหลายกรณีสามารถข้าม multi-factor authentication ที่ผูกกับการล็อกอินแบบปกติได้ การวิเคราะห์ session ตัวอย่างในแซนด์บ็อกซ์แสดงให้เห็นว่ามีคำขอไปยังปลายทาง /api/device/start และ /api/device/status/<sessionId> ซึ่งช่วยยืนยันว่า workflow ฟิชชิงแบบ device-code ทำงานอย่างไร
ในมุมการตรวจจับ ไทม์ไลน์ของการเปลี่ยนแปลง DOM จะแสดงช่วงเวลาที่ payload เข้ารหัสถูกถอดออกและเนื้อหาฟิชชิงปรากฏบนหน้า เผยให้เห็น device code และ artifact อื่น ๆ ที่ไม่ปรากฏในการตอบกลับครั้งแรก นอกจากนี้การดูรายละเอียด URL ยังรวบรวม final URL ข้อมูลโดเมน ใบรับรอง SSL ระเบียน DNS สถิติคำขอ และ signature ที่ถูก trigger ไว้ในที่เดียว ในตัวอย่างนี้พบ signature ของการฟิชชิงแบบ Microsoft OAuth device-code ถูก trigger ขึ้น ซึ่งช่วยให้นักวิเคราะห์ประเมินโครงสร้างพื้นฐานเบื้องหลังหน้าฟิชชิงได้โดยไม่ต้องสลับไปมาระหว่างเครื่องมือหลายตัว
ผลกระทบต่อไทย
องค์กรในไทยจำนวนมากใช้ Microsoft 365 และ Entra ID (Azure AD) เป็นระบบยืนยันตัวตนหลัก ทำให้การโจมตีแบบ device-code phishing อย่าง EvilTokens เป็นภัยที่เกี่ยวข้องโดยตรง เพราะเทคนิคนี้สามารถหลบเลี่ยง MFA แบบดั้งเดิมและขโมย token เข้าถึงอีเมล ไฟล์ และระบบภายในองค์กรได้ทันทีที่เหยื่ออนุมัติรหัส ที่น่ากังวลคือหน้าฟิชชิงถูกซ่อนจากเครื่องมือสแกนอัตโนมัติและ secure email gateway จำนวนมากที่ตรวจเฉพาะ HTML ต้นทาง ทำให้ลิงก์อันตรายอาจผ่านการกรองเข้าถึงกล่องจดหมายของพนักงานได้ องค์กรไทยที่พึ่งพาการตรวจ URL แบบ static เพียงอย่างเดียวจึงมีความเสี่ยงสูงที่จะตรวจไม่พบการโจมตีลักษณะนี้จนกว่าบัญชีจะถูกยึดไปแล้ว
คำแนะนำ
ผู้ดูแลระบบและทีม SOC ควรเสริมการมองเห็นระดับเบราว์เซอร์ในการสืบสวนฟิชชิง เช่น ใช้ sandbox ที่เรนเดอร์หน้าและ execute JavaScript จริงเพื่อดูเนื้อหาที่ปรากฏใน DOM แทนการดูเฉพาะ source ต้นทาง สำหรับการป้องกัน device-code phishing โดยเฉพาะ ควรพิจารณาปิดหรือจำกัด device code flow ใน Microsoft Entra ID ผ่าน Conditional Access สำหรับผู้ใช้และสถานที่ที่ไม่จำเป็นต้องใช้ บังคับใช้ phishing-resistant MFA เช่น FIDO2 หรือ passkey ตรวจสอบ sign-in log หา device-code authentication ที่ผิดปกติ และให้ความรู้พนักงานว่าอย่ากรอก device code ที่ตนไม่ได้เป็นผู้เริ่มกระบวนการล็อกอินด้วยตนเอง รวมถึงเก็บ IOC ที่ได้จากการวิเคราะห์ในเบราว์เซอร์มาใช้ในการ hunting และ detection ต่อไป