Diamond Ticket ו־Bronze Bit

שינוי TGT אמיתי מתחת לרדאר וניצול Constrained Delegation גם על Protected Users.

Diamond Ticket — תיאוריה

ב־ בונים מהאפס עם מפתח ה־KRBTGT ו־PAC מומצא. הבעיה: ה־PAC המומצא חסר פרטים אמיתיים ולכן קל יותר לזיהוי.

ב־ לא בונים כלום — לוקחים אמיתי ולגיטימי של משתמש קיים, מפענחים אותו עם מפתח ה־KRBTGT, משנים את ה־PAC (מוסיפים קבוצות, SIDHistory, הרשאות) ומצפינים בחזרה. מבחוץ זה נראה בדיוק כמו TGT רגיל — אותם שדות, אותן חתימות.

תוצאה: התוקף מלוטש הרשאות של Admin תוך שימוש בזהות וב־ לגיטימי של משתמש רגיל.

שתי עמודות: משמאל Golden Ticket — בניית TGT מהאפס עם PAC מומצא, קל יותר לזיהוי. מימין Diamond Ticket — פענוח TGT אמיתי, שינוי PAC והצפנה מחדש, נראה לגיטימי. סיבוב KRBTGT כפול מבטל את שניהם.

בקצרה ובפשטות

Golden Ticket בונה TGT מאפס עם PAC מומצא; Diamond Ticket משנה TGT אמיתי קיים.
Diamond נראה לגיטימי יותר — אותם שדות ואותן חתימות.
Bronze Bit עוקף הגבלת delegation על חשבונות Protected Users.
סיבוב KRBTGT כפול מבטל גם Golden וגם Diamond.

דוגמה מהחייםאחרי חשד לפריצה, סובבו את KRBTGT פעמיים ברווח של מספר שעות. כל TGT שנוצר או שונה עם המפתח הישן הופך ללא־תקף מיד.

Bronze Bit (CVE-2020-17049) — תיאוריה

ה־KDC אמור לסרב ל־S4U2Proxy עבור חשבונות המסומנים "Account is sensitive and cannot be delegated" או השייכים ל־Protected Users. ההגנה נשענת על ה־KDC שבודק את הדגל ועל חתימת ה־PAC.

: התוקף שולף hash של חשבון השירות המקבל ומדלג על בדיקת החתימה — מגיש בקשה עם חתימה «מתוקנת», וה־KDC מקבל אותה גם עבור חשבון מוגן. חשבון שאמור להיות בלתי ניתן ל־delegation — ניתן לכך בפועל.

פרקטיקה — מעבדה בלבד

# Diamond Ticket עם Rubeus (מבוסס על TGT קיים)
Rubeus.exe diamond /krbkey:<KRBTGT_AES_KEY> /tgtdeleg /show /ptt

# או עם מפתח RC4
Rubeus.exe diamond /rc4:<KRBTGT_RC4> /user:victim /domain:corp.local /ptt

powershell

# Bronze Bit נגד חשבון Protected Users
Rubeus.exe s4u /user:svc_web /rc4:<svc_web_hash> \
  /impersonateuser:Administrator \
  /msdsspn:http/app.corp.local /ptt /bronzebit

powershell

זיהוי (Detection)

4768 / 4769 — השוואת lifetime ו־encryption type: לעיתים נוצר עם RC4 במקום AES בניגוד למדיניות הדומיין.
חריגה ב־PAC: קבוצות או SIDHistory שלא קיימים בחשבון המקורי — נתפס בלוגים בצד היישום (4624 Type 3 עם PAC מורחב).
S4U2Proxy עבור חשבונות sensitive — אמור להיות אפס; כל אירוע = חשד ל־.
קורלציה: svc_web פונה ל־KDC ב־S4U עבור Administrator דקות אחרי בקשת hash — דפוס חשוד.

מיטיגציה

סיבוב כפול של מפתח KRBTGT (בכל חשד ל־compromise) — הופך את כל ה־Diamond/Golden Tickets ללא־תקפים.
מזעור אטאקה־סרפייס של delegation: הסירו , עברו ל־ בלבד.
הגנה על KRBTGT ו־DCs — Tier 0 מלא.
Protected Users עדיין שווה: דורשת הרשאות מוקדמות על השירות; זה מצמצם את המקום בו היא אפשרית.
פאץ' (נובמבר 2020 ואילך) + מדיניות KrbtgtFullPacSignature.