กำหนดการรับรองความถูกต้อง Kerberos: เพิ่มความปลอดภัยสูงสุด

การรับรองความถูกต้อง Kerberos เป็นวิธีการตรวจสอบความถูกต้องเริ่มต้นของ Microsoft นับตั้งแต่ Windows Server 2000 ในโพสต์ที่แล้วของฉัน ฉันได้อธิบายจุดอ่อนในโปรโตคอล NTLM แบบเก่า และเหตุใดองค์กรจึงควรใช้ความพยายามร่วมกันเพื่อหยุดใช้งาน โดยเฉพาะอย่างยิ่ง NTLMv1 ที่อ่อนแอกว่า

แต่การรับรองความถูกต้องของ Kerberos ทำงานอย่างไร และเหตุใดจึงดีกว่า NTLM นอกจากนี้ การรับรองความถูกต้องของ Kerberos มีช่องโหว่ในตัวเองหรือไม่ (การแจ้งเตือนสปอยเลอร์: มี!) และคุณจะลดความเสี่ยงได้อย่างไร มาดำดิ่งกัน

การตรวจสอบสิทธิ์ Kerberos ทำงานอย่างไร

การรับรองความถูกต้องของ Kerberos ใช้ชื่อมาจาก Cerberos ซึ่งเป็นสุนัขสามหัวที่เฝ้าทางเข้าฮาเดสในตำนานเทพเจ้ากรีกเพื่อป้องกันไม่ให้สิ่งมีชีวิตเข้าสู่โลกแห่งความตาย

ชื่อนี้ถูกเลือกเนื่องจากการรับรองความถูกต้องของ Kerberos เป็นการเชื่อถือแบบสามทางที่ปกป้องประตูสู่เครือข่ายของคุณ “หัว” ทั้งสามของ Kerberos ได้แก่:

• เครื่องไคลเอนต์ของผู้ใช้
• เซิร์ฟเวอร์พร้อมบริการที่ผู้ใช้ต้องการเข้าถึง
• Key Distribution Center (KDC) ซึ่งเป็นกระบวนการที่ทำงานบนตัวควบคุมโดเมนทุกตัวในโดเมน Active Directory และให้บริการหลักสองประการ: Ticket-Granting Service (TGS) และ บริการตรวจสอบสิทธิ์ (AS)

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

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

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

1. สำหรับการตรวจสอบสิทธิ์เบื้องต้น เครื่องไคลเอ็นต์ของผู้ใช้จะส่งคำขอไปยัง KDC Authentication Service (AS) คำขอประกอบด้วยรายละเอียดต่างๆ เช่น ชื่อผู้ใช้ ตลอดจนวันที่และเวลา ข้อมูลทั้งหมดยกเว้นชื่อผู้ใช้จะถูกเข้ารหัสโดยใช้แฮชของรหัสผ่านของผู้ใช้
2. KDC AS ใช้ชื่อผู้ใช้เพื่อค้นหาสำเนาแฮชรหัสผ่านของผู้ใช้ และใช้เพื่อถอดรหัสคำขอส่วนที่เหลือ หากการถอดรหัสสำเร็จ นั่นหมายความว่าไคลเอนต์ใช้แฮชรหัสผ่านที่ถูกต้อง และผู้ใช้ได้ตรวจสอบสิทธิ์สำเร็จแล้ว
3. เมื่อผู้ใช้ได้รับการตรวจสอบสิทธิ์แล้ว KDC AS จะส่ง ตั๋วการให้ตั๋ว (TGT) ให้กับลูกค้าของผู้ใช้ TGT มีคีย์เซสชันที่ไม่ซ้ำกันและการประทับเวลาที่ระบุระยะเวลาที่เซสชันนั้นใช้ได้ (ปกติ 8 หรือ 10 ชั่วโมง) สิ่งสำคัญ ก่อนที่จะส่ง TGT นั้น KDC จะเข้ารหัสโดยใช้แฮชรหัสผ่านสำหรับบัญชีพิเศษ บัญชี KRBTGT แฮชรหัสผ่านนั้นจะถูกแชร์ระหว่าง DC ทั้งหมดในโดเมน Active Directory เพื่อให้สามารถอ่านได้ TGT ที่พวกเขาได้รับเมื่อผู้ใช้ร้องขอการเข้าถึงทรัพยากรไอทีต่างๆ
4. เมื่อใดก็ตามที่ผู้ใช้ต้องการเข้าถึงทรัพยากรไอที เครื่องไคลเอ็นต์จะส่งคำขอไปยัง Ticket Granting Service (TGS) ของ KDC รวมถึง TGT เพื่อพิสูจน์ว่าผู้ใช้ได้รับการรับรองความถูกต้องเมื่อเร็วๆ นี้
5. KDC TGS ถอดรหัส TGT โดยใช้รหัสผ่าน KRBTGT หากกระบวนการนั้นสำเร็จและการประทับเวลาบ่งชี้ว่า TGT ยังคงใช้ได้ TGS จะสร้างโทเค็นและเข้ารหัสโดยใช้แฮชรหัสผ่าน NTLM ของบัญชีบริการ (ซึ่งตามหลักการแล้ว จะทราบเฉพาะกับ DC และบริการเอง) โดยจะส่ง ตั๋ว TGS ที่เป็นผลลัพธ์ไปยังเครื่องไคลเอ็นต์ของผู้ใช้
6. เครื่องไคลเอนต์ส่งตั๋ว TGS ไปยังแอปพลิเคชันเซิร์ฟเวอร์ ซึ่งจะถอดรหัสโดยใช้แฮชรหัสผ่านของตัวเอง เมื่อตรวจสอบแล้ว ระบบจะให้สิทธิ์การเข้าถึงทรัพยากรแก่ผู้ใช้ในช่วงระยะเวลาหนึ่ง ซึ่งเรียกว่า Time to Live (TTL) (โดยค่าเริ่มต้น TTL คือ 10 ชั่วโมง) (ฉันได้ข้ามรายละเอียดการอนุญาต — กำหนดอย่างชัดเจนว่าผู้ใช้ได้รับอนุญาตให้เข้าถึงทรัพยากรใด — เนื่องจากเรามุ่งเน้นไปที่การตรวจสอบสิทธิ์ที่นี่)

เคอร์เบรอส กับ NTLM

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

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

นอกจากนี้ การรับรองความถูกต้องของ Kerberos ยังมอบข้อได้เปรียบเหนือ NTLM ในเรื่องความปลอดภัยดังต่อไปนี้:

• การตรวจสอบสิทธิ์ Kerberos ใช้วิธีการเข้ารหัสขั้นสูงมากกว่าฟังก์ชันการเข้ารหัส MD4 ที่ล้าสมัยที่ใช้ใน NTLM ที่จริงแล้ว เมื่อใช้การตั้งค่านโยบายความปลอดภัยในนโยบายกลุ่ม คุณสามารถกำหนดค่าประเภทการเข้ารหัสต่อไปนี้ที่ได้รับอนุญาตในการตรวจสอบสิทธิ์ Kerberos:
• DES_CBC_CRC
• DES_CBC_MD5
• RC4_HMAC_MD5
• AES128_HMAC_SHA1
• AES256_HMAC_SHA1
• Kerberos รองรับการรับรองความถูกต้องแบบหลายปัจจัย (MFA)
• NTLM ทำให้ไคลเอ็นต์ของผู้ใช้ไม่สามารถตรวจสอบตัวตนของเซิร์ฟเวอร์ที่กำลังตรวจสอบความถูกต้องได้ แต่ Kerberos ให้การตรวจสอบความถูกต้องร่วมกัน

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

ช่องโหว่ในการรับรองความถูกต้องของ Kerberos

อย่างไรก็ตาม กระบวนการตรวจสอบสิทธิ์ Kerberos ก็ไม่ใช่ปัญหาที่อาจเกิดขึ้น โดยเฉพาะอย่างยิ่ง โปรโตคอลมีความเสี่ยงต่อการโจมตี Kerberoasting, Golden Ticket และ Silver Ticket และการโจมตีแบบ pass-the-ticket

การคั่วแบบเคอร์เบอโรสต์

Kerberoasting ได้รับการอธิบายครั้งแรกในปี 2014; ปัจจุบันเป็นการโจมตีทั่วไปที่แฮกเกอร์ใช้ซึ่งทำลายข้อมูลประจำตัวของผู้ใช้และต้องการเริ่มการเคลื่อนไหวด้านข้าง เนื่องจากผู้โจมตีดูเหมือนจะเป็นผู้ใช้โดเมนที่ถูกต้อง พวกเขาจึงสามารถทำตามขั้นตอนที่ 1-5 ของกระบวนการข้างต้นได้ จากนั้น เมื่อลูกค้าได้รับตั๋วบริการ แฮกเกอร์จะแยกมันออกจากหน่วยความจำและพยายามถอดรหัสมันแบบออฟไลน์

สำหรับบัญชีบริการที่มีรหัสผ่านเก่าหรือรหัสผ่านที่ไม่รัดกุม Kerberoasting เป็นเทคนิคการโจมตีที่ทรงพลัง ในความเป็นจริง มีเครื่องมือที่พร้อมใช้งานที่ช่วยปรับปรุงกระบวนการทั้งหมด: Impacket, PowerSploit และ Empire ทำให้กระบวนการขอตั๋วบริการและแยกแฮชของตั๋วเป็นอัตโนมัติ ในขณะที่เครื่องมือถอดรหัสรหัสผ่านเช่น John the Ripper และ Hashcat สามารถลองใช้รหัสผ่านที่เป็นไปได้มากกว่าล้านรหัส ต่อวินาที ทำให้พวกเขาสามารถใช้รหัสผ่านข้อความธรรมดาแบบ brute-force ในลำดับที่ค่อนข้างสั้นจากแฮชที่มีช่องโหว่

เนื่องจากในกระบวนการตรวจสอบสิทธิ์ Kerberos นั้น DC จะไม่ติดตามว่าผู้ใช้เชื่อมต่อกับบริการจริงหรือไม่หลังจากขอตั๋ว แฮกเกอร์จึงสามารถขอตั๋วหลายร้อยใบเพื่อพยายามถอดรหัส โดยไม่สร้างการรับส่งข้อมูลไปยังบริการเป้าหมายที่อาจก่อให้เกิดการแจ้งเตือน นอกจากนี้ ผู้โจมตีไม่จำเป็นต้องมีข้อมูลประจำตัวของผู้ดูแลระบบเพื่อเริ่มการโจมตี การประนีประนอมข้อมูลรับรองของผู้ใช้ทั่วไปก็เพียงพอแล้ว

ตั๋วปลอมแปลง: การโจมตีตั๋วทองคำและตั๋วเงิน

การตรวจสอบสิทธิ์ Kerberos สร้างขึ้นบนสมมติฐานว่า TGT ใดๆ ที่เข้ารหัสด้วยแฮชรหัสผ่าน KRBTGT นั้นถูกต้องตามกฎหมาย ดังนั้นผู้โจมตีที่สามารถสร้างตั๋วปลอมจะมีพลังที่ไม่จำกัดในโดเมน — ที่เรียกว่า Golden Ticket

ในการปลอมแปลง TGT แฮกเกอร์จำเป็นต้องมีข้อมูลสำคัญสี่ส่วน:

• FQDN (ชื่อโดเมนแบบเต็ม) ของโดเมน
• SID (ตัวระบุความปลอดภัย) ของโดเมน
• ชื่อผู้ใช้ของบัญชีที่ต้องการแอบอ้าง
• แฮชรหัสผ่าน KRBTGT

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

รายการที่สี่นั้นยากกว่าเล็กน้อย แต่ก็ยังไม่ได้ยากขนาดนั้น ฉันอธิบายรายละเอียดเหล่านี้ในบล็อกโพสต์ Golden Ticket ของฉัน แต่มีดังต่อไปนี้:

• การขโมยไฟล์ NTDS.DIT ซึ่งจัดเก็บแฮชรหัสผ่านสำหรับผู้ใช้ทั้งหมดในโดเมน
• ประนีประนอมกับเวิร์กสเตชันและใช้สิ่งประดิษฐ์ข้อมูลรับรองผู้ดูแลระบบที่เหลืออยู่
• การใช้เครื่องมือโอเพ่นซอร์ส Mimikatz เพื่อรวบรวมข้อมูลประจำตัว
• การแกล้งทำเป็น DC และขอแฮชรหัสผ่านจาก DC ที่ถูกต้อง (การโจมตี DCSync)

ด้วยข้อมูลทั้งสี่ชิ้นในมือ แฮ็กเกอร์สามารถสร้างตั๋ว Kerberos เพื่อปลอมตัวเป็นผู้ใช้ AD ใดๆ ที่พวกเขาต้องการได้ รวมถึงผู้ดูแลระบบโดเมนที่มีสิทธิพิเศษสูงด้วย ยิ่งไปกว่านั้น พวกเขาสามารถทำให้ตั๋วเหล่านั้นใช้ได้นานเท่าที่ต้องการ แม้ว่าจะละเมิดการตั้งค่านโยบายการจำกัดเวลาขององค์กรก็ตาม

นอกจากนี้ยังมีการโจมตี Silver Ticket ซึ่งมีข้อจำกัดมากกว่าแต่ก็สามารถสร้างความเสียหายได้ค่อนข้างมาก การใช้เทคนิคเช่น Kerberoasting ผู้โจมตีจะขโมย TGS สำหรับบริการ (เช่น SharePoint) แยกแฮชของบัญชีบริการ และใช้แฮชนั้นเพื่อสร้างตั๋ว TGS เพิ่มเติมสำหรับบริการนั้น

ตั๋วที่ถูกขโมย: การโจมตีผ่านตั๋ว (PtT)

นอกเหนือจากการปลอมตั๋วแล้ว แฮ็กเกอร์ยังสามารถขโมยตั๋ว TGS หรือ TGT ที่ถูกต้องตามกฎหมายที่ KDS ออกให้แก่ผู้ใช้อีกด้วย เมื่อตั๋วเหล่านั้นอยู่ในมือ พวกเขาก็จะเข้าถึงทรัพยากรด้านไอทีได้เสมือนว่าเป็นผู้ใช้รายนั้น โดยที่ไม่เคยเรียนรู้รหัสผ่านของผู้ใช้เลย เทคนิคหนึ่งคือการใช้เครื่องมือเช่น Mimikatz เพื่อแยกตั๋ว Kerberos ออกจากหน่วยความจำของกระบวนการ LSASS.exe

หากแฮกเกอร์บุกรุกบัญชีของผู้ใช้รายใดรายหนึ่ง พวกเขาสามารถรับ TGT และตั๋ว TGS ทั้งหมดสำหรับผู้ใช้รายนั้นได้ แต่ฝ่ายตรงข้ามที่ขโมยสิทธิ์ของผู้ดูแลระบบสามารถรับตั๋ว TGT และ TGS ทั้งหมดที่แคชไว้ในระบบได้

แนวทางปฏิบัติที่ดีที่สุดในการลดความเสี่ยงของคุณ

การปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดด้านความปลอดภัยด้านไอทีสามารถลดความเสี่ยงที่มีอยู่ในการรับรองความถูกต้องของ Kerberos ได้ นี่คือรายการยอดนิยมที่ฉันแนะนำ

ปฏิบัติตามสุขอนามัยของรหัสผ่านที่ดี โดยเฉพาะกับบัญชีบริการ

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

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

ในวงกว้างยิ่งขึ้น ให้ปฏิบัติตามหลักเกณฑ์ NIST ปัจจุบันสำหรับรหัสผ่านทั้งหมดในสภาพแวดล้อมของคุณ โดยเฉพาะอย่างยิ่ง โปรดทราบว่า ความยาวของรหัสผ่านมีความสำคัญต่อการขัดขวางแฮกเกอร์มากกว่าความซับซ้อนของรหัสผ่าน และไม่แนะนำให้เปลี่ยนรหัสผ่านบ่อยๆ อีกต่อไป

จำกัดการเข้าถึงรหัสผ่านบัญชี KRBTGT และเปลี่ยนรหัสผ่านเป็นประจำ

กลยุทธ์การป้องกันเบื้องต้นต่อการโจมตีของ Golden Ticket คือการบังคับใช้หลักการรักษาความปลอดภัยที่สำคัญ: สิทธิพิเศษน้อยที่สุด ด้วยการลดว่าใครและสิ่งใดบ้างที่สามารถเข้าถึงแฮชรหัสผ่าน KRBTGT ได้ คุณจะจำกัดช่องโหว่ของคุณต่อการโจมตี Golden Ticket สำหรับผู้เริ่มต้น ให้ทราบอย่างแน่ชัดว่าบัญชีใดมีสิทธิ์ที่จำเป็นในการแยกแฮชรหัสผ่าน โดยค่าเริ่มต้น ซึ่งจะรวมถึงกลุ่มตัวควบคุมบิวด์อิน\ผู้ดูแลระบบและตัวควบคุมโดเมนในตัว โดยทั่วไปแล้วบัญชีที่ใช้สำหรับ Azure AD Connect จะมีพลังนี้เช่นกัน ตรวจสอบให้แน่ใจว่าคุณมีจำนวนผู้ดูแลระบบโดเมนขั้นต่ำที่แน่นอน รวมถึงสมาชิกของกลุ่มอื่นๆ ที่ให้สิทธิ์ในการเข้าสู่ระบบ DC เช่น ตัวดำเนินการพิมพ์และเซิร์ฟเวอร์ หากคุณพบบัญชีอื่นที่สามารถเข้าถึงแฮชรหัสผ่าน KRBTGT ได้ ให้ตรวจสอบทันทีและลบการอนุญาตใดๆ ที่ไม่จำเป็นอย่างเคร่งครัด

แน่นอนว่า คุณจะยังคงมีบัญชี (จำนวนจำกัด) ที่สามารถเข้าถึงข้อมูลสำคัญนี้ได้ ดังนั้นอย่าลืมเปลี่ยนรหัสผ่าน KRBTGT เป็นประจำ การเปลี่ยนรหัสผ่านไม่ได้ป้องกันแฮกเกอร์จากการสร้าง Golden Tickets แต่จะทำให้รหัสผ่านที่มีอยู่ในระบบของคุณเป็นโมฆะ เพื่อหลีกเลี่ยงข้อผิดพลาดในการตรวจสอบสิทธิ์ที่เกิดจากการจำลองแฮชรหัสผ่าน KRBTGT ใหม่ในสภาพแวดล้อมของคุณล่าช้า ฉันขอแนะนำให้ใช้สคริปต์รีเซ็ตรหัสผ่านบัญชี KRBTGT ของ Microsoft ทุกๆ 180 วัน นอกเหนือจากการหมุนเวียนรหัสผ่านตามกำหนดการเหล่านี้ ฉันขอแนะนำอย่างยิ่งให้เปลี่ยนรหัสผ่านทุกครั้งที่มนุษย์ที่มีความสามารถในการสร้าง Golden Ticket ออกจากองค์กร (เช่น ความสามารถในการแยกแฮช KRBTGT) รวมถึงทุกครั้งที่คุณเห็นหลักฐาน ของการโจมตีตั๋วทองคำ

คำเตือน: ดำเนินการด้วยความระมัดระวัง! เพื่อหลีกเลี่ยงปัญหาร้ายแรง วิธีที่ดีที่สุดคือรีเซ็ตรหัสผ่าน KRBTGT โดยใช้สคริปต์จาก Microsoft หากต้องการบังคับให้ผู้ใช้ทุกคนรับ TGT ใหม่ที่เข้ารหัสด้วยแฮชรหัสผ่านใหม่ คุณอาจต้องดำเนินการเพิ่มเติม สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับปัญหาเหล่านี้ โปรดดูโพสต์ Golden Ticket ของฉัน

ติดตาม วิเคราะห์ และแจ้งเตือนกิจกรรมทั่วทั้งระบบนิเวศไอทีของคุณ

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

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

นอกจากนี้ ให้ตรวจสอบระบบของคุณเพื่อหาตั๋วที่มีค่า TTL มากกว่าค่าเริ่มต้นของ Kerberos ที่ 10 ชั่วโมง Golden Tickets มักกำหนดไว้ที่ 10 ปี

มีแผนการฟื้นฟู

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

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

บทสรุป

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