ช่องโหว่ KDC Spoofing ที่สามระบุโดย Silverfort นักวิจัย – คราวนี้ใน IBM QRadar [CVE-2019-4545]

*****โดย ยอฟ อิลลิน Yaron Kassner, ดอร์ ซีกัล & Rotem Zach, Silverfort*****

การปลอมแปลง KDC ไม่เคยล้าสมัย เราได้เปิดเผยช่องโหว่การปลอมแปลงของ KDC ใน Cisco ASA และ เครือข่ายพาโลอัลโต PAN-OS ย้อนกลับไปในเดือนพฤษภาคม 2020 ตอนนี้เราสามารถแบ่งปันได้ว่า IBM QRadar ก็มีความเสี่ยงเช่นกัน เนื่องจากทาง Kerberos ได้ดำเนินการแล้ว
ช่องโหว่ KDC Spoofing ช่วยให้ผู้โจมตีข้ามการพิสูจน์ตัวตน Kerberos ไปยัง QRadar และส่งผลให้ได้รับสิทธิ์การเข้าถึงระดับผู้ดูแลระบบ เราได้ทำงานอย่างใกล้ชิดกับวิศวกรของ IBM เพื่อช่วยแก้ไขปัญหานี้ ซึ่งเป็นผลมาจากปัญหาที่เกิดขึ้นเมื่อเร็วๆ นี้ บูเลทีนการรักษาความปลอดภัย . บล็อกโพสต์นี้สรุปช่องโหว่ อธิบายวิธีหลีกเลี่ยงช่องโหว่เหล่านี้ในฐานะนักพัฒนาที่ใช้ Kerberos และพูดคุยเกี่ยวกับการลดผลกระทบสำหรับองค์กรที่ใช้ QRadar และระบบอื่นๆ ที่ใช้ Kerberos

อธิบายช่องโหว่

IBM QRadar Security Information and Event Management (SIEM) ช่วยให้ทีมรักษาความปลอดภัยตรวจจับและจัดลำดับความสำคัญของภัยคุกคามทั่วทั้งองค์กร และให้ข้อมูลเชิงลึกที่สำคัญที่ช่วยให้ทีมตอบสนองได้อย่างรวดเร็วเพื่อลดผลกระทบของเหตุการณ์
ช่องโหว่นี้อยู่ที่การใช้โปรโตคอล Kerberos ของ IBM Kerberos เป็นโปรโตคอลการตรวจสอบสิทธิ์ที่ใช้กันทั่วไปสำหรับการตรวจสอบสิทธิ์ภายในองค์กร มีการใช้กันอย่างแพร่หลายในเครือข่ายองค์กรเนื่องจากความนิยมของ Active Directoryและเป็นที่ต้องการมากกว่าโปรโตคอลการตรวจสอบสิทธิ์ที่อ่อนแอ เช่น NTLM
IBM ใช้โปรโตคอลการตรวจสอบสิทธิ์ Kerberos สำหรับการตรวจสอบสิทธิ์การเข้าถึงระดับผู้ดูแลระบบ ดังนั้น การข้ามการตรวจสอบสิทธิ์ Kerberos ทำให้ผู้โจมตีสามารถเข้าถึง IBM QRadar ในระดับผู้ดูแลระบบ ดูข้อมูลที่ละเอียดอ่อน และอาจแก้ไขบันทึกโดยไม่ต้องมีข้อมูลประจำตัวที่ถูกต้องตามกฎหมาย
เพื่อให้โปรโตคอล Kerberos ทำงานได้ ควรมีสามสิ่งต่อไปนี้:

• 1. ผู้ใช้รับรองความถูกต้องกับเซิร์ฟเวอร์
  2. เซิร์ฟเวอร์รับรองความถูกต้องกับลูกค้า
  3. KDC รับรองความถูกต้องกับเซิร์ฟเวอร์

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

สำหรับคำศัพท์และภูมิหลังของ Kerberos เกี่ยวกับวิธีการทำงานของการโจมตีด้วยการปลอมแปลง KDC โปรดดูที่ส่วนท้ายของโพสต์บล็อกนี้

เราค้นพบช่องโหว่ใน QRadar ได้อย่างไร

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

การปลอมแปลงการรับรองความถูกต้อง Kerberos/SASL

ต่อไปนี้เป็นขั้นตอนที่ผู้โจมตีจะดำเนินการเพื่อปลอมแปลง DC เพื่อข้ามการตรวจสอบสิทธิ์ประเภทนี้ สมมติว่าเรามีความสามารถในการจี้การสื่อสารเครือข่ายระหว่าง QRadar และ DC ในกรณีนี้ เราสามารถสร้าง DC ปลอมที่มีชื่อผู้ใช้เหมือนกับชื่อผู้ใช้และรหัสผ่านของผู้ดูแลระบบที่เราเลือกได้ จากนั้นเราจะเริ่มต้นการยืนยันตัวตนกับ QRadar และใช้ผู้ใช้และรหัสผ่านที่เราเลือก QRadar รับรองความถูกต้องกับ Kerberos และเราจี้การสื่อสาร Kerberos และส่งคืน AS_REP ที่ตรงกับรหัสผ่านที่เราเลือก และ TGS_REP ที่ประกอบด้วยตั๋วบริการ ซึ่งเข้ารหัสด้วยคีย์เซสชันบริการที่เราเลือก และคีย์เซสชันที่เราเลือก เข้ารหัสด้วยรหัสผ่านที่เราเลือก เนื่องจากในขั้นตอนเหล่านี้ การยืนยันเพียงครั้งเดียวที่ทำในฝั่ง QRadar อาศัยรหัสผ่านที่เราเลือก ดังนั้น QRadar จึงไม่ควรปฏิเสธการรับรองความถูกต้อง ณ จุดนี้ เมื่อ QRadar ได้รับตั๋วบริการแล้ว ก็สามารถส่งคำขอ LDAP ไปยัง DC ได้ เราจะจี้ทราฟฟิก LDAP ด้วยเช่นกัน เรามีสองทางเลือก ณ จุดนี้:
1. LDAP ถูกใช้งานโดยไม่มี TLS ในกรณีนี้ เราสามารถจี้ทราฟฟิก LDAP ได้ QRadar ส่งคำขอผูกไปยัง DC ด้วยข้อความ Kerberos AP_REQ ซึ่งมีตั๋วบริการที่เรามี เราสามารถส่งคืน AP_REP ที่อิงตามคีย์เซสชันบริการที่เราเลือก และ QRadar จะยอมรับ
2. กำหนดค่า LDAPS แล้ว ในกรณีนี้ เราไม่สามารถส่งคืนคำตอบในนามของ DC ได้ เนื่องจากมีการใช้ TLS เพื่อรับรองความถูกต้องของ DC ซึ่งถือว่าใบรับรองได้รับการกำหนดค่าที่ฝั่ง QRadar

การปลอมแปลงการตรวจสอบสิทธิ์ Kerberos/SASL/LDAPS สำหรับ QRadar

ก่อนที่จะเลิกใช้ตัวเลือกที่ 2 เราสังเกตเห็นพฤติกรรมแปลก ๆ ดังต่อไปนี้ หากเรากำหนดค่าที่อยู่ IP เป็น URL ของเซิร์ฟเวอร์ การรับรองความถูกต้องจะยังคงใช้งานได้ ตามทฤษฎีแล้ว การตรวจสอบสิทธิ์ด้วยที่อยู่ IP ไม่ควรทำงานเพราะ Kerberos ไม่อนุญาตให้มีการรับรองความถูกต้องของที่อยู่ IP เว้นแต่จะมีการกำหนดค่า SPN อย่างชัดเจน
เมื่อส่ง TGS_REQ QRadar จะขอตั๋วไปที่ ldap/ เนื่องจาก DC ไม่มีชื่อหลักบริการ (SPN) ตามชื่อนั้น จึงส่งกลับข้อผิดพลาด KRB_ERR_S_PRINCIPAL_UNKOWN ตามโปรโตคอล Kerberos QRadar ควรจะปฏิเสธการตรวจสอบ ณ จุดนี้ อย่างไรก็ตาม การจับภาพเครือข่ายเผยให้เห็นว่าคำขอ LDAP ถูกเปิดแม้ว่าจะเกิดข้อผิดพลาดก็ตาม และ QRadar จะรีเซ็ตทันที จากนั้นผู้ใช้สามารถเข้าสู่ระบบได้ เราสรุปได้ว่า QRadar ถือว่าการรับรองความถูกต้องสำเร็จก่อนที่การแลกเปลี่ยนแอปพลิเคชัน Kerberos จะเสร็จสมบูรณ์ สามารถใช้ประโยชน์ได้ง่าย ในฐานะผู้โจมตี เราสามารถส่ง KRB_ERR_S_PRINCIPAL_UNKOWN ได้ทันทีหลังจากปลอมแปลง AS_REP และเราสามารถทำให้ QRadar ยอมรับการยืนยันตัวตนด้วยรหัสผ่านที่เราเลือกได้ การโจมตีแสดงไว้ด้านล่าง

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

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

การแสวงหาผลประโยชน์

ตอนนี้เราทราบแล้วว่า QRadar มีความเสี่ยง เราจึงจำลองการโจมตีโดยเปลี่ยนเส้นทางการรับส่งข้อมูลระหว่าง QRadar และ KDC (ในกรณีนี้คือตัวควบคุมโดเมน) บนพอร์ต 88 (พอร์ต Kerberos) ไปยัง Windows Server ของเราเอง เราตั้งค่าโดเมนปลอมบนเซิร์ฟเวอร์ windows และตรวจสอบว่ามีผู้ใช้ที่มี UPN เดียวกันกับผู้ดูแลระบบ QRadar ในโดเมนจริง เรากำหนดค่ารหัสผ่านของผู้ใช้นั้นเป็น “1” ในโดเมนปลอม

จากนั้นเราลองสถานการณ์ต่อไปนี้:
– เข้าสู่ระบบปกติ (ไม่ถูกเบี่ยงเบนการจราจร) – เราจัดการเพื่อเข้าสู่ระบบด้วยรหัสผ่านเดิมของผู้ดูแลระบบตามที่คาดไว้ เมื่อลองใช้รหัสผ่าน “1” การเข้าสู่ระบบล้มเหลว
– การเข้าสู่ระบบด้วยทราฟฟิกที่โอนไปยัง DC ปลอมของเรา – การเข้าสู่ระบบด้วยรหัสผ่านเดิมของผู้ดูแลระบบล้มเหลว แต่การเข้าสู่ระบบด้วยรหัสผ่าน “1” ใช้งานได้

การลดผลกระทบของ IBM

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

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

การป้องกันและบรรเทาสาธารณภัย

ขั้นตอนการบรรเทาผลกระทบสำหรับผู้เชี่ยวชาญด้านความปลอดภัย

1. สลับการรับรองความถูกต้องใน QRadar ของคุณจาก Kerberos ไปยัง LDAPS
2. อัปเกรด QRadar ของคุณเป็นเวอร์ชันคงที่
3 อัปเดตของคุณ Silverfort นโยบายสำหรับ QRadar ตามนั้น
4. ตรวจสอบการรับรองความถูกต้อง Kerberos ของคุณอย่างต่อเนื่อง ค้นหาทรัพยากรที่ขอ AS_REQ เท่านั้น หากไม่มี TGS_REQ แสดงว่าเป็นสัญญาณสีแดง
5 ใช้ Silverfortเครื่องมือโอเพ่นซอร์สของ เพื่อค้นหาบันทึกการรับรองความถูกต้องสำหรับบริการที่ไม่ได้ร้องขอตั๋วบริการ
6. ดูคำแนะนำสำหรับนักพัฒนาซอฟต์แวร์สำหรับแอปพลิเคชันที่พัฒนาขึ้นภายในที่ใช้ Kerberos และระบบที่คุณกำหนดค่าด้วยตัวเอง

ในฐานะนักพัฒนา

เราขอแนะนำสองสามขั้นตอนเพื่อให้แน่ใจว่าโซลูชันของคุณไม่เสี่ยงต่อการปลอมแปลง KDC:
1. ตรวจสอบว่าการใช้งาน Kerboros ต้องใช้รหัสผ่านหรือแท็บคีย์: ในการตรวจสอบ DC คุณต้องใช้ความลับที่ใช้ร่วมกันบางประเภท หากโซลูชันของคุณไม่เปิดใช้งานการกำหนดค่าไฟล์แท็บคีย์ หรือ บัญชีบริการ รหัสผ่าน แอปพลิเคชันมีความอ่อนไหวต่อการปลอมแปลง KDC อย่างแน่นอน
2. เรียกใช้ Wireshark – ใช้ Wireshark เพื่อดูว่าคำขอ Kerberos ใดถูกส่งไปในระหว่างการตรวจสอบสิทธิ์ หากไม่มี TGS_REQ แสดงว่าเป็นสัญญาณสีแดง
3. หากคุณต้องการใช้โปรโตคอลการตรวจสอบสิทธิ์ด้วยตัวคุณเอง คุณต้องปฏิบัติตามโปรโตคอล RFCs อย่างขยันขันแข็ง เราขอแนะนำให้ใช้เส้นทางที่ง่ายกว่าและใช้โปรโตคอลเหล่านี้ที่มีอยู่
4. ใช้ไลบรารีของบุคคลที่สามอย่างเหมาะสม – ไลบรารีของบุคคลที่สามบางไลบรารีต้องการการกำหนดค่าเฉพาะเพื่อหลีกเลี่ยงการปลอมแปลง KDC ตัวอย่างเช่น ไลบรารีทั่วไปที่ใช้สำหรับ Kerberos ที่เรียกว่า pam-krb3 จะต้องมีการกำหนดค่าแท็บคีย์เพื่อให้ทำงานได้อย่างถูกต้อง นี่คือย่อหน้าที่เกี่ยวข้องจากเอกสาร (https://github.com/rra/pam-krb5/blob/master/README.md)

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

พื้นหลัง

ภาพรวมของพิธีสาร Kerberos

โปรโตคอลการตรวจสอบสิทธิ์ Kerberos ได้รับการพัฒนาในปี 1980 โดย Steve Miller และ Clifford Neuman อนุญาตให้ลงชื่อเพียงครั้งเดียว (SSO) ในเครือข่ายที่มีการจัดการและเครือข่ายนั้น Active Directory การใช้งาน (AD) ได้เปลี่ยนให้เป็นโปรโตคอลการตรวจสอบสิทธิ์หลักสำหรับสภาพแวดล้อมภายในองค์กร
โปรโตคอลประกอบด้วยการแลกเปลี่ยนสามรายการเพื่อให้การรับรองความถูกต้องร่วมกันสำหรับผู้ใช้และเซิร์ฟเวอร์ที่เข้าถึง เมื่อผู้ใช้เข้าสู่ระบบ พวกเขาจะป้อนข้อมูลประจำตัวและการแลกเปลี่ยนบริการรับรองความถูกต้อง (AS) จะเกิดขึ้น ผู้ใช้จะได้รับ Ticket Granting Ticket (TGT) ซึ่งภายหลังจะใช้เพื่อรับตั๋วสำหรับบริการเฉพาะระหว่าง Ticket Granting Service (TGS) Exchange จากนั้นตั๋วจะถูกใช้ระหว่างการแลกเปลี่ยนไคลเอนต์/เซิร์ฟเวอร์เพื่อยืนยันตัวตน:

1. บริการรับรองความถูกต้อง (AS) Exchange

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

2. บริการแลกเปลี่ยนตั๋ว (TGS)

เมื่อผู้ใช้พยายามเข้าถึงบริการในเครือข่าย ผู้ใช้จะส่ง TGS_REQ ไปยังฟังก์ชัน Ticket Granting Server (TGS) ของ KDC ข้อความนี้เข้ารหัสด้วยคีย์เซสชันการเข้าสู่ระบบ ซึ่งได้รับระหว่าง AS Exchange TGS_REQ ได้รับการตรวจสอบโดย TGS ซึ่งจะส่งคืน TGS_REP TGS_REP ประกอบด้วยคีย์เซสชันบริการและตั๋วบริการ ซึ่งเข้ารหัสด้วยคีย์หลักของเซิร์ฟเวอร์ที่โฮสต์บริการ มาสเตอร์คีย์ของเซิร์ฟเวอร์ในระบบที่ใช้ Unix ได้รับการกำหนดค่าในไฟล์ที่เรียกว่าไฟล์แท็บคีย์ มาสเตอร์คีย์ของเซิร์ฟเวอร์ในเซิร์ฟเวอร์สมาชิกได้มาจากรหัสผ่านของบัญชีคอมพิวเตอร์ TGS Exchange แสดงไว้ด้านล่าง

3. การแลกเปลี่ยนไคลเอ็นต์/เซิร์ฟเวอร์

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

โปรโตคอลป้องกันการปลอมแปลง

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

KDC Spoofing คืออะไร?

ในปี 2000 Dug Song รายงานก ความอ่อนแอ ที่ส่งผลต่อโปรโตคอล Kerberos (เพลง Dug.2000. ช่องโหว่ Kerberos KDC Spoofing 28 สิงหาคม).
เขาพบว่าการใช้งานและการกำหนดค่าบางอย่างของไคลเอนต์ Kerberos ไม่สามารถดำเนินการแลกเปลี่ยนไคลเอ็นต์/เซิร์ฟเวอร์ได้ และอนุญาตให้มีการรับรองความถูกต้องตามความสำเร็จของการแลกเปลี่ยนก่อนหน้านี้ น่าเสียดายที่พฤติกรรมนี้ไม่ปลอดภัย และผู้โจมตีสามารถใช้ประโยชน์ได้ ผู้โจมตีที่สามารถจี้การสื่อสารระหว่างไคลเอ็นต์และ DC ได้ สามารถทำตามขั้นตอนต่อไปนี้:
1. สร้าง KDC ปลอม
2. รับชื่อผู้ใช้ที่ได้รับอนุญาตให้เข้าถึงบริการที่คุณต้องการโจมตี
3. สร้างผู้ใช้ใน KDC ปลอมด้วยรหัสผ่านที่ผู้โจมตีเลือก สำหรับการสาธิต ให้เรียกรหัสผ่านนี้ว่า ”1”
4. รับรองความถูกต้องของบริการด้วยชื่อผู้ใช้และรหัสผ่านที่ได้รับ "1"
5. จี้การสื่อสารจากไคลเอนต์ไปยัง DC และโอนไปยัง KDC ปลอม
6. ระหว่าง AS Exchange ให้ส่งคืน AS_REP ที่สอดคล้องกับรหัสผ่าน ”1” คีย์ KDC ปลอม และคีย์เซสชันการเข้าสู่ระบบปลอม
7. ระหว่างการแลกเปลี่ยน TGS ให้ส่งคืน TGS_REP ใดๆ
8. ลูกค้าจะยอมรับการรับรองความถูกต้องโดยไม่ต้องทำการแลกเปลี่ยนแอปพลิเคชัน

การโจมตีด้วยการปลอมแปลงของ KDC ถือว่าผู้โจมตีสามารถจี้ทราฟฟิกที่เข้าและออกจาก KDC และตอบโต้ในนามของ KDC ได้ สามารถทำได้โดยใช้เทคนิคต่างๆ ตัวอย่างเช่น หากผู้โจมตีอยู่ในส่วนเครือข่ายทางกายภาพเดียวกันกับไคลเอนต์ ก็สามารถทำการโจมตีด้วยการปลอมแปลง ARP ตามที่ระบุไว้ใน Network Security Hacks (Lockhart 2007). อีกวิธีหนึ่งที่เป็นไปได้คือเข้าควบคุมอุปกรณ์เครือข่าย เช่น สวิตช์หรือเราเตอร์ และควบคุมการสื่อสารจากที่นั่น