แฮกเกอร์พลาด! เปิดเซิร์ฟเวอร์ทิ้งไว้ เผย 3 ปฏิบัติการฟิชชิ่ง Microsoft 365

Forg365: แพลตฟอร์ม Phishing-as-a-Service เชิงพาณิชย์

ในอีกทางหนึ่ง แพลตฟอร์ม Forg365 Phishing-as-a-service (PhaaS) ถูกระบุโดยนักวิจัย ZeroBEC (รายงานระหว่างวันที่ 9-13 กรกฎาคม 2026) ว่าเป็นชุดเครื่องมือเชิงพาณิชย์ที่จำหน่ายผ่าน Telegram ในราคา $400 ต่อเดือน (หรือ $3,800 ต่อปี) ซึ่งแตกต่างจาก Evilginx forks แบบกำหนดเองที่พบบนเซิร์ฟเวอร์ที่ถูกเปิดโปง Forg365 ได้รวมวิธีการและเครื่องมือโจมตีหลายแบบเข้าไว้ในแผงควบคุมเดียว

Forg365 ผสานความสามารถหลักสามประการ:

• AiTM proxying — พร็อกซีแบบโปร่งใสที่ดักจับโทเค็นเซสชันหลังจากผู้ใช้ยืนยันตัวตน MFA เสร็จ
• Device code phishing — ใช้ประโยชน์จาก OAuth device-code flow ที่ถูกต้องตามกฎหมายของ Microsoft หมายความว่าผู้ใช้ยืนยันตัวตนบนหน้าเว็บจริงของ Microsoft โดยที่ผู้โจมตีไม่เคยเห็นรหัสผ่าน
• AI-assisted lure generation — ใช้ AI เพื่อสร้างอีเมลฟิชชิ่งและหน้า Landing Page ที่ดูน่าเชื่อถือ โดยปลอมแปลงเป็น SharePoint, OneDrive, DocuSign และ Adobe Acrobat Sign

แพลตฟอร์มนี้ยังมีความสามารถในการหลบเลี่ยงระบบรักษาความปลอดภัย (Antibot evasion) การเข้าถึงกล่องจดหมายหลังการประนีประนอม (ผู้ปฏิบัติการสามารถเรียกดูและขโมยอีเมลจากภายในแผงควบคุม) การหมุนเวียน SMTP และการจัดตารางแคมเปญ

การโจมตีแบบหนึ่งขโมยโทเค็นหลัง MFA ส่วนอีกแบบอาศัยโปรโตคอลที่ถูกต้องตามกฎหมาย

การค้นพบทั้งสองนี้ชี้ให้เห็นถึงความแตกต่างที่สำคัญระหว่างการโจมตีแบบ AiTM proxy และ Device Code Abuse การทำความเข้าใจความแตกต่างนี้เป็นสิ่งสำคัญ เพราะ มาตรการป้องกันแบบเดียวกันใช้ไม่ได้ผลกับทั้งสองแบบ:

• การโจมตีแบบ AiTM proxy (สไตล์ Evilginx): ผู้โจมตีสร้างหน้าเข้าสู่ระบบปลอมที่ทำหน้าที่เป็นพร็อกซีส่งต่อไปยังหน้าเข้าสู่ระบบจริงของ Microsoft ผู้ใช้ป้อนรหัสผ่านและยืนยันตัวตน MFA บนพร็อกซีของผู้โจมตี หลังจากการยืนยันตัวตนสำเร็จ Microsoft จะออกคุกกี้เซสชันให้กับเบราว์เซอร์ที่เชื่อว่าเป็นผู้ใช้ที่ถูกต้อง — แต่คุกกี้นั้นตกไปอยู่ในพร็อกซีของผู้โจมตี ไม่ใช่เบราว์เซอร์ของผู้ใช้ ผู้โจมตีสามารถนำคุกกี้นั้นไปใช้เพื่อเข้าถึงบัญชี Microsoft 365 ของเหยื่อ

• Device code phishing: ผู้โจมตีสร้าง Device Code ที่ถูกต้องของ Microsoft (รหัสสั้นๆ ที่ใช้ในการเข้าสู่ระบบบนอุปกรณ์ที่ไม่มีคีย์บอร์ด เช่น สมาร์ททีวี) และส่งไปยังเหยื่อในอีเมลฟิชชิ่ง เหยื่อเข้าไปที่หน้าเข้าสู่ระบบจริงของ Microsoft ป้อนรหัส ยืนยันตัวตน MFA และอนุญาตให้แอปพลิเคชันของผู้โจมตีเข้าถึง ไม่มีอะไรถูก "หลบเลี่ยง" — เหยื่อเป็นผู้อนุญาตการเข้าถึงด้วยตนเอง จากนั้นแบ็กเอนด์ของผู้โจมตีจะสอบถาม Microsoft เพื่อขอโทเค็น

มาตรการป้องกันที่แนะนำ: การควบคุมใดหยุดการโจมตีแบบใด

มาตรการป้องกันการโจมตีแบบ Adversary-in-the-Middle Proxy (สไตล์ Evilginx)

มาตรการป้องกันที่มีประสิทธิภาพสูงสุดต่อการโจมตีแบบ AiTM proxy คือ Phishing-resistant MFA โดยเฉพาะ FIDO2/WebAuthn และ Passkeys กลไกเหล่านี้ผูกมัดข้อมูลประจำตัวเข้ากับชื่อโดเมนที่ถูกต้อง ดังนั้นเมื่อเบราว์เซอร์ของผู้ใช้เชื่อมต่อกับไซต์พร็อกซีของผู้โจมตี (ซึ่งมีโดเมนต่างกัน) โปรโตคอลการยืนยันตัวตนจะตรวจพบความไม่ตรงกันของโดเมนและปฏิเสธการแลกเปลี่ยนข้อมูลประจำตัวโดยอัตโนมัติ

มาตรการป้องกันอื่นๆ ได้แก่:

• นโยบาย Conditional Access (Entra ID): กำหนดให้อุปกรณ์ต้องเป็นไปตามข้อกำหนดและต้องมาจากตำแหน่งที่เชื่อถือได้ เพื่อป้องกันการออกโทเค็นจากพร็อกซีที่ไม่น่าเชื่อถือ
• Continuous Access Evaluation (CAE): ช่วยให้เพิกถอนโทเค็นได้เกือบเรียลไทม์เมื่อตรวจพบสภาวะที่มีความเสี่ยง
• ตรวจสอบการใช้งานโทเค็นที่ผิดปกติ: มองหาโทเค็นที่ใช้จาก IP หรือประเทศที่แตกต่างจากที่ออก, การเดินทางที่เป็นไปไม่ได้ และ "คุณสมบัติการเข้าสู่ระบบที่ไม่คุ้นเคย"
• บล็อกโดเมนฟิชชิ่งที่จดทะเบียนใหม่: ตรวจสอบโดเมนที่จดทะเบียนภายใน 30 วันที่ผ่านมาซึ่งแก้ไขไปยังช่วง IP ที่รู้จักของโครงสร้างพื้นฐานฟิชชิ่ง

มาตรการป้องกันการละเมิด Device Code Authentication

Device Code Phishing ไม่จำเป็นต้องให้ผู้โจมตีหลอกให้ผู้ใช้ป้อนข้อมูลรับรองบนหน้าเว็บปลอม — ผู้ใช้โต้ตอบกับหน้าเข้าสู่ระบบจริงของ Microsoft ซึ่งหมายความว่า FIDO2/passkeys เพียงอย่างเดียวไม่สามารถป้องกันการโจมตีนี้ได้อย่างสมบูรณ์ เนื่องจากเป็นการใช้ OAuth flow ที่ถูกต้องตามกฎหมาย

มาตรการป้องกันหลักคือการ บล็อก Device-code OAuth grant สำหรับผู้ใช้ที่ไม่จำเป็นต้องใช้ โดยใช้ Microsoft Entra ID Conditional Access:

• สร้างนโยบายโดยใช้เงื่อนไข "Authentication Flows" เพื่อบล็อก Device Code Flow สำหรับผู้ใช้ทั้งหมด ยกเว้นกลุ่มข้อยกเว้นที่บันทึกไว้
• ก่อนที่จะบล็อก ให้รันในโหมดรายงานเพียงอย่างเดียว หรือตรวจสอบบันทึกการเข้าสู่ระบบในประวัติเพื่อระบุการใช้งาน Device Code ที่ถูกต้องตามกฎหมาย (เช่น สมาร์ททีวี อุปกรณ์ในห้องประชุม)
• วางแผนข้อยกเว้นสำหรับ Device Registration Service (DRS) เพราะการบล็อก Device Code Flow อาจรบกวน Autopilot และการลงทะเบียนอุปกรณ์ Windows

มาตรการป้องกันเพิ่มเติม:

• จำกัด App Consent และขอบเขต OAuth Grant: จำกัดว่าแอปใดบ้างที่สามารถใช้ Device-code grants และตรวจสอบแอปพลิเคชันที่ได้รับความยินยอมอย่างสม่ำเสมอ
• ปรับใช้ Phishing-resistant MFA แม้แต่กับ Device-code Flows: แม้จะไม่ใช่ทางออกที่สมบูรณ์ แต่ FIDO2 hardware keys หรือ Certificate-based authentication ก็ยังช่วยลดพื้นที่การโจมตีได้

บทสรุป

คำแนะนำต่อสาธารณะของ FBI ในเดือนพฤษภาคม 2026 เกี่ยวกับแพลตฟอร์ม Kali365 PhaaS แนะนำให้บล็อก Device Code Flow เป็นมาตรการป้องกันหลักโดยเฉพาะ ในขณะที่แพลตฟอร์มฟิชชิ่งอย่าง Forg365 ยังคงทำให้เทคนิคการโจมตีเหล่านี้กลายเป็นเชิงพาณิชย์มากขึ้น ความเร่งด่วนในการปฏิบัติการสำหรับฝ่ายป้องกันนั้นชัดเจน: ปรับใช้ FIDO2/passkeys สำหรับบัญชีที่มีสิทธิ์ทั้งหมดเพื่อหยุดการโจมตีแบบ AiTM proxy และใช้ Conditional Access เพื่อปิดการใช้งาน Device-code grant สำหรับผู้ใช้ที่ไม่ต้องการ ไดเรกทอรีที่เปิดเผยเพียงแห่งเดียวอาจเปิดโปงสามแคมเปญ — แต่บทเรียนนี้ใช้ได้กับทุก Microsoft 365 tenant