การโจมตีด้วยโค้ดอุปกรณ์ใน Azure: จากการเจาะระบบไปจนถึงการตรวจจับ

TL; DR

มันคืออะไร: การหลอกลวงด้วยรหัสอุปกรณ์ (Device code phishing) เป็นเทคนิคการโจมตี OAuth ที่ผู้โจมตีเริ่มต้นกระบวนการตรวจสอบสิทธิ์ด้วยรหัสอุปกรณ์ที่ถูกต้องตามกฎหมายเพื่อโจมตี Microsoft Entra IDจากนั้นหลอกให้ผู้ใช้ป้อนรหัสที่ได้มาในหน้าล็อกอินจริง login.microsoft.com/devicelogin ซึ่งจะทำให้ผู้โจมตีได้รับโทเค็นการเข้าถึงที่ถูกต้องโดยไม่ต้องเก็บรหัสผ่านเลย 

ทำไมมันเรื่อง: จากเดิมที่เป็นเทคนิคการโจมตีระดับรัฐ (STORM-2372 ที่เชื่อมโยงกับรัสเซีย ซึ่งเริ่มใช้งานตั้งแต่เดือนสิงหาคม 2024) มันได้พัฒนาไปเป็นชุดเครื่องมือโจมตีทั่วไปภายในเวลาไม่ถึงหนึ่งปี ชุดเครื่องมือ EvilTokens PhaaS ที่ Microsoft เปิดตัวในเดือนเมษายน 2026 จะทำการโจมตีโดยอัตโนมัติทุกขั้นตอนตั้งแต่ต้นจนจบ ทำให้โค้ดไม่หมดอายุภายใน 15 นาที และสามารถเรียกใช้แคมเปญส่วนบุคคลได้ 10-15 แคมเปญทุกๆ 24 ชั่วโมง 

เหตุใดจึงตรวจจับได้ยาก: ไม่มีหน้าล็อกอินปลอม ไม่มีโดเมนที่ถูกขโมยจากการสะกดผิด ไม่มีการดักจับข้อมูลประจำตัว และไม่มีมัลแวร์ให้สแกน URL เดียวที่เกี่ยวข้องคือ login.microsoft.com/devicelogin การตรวจสอบสิทธิ์แบบหลายปัจจัย (MFA) สำเร็จบนอุปกรณ์จริงของเหยื่อ ดังนั้นสัญญาณทุกอย่างที่เกตเวย์อีเมล EDR หรือผลิตภัณฑ์ปกป้องข้อมูลประจำตัวได้รับการฝึกฝนให้ตรวจสอบจึงแสดงผลว่าไม่มีความผิดปกติ 

ความแตกต่างจาก AiTM: การโจมตีแบบ Adversary-in-the-Middle (AiTM) ใช้พร็อกซีสร้างหน้าล็อกอินปลอมเพื่อขโมยคุกกี้เซสชัน ในขณะที่การฟิชชิ่งด้วยโค้ดอุปกรณ์จะข้ามพร็อกซีไปโดยสิ้นเชิง เหยื่อจะยืนยันตัวตนบนหน้าเว็บของ Microsoft จริงๆ ดังนั้นจึงไม่มีโครงสร้างพื้นฐานของ AiTM ให้ตรวจจับ บล็อก หรือปิดได้ 

สัญญาณตรวจจับแกนกลาง: การเข้าสู่ระบบสำเร็จโดยใช้วิธีการยืนยันตัวตนด้วยรหัสอุปกรณ์ ทรัพยากรที่เข้าถึงเป็นไคลเอ็นต์ของ Microsoft (เช่น Azure CLI, Microsoft Office) และการเข้าสู่ระบบนั้นดำเนินการจากตำแหน่งที่ผิดปกติหรือโดยหน่วยงานที่โดยปกติไม่ได้ยืนยันตัวตนโดยใช้รหัสอุปกรณ์ แทบไม่มีขั้นตอนการทำงานของผู้ใช้ปลายทางที่ถูกต้องตามกฎหมายใดที่สร้างรูปแบบนี้ขึ้นมา สำหรับหลายองค์กร ทุกครั้งที่พบรูปแบบนี้จะต้องได้รับการตรวจสอบ 

หากตรวจพบให้ดำเนินการตอบสนองทันที: เพิกถอนสิทธิ์การเข้าถึงของผู้ใช้ทันที (โปรดดูที่ เอกสารของ Microsoft) ปิดใช้งานผู้ใช้ที่ถูกบุกรุก และลบการมอบหมายบทบาทของพวกเขา โปรดทราบว่าการยกเลิกโทเค็นรีเฟรชไม่ได้ทำให้โทเค็นการเข้าถึงที่ออกไปแล้วเป็นโมฆะ โทเค็นเหล่านั้นยังคงใช้งานได้จนกว่าจะหมดอายุ ค้นหากิจกรรมที่เป็นอันตรายที่มาจากเซสชันที่น่าสงสัย การยกเลิกโทเค็นเพียงอย่างเดียวไม่เพียงพอ ผู้โจมตีอาจสร้างความคงอยู่ถาวรได้แล้ว

มาตรการสำคัญด้านนโยบาย: บล็อกการเข้าถึงด้วยรหัสอุปกรณ์ผ่าน Conditional Access สำหรับกลุ่มผู้ใช้ที่ไม่มีความจำเป็นทางธุรกิจที่ระบุไว้ชัดเจน คำแนะนำของ Microsoft เองก็แนะนำให้ทำเช่นนี้ ผู้ใช้ระดับองค์กรส่วนใหญ่ รวมถึงนักพัฒนาส่วนใหญ่ แทบจะไม่เคยยืนยันตัวตนด้วยวิธีนี้อย่างถูกต้องตามกฎหมาย ในกรณีที่จำเป็นต้องใช้การยืนยันตัวตนด้วยรหัสอุปกรณ์จริงๆ ให้จำกัดการใช้งานเฉพาะในสถานที่ที่เชื่อถือได้ผ่านการกำหนดขอบเขตทางภูมิศาสตร์ (Geo-fencing) 

สิ่งที่ทีมรักษาความปลอดภัยจำเป็นต้องรู้เกี่ยวกับการหลอกลวงรหัสอุปกรณ์

กลุ่มผู้คุกคามระดับรัฐ (STORM-2372 ซึ่งเชื่อมโยงกับผลประโยชน์ของรัฐบาลรัสเซีย) ได้ดำเนินการโจมตีแบบฟิชชิ่งโดยการขโมยรหัสอุปกรณ์มาตั้งแต่เดือนสิงหาคม 2024 โดยมุ่งเป้าไปที่หน่วยงานรัฐบาล ผู้รับเหมาด้านการป้องกันประเทศ องค์กรพัฒนาเอกชน บริษัทโทรคมนาคม บริษัทพลังงาน และองค์กรด้านการดูแลสุขภาพทั่วโลก 

นี่ไม่ใช่ช่องโหว่ที่ Microsoft สามารถแก้ไขได้ เพราะเป็นคุณสมบัติการออกแบบของโปรโตคอลรหัสอุปกรณ์ OAuth 2.0 ซึ่งได้รับการสนับสนุนจากผู้ให้บริการยืนยันตัวตนรายใหญ่ทุกราย การโจมตีนี้สามารถหลีกเลี่ยงการป้องกันได้ MFA ได้ทุกที่ (เหยื่อกรอกข้อมูลโดยสมัครใจ) ไม่ทิ้งโครงสร้างพื้นฐานที่น่าสงสัยให้เครื่องมือรักษาความปลอดภัยตรวจจับได้ (URL เดียวคือ microsoft.com) และโทเค็นที่ได้จะยังคงอยู่แม้หลังจากการรีเซ็ตรหัสผ่าน เกตเวย์อีเมลทั่วไป CASB และเครื่องสแกน URL ต่างให้คะแนนลิงก์โจมตีนี้ว่าปลอดภัยเพราะ... is ปลอดภัย เพราะมันจะนำคุณไปยังหน้าล็อกอินของ Microsoft เอง 

หลังจากการเจาะระบบ ผู้โจมตีสามารถลงทะเบียนอุปกรณ์ที่ใช้งานได้อย่างต่อเนื่องภายใน 10 นาที สร้างแผนผังโครงสร้างองค์กรผ่าน Microsoft Graph คัดกรองเป้าหมายที่มีมูลค่าสูง (เช่น ฝ่ายการเงิน ผู้บริหาร และฝ่ายธุรการ) สร้างกฎกล่องจดหมายที่ซ่อนอยู่ และขโมยรายละเอียดการโอนเงินและจดหมายโต้ตอบของผู้บริหาร ซึ่งเป็นวัตถุดิบสำหรับการโจมตีทางอีเมลธุรกิจและการฉ้อโกงทางการเงิน 

มาตรการแก้ไขปัญหาเฉพาะหน้าขององค์กร: บล็อกการตรวจสอบรหัสอุปกรณ์ผ่านการเข้าถึงแบบมีเงื่อนไขสำหรับผู้ใช้ทุกคนที่ไม่ต้องการใช้งานอย่างชัดเจน และตรวจสอบให้แน่ใจว่า... การตอบสนองต่อเหตุการณ์ คู่มือนี้ครอบคลุมถึงการเพิกถอนโทเค็น OAuth (ไม่เฉพาะการรีเซ็ตรหัสผ่าน) และการผูกโทเค็นสำหรับบัญชีที่มีมูลค่าสูง ดูคำแนะนำเชิงกลยุทธ์ด้านล่างสำหรับกรอบการตัดสินใจฉบับเต็ม

แล้วถ้า URL ที่ใช้ในการหลอกลวงคือ microsoft.com ล่ะ?

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

ปัจจุบันช่องโหว่นี้ถูกนำไปใช้ในวงกว้าง และถึงแม้ว่าข้อบกพร่องพื้นฐานจะอยู่ที่มาตรฐาน OAuth เองก็ตาม Entra IDการนำไปใช้งานของมันทำให้การนำไปใช้เป็นอาวุธเป็นเรื่องง่าย ไมโครซอฟต์ระบุว่า... แคมเปญต่อเนื่องเพื่อ STORM-2372กลุ่มผู้คุกคามดังกล่าวได้รับการประเมินด้วยความมั่นใจระดับปานกลางว่าสอดคล้องกับผลประโยชน์ของรัฐบาลรัสเซีย ปฏิบัติการนี้ได้มุ่งเป้าไปที่หน่วยงานรัฐบาล ผู้รับเหมาด้านการป้องกันประเทศ องค์กรพัฒนาเอกชน ผู้ให้บริการโทรคมนาคม บริษัทพลังงาน และองค์กรด้านการดูแลสุขภาพในหลายทวีปมาตั้งแต่เดือนสิงหาคม 2024 เป็นอย่างน้อย ในเดือนเมษายน 2026 ไมโครซอฟต์ได้บันทึกการยกระดับที่สำคัญ: การเกิดขึ้นของ EvilTokens ชุดเครื่องมือฟิชชิ่งแบบบริการ (PhaaS) ที่ใช้ AI ซึ่งทำการโจมตีรหัสอุปกรณ์โดยอัตโนมัติแบบครบวงจร—การสร้างรหัสแบบเรียลไทม์ตามความต้องการเพื่อหลีกเลี่ยงข้อจำกัดเวลาหมดอายุ 15 นาที การสร้างเหยื่อล่อเฉพาะบุคคลโดยใช้ AI แบบสร้างสรรค์ และการดำเนินแคมเปญที่แตกต่างกัน 10 ถึง 15 แคมเปญทุกๆ 24 ชั่วโมง เทคนิคนี้ได้พัฒนาจากเทคนิคเฉพาะของรัฐชาติไปสู่ชุดเครื่องมือโจมตีทั่วไปภายในเวลาไม่ถึงหนึ่งปี  

ในบทความนี้ เราจะอธิบายอย่างละเอียดว่าการโจมตีนี้ทำงานอย่างไรในระดับโปรโตคอล พร้อมทั้งสาธิตการจำลองสถานการณ์จริง Entra ID การจับภาพบันทึกจะให้คำสั่งค้นหา KQL ที่คุณสามารถเรียกใช้ในสภาพแวดล้อมของคุณได้ในวันนี้ และขยายตรรกะการตรวจจับที่ได้มาจากบันทึกที่สร้างขึ้นโดยการโจมตี 

ขั้นตอนการทำงานของโค้ดอุปกรณ์เป็นอย่างไร?

OAuth 2.0 Device Authorization Grant ซึ่งกำหนดไว้ใน RFC 8628 และเผยแพร่ในเดือนสิงหาคม 2019 เป็นกระบวนการตรวจสอบสิทธิ์ที่ออกแบบมาสำหรับอุปกรณ์ที่ไม่มีเบราว์เซอร์หรือมีข้อจำกัดด้านการป้อนข้อมูล เช่น สมาร์ททีวี เครื่องเล่นเกม เซ็นเซอร์ IoT ป้ายดิจิทัล อุปกรณ์ห้องประชุม และเครื่องมือ CLI เช่น Azure CLI หรือ AWS CloudShell แทนที่จะลงชื่อเข้าใช้โดยตรงบนอุปกรณ์ ผู้ใช้จะเห็นรหัสตัวอักษรและตัวเลขสั้นๆ และ URL จากนั้นผู้ใช้จะเปิด URL นั้นบนอุปกรณ์อื่น (โดยทั่วไปคือโทรศัพท์หรือแล็ปท็อป) ป้อนรหัส และทำการตรวจสอบสิทธิ์ให้เสร็จสมบูรณ์ที่นั่น รวมถึงการแจ้งเตือน MFA ด้วย ในขณะเดียวกัน อุปกรณ์หลักจะตรวจสอบเซิร์ฟเวอร์การอนุญาตในเบื้องหลังและรับโทเค็นการเข้าถึงเมื่อผู้ใช้อนุมัติ 

กระบวนการนี้ได้รับการสนับสนุนอย่างกว้างขวาง: ไมโครซอฟต์ Entra IDGoogle, GitHub, Okta และผู้ให้บริการยืนยันตัวตนรายใหญ่ส่วนใหญ่ใช้กลไกนี้ และเป็นวิธีการเข้าสู่ระบบเริ่มต้นสำหรับ Azure CLI (`az login`) แม้ว่ามันจะไม่ใช่กระบวนการ OAuth ที่พบได้บ่อยที่สุดในแอปพลิเคชันเว็บทั่วไป แต่ก็เป็นกลไกมาตรฐานสำหรับสภาพแวดล้อมแบบ headless และแบบที่มีข้อจำกัดด้านอินพุต และมีการใช้งานอย่างแพร่หลายในเครื่องมือระดับองค์กร ไปป์ไลน์ DevOps และแพลตฟอร์มสตรีมมิ่งสำหรับผู้บริโภค 

ความเสี่ยงด้านการออกแบบเป็นสิ่งที่เกิดขึ้นโดยธรรมชาติตามมาตรฐานนี้ แต่ Entra IDการนำไปใช้ของ 's นั้นยิ่งทำให้ภัยคุกคามเหล่านี้รุนแรงขึ้น ซึ่งเป็นเหตุผลว่าทำไมชุดเครื่องมือฟิชชิ่งที่แพร่ระบาดอยู่ในปัจจุบันจึงมุ่งเป้าไปที่ Microsoft ปัจจุบัน Microsoft เองก็แนะนำให้บล็อกการไหลของข้อมูลผ่าน Conditional Access ในทุกที่ที่ไม่จำเป็นต้องใช้งานอย่างชัดเจน 

ข้อบกพร่องด้านการออกแบบที่สำคัญ: รหัสอุปกรณ์ (device_code) เป็นเพียงตัวเชื่อมระหว่างอุปกรณ์ที่ส่งคำขอตรวจสอบสิทธิ์กับผู้ใช้ที่กำลังตรวจสอบสิทธิ์ ไมโครซอฟต์ไม่ได้ตรวจสอบว่าอุปกรณ์ที่ส่งคำขอตรวจสอบสิทธิ์นั้นเป็นอุปกรณ์ที่ผู้ใช้ตั้งใจจะอนุญาตหรือไม่ มันไม่ได้ตรวจสอบข้อมูลประจำตัวของอุปกรณ์ ตำแหน่งเครือข่าย หรือความน่าเชื่อถือใดๆ ใครก็ตามที่มีรหัสและส่งคำขอตรวจสอบสิทธิ์ก็จะได้รับโทเค็นนั้น 

การวิเคราะห์การโจมตี

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

ผู้โจมตีใช้กระแสข้อมูลนี้เป็นอาวุธได้อย่างไร

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

ผู้โจมตีส่งคำขอ POST เพียงครั้งเดียวโดยไม่ยืนยันตัวตน โดยใช้รหัสไคลเอ็นต์ของ Microsoft ที่เป็นที่รู้จักกันดี (เช่น Azure CLI, Microsoft Office หรือไคลเอ็นต์สาธารณะอื่นๆ ของ Microsoft เอง ซึ่งรหัสเหล่านี้เป็นสาธารณะ สามารถระบุได้ง่าย และเป็นไปไม่ได้ที่ Microsoft จะเพิกถอนโดยไม่ทำให้เครื่องมือที่ถูกต้องตามกฎหมายซึ่งขึ้นอยู่กับรหัสเหล่านี้เสียหาย) และจะได้รับรหัสอุปกรณ์ที่ถูกต้องในทันที รหัสไคลเอ็นต์ของ Microsoft เหล่านี้เป็นของขวัญสำหรับผู้โจมตี: ได้รับความไว้วางใจโดยค่าเริ่มต้น ได้รับการยินยอมล่วงหน้าในขอบเขตที่กว้าง และพร้อมใช้งานอย่างถาวร รหัสผู้เช่าสามารถหาได้ง่ายเมื่อผู้โจมตีระบุโดเมนเป้าหมายได้แล้ว 

curl -X POST https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/devicecode \ 
  -d "client_id=04b07795-8ddb-461a-bbee-02f9e1bf7b46&scope=https://management.azure.com/.default" 

ผู้โจมตีจะห่อหุ้ม URL สำหรับการยืนยันและรหัสผู้ใช้ไว้ในสิ่งล่อใจที่น่าเชื่อถือ เช่น คำเชิญเข้าร่วมการประชุม Teams การแจ้งเตือนการแชร์เอกสาร หรือการแจ้งเตือนด้านความปลอดภัยทางไอที ​​แล้วส่งผ่านทางอีเมล Teams WhatsApp Signal หรือวิธีการอื่น ๆ โดยเฉพาะอย่างยิ่ง ช่องโหว่ STORM-2372 ถูกพบว่าปลอมแปลงการแจ้งเตือนการประชุม Teams และคำเชิญเข้าร่วมกลุ่ม WhatsApp ขณะที่เหยื่อกำลังอ่านอีเมล สคริปต์ของผู้โจมตีก็กำลังตรวจสอบข้อมูลอยู่แล้ว เมื่อเหยื่อทำการยืนยันตัวตนเสร็จสิ้น ระบบก็จะได้รับคู่โทเค็นทั้งหมด 

เหตุใดมาตรการรักษาความปลอดภัยที่มีอยู่จึงล้มเหลว

สิ่งที่ทำให้การหลอกลวงด้วยรหัสอุปกรณ์มีความอันตรายเป็นพิเศษคือจำนวนระบบป้องกันแบบดั้งเดิมที่มันถูกทำให้ไร้ประสิทธิภาพไปพร้อมกัน: 

ในมุมมองของแพลตฟอร์มการยืนยันตัวตนของ Microsoft การเข้าสู่ระบบครั้งนี้ถือว่าถูกต้องตามกฎหมายทุกประการ 

• MFA ถูกควบคุม ไม่ใช่ถูกข้ามผ่าน เหยื่อทำการยืนยันตัวตนด้วย MFA ตามปกติ โทเค็นที่ได้จะมีค่า mfaAuthenticated=true
• ไม่มีโครงสร้างพื้นฐานของผู้โจมตีให้ตรวจจับได้ URL เดียวในห่วงโซ่การโจมตีคือ microsoft.com ซึ่งมีชื่อเสียงที่ดีเยี่ยมในทุกแหล่งข้อมูลข่าวกรองภัยคุกคามและมีใบรับรอง EV ที่ถูกต้อง เกตเวย์อีเมล CASB แซนด์บ็อกซ์ URL และการเขียนลิงก์ปลอดภัยของพร็อกซีทั้งหมดตรวจสอบแล้วและส่งคืนผลลัพธ์ว่า ปลอดภัย
• โทเค็นรีเฟรชยังคงใช้งานได้แม้หลังจากการรีเซ็ตรหัสผ่าน ต่างจากคุกกี้เซสชัน (ซึ่งการโจมตี AiTM ขโมยไป) โทเค็นรีเฟรชของ OAuth ถูกออกแบบมาสำหรับการเข้าถึงระยะยาวและข้ามอุปกรณ์ สามารถแลกเปลี่ยนเป็นโทเค็นการเข้าถึงใหม่ได้โดยอัตโนมัติโดยไม่ต้องมีการโต้ตอบจากผู้ใช้หรือการแจ้งเตือน MFA ซ้ำ การรีเซ็ตรหัสผ่านของเหยื่อไม่ได้เป็นการยกเลิกโทเค็น ผู้โจมตียังคงเข้าถึงได้เว้นแต่จะมีการยกเลิกโทเค็นอย่างชัดเจน
• ร่องรอยการตรวจสอบทางนิติวิทยาศาสตร์มีน้อยมาก บันทึกการเข้าสู่ระบบแสดงว่าเข้าสู่ระบบสำเร็จ โดยมีระดับความเสี่ยง = ไม่มี และ MFA = สำเร็จ ไม่มีการเข้าสู่ระบบล้มเหลวหลายครั้ง ไม่มีการเปลี่ยนแปลงข้อมูลประจำตัว ไม่มีการสร้างวัตถุที่น่าสงสัย สัญญาณเดียวที่เป็นไปได้คือการรีเฟรชโทเค็นแบบไม่โต้ตอบจาก IP ที่ไม่คาดคิด—และเฉพาะในกรณีที่คุณตรวจสอบอย่างเฉพาะเจาะจงเท่านั้น 

สำคัญ: นี่ไม่ใช่การโจมตีแบบ Adversary-in-the-Middle (AiTM) เครื่องมือ AiTM เช่น EvilProxy จะดักจับเซสชันผ่าน Reverse Proxy และเก็บคุกกี้หลังจากยืนยันตัวตนแบบหลายปัจจัย (MFA) ซึ่งต้องใช้โครงสร้างพื้นฐานที่ผู้โจมตีควบคุมได้ เช่น โดเมน ใบรับรอง และเซิร์ฟเวอร์ที่ใช้งานอยู่ ซึ่งทั้งหมดนี้จะทิ้งร่องรอยให้ผู้ตรวจสอบได้ การฟิชชิ่งรหัสอุปกรณ์นั้นต้องการเพียงแค่ HTTP POST ครั้งเดียวและอีเมลที่ดูน่าเชื่อถือ โทเค็นที่ได้จะมีอายุยืนยาวกว่าและครอบคลุมขอบเขตที่กว้างกว่าคุกกี้เซสชัน และไม่มีโครงสร้างพื้นฐานของผู้โจมตีให้ตรวจสอบหรือทำลาย

มุมมองของผู้โจมตี: ขั้นตอนการทำงานทีละขั้น

เพื่อแสดงให้เห็นถึงห่วงโซ่การโจมตีทั้งหมด เราได้จำลองสถานการณ์ในสภาพแวดล้อมห้องปฏิบัติการที่มีการควบคุม โดยใช้บัญชีผู้ใช้สำหรับการวิจัยโดยเฉพาะ (glich.net) การจำลองนี้จำลองสถานการณ์ที่ผู้โจมตีปฏิบัติการในฐานะ helpdesk@glich.net กำหนดเป้าหมายไปยังผู้ใช้ roni@glich.net ด้วยการล่อลวงแบบฟิชชิ่งรหัสอุปกรณ์ที่ปลอมแปลงเป็น... คำขอตรวจสอบข้อมูลประจำตัว. 

ขั้นตอนที่ 1: การสร้างรหัสอุปกรณ์

ผู้โจมตีส่งคำขอ POST ไปยัง Entra IDปลายทางอนุญาตอุปกรณ์ของ Azure CLI โดยใช้ Client ID สาธารณะ จะได้รับรหัสอุปกรณ์และรหัสผู้ใช้ และเริ่มตรวจสอบปลายทางโทเค็นทันที 

ขั้นตอนที่ 2: การสร้างและส่งเหยื่อล่อฟิชชิ่ง

ผู้โจมตีจะใส่รหัสอุปกรณ์และ URL login.microsoft.com/devicelogin ลงในอีเมลที่ฟังดูเร่งด่วน โดยปลอมแปลงเป็นคำเชิญเข้าร่วมการประชุม Teams คำขอตรวจสอบข้อมูลประจำตัว หรือการแจ้งเตือนด้านความปลอดภัยทางไอที 

ขั้นตอนที่ 3: การอนุมัติจากผู้ใช้

ผู้ใช้ได้รับอีเมลและอนุญาตให้ผู้โจมตีเข้าถึงระบบได้ 

เมื่อเหยื่อป้อนรหัสและข้อมูลประจำตัวในเบราว์เซอร์ ระบบจะดึงโทเค็นเหล่านั้นมา 

ขั้นตอนที่ 4: หลังการใช้ประโยชน์

ด้วยโทเค็นการเข้าถึงที่ถูกต้องและโทเค็นรีเฟรชที่มีอายุการใช้งานยาวนาน ผู้โจมตีได้ยืนยันสิทธิ์การเข้าถึงสภาพแวดล้อม Microsoft 365 ของเหยื่อแล้ว และเวลากำลังนับถอยหลัง ของ Microsoft การวิเคราะห์เดือนเมษายน 2026 จากการโจมตีแบบฟิชชิ่งโดยใช้รหัสอุปกรณ์ที่เปิดใช้งาน AI (ซึ่งเป็นการพัฒนาต่อยอดโดยตรงจากกิจกรรม STORM-2372 ที่รายงานครั้งแรกในเดือนกุมภาพันธ์ 2025) ได้บันทึกขั้นตอนการดำเนินการหลังการเจาะระบบที่ผู้โจมตีใช้ในโลกแห่งความเป็นจริง โดยลำดับขั้นตอนเป็นไปตามรูปแบบที่สอดคล้องกัน: 

การลงทะเบียนอุปกรณ์เพื่อคงสถานะการใช้งาน 

ในบางกรณี ภายใน 10 นาทีหลังจากการโจมตีครั้งแรก ผู้โจมตีจะลงทะเบียนอุปกรณ์ใหม่ภายใต้บัญชีที่ถูกบุกรุกเพื่อสร้างโทเค็นรีเฟรชหลัก (Primary Refresh Token หรือ PRT) PRT ให้สิทธิ์การเข้าถึงระยะยาวที่รองรับ SSO ซึ่งยังคงใช้งานได้แม้ว่าโทเค็นแต่ละรายการจะถูกยกเลิกไปแล้วก็ตาม ทำให้ผู้โจมตีมีฐานที่มั่นถาวรซึ่งตรวจจับและแก้ไขได้ยากกว่าโทเค็นรีเฟรชที่ถูกขโมยเพียงอย่างเดียว 

ไมโครซอฟต์ กราฟ รีโคเนชั่นส์ 

ผู้โจมตีใช้โทเค็นที่ถูกขโมยไปสอบถาม Microsoft Graph API เพื่อสร้างแผนที่โครงสร้างองค์กรภายใน บทบาทผู้ใช้ และการกำหนดสิทธิ์โดยอัตโนมัติ การสอดแนมอัตโนมัตินี้ทำให้พวกเขาสามารถระบุได้อย่างรวดเร็วว่าบัญชีที่ถูกบุกรุกใดบ้างที่สามารถเข้าถึงทรัพยากรที่สำคัญได้ และอยู่ที่ใด การเพิ่มระดับสิทธิ์ เป็นไปได้ 

การกรองเป้าหมายที่มีมูลค่าสูง 

แทนที่จะใช้ประโยชน์จากบัญชีที่ถูกเจาะทุกบัญชีอย่างไม่เลือกปฏิบัติ กลุ่มแฮกเกอร์กลับคัดกรองกลุ่มเหยื่อโดยเลือกเฉพาะบุคคลที่มีมูลค่าสูง เช่น บุคคลที่อยู่ในตำแหน่งทางการเงิน ผู้บริหาร หรือฝ่ายธุรการ วิธีการคัดเลือกนี้ทำให้การโจมตีหลังการเจาะระบบมุ่งเน้นไปที่บัญชีที่มีศักยภาพในการให้ผลตอบแทนสูงสุด 

กฎกล่องจดหมายที่เป็นอันตรายสำหรับการคงอยู่ 

สำหรับเป้าหมายที่เลือกไว้ ผู้โจมตีได้สร้างกฎในกล่องจดหมายโดยใช้แอปพลิเคชัน Microsoft Office เพื่อเปลี่ยนเส้นทาง ซ่อน หรือลบอีเมลขาเข้า กฎเหล่านี้มีจุดประสงค์สองประการ คือ การรักษาการเข้าถึงการสื่อสารทางอีเมลอย่างต่อเนื่องโดยไม่ต้องเข้าสู่ระบบซ้ำ และการปกปิดหลักฐานการถูกโจมตีจากเหยื่อ (เช่น การลบการแจ้งเตือนด้านความปลอดภัยหรือการแจ้งเตือนการรีเซ็ตรหัสผ่านโดยอัตโนมัติ) 

การขโมยอีเมลเป้าหมาย 

กิจกรรมที่รุกล้ำมากที่สุดนั้นสงวนไว้สำหรับผู้ใช้ที่มีอำนาจทางการเงิน ผู้โจมตีทำการค้นหาข้อมูลเชิงลึกในอีเมล โดยเฉพาะอย่างยิ่งรายละเอียดการโอนเงิน ใบแจ้งหนี้ที่รอการอนุมัติ และจดหมายโต้ตอบของผู้บริหาร ซึ่งเป็นวัตถุดิบสำหรับการโจมตีทางอีเมลธุรกิจ (BEC) และการฉ้อโกงทางการเงิน 

การหน่วงเวลาการดำเนินการเพื่อหลีกเลี่ยงการตรวจจับ 

ไม่ใช่ว่าผู้โจมตีทุกคนจะลงมือทันที ในหลายกรณีที่พบเห็น ผู้โจมตีรอหลายชั่วโมงหลังจากที่ระบบถูกบุกรุกครั้งแรกก่อนที่จะดำเนินการใดๆ หลังการโจมตี ซึ่งเป็นเทคนิคการหลีกเลี่ยงโดยเจตนาที่ออกแบบมาเพื่อแยกเหตุการณ์การตรวจสอบสิทธิ์ที่น่าสงสัยออกจากกิจกรรมที่เป็นอันตรายในบันทึก ทำให้ฝ่ายป้องกันติดตามความสัมพันธ์เชิงเวลาได้ยากขึ้น เมื่อกิจกรรมที่เป็นอันตรายเริ่มต้นขึ้น เหตุการณ์การตรวจสอบสิทธิ์ที่ทำให้เกิดกิจกรรมนั้นได้หมดอายุจากคิวการคัดกรองระยะสั้นและหน้าต่างการแจ้งเตือนแบบเรียลไทม์แล้ว ฝ่ายป้องกันที่ตรวจสอบการเข้าสู่ระบบที่น่าสงสัยที่ T+0 อาจไม่พบกิจกรรมใดๆ ตามมาและปิดเคสนั้นว่าเป็นเรื่องปกติ—แต่ผู้โจมตีอาจเริ่มขโมยข้อมูลในอีกหลายชั่วโมงต่อมา เมื่อการแจ้งเตือนเดิมไม่ปรากฏบนหน้าจอของใครอีกแล้ว ช่องว่างที่จงใจสร้างขึ้นระหว่างการเข้าถึงและการดำเนินการนี้เองที่ทำให้การฟิชชิ่งรหัสอุปกรณ์มีความทนทานต่อการตรวจจับตามเวลาเป็นพิเศษ: การละเมิดและผลกระทบจะไม่ปรากฏในหน้าต่างการตรวจสอบเดียวกัน เว้นแต่ว่าฝ่ายป้องกันจะติดตามความสัมพันธ์ข้ามช่วงเวลาที่ยาวนานอย่างชัดเจน 

มุมมองของฝ่ายป้องกัน: เราควรตรวจสอบอะไรบ้างในบันทึกเหตุการณ์

สำหรับนักล่าภัยคุกคามและนักวิเคราะห์ SOC—ของจริง Entra ID ไฟล์บันทึกข้อมูลแสดงให้เห็นอย่างชัดเจนว่าควรตรวจสอบอะไรบ้าง 

เราจับภาพได้ Entra ID รายการบันทึกการเข้าสู่ระบบที่สร้างขึ้นโดยกระบวนการนี้ คำขอตรวจสอบของแฮ็กเกอร์—การตอบสนอง authorization_pending ซ้ำๆ—จะไม่ถูกบันทึกเลย มีเพียงการออกโทเค็นสำเร็จเท่านั้นที่จะสร้างรายการบันทึก โดยแบ่งออกเป็นสองแท็บ: 

รายการที่ 1: แบบโต้ตอบ (ฝั่งเบราว์เซอร์/ผู้เสียหาย)

เหยื่อเข้าเยี่ยมชม microsoft.com/devicelogin และอนุมัติรหัส การตรวจสอบสิทธิ์แบบหลายปัจจัย (MFA) สำเร็จลุล่วงด้วยการยืนยันตัวตนในเซสชันก่อนหน้า เหยื่อไม่พบปัญหาใดๆ นอกจากการคลิก "อนุมัติ" 

รายการที่ 2: แบบไม่โต้ตอบ (การตรวจสอบสถานะฝั่งไคลเอ็นต์/ผู้โจมตี)

การเปรียบเทียบแบบเคียงข้างกัน

หลักการตรวจจับนั้นชัดเจน: ข้อมูลทั้งสองรายการมี Correlation ID เหมือนกัน แต่ User Agent และอาจรวมถึงที่อยู่ IP นั้นแตกต่างกัน ส่วนของเบราว์เซอร์แสดงว่าใช้ Chrome บน Mac ส่วนของการสำรวจแสดงว่าใช้ curl ในการโจมตีจริง ข้อมูลบันทึกคู่นี้ที่มีความแตกต่างกัน โดยเฉพาะอย่างยิ่งการแบ่งแยกตามภูมิศาสตร์ที่บ่งชี้ถึงการเดินทางที่อาจเป็นไปไม่ได้หรือแหล่งที่มาที่น่าสงสัย คือสัญญาณหลักในการสร้างระบบแจ้งเตือน 

การตรวจสอบ IP ฝั่งการสำรวจอย่างละเอียดโดยใช้ข้อมูลจากแหล่งข่าวกรองภัยคุกคาม รายชื่อชื่อเสียงของ IP ค่า User Agent ที่น่าสงสัย (เช่น ตัวอย่าง "curl" ในบันทึก) และเมตาเดต้าของ ASN จะช่วยเสริมความแข็งแกร่งในการตรวจจับมากยิ่งขึ้น โครงสร้างพื้นฐานของผู้โจมตีมักมาจากผู้ให้บริการโฮสติ้ง VPN เชิงพาณิชย์ หรือ ASN ที่ไม่มีอยู่จริงในกลุ่มผู้ใช้ของคุณ IP ฝั่งการสำรวจที่แปลงเป็น ASN ที่ทราบว่าไม่ดี หรือปรากฏอยู่ในบัญชีดำ เป็นตัวบ่งชี้ที่มีความน่าเชื่อถือสูง แม้ว่าจะไม่มีความไม่ตรงกันของ IP ระหว่างขาของการสำรวจก็ตาม

ตรวจจับการหลอกลวงด้วยรหัสอุปกรณ์ในสภาพแวดล้อมของคุณ

สำหรับนักล่าภัยคุกคาม: คัดลอกและวางคำสั่ง KQL สำหรับ Azure Monitor, Microsoft Sentinel หรือ SIEM ใดๆ ที่เข้ากันได้กับ KQL 

คำสั่ง KQL ต่อไปนี้สามารถใช้ค้นหาการหลอกลวงด้วยรหัสอุปกรณ์ในระบบของคุณได้ Entra ID บันทึกการเข้าสู่ระบบเหล่านี้ได้รับการออกแบบมาให้สามารถคัดลอกและวางได้ทันทีสำหรับ Azure Monitor, Microsoft Sentinel หรือ SIEM ใดๆ ที่เข้ากันได้กับ KQL 

เป้าหมายคือการตรวจจับการใช้โค้ดอุปกรณ์ในทางที่ผิดให้เร็วที่สุดเท่าที่จะเป็นไปได้ โดยแต่ละคำสั่งค้นหาด้านล่างนี้จะมุ่งเป้าไปที่สัญญาณที่แตกต่างกัน ได้แก่ รูปแบบการใช้โค้ดอุปกรณ์ที่ผิดปกติ ความไม่ตรงกันของ IP หรือ User-Agent ระหว่างส่วนโต้ตอบและส่วนการสำรวจ และการสร้างโค้ดปริมาณมากที่อาจบ่งชี้ถึงแคมเปญที่กำลังดำเนินการอยู่ 

1. แสดงเหตุการณ์การไหลของโค้ดอุปกรณ์ทั้งหมดบนพื้นผิวเพื่อทำการวิเคราะห์ความสัมพันธ์

แบบสอบถามนี้จะดึงข้อมูลทั้งสองส่วน (แบบโต้ตอบและไม่โต้ตอบ) ของการไหลของโค้ดในแต่ละอุปกรณ์ จัดเรียงหรือรวมข้อมูลตาม CorrelationId เพื่อเปรียบเทียบข้อมูลแบบเคียงข้างกัน และมองหาความไม่ตรงกันของ IP หรือ User-Agent ซึ่งเป็นสัญญาณการตรวจจับหลัก 

SigninLogs 
| where AuthenticationProtocol == "deviceCode" 
    or OriginalTransferMethod == "deviceCodeFlow" 
| project CorrelationId, UserPrincipalName, IPAddress, UserAgent, 
          IsInteractive, TimeGenerated, AppDisplayName, 
          AuthenticationProtocol 
| order by CorrelationId, TimeGenerated asc

2. ตรวจจับการไหลของรหัสอุปกรณ์ที่มีความไม่ตรงกันของที่อยู่ IP ระหว่างขา

แบบสอบถามนี้เชื่อมโยงรายการแบบโต้ตอบและไม่โต้ตอบของแต่ละโฟลว์รหัสอุปกรณ์โดยใช้ CorrelationId และทำเครื่องหมายโฟลว์ที่มีที่อยู่ IP แตกต่างกัน ซึ่งเป็นตัวบ่งชี้ที่ชัดเจนว่าไคลเอนต์ที่ทำการสำรวจไม่ใช่เครื่องหรือสถานที่เดียวกับเบราว์เซอร์ที่ใช้ในการตรวจสอบสิทธิ์ สำหรับการแจ้งเตือนที่มีความแม่นยำสูงขึ้น ให้เพิ่มข้อมูล ASN และฟีดข่าวกรองภัยคุกคามลงใน IP ที่ทำการสำรวจ โดยทำเครื่องหมายโฟลว์ที่ IP ที่ทำการสำรวจเป็นของผู้ให้บริการโฮสติ้ง VPN เชิงพาณิชย์ หรือช่วง IP ที่ถูกขึ้นบัญชีดำ แม้ว่า IP เหล่านั้นจะอยู่ในประเทศเดียวกันก็ตาม 

let interactive = SigninLogs 
| where AuthenticationProtocol == "deviceCode" 
    and IsInteractive == true 
| project CorrelationId, UserPrincipalName, BrowserIP = IPAddress, 
          BrowserUA = UserAgent, TimeGenerated; 
let polling = AADNonInteractiveUserSignInLogs 
| join kind=inner interactive on CorrelationId 
| project CorrelationId, PollingIP = IPAddress, PollingUA = UserAgent; 
interactive 
| join kind=inner polling on CorrelationId 
//| where BrowserIP != PollingIP 
| project TimeGenerated, UserPrincipalName, BrowserIP, BrowserUA, 
          PollingIP, PollingUA, CorrelationId 

3. ตรวจสอบการสร้างโค้ดอุปกรณ์ปริมาณมากจากแอปพลิเคชันเดียว

ผู้โจมตีที่ดำเนินการแคมเปญฟิชชิ่งรหัสอุปกรณ์จะสร้างรหัสจำนวนมากในช่วงเวลาสั้นๆ การค้นหานี้แสดงแอปพลิเคชันที่มีการไหลเวียนของรหัสอุปกรณ์สูงผิดปกติจากผู้ใช้ที่แตกต่างกันในช่วง 24 ชั่วโมงที่ผ่านมา 

SigninLogs 
| where TimeGenerated > ago(24h) 
| where AuthenticationProtocol == "deviceCode" 
    or OriginalTransferMethod == "deviceCodeFlow" 
| summarize DistinctUsers = dcount(UserPrincipalName), 
            FlowCount = count() 
    by AppDisplayName, AppId 
| where DistinctUsers > 3  // adjust threshold to your environment 
| order by DistinctUsers desc

ปรับค่าเกณฑ์และช่วงเวลาให้ตรงกับค่าพื้นฐานของสภาพแวดล้อมของคุณ องค์กรที่ใช้ขั้นตอนการเขียนโค้ดอุปกรณ์อย่างถูกต้องตามกฎหมาย (เช่น สำหรับ Azure CLI หรือการเริ่มต้นใช้งานอุปกรณ์ IoT) ควรจัดทำรายการรหัสไคลเอ็นต์ที่ใช้งานได้ดีและยกเว้นรหัสเหล่านั้น 

พบท่อนไม้คู่หนึ่งที่น่าสงสัย—แล้วจะทำอย่างไรต่อไป?

ไม่ใช่ทุกกรณีที่การเรียกใช้โค้ดอุปกรณ์สำเร็จโดยที่ User-Agent ไม่ตรงกันจะเป็นการกระทำที่เป็นอันตรายเสมอไป ยังมีสถานการณ์ที่ถูกต้องตามกฎหมายอยู่ (เช่น นักพัฒนาใช้คำสั่ง az login บนเซิร์ฟเวอร์ระยะไกลและยืนยันตัวตนจากแล็ปท็อปของตนเอง) ควรตรวจสอบก่อนที่จะแจ้งเรื่องไปยังระดับที่สูงขึ้น อย่างไรก็ตาม หากบันทึกแสดงลักษณะของการละเมิด เช่น IP ที่ใช้ในการตรวจสอบที่ไม่คุ้นเคย, ASN ของผู้ให้บริการโฮสติ้ง, หรือผู้ใช้ที่ไม่ได้เริ่มต้นการเรียกใช้โค้ดอุปกรณ์ ให้ถือว่าเป็นการขโมยโทเค็นที่ได้รับการยืนยันแล้ว และดำเนินการตามขั้นตอนต่อไปนี้ทันที: 

1. ยกเลิกโทเค็นรีเฟรชทั้งหมดทันที 

เพิกถอนสิทธิ์การเข้าถึงของผู้ใช้ทันที (โปรดดูที่ เอกสารของไมโครซอฟต์) ปิดใช้งานผู้ใช้ที่ถูกบุกรุก และลบการมอบหมายบทบาทของพวกเขา การดำเนินการนี้จะทำให้โทเค็นรีเฟรชที่ใช้งานอยู่ทั้งหมดเป็นโมฆะ และตัดความสามารถของผู้โจมตีในการขอรับโทเค็นการเข้าถึงใหม่โดยไม่ให้ผู้โจมตีรู้ตัว ควรทำขั้นตอนนี้ก่อนรีเซ็ตรหัสผ่าน การรีเซ็ตรหัสผ่านเพียงอย่างเดียวจะไม่ยกเลิกโทเค็นรีเฟรช OAuth 

2. ยุติเซสชันที่ใช้งานอยู่ 

การยกเลิก refresh token ไม่ได้ทำให้ access token ที่ออกไปแล้วเป็นโมฆะ—access token เหล่านั้นยังคงใช้งานได้จนกว่าจะหมดอายุ หากเทนเนนต์ของคุณใช้ Continuous Access Evaluation (CAE) ให้บังคับประเมินเซสชันที่ใช้งานอยู่ทั้งหมดของผู้ใช้ใหม่เพื่อล้างแคชโทเค็น สำหรับเวิร์กโหลดที่ไม่ใช้ CAE ให้ยกเลิกเซสชันของผู้ใช้ใน Entra ID (ผู้ใช้ → ยกเลิกเซสชัน) เพื่อลบล้างโทเค็นที่แคชไว้ในบริการ Microsoft 365 ทั้งหมด 

3. ตรวจสอบกลไกการคงอยู่ของข้อมูล 

ตรวจสอบหาอุปกรณ์ที่ลงทะเบียนใหม่ กฎกล่องจดหมาย การยินยอมแอป OAuth และการกระทำอื่น ๆ ที่เกิดขึ้นในเซสชันเดียวกัน ให้ความสนใจเป็นพิเศษกับการลงทะเบียนอุปกรณ์ (ซึ่งสร้างโทเค็นรีเฟรชหลัก) กฎกล่องจดหมายที่ส่งต่อ เปลี่ยนเส้นทาง หรือลบอีเมล และการเปลี่ยนแปลงวิธีการตรวจสอบสิทธิ์ (เช่น การเพิ่มหมายเลขโทรศัพท์ใหม่สำหรับ MFA) การยกเลิกโทเค็นเพียงอย่างเดียวไม่เพียงพอ ผู้โจมตีอาจสร้างความคงอยู่ของการเข้าถึงได้แล้ว ลบทุกอย่างที่ผู้ใช้ไม่รู้จัก 

4. บรรจุ การเคลื่อนไหวด้านข้าง 

หากผู้ใช้ที่ถูกโจมตีมีบทบาทพิเศษ (เช่น ผู้ดูแลระบบส่วนกลาง ผู้ดูแลระบบ Exchange เป็นต้น) หรือเข้าถึงทรัพยากรที่สำคัญ ให้จำกัดการเข้าถึงบัญชีผ่านการกำหนดสิทธิ์แบบมีเงื่อนไขในระหว่างการตรวจสอบ ตรวจสอบว่าผู้โจมตีใช้โทเค็นที่ถูกขโมยไปเพื่อเข้าถึง SharePoint, Teams หรือทรัพยากร Azure หรือไม่ โดยบันทึกการตรวจสอบแบบรวม (Unified Audit Log) และบันทึกกิจกรรมของ Microsoft Graph จะแสดงขอบเขตการเข้าถึง 

5. เก็บรักษาหลักฐานและแจ้งศูนย์ปฏิบัติการฉุกเฉิน (SOC) 

ส่งออกรายการบันทึกการเข้าสู่ระบบที่เกี่ยวข้อง (ทั้งส่วนที่มีการโต้ตอบและไม่มีการโต้ตอบ โดยเชื่อมโยงด้วยรหัสความสัมพันธ์) กิจกรรมบันทึกการตรวจสอบล่าสุดของผู้ใช้ และกฎกล่องจดหมายหรือการลงทะเบียนอุปกรณ์ใดๆ ที่คุณลบออก ข้อมูลเหล่านี้มีความสำคัญอย่างยิ่งต่อการกำหนดขอบเขตความเสียหายและข้อกำหนดการรายงานเหตุการณ์ที่อาจเกิดขึ้นในภายหลัง

คำแนะนำและแนวปฏิบัติที่ดีที่สุด

คำแนะนำเชิงกลยุทธ์

สำหรับผู้บริหารและผู้นำด้านความปลอดภัย การตัดสินใจเชิงนโยบายคือสิ่งที่สำคัญที่สุด 

• ปิดกั้นกระบวนการยืนยันตัวตนด้วยรหัสอุปกรณ์สำหรับผู้ใช้ทุกคนที่ไม่ได้ต้องการการใช้งานดังกล่าวอย่างชัดเจน นี่คือการเปลี่ยนแปลงนโยบายการเข้าถึงแบบมีเงื่อนไข ซึ่งจะช่วยขจัดช่องโหว่ด้านความปลอดภัยสำหรับพนักงานส่วนใหญ่ของคุณได้อย่างสิ้นเชิง
• อัปเดตคู่มือรับมือเหตุการณ์ของคุณให้รวมการเพิกถอนโทเค็น OAuth เป็นขั้นตอนบังคับควบคู่ไปกับการรีเซ็ตรหัสผ่าน การรีเซ็ตรหัสผ่านเพียงอย่างเดียวไม่ได้เพิกถอนโทเค็นรีเฟรช ผู้โจมตียังคงเข้าถึงได้ตลอดไปเว้นแต่จะเพิกถอนโทเค็นอย่างชัดเจน
• ให้ความสำคัญกับการผูกโทเค็น (การป้องกันโทเค็น) สำหรับบัญชีที่มีมูลค่าสูง เช่น ผู้บริหาร ฝ่ายการเงิน และผู้ดูแลระบบ โดยทั่วไปแล้วฟีเจอร์นี้ใช้งานได้บน Windows (เวอร์ชันทดลองบน iOS/macOS) และเป็นมาตรการป้องกันเชิงลึกที่แข็งแกร่งที่สุดในการป้องกันการโจมตีซ้ำโทเค็นจากการรั่วไหลของโค้ดอุปกรณ์ที่ถูกขโมย
• ตรวจสอบว่าแอปพลิเคชันใดในระบบของคุณเปิดใช้งานการขอรหัสอุปกรณ์ (Device Code Flow) ไว้ หลายองค์กรมีแอปพลิเคชัน OAuth ที่มีสิทธิ์การเข้าถึงด้วยรหัสอุปกรณ์โดยที่ไม่ได้ตั้งค่าไว้ตั้งแต่แรก การลดจำนวนแอปพลิเคชันที่เสี่ยงต่อปัญหานี้ถือเป็นวิธีที่ได้ผลเร็ว
• ตรวจสอบให้แน่ใจว่าทีมปฏิบัติการด้านความปลอดภัยของคุณกำลังตรวจสอบบันทึกการเข้าสู่ระบบแบบไม่โต้ตอบ ไม่ใช่แค่บันทึกแบบโต้ตอบเท่านั้น กิจกรรมการรีเฟรชโทเค็นของผู้โจมตีจะปรากฏเฉพาะในบันทึกแบบไม่โต้ตอบ ซึ่งศูนย์ปฏิบัติการด้านความปลอดภัยหลายแห่งไม่ได้ตรวจสอบเป็นประจำ

คำแนะนำเชิงยุทธวิธี

สำหรับวิศวกรและผู้ดูแลระบบด้านความปลอดภัย—คำแนะนำในระดับการนำไปใช้งาน: 

จำกัดหรือปิดกั้นการไหลของรหัสอุปกรณ์ผ่านการเข้าถึงแบบมีเงื่อนไข

หากองค์กรของคุณไม่ได้ใช้การตรวจสอบสิทธิ์ด้วยรหัสอุปกรณ์สำหรับกรณีการใช้งานที่ถูกต้อง (เครื่องมือ CLI, อุปกรณ์ IoT, ฮาร์ดแวร์ห้องประชุม) ให้บล็อกการเข้าถึงทั้งหมดโดยใช้ นโยบายการเข้าถึงแบบมีเงื่อนไข Entra IDสร้างนโยบายที่กำหนดเป้าหมายไปที่ ผู้ใช้ทั้งหมด → ทรัพยากรเป้าหมาย → ทรัพยากรทั้งหมด (เดิมคือแอปบนคลาวด์) → เงื่อนไข → ขั้นตอนการตรวจสอบสิทธิ์ → ขั้นตอนรหัสอุปกรณ์ = บล็อก หากบางทีมต้องการ ให้กำหนดขอบเขตของนโยบายอนุญาตเฉพาะผู้ใช้หรือกลุ่มที่ระบุ และแพลตฟอร์มอุปกรณ์ที่รู้จักเท่านั้น โดยยังคงยึดตามนโยบายหลัก หลักการของสิทธิที่น้อยที่สุด. 

กำหนดขั้นตอนที่เกี่ยวข้องเพื่อลดความเสี่ยงจากการขโมยโทเค็น

การรีเซ็ตรหัสผ่านเพียงอย่างเดียวไม่สามารถยกเลิกโทเค็นรีเฟรช OAuth ได้ ขั้นตอนการตอบสนองของคุณสำหรับบัญชีที่ถูกบุกรุกจะต้องรวมถึง: (1) การยกเลิกการเข้าถึงของผู้ใช้และการปิดใช้งานบัญชี (2) การประเมินเซสชัน Continuous Access Evaluation (CAE) ที่ใช้งานอยู่ทั้งหมดอีกครั้ง และ (3) การตรวจสอบความยินยอมของแอป OAuth ของผู้ใช้และการลบหลักการบริการที่ไม่คุ้นเคยออก หากไม่ดำเนินการตามขั้นตอนเหล่านี้ ผู้โจมตีจะยังคงเข้าถึงได้ผ่านโทเค็นรีเฟรชจนกว่าจะหมดอายุ ซึ่งโดยปกติจะมีระยะเวลาสูงสุด 90 วัน Entra ID องค์ประกอบ 

ตรวจสอบบันทึกการเข้าสู่ระบบแบบไม่โต้ตอบเพื่อหาความผิดปกติทางภูมิศาสตร์

แท็บลงชื่อเข้าใช้แบบไม่โต้ตอบใน Entra ID คือจุดที่เหตุการณ์การรีเฟรชโทเค็นปรากฏขึ้น ผู้โจมตีที่ใช้โทเค็นรีเฟรชที่ถูกขโมยจะสร้างการเข้าสู่ระบบแบบไม่โต้ตอบจากที่อยู่ IP และ User Agent ที่มีแนวโน้มที่จะแตกต่างจากค่าพื้นฐานของผู้ใช้ ตั้งค่าการแจ้งเตือนสำหรับการเข้าสู่ระบบแบบไม่โต้ตอบ โดยที่ IP ต้นทางอยู่ในประเทศหรือ ASN ที่แตกต่างจากที่ผู้ใช้เข้าสู่ระบบแบบโต้ตอบครั้งล่าสุด ดำเนินการเพิ่มเติมโดยการเปรียบเทียบ IP ต้นทางกับแหล่งข้อมูลข่าวกรองภัยคุกคามและฐานข้อมูลชื่อเสียง IP—กิจกรรมการสำรวจหรือการรีเฟรชจาก IP ที่อยู่ในบัญชีดำ ผู้ให้บริการโฮสติ้งที่ปลอดภัย หรือเครือข่ายพร็อกซีที่อยู่อาศัย เป็นตัวบ่งชี้ที่มีความน่าเชื่อถือสูงไม่ว่าจะอยู่ในภูมิภาคใดก็ตาม การผสมผสานทางภูมิศาสตร์นี้ การตรวจจับความผิดปกติ และการกรองตามชื่อเสียงเป็นสัญญาณแรกเริ่มและน่าเชื่อถือที่สุดสำหรับการขโมยรหัสโทเค็นอุปกรณ์ 

วิธีป้องกันการหลอกลวงด้วยรหัสอุปกรณ์

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

กลยุทธ์การรับมือนั้นตรงไปตรงมา: บล็อกการไหลของโค้ดอุปกรณ์ในจุดที่ไม่จำเป็น ตรวจสอบให้แน่ใจว่าคู่มือการรับมือเหตุการณ์ฉุกเฉิน (IR playbook) ของคุณมีฟังก์ชันการเพิกถอนโทเค็น และตรวจสอบบันทึกการเข้าสู่ระบบแบบไม่โต้ตอบซึ่งองค์กรส่วนใหญ่มองข้ามไป การเจาะลึกทางเทคนิคในบทความนี้—ตั้งแต่การวิเคราะห์โปรโตคอล การบันทึกข้อมูล ไปจนถึงการสืบค้น KQL—จะช่วยให้ทีมรักษาความปลอดภัยของคุณมีทุกสิ่งที่จำเป็นในการค้นหากิจกรรมเหล่านี้ได้ในปัจจุบัน 

เนื่องจากการโจมตีทางด้านข้อมูลประจำตัวแบบ OAuth ยังคงพัฒนาอย่างต่อเนื่อง ช่องว่างระหว่างสิ่งที่เครื่องมือรักษาความปลอดภัยแบบดั้งเดิมสามารถมองเห็นได้กับสิ่งที่เกิดขึ้นในระดับข้อมูลประจำตัวจึงมีแต่จะกว้างขึ้น องค์กรที่ลงทุนในระบบรักษาความปลอดภัยระดับโปรโตคอลจึงควรให้ความสำคัญ การตรวจจับและการตอบสนอง—ไม่ใช่แค่การตรวจสอบปลายทางและเครือข่ายเท่านั้น—ที่จะเป็นตัวตรวจจับวิวัฒนาการขั้นต่อไปของเทคนิคนี้ ก่อนที่จะเข้าสู่ขั้นตอนหลังการโจมตี 

Silverfortทีมวิจัยของ ยังคงติดตามวิวัฒนาการของเทคนิคการโจมตีที่ใช้ OAuth อย่างต่อเนื่อง