แคมเปญ token spraying ยึดบัญชี Microsoft 365 ใน 79 องค์กร — ใช้โทเคนที่ขโมยหลังผ่าน MFA แล้วฝังอุปกรณ์ Entra ปลอมไว้อยู่ต่อ

สรุปสั้น

การขโมยโทเคนล็อกอินผ่านหน้าเว็บตัวกลาง หรือ adversary-in-the-middle (AitM) คือ วิธีหลบ MFA ที่ผู้โจมตีใช้มาระยะหนึ่งแล้ว รอบนี้บริษัท Huntress ผู้ให้บริการด้านความปลอดภัย เปิดเผยแคมเปญที่นำวิธีนี้ไปใช้แบบกวาดจำนวนมาก ระหว่างวันที่ 14 กรกฎาคมถึง 22 กันยายน 2569 ผู้โจมตีที่ยังไม่ทราบตัวตนนำโทเคนที่ขโมยมาไปลองล็อกอิน Microsoft 365 ข้ามหลายองค์กร จากช่วง IP ของผู้ให้บริการโฮสต์ 1337 Services ในเยอรมนี และยึดได้ 97 บัญชีใน 79 องค์กร Huntress เรียกวิธีนี้ว่า token spraying เพราะคล้าย password spraying ที่ลองรหัสผ่านทีละมาก ๆ ต่างกันตรงที่ของที่นำมาลอง คือ โทเคนที่ขโมยมาแล้ว

MFA ไม่ช่วยในกรณีนี้ เพราะโทเคนถูกออกหลังเหยื่อผ่าน MFA ไปแล้ว ใครถือโทเคนก็เข้าบัญชีได้โดยไม่ต้องรู้รหัสผ่านและไม่ต้องยืนยันซ้ำ เมื่อเข้าได้ ผู้โจมตีรีบฝังช่องทางอยู่ต่อก่อนโทเคนหมดอายุ ทั้งลงแอปยืนยันตัวตนของตัวเอง ลงทะเบียนอุปกรณ์ปลอมใน Microsoft Entra ID และตั้งกฎกล่องจดหมาย (inbox rule) ซ่อนอีเมลเรื่องเงินเดือนและธนาคาร เพื่อปูทางสู่การหลอกโอนเงินผ่านอีเมล (BEC) ของที่ฝังไว้เหล่านี้ไม่หายเมื่อรีเซ็ตรหัสผ่าน ตัวเลขทั้งหมดยังมาจากลูกค้าของ Huntress เท่านั้น จึงเป็นภาพขั้นต่ำของแคมเปญ องค์กรที่สงสัยว่าโดนต้องเพิกถอนเซสชัน ลบอุปกรณ์และวิธี MFA ที่ไม่รู้จัก และตั้ง Conditional Access ให้ครอบคลุมผู้ใช้และแอปทั้งหมด

รายละเอียดข่าว

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 26 ตุลาคม 2569 ว่าทีมนักวิจัยของบริษัท Huntress เปิดเผยแคมเปญนี้ในรายงานเมื่อวันที่ 22 ตุลาคม 2569 ซึ่งผู้โจมตีพยายามล็อกอินไม่สำเร็จกว่า 200,000 ครั้ง และสำเร็จอย่างน้อย 497 ครั้ง Huntress เห็นกิจกรรมครั้งแรกเมื่อวันที่ 14 กรกฎาคม 2569 จากการล็อกอินผ่าน IP 193.26.115[.]221 บนอุปกรณ์ใน Entra ID ที่ชื่อ DESKTOP- ตามด้วยเลขฐานสิบหก 8 ตัว ในช่วงเดียวกัน Microsoft Entra ID Protection ก็แจ้งเตือน IP 4 รายการใน tenant ของลูกค้าหลายรายว่าตรงกับ IP ที่ Microsoft ผูกไว้กับกลุ่มรัฐหรือกลุ่มอาชญากรไซเบอร์ โครงสร้างพื้นฐานชุดนี้จึงถูกจับตาจากสองฝั่ง ไทม์ไลน์ของแคมเปญแบ่งได้ 4 ช่วงตาม IP ที่ผู้โจมตีสลับใช้ภายใน 193.26.115[.]0/24

• ช่วงที่ 1 (14 ก.ค.–3 ส.ค.) — เข้าได้ 37 องค์กร และลงทะเบียนอุปกรณ์ปลอม 37 เครื่อง
• ช่วงที่ 2 (เริ่ม 17 ส.ค.) — กลับมาหลังเงียบไปสองสัปดาห์ เพิ่ม device-code phishing และการล้าง MFA เดิมของเหยื่อ
• ช่วงที่ 3 (11 ก.ย.) — กวาดอัตโนมัติ ภายในสองชั่วโมง Huntress ต้องส่งรายงานเหตุให้ลูกค้า 22 ราย
• ช่วงที่ 4 (2–22 ก.ย.) — ใช้หน้า AitM บนผู้ให้บริการอีกรายคู่กับการเล่นซ้ำจาก 193.26.115[.]210 และจบด้วยการยึดเซสชันครั้งสุดท้ายเมื่อวันที่ 22 กันยายน

ผลของการสลับ IP คือ การบล็อก IP เดี่ยวหยุดได้แค่ช่วงเดียว ด้านโครงสร้างพื้นฐาน IP แรก 193.26.115[.]221 ระบุตำแหน่งในโรมาเนีย และ VirusTotal บันทึกว่าเคยถูกใช้กับ AsyncRAT โทรจันควบคุมเครื่องระยะไกล IP นี้อยู่ในเครือข่ายของบริษัท 1337 Services GmbH (AS210558) ที่จดทะเบียนในฮัมบูร์ก เยอรมนี ซึ่ง GreyNoise พบ IP ของผู้ให้บริการรายนี้ 29 รายการ เป็นอันตราย 10 รายการ และน่าสงสัย 5 รายการ ผู้ให้บริการรายนี้ยังเชื่อมโยงกับ StarkRDP และ rdp[.]sh บริการให้เช่าเซิร์ฟเวอร์เสมือนที่โดเมนถูกยึดในปฏิบัติการ Talent ของหน่วยบังคับใช้กฎหมายนานาชาติเมื่อมกราคม 2568 พร้อมเว็บบอร์ด Nulled, Cracked และบริการ Sellix ปัจจุบันทั้งสองบริการกลับมาเปิดแล้ว โดย StarkRDP เปลี่ยนชื่อเป็น exy[.]sh ฝั่ง StarkRDP ปฏิเสธมาตั้งแต่ถูกยึดโดเมน โดยโพสต์บน Telegram เมื่อวันที่ 30 มกราคมที่นาย Brian Krebs นักข่าวด้านความปลอดภัยอิสระอ้างถึง ระบุว่าบริการดำเนินงานตามกฎหมายและไม่เกี่ยวกับข้อกล่าวหา ส่วน Huntress อ้างบทความของนาย Krebs เมื่อกุมภาพันธ์ 2568 ที่ชี้ว่าผู้ก่อตั้ง 1337 Services อาจเคยดูแลเว็บบอร์ด Cracked และอธิบายว่าผู้ให้บริการโฮสต์ที่ถูกกฎหมายแบบนี้มักถูกผู้โจมตีเช่าใช้เป็นแหล่ง IP

ข้อจำกัดของหลักฐานมี 3 ข้อ ข้อแรก ตัวเลขทั้งหมดมาจากเทเลเมทรีในลูกค้าของ Huntress เอง จำนวนเหยื่อจริงจึงอาจมากกว่านี้ ข้อสอง ความเชื่อมโยงกับ AsyncRAT, StarkRDP และ rdp[.]sh เป็นประวัติของ IP และผู้ให้บริการโฮสต์ ยังไม่มีหลักฐานว่าแคมเปญนี้วาง AsyncRAT หรือว่าผู้ให้บริการเหล่านั้นเป็นผู้ลงมือ และ Huntress เองก็ไม่ทราบแน่ชัดว่าทำไมผู้โจมตีสลับ IP ข้อสาม ตัวเลขของช่วงที่ 3 ในรายงานไม่ตรงกันเอง ส่วนหนึ่งระบุล็อกอินสำเร็จ 303 ครั้งใน 29 องค์กร อีกส่วนระบุ 232 ครั้งใน 28 องค์กร

วิธีการโจมตี

ขั้นที่ 1 ขโมยโทเคนผ่านหน้า AitM — เหยื่อล็อกอินผ่านหน้าเว็บตัวกลางโดยไม่รู้ตัว แล้วโทเคนถูกเก็บไป หน้าตัวกลางส่งต่อหน้าล็อกอินและคำขอ MFA ของจริงจาก Microsoft มาให้เหยื่อเห็น เหยื่อจึงกรอกรหัสผ่านและยืนยัน MFA ตามปกติ เมื่อ Microsoft ออกโทเคนยืนยันว่าล็อกอินสำเร็จ หน้าตัวกลางจะเก็บโทเคนนั้นไว้ วิธีนี้ได้ผลเพราะโทเคนถูกออกหลังผ่าน MFA แล้ว ผู้ถือโทเคนจึงไม่ต้องผ่าน MFA อีก

ทางขโมยโทเคนอีกสองทาง — นอกจาก AitM แล้ว Huntress ยังพบโทเคนในแคมเปญนี้มาจากอีกสองทาง ทางแรก คือ device-code phishing ที่หลอกให้เหยื่อกรอกรหัสอุปกรณ์บนหน้าล็อกอินจริงของ Microsoft ซึ่งเท่ากับอนุญาตเซสชันของผู้โจมตีเอง เป็นกลไกเดียวกับบริการฟิชชิง EvilTokens ใน 2026/09/159 ทางที่สอง คือ การหลอกระหว่างที่เหยื่อล็อกอินจริง

ขั้นที่ 2 แยกที่ดักโทเคนกับที่ใช้โทเคนไว้คนละแห่ง — ผู้โจมตีวางหน้า AitM บนผู้ให้บริการรายอื่น แต่เล่นซ้ำโทเคนจาก IP ของ 1337 Services ภายในไม่กี่นาที เคสวันที่ 21 กรกฎาคม เหยื่อถึงหน้ายืนยัน MFA บนหน้า AitM เวลา 17:18 UTC อีก 12 นาทีต่อมาเซสชันถูกเล่นซ้ำจาก 193.26.115[.]199 และเวลา 18:08 UTC มีแอปยืนยันตัวตนใหม่ชื่อ “iPhone 13” ถูกเปิดใช้ในบัญชี รวมแล้วไม่ถึง 51 นาที ส่วนเคสวันที่ 22 กันยายน ช่วงห่างระหว่างหน้ายืนยัน MFA กับการเล่นซ้ำเหลือแค่ 4 นาที การแยกสองชั้นแบบนี้ทำให้การบล็อก IP ของ 1337 Services หยุดการดักโทเคนไม่ได้ และการปิดหน้า AitM ก็หยุดการใช้โทเคนที่ขโมยไปแล้วไม่ได้

ขั้นที่ 3 เล่นซ้ำโทเคนด้วยเครื่องมือสองชุด — ชุดหนึ่งเป็นสคริปต์อัตโนมัติ อีกชุดเลียนแบบเบราว์เซอร์ปกติ ชุดแรกใช้ user agent node แลกโทเคน (OAuth2:Token) ผ่านไคลเอนต์ Microsoft Office และ Microsoft Authentication Broker เพื่อเข้า Microsoft Graph, Exchange Online, SharePoint Online และบริการลงทะเบียนอุปกรณ์ ชุดที่สองเล่นซ้ำเซสชันเบราว์เซอร์ด้วย user agent ของ Chrome หรือ Edge บน Windows เพื่อเข้า OfficeHome และ Exchange Online ซึ่งดูเหมือนการใช้งานปกติเมื่อมองแยกทีละรายการ

ขั้นที่ 4 ฝังช่องทางที่อยู่ได้นานกว่าโทเคน — โทเคนที่ขโมยมาหมดอายุหรือถูกเพิกถอนได้ ผู้โจมตีจึงรีบสร้างช่องทางที่ทนกว่า ใน 19 องค์กร วิธี MFA เดิมของเหยื่อถูกล้างแล้วลงวิธีใหม่ภายใน 3 ชั่วโมงหลังล็อกอินครั้งแรกจาก IP ของแคมเปญ แอปยืนยันตัวตนที่ผู้โจมตีลงไว้ทำให้ผ่าน MFA ของการล็อกอินครั้งใหม่ได้ตลอด และอยู่รอดแม้รีเซ็ตรหัสผ่าน ผู้โจมตียังลงทะเบียนคอมพิวเตอร์ปลอมใน Entra ID อย่างน้อย 48 เครื่อง ตั้งชื่อ DESKTOP- ตามด้วยเลขฐานสิบหกตัวพิมพ์ใหญ่ 8 ตัว ซึ่งต่างจากชื่อเริ่มต้นของ Windows ที่ใช้ 7 ตัว อุปกรณ์ที่ลงทะเบียนแล้วใช้ขอโทเคนใหม่ได้ทนกว่าเซสชันที่ขโมยมา และค้างอยู่ในไดเรกทอรีจนกว่าจะมีคนลบ

ขั้นที่ 5 ซ่อนอีเมลเพื่อปูทาง BEC — ผู้โจมตีตั้งกฎกล่องจดหมายที่ชื่อสั้นจนไม่สะดุดตา เพื่อซ่อนอีเมลที่เหยื่อไม่ควรเห็น ชื่อกฎมีเช่น . sss iT และ ........ กฎเหล่านี้ลบอีเมล หรือย้ายไปโฟลเดอร์ที่ไม่ค่อยมีคนเปิดอย่าง RSS Feeds และ Conversation History กฎชื่อ s ซ่อนอีเมลที่มีคำว่า payroll, direct deposit, bank หรือ bonus ส่วนกฎ d ซ่อนคำตอบจากนักบัญชีภายนอกรายหนึ่ง หลังผู้โจมตีใช้บัญชีของเหยื่อส่งอีเมลเรื่องเงินเดือนไปหานักบัญชีรายนั้น อีกกล่องหนึ่งถูกตั้งให้อ่านแล้วลบอีเมลเข้าทั้งหมด จากนั้นถูกใช้ส่งสแปมไปหาผู้รับภายนอกหลายร้อยราย จน Entra ID Protection จัดบัญชีเป็นความเสี่ยงสูง ทุกกฎถูกสร้างจาก VPN หรือโฮสต์เช่ารายอื่น เช่น ExpressVPN, NordVPN และ Interserver การตรวจเฉพาะ IP ของ 1337 Services จึงมองไม่เห็นขั้นนี้

ร่องรอยที่ใช้ตรวจจับ — สัญญาณหลัก คือ การล็อกอินด้วยโทเคนจากโฮสต์เช่าผ่านไคลเอนต์ของ Microsoft ที่ user agent ดูไม่เป็นธรรมชาติ ได้แก่ การล็อกอินแบบ OAuth2:Token หรือ Cmsi:Cmsi จาก IP ของผู้ให้บริการโฮสต์ ผ่านไคลเอนต์ Microsoft Office หรือ Authentication Broker ด้วย user agent node หรือ Mozilla/5.0 ที่ไม่มีรายละเอียดอื่น โดยเฉพาะที่เข้ากล่องจดหมายหรือบริการลงทะเบียนอุปกรณ์ รหัสข้อผิดพลาด AADSTS53003 จาก Conditional Access บล็อกแปลว่ารหัสหรือโทเคนนั้นใช้ได้จริง เพราะการบล็อกเกิดหลังยืนยันตัวตนสำเร็จ ส่วน AADSTS50133 (SsoArtifactRevoked) เกิดเมื่อผู้โจมตีพยายามใช้เซสชันที่ถูกเพิกถอนแล้ว

ผลกระทบ

กลุ่มที่โดนโดยตรง คือ องค์กรที่ใช้ Microsoft 365 แล้วพนักงานล็อกอินผ่านลิงก์ฟิชชิง หรือกรอกรหัสอุปกรณ์ให้ผู้โจมตี ในชุดข้อมูลของ Huntress มี 97 บัญชีใน 79 องค์กร

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

ข้อมูลช่วงที่ 3 ชี้ว่า Conditional Access ได้ผลจริง IP 193.26.115[.]72 ถูกบล็อก 1,052 ครั้ง แต่การบล็อกทั้งหมดมาจากเพียง 4 องค์กร ส่วนองค์กรที่ผู้โจมตีเข้าได้ไม่มีนโยบายใดขวาง และสองกลุ่มนี้ไม่ทับกันเลย Huntress จึงเตือนว่าการจัดลำดับเหตุตามจำนวนครั้งที่ถูกยิงจะพาทีมไปดูองค์กรที่ป้องกันได้อยู่แล้ว ควรจัดลำดับตามว่ารหัสหรือโทเคนนั้นใช้ได้จริงหรือไม่

คำแนะนำ

ทำทันที

• บังคับ Conditional Access ให้ครอบคลุมทั้งหมด — ตั้งนโยบายให้ต้องผ่าน MFA หรือบล็อก สำหรับผู้ใช้ทุกคน แอปคลาวด์ทุกตัว และไคลเอนต์ทุกประเภท โดยไม่มีเงื่อนไขยกเว้น ตามที่ Huntress แนะนำ
• จำกัด device-code flow — ใช้นโยบาย authentication flows ใน Conditional Access ปิด device-code flow ถ้าจำเป็นต้องใช้ ให้แยกเป็นบัญชีบริการที่มีสิทธิ์จำกัด

ตรวจว่าโดนแล้วหรือยัง

• ตรวจการล็อกอินจากโฮสต์เช่า — ค้นล็อก sign-in หา OAuth2:Token และ Cmsi:Cmsi จาก IP ผู้ให้บริการโฮสต์ ที่ใช้ user agent node หรือ Mozilla/5.0 เปล่า และถือว่า AADSTS53003 เป็นสัญญาณว่ารหัสหรือโทเคนรั่วจริง
• ตรวจอุปกรณ์ใน Entra ID — หาอุปกรณ์ชื่อ DESKTOP-, Device- หรือ Work Pc ตามด้วยเลขฐานสิบหก 8 ตัว โดยเฉพาะที่ลงทะเบียนจาก IP โฮสติ้ง และยืนยันก่อนลบ เพราะชื่อรูปแบบนี้พบนอกแคมเปญนี้ด้วย
• ตรวจวิธี MFA — หาบัญชีที่ MFA ถูกล้างแล้วลงใหม่ภายในไม่กี่นาที และแอปยืนยันตัวตนที่ผู้ใช้ไม่รู้จัก
• ตรวจ inbox rule — หากฎที่ชื่อยาว 1–3 ตัวอักษรหรือมีแต่เครื่องหมาย กฎที่ย้ายอีเมลไป RSS Feeds, RSS Subscriptions หรือ Conversation History และกฎที่จับคำเรื่องเงินเดือนหรือธนาคาร

ถ้าพบว่าโดนแล้ว

• เพิกถอนเซสชันก่อน แล้วค่อยรีเซ็ตรหัสผ่าน — การรีเซ็ตอย่างเดียวไม่ทำให้ access token ที่ออกไปแล้วใช้ไม่ได้ จากนั้นลบอุปกรณ์ วิธี MFA และ inbox rule ที่ผู้โจมตีลงไว้

ระยะยาว

• ปิดการอนุญาตแอปเองของผู้ใช้ — ตรวจแอปองค์กร (enterprise application) ใหม่ที่ได้สิทธิ์เข้า tenant และตั้งให้ผู้ใช้ทั่วไปต้องขออนุมัติแทนการอนุญาตแอปเอง

Indicators of Compromise (IoCs)

indicator ถูก defang แล้ว ([.]) เพื่อป้องกันการคลิกโดยไม่ตั้งใจ

แหล่งอ้างอิง

• Microsoft 365 Token-Replay Attacks Compromise 97 Accounts at 79 Organizations — The Hacker News
• M365 Token Spray and Replay Campaign Compromises Business Email Accounts — Huntress
• IPs of 1337 Services GmbH — GreyNoise