ในโลกของ Threat Intelligence เหตุการณ์ที่เปิดเผยข้อมูลการโจมตีได้ละเอียดที่สุดมักไม่ใช่การสืบสวนเชิงรุก แต่มาจากความผิดพลาดของผู้โจมตีเอง กรณีนี้ก็เช่นกัน เมื่อนักวิจัยจาก Lexfo ค้นพบ Attack Server ที่ตั้งค่า Security ผิดพลาด เปิดเผยข้อมูลภายในของปฏิบัติการ Phishing ถึง 3 กลุ่ม ที่กำลังมุ่งโจมตีบัญชี Microsoft 365 ขององค์กรทั่วโลกอย่างเป็นระบบ
สิ่งที่เปิดเผยออกมาไม่ได้แค่ยืนยันว่ามีการโจมตีเกิดขึ้น แต่ให้รายละเอียดลึกถึงโครงสร้างปฏิบัติการ เครื่องมือที่ใช้ จำนวนเหยื่อ และวิธีที่ผู้โจมตีรักษา Access ไว้ในระยะยาวแม้เหยื่อจะเปลี่ยนรหัสผ่านแล้วก็ตาม
Evilginx คืออะไร
Evilginx เป็น Open-source Framework สำหรับโจมตีแบบ Adversary-in-the-Middle (AiTM) ที่พัฒนาขึ้นในปี 2017 สำหรับใช้ใน Penetration Testing แต่ถูกนำไปใช้ในการโจมตีจริงอย่างกว้างขวาง ต่างจากการ Phishing แบบดั้งเดิมที่สร้างหน้า Login ปลอม Evilginx ทำงานโดยวางตัวเองเป็น Proxy ระหว่างเบราว์เซอร์ของเหยื่อกับเซิร์ฟเวอร์จริงของ Microsoft ทำให้เหยื่อ Login ผ่านหน้าจริงของ Microsoft แต่ Evilginx ดักจับ Session Cookie ได้ในระหว่างนั้น
ผลคือไม่ว่าเหยื่อจะเปิด MFA ในรูปแบบใด ไม่ว่าจะเป็น SMS OTP, Authenticator App หรือ Hardware Key ผู้โจมตีก็ยังได้ Cookie Session ที่มีอายุการใช้งานและข้าม MFA ไปได้แล้ว เพราะ Cookie แสดงถึง Session ที่ Authenticate สำเร็จแล้ว
การค้นพบ — Server ที่ตั้งค่าผิดพลาด
Lexfo ค้นพบ Open Directory บน Attack Server ในช่วงปลายเดือนเมษายน 2026 ระหว่างการทำ Routine Internet Scan Server นั้นเปิดเผย Log, Token, Configuration และข้อมูลปฏิบัติการของผู้โจมตีโดยไม่มีการป้องกัน ซึ่งทำให้นักวิจัยสามารถสร้างภาพของการโจมตี 3 กลุ่มได้อย่างละเอียด
3 กลุ่มผู้โจมตีและวิธีการของแต่ละกลุ่ม
กลุ่มที่ 1 — "codemado" กับ AiTM Platform และ MaDoO Blaster
กลุ่มแรกถูกติดตามในชื่อ codemado ซึ่งเป็น Actor ชาวอียิปต์ที่ Active ในฟอรัม VoIP และ Hacking Forum มาตั้งแต่ปี 2018 กลุ่มนี้รัน Microsoft 365 AiTM Platform ที่พัฒนาขึ้นเองและสร้างรายได้ด้วยการขาย Access ที่ขโมยมาผ่านบริการ Bulk Mailer ชื่อ MaDoO Blaster แคมเปญเริ่มเมื่อวันที่ 20 เมษายน 2026 และยังคงดำเนินต่อเนื่องแม้จะถูกค้นพบ โดยมีการสร้าง Subdomain ใหม่และ Wildcard Certificate ใหม่อยู่เสมอ
กลุ่มที่ 2 — "saroula01" กับ Device Code Flow Abuse
กลุ่มที่สองสร้างความน่าสนใจเป็นพิเศษ เพราะ saroula01 พัฒนาระบบโจมตีที่ใช้ Microsoft OAuth Device Code Flow แทนการ Proxy Session ธรรมดา ซึ่งมีข้อได้เปรียบสำคัญคือผู้โจมตีได้ทั้ง Access Token และ Refresh Token ที่สามารถต่ออายุ Session ได้แบบอัตโนมัติเป็นเวลานาน
แทนที่จะใช้ Evilginx แบบ Proxy กลุ่มนี้สร้าง Lure Page ที่หน้าตาเหมือน Microsoft Authenticator จากนั้นแสดง Device Code และบอกให้เหยื่อนำไปกรอกที่ microsoft.com/devicelogin จริง เมื่อเหยื่อทำตาม Microsoft จะออก Token ให้อุปกรณ์ที่ผู้โจมตีลงทะเบียนไว้โดยอัตโนมัติ
กลุ่มที่ 3 — The Quarry PhaaS Ecosystem
กลุ่มที่สามเชื่อมโยงกับ Phishing-as-a-Service Platform ที่ SOCRadar ตั้งชื่อว่า The Quarry ซึ่ง SOCRadar เผยแพร่รายงานในเดือนมิถุนายน 2026 ระบุว่า Platform นี้พัฒนาโดย Developer ที่ใช้ชื่อว่า RockyBelling และถูกขายให้กับ Operator ใกล้ถึง 200 ราย ทำให้เทคนิคการโจมตีเดียวกันกระจายไปในวงกว้างอย่างมาก
รายละเอียดทางเทคนิค — ทำไม Token ถึงอันตรายกว่า Cookie
ความแตกต่างสำคัญระหว่างการขโมย Session Cookie กับการขโมย OAuth Token อยู่ที่อายุการใช้งาน Session Cookie มักมีอายุจำกัดและจะหมดอายุเมื่อผู้ใช้ Sign Out แต่ Access Token และ Refresh Token จาก Device Code Flow มีคุณสมบัติที่แตกต่างกัน
Access Token มีอายุสั้น (ปกติ 1 ชั่วโมง) แต่ Refresh Token สามารถใช้ต่ออายุ Access Token ได้แบบอัตโนมัติตราบใดที่ยังมีการใช้งาน จากข้อมูลที่ค้นพบในไฟล์บน Server ผู้โจมตีมี Token บางตัวที่ถูก Refresh ถึง 25 ครั้ง ซึ่งแสดงให้เห็นว่า Access ยังคงใช้งานได้มาเป็นเวลานานมาก แม้เหยื่อจะไม่รู้ตัวว่ากำลังถูก Access อยู่
จาก Token File ที่ถูก Commit ผิดพลาดบน Repository นักวิจัยพบ Live Microsoft Token 97 รายการ ของเหยื่อ 3 ราย ซึ่งทั้งหมดตั้งค่า autoRefresh ไว้
ขนาดความเสียหาย
จากการวิเคราะห์ Log ของ Telegram Bot ที่ผู้โจมตีใช้รับแจ้งเตือนเมื่อโจมตีสำเร็จ นักวิจัยพบว่ามีบัญชีที่ถูก Capture ทั้งสิ้น 218 บัญชี จากกว่าหนึ่งโหลประเทศ ระหว่างเดือนมิถุนายน 2025 ถึงกรกฎาคม 2026 และในจำนวนนั้น 94% เป็น Corporate Mailbox ซึ่งมีความน่าสนใจสูงกว่าบัญชีส่วนตัวในแง่ของข้อมูลทางธุรกิจและ Access ต่อระบบอื่น
ตัวเลข 218 บัญชีมาจากเพียงหนึ่งแคมเปญที่ค้นพบ ยังไม่รวมกลุ่มอื่นอีก 2 กลุ่มที่พบในปฏิบัติการเดียวกัน
ผลกระทบที่อาจเกิดขึ้น
- บัญชีที่ถูก Compromise ยังคง Active แม้เหยื่อเปลี่ยนรหัสผ่านแล้ว เพราะ Token ยังใช้งานได้จนกว่าจะถูก Revoke
- ผู้โจมตีเข้าถึง Mailbox, Teams, SharePoint และ OneDrive ของเหยื่อทั้งหมด เปิดโอกาสสำหรับ Business Email Compromise (BEC) และการขโมยข้อมูล
- แคมเปญยังดำเนินต่อแม้ถูกค้นพบ เพราะผู้โจมตีสร้าง Infrastructure ใหม่ได้รวดเร็ว
- PhaaS Model ทำให้เทคนิคกระจายในวงกว้าง Operator เกือบ 200 รายที่ใช้ Platform เดียวกันหมายถึงองค์กรทุกขนาดล้วนตกเป็นเป้าหมาย
สิ่งที่องค์กรควรตรวจสอบทันที
- ตรวจสอบ Azure AD / Microsoft Entra Sign-in Log หา Login ที่ใช้ Device Code Authentication จาก IP หรือประเทศที่ผิดปกติ
- ตรวจสอบ OAuth Token ที่ Active ใน Microsoft 365 Admin Center โดยเฉพาะ Token ที่ออกให้อุปกรณ์ที่ไม่รู้จัก
- ตรวจสอบว่ามี Mailbox Rule ที่ตั้งค่า Forward อีเมลไปยังที่อยู่ภายนอกโดยไม่ได้รับอนุญาต
- ตรวจสอบ Audit Log หาการเข้าถึง SharePoint หรือ OneDrive ที่ผิดปกติในช่วงเวลากลางคืนหรือจาก Location ที่ไม่คุ้นเคย
- ทำการ Revoke ทุก Active Token สำหรับบัญชีที่สงสัยว่าถูก Compromise
แนวทางลดความเสี่ยง
1. บล็อก Device Code Flow ผ่าน Conditional Access Policy
สำหรับองค์กรที่ไม่มีอุปกรณ์ที่ต้องใช้ Device Code Flow จริง (ซึ่งส่วนใหญ่ไม่มี) การบล็อก Flow นี้เป็นวิธีที่ตรงที่สุดในการป้องกัน saroula01-style attacks
2. เปิดใช้ Continuous Access Evaluation (CAE)
CAE ช่วยให้ Microsoft สามารถ Revoke Token ได้ทันทีเมื่อตรวจพบความผิดปกติ เช่น การ Sign-in จาก Location ใหม่ แทนที่จะต้องรอให้ Token หมดอายุตามกำหนด
3. ใช้ Phishing-Resistant MFA
FIDO2 Security Key หรือ Passkey เป็น MFA ที่ไม่สามารถดักจับผ่าน AiTM ได้ เพราะ Credential ผูกกับ Origin Domain ซึ่งผู้โจมตีไม่สามารถปลอมแปลงได้
4. ตั้ง Alert สำหรับ Impossible Travel และ Token Anomaly
กำหนด Rule ใน Microsoft Sentinel หรือ Entra ID Protection เพื่อ Alert เมื่อมีการใช้ Token จาก Location ที่เดินทางไปไม่ได้ในเวลาสั้น หรือเมื่อมี Refresh Token ถูกใช้งานบ่อยผิดปกติ
5. ให้ความรู้ผู้ใช้เกี่ยวกับ Device Code Phishing
แจ้งให้ผู้ใช้ทราบว่าไม่ควรกรอก Code ใด ๆ บน microsoft.com/devicelogin เว้นแต่เป็นกระบวนการที่ตัวเองเริ่มต้นเอง เช่น การ Login บน Smart TV หรืออุปกรณ์ที่ไม่มีเบราว์เซอร์
วิเคราะห์ในมุมมองจาก TXEC
เหตุการณ์นี้ตอกย้ำ 2 ประเด็นที่ TXEC ติดตามมาตลอด ประการแรกคือ MFA แบบดั้งเดิมไม่เพียงพออีกต่อไปในการป้องกันการโจมตีระดับนี้ ทั้ง Evilginx AiTM และ Device Code Phishing ผ่าน MFA ทุกรูปแบบได้ยกเว้น FIDO2/Passkey ซึ่งหมายความว่าองค์กรที่คิดว่า "เปิด MFA แล้วปลอดภัย" จำเป็นต้องทบทวนความเข้าใจนี้
ประการที่สองคือ PhaaS Ecosystem กำลังทำให้เทคนิคระดับสูงกลายเป็นสินค้าที่หาซื้อได้ เมื่อ Operator เกือบ 200 รายใช้ Platform เดียวกัน หมายความว่าองค์กรทุกขนาดตกเป็นเป้าหมายได้ ไม่ใช่เฉพาะองค์กรขนาดใหญ่ที่น่าสนใจสำหรับกลุ่ม APT
สำหรับองค์กรไทยที่ใช้ Microsoft 365 การตรวจสอบ Conditional Access Policy และการ Monitor Sign-in Log อย่างสม่ำเสมอถือเป็นสิ่งที่ต้องทำโดยไม่รอช้า
รู้ก่อน ตรวจพบเร็ว ลดความเสียหายได้มากกว่า
[ แหล่งอ้างอิง: The Hacker News, Lexfo, GBHackers, CyberSecurityNews, CyberPress ]