RC4 ใน Active Directoryความเสี่ยงที่มองไม่เห็นซึ่งยากต่อการค้นหามากกว่าที่คุณคิด

เหตุใดการค้นหาส่วนประกอบที่จำเป็นของ RC4 จึงทำได้ยาก

หาก RC4 เป็นความเสี่ยงที่รู้จักกันดี ทำไมสภาพแวดล้อมจำนวนมากจึงยังคงพึ่งพาความเสี่ยงนี้อยู่? คำตอบไม่ใช่ความประมาทเลินเล่อ แต่เป็นเพราะการมองเห็นความเสี่ยงนั้น การสัมผัสกับ RC4 มักไม่ปรากฏให้เห็นเอง มันสามารถทำงานอย่างเงียบๆ ในเบื้องหลัง บ่อยครั้งในสถานที่ที่ไม่ได้ถูกแตะต้องมานานหลายปี 

สาเหตุหลักมาจากคุณลักษณะ AD เพียงอย่างเดียว: msDS-SupportedEncryptionTypes. เมื่อไม่ได้กำหนดแอตทริบิวต์นี้ไว้อย่างชัดเจนในบัญชี KDC จะไม่มีคำสั่งใดๆ เกี่ยวกับการเข้ารหัสที่จะใช้ และในอดีตนั้นหมายความว่า RC4, AES-128 หรือ AES-256 ล้วนได้รับอนุญาต สภาพแวดล้อมส่วนใหญ่มีบัญชีหลายพันบัญชีที่ไม่ได้กำหนดแอตทริบิวต์นี้ไว้ และแต่ละบัญชีก็มีโอกาสตกเป็นเป้าหมายของการโจมตีแบบ Kerberoasting และการถูกบุกรุกได้ 

บัญชีสองประเภทที่มีความเสี่ยงเป็นพิเศษ ได้แก่ บัญชีบริการและบัญชีเครื่องจักร

บัญชีบริการใน Active Directoryจุดบอดที่ใหญ่ที่สุดของ RC4

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

หากรหัสผ่านของบัญชีบริการถูกตั้งค่าครั้งล่าสุดก่อน Windows Server 2008 ซึ่งเป็นเวอร์ชันที่รองรับการเข้ารหัส AES ใน Active Directory บัญชีนั้นจะไม่เคยมีคีย์ AES สร้างขึ้นมาก่อน การอัปเกรดโดเมนเพียงอย่างเดียวไม่สามารถแก้ไขปัญหานี้ได้ มีเพียงการรีเซ็ตรหัสผ่านเท่านั้นที่จะกระตุ้นการสร้างคีย์ AES แทน RC4 แต่ก่อนที่คุณจะทำเช่นนั้นได้ คุณต้องรู้ว่าบัญชีใดอยู่ในสถานะนี้ ซึ่งเป็นสิ่งที่สภาพแวดล้อมส่วนใหญ่ไม่สามารถมองเห็นได้ 

บัญชีเครื่องจักรใน Active Directory: การพึ่งพาอีกรูปแบบหนึ่ง

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

ปัญหาอยู่ที่ระบบปฏิบัติการเอง อุปกรณ์ที่ใช้ Windows เวอร์ชันเก่ากว่า Server 2008 ไม่รองรับการเข้ารหัส AES สำหรับบัญชีเหล่านี้ RC4 ไม่ใช่แค่ตัวเลือกเริ่มต้น แต่เป็นข้อกำหนดที่จำเป็นจนกว่าระบบจะได้รับการอัปเกรด 

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

ลำดับเหตุการณ์การยกเลิกการใช้งาน RC4: เกิดอะไรขึ้นในแต่ละขั้นตอน และทำไมจึงมีความสำคัญในตอนนี้

ไมโครซอฟต์ได้วางแผนการยกเลิกการใช้งาน RC4 เป็นการทยอยเปิดใช้งาน ซึ่งทำให้องค์กรต่างๆ มีเวลาเตรียมตัว แต่เวลานั้นกำลังจะหมดลงแล้ว 

มกราคม 2026 การอัปเดตครั้งนี้ได้เพิ่มขั้นตอนการตรวจสอบเข้ามา การเข้ารหัส RC4 ยังคงได้รับอนุญาต แต่ได้มีการเพิ่มกลไกการบันทึกข้อมูลใหม่เพื่อให้องค์กรสามารถมองเห็นได้ว่ามีการใช้งานที่ใดบ้าง 

เมษายน 2026 การอัปเดตคือจุดเริ่มต้นของการบังคับใช้ ศูนย์กระจายคีย์ (KDC) ตอนนี้ทำงานในโหมด AES เท่านั้นเป็นค่าเริ่มต้นสำหรับบัญชีที่ msDS-SupportedEncryptionTypes ไม่สามารถระบุได้ RC4 ไม่ใช่ตัวเลือกสำรองอีกต่อไป และบัญชีบริการหรือเครื่องใดๆ ที่ยังคงพึ่งพา RC4 จะเริ่มประสบปัญหาการตรวจสอบสิทธิ์ล้มเหลว มีวิธีแก้ปัญหาชั่วคราวอยู่: RC4DefaultDisablementPhase คีย์รีจิสทรีช่วยให้ผู้ดูแลระบบสามารถย้อนกลับพฤติกรรมของ DC ได้ด้วยตนเองในระหว่างที่ดำเนินการแก้ไขปัญหา แต่เป็นเพียงทางเลือกชั่วคราวเท่านั้น 

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

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

วิธีตรวจสอบปริมาณสาร RC4 ในสภาพแวดล้อมของคุณด้วย Silverfort

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

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

ขั้นตอนที่ 1-ตัวชี้วัดความเสี่ยง: ฉันระบุ บัญชีที่มีการเข้ารหัสที่อ่อนแอ

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

• การเข้ารหัสที่อ่อนแอ (ผู้ใช้)—เกิดขึ้นเมื่อบัญชีผู้ใช้ตรวจสอบสิทธิ์โดยใช้ RC4 หรือการเข้ารหัส Kerberos ที่อ่อนแอประเภทอื่น
• การเข้ารหัสที่อ่อนแอ (เซิร์ฟเวอร์)—ยกขึ้นเมื่อพบเห็นกรณีเดียวกันนี้ในบัญชีบริการหรือบัญชีเครื่องจักร 

ตัวชี้วัดเหล่านี้จะแสดงรายการบัญชีที่ตรวจพบการเข้ารหัสที่อ่อนแอในข้อมูลการตรวจสอบสิทธิ์ได้อย่างทันทีและนำไปปฏิบัติได้จริง ไม่ใช่แค่บัญชีที่อาจมีความเสี่ยงจากด้านการตั้งค่า แต่เป็นบัญชีที่กำลังใช้การเข้ารหัสที่อ่อนแออยู่ในขณะนี้