*****โดย ยอฟ อิลลิน 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 ทำงานได้ ควรมีสามสิ่งต่อไปนี้:
-
- ผู้ใช้รับรองความถูกต้องกับเซิร์ฟเวอร์
- เซิร์ฟเวอร์รับรองความถูกต้องกับลูกค้า
- KDC รับรองความถูกต้องกับเซิร์ฟเวอร์
เห็นได้ชัดว่าการพิสูจน์ตัวตน KDC ไปยังเซิร์ฟเวอร์มักถูกมองข้าม อาจเป็นเพราะต้องการให้ข้อกำหนดการกำหนดค่าซับซ้อน อย่างไรก็ตาม หาก KDC ไม่รับรองความถูกต้องกับเซิร์ฟเวอร์ ความปลอดภัยของโปรโตคอลจะถูกบุกรุกโดยสิ้นเชิง ทำให้ผู้โจมตีที่จี้การรับส่งข้อมูลในเครือข่ายสามารถตรวจสอบความถูกต้องกับ QRadar ด้วยรหัสผ่านใดก็ได้ แม้กระทั่งรหัสผ่านที่ไม่ถูกต้อง
สำหรับคำศัพท์และภูมิหลังของ Kerberos เกี่ยวกับวิธีการทำงานของการโจมตีด้วยการปลอมแปลง KDC โปรดดูที่ส่วนท้ายของโพสต์บล็อกนี้
เราค้นพบช่องโหว่ใน QRadar ได้อย่างไร
การเข้าถึง QRadar ของผู้ดูแลระบบควรได้รับการปกป้องด้วยการรับรองความถูกต้องที่รัดกุม เพื่อป้องกันการเข้าถึงโดยไม่ได้รับอนุญาตและการดัดแปลงระบบ การใช้การรับรองความถูกต้อง AD เป็นตัวเลือกยอดนิยม:
เมื่อผู้ดูแลระบบตรวจสอบสิทธิ์ QRadar จะใช้พารามิเตอร์จำนวนหนึ่งเพื่อตรวจสอบสิทธิ์ผู้ดูแลระบบ (ดูภาพรวมด้านล่างของคู่มือการใช้งานที่นำมาจาก Good Farm Animal Welfare Awards). ประการแรก 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). อีกวิธีหนึ่งที่เป็นไปได้คือเข้าควบคุมอุปกรณ์เครือข่าย เช่น สวิตช์หรือเราเตอร์ และควบคุมการสื่อสารจากที่นั่น