AS-REP Roasting (T1558.004)

מתקפת AS-REP roasting היא התקפה על חשבונות Active Directory ברשת Windows שבהם אימות מקדים ב-Kerberos כבוי. ה-domain controller עונה לבקשה לחשבון כזה, גם אם היא מגיעה ממי שלא הוכיח את זהותו. מפתח שנגזר מסיסמת החשבון מגן על חלק מהתשובה הזו. התוקף מעתיק לעצמו את החלק הזה, ומנחש סיסמאות במצב לא מקוון.

תסבירו לי כמו לילד בן 10

תארו לכם בית ספר שבו המורה שומרת את קופסאות האוכל הנעולות של התלמידים. היא מחזירה לכל תלמיד את הקופסה שלו רק אחרי שהוא מוכיח מי הוא. כמה שמות ברשימה של המורה מסומנים ב"אין צורך לשאול". אז כל מי שאומר אחד מהשמות האלה מקבל את קופסת האוכל של אותו תלמיד.

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

זה בדיוק מה שקורה בחשבון שמסומן ב"אין צורך לשאול". מי שמבקש בשם חשבון כזה מקבל בחזרה תשובה נעולה, בדיוק כמו קופסת האוכל. התוקף מנחש את הסיסמה בשקט, בלי שמישהו שם לב.

איך עובד תהליך ההתחברות ב-Kerberos, ומה מוסיף לו אימות מקדים?

תהליך ההתחברות הרגיל

המערכת Active Directory מחזיקה את חשבונות המשתמשים ברשת Windows, כולל השמות והסיסמאות שלהם. domain controller הוא שרת שמפעיל את Active Directory ומאמת זהויות ברשת. על כל domain controller רץ שירות שנקרא Key Distribution Center (KDC), והוא מטפל ב-Kerberos. Kerberos הוא פרוטוקול האימות שרשתות Windows (ודומיין Active Directory) משתמשות בו כדי לאמת זהות של משתמשים ומחשבים.

כשמשתמש מתחבר, המחשב שלו פונה ל-KDC כדי להוכיח את זהות המשתמש. בתמורה הוא מקבל אישור בדמות כרטיס (ticket-granting ticket, TGT) שמאפשר לו לבקש גישה לשירותים מאוחר יותר, בלי להציג שוב את הסיסמה. בחילופי ההודעות הראשונים האלה יש שתי הודעות: ה-AS-REQ היא הבקשה של המחשב, וה-AS-REP היא התשובה של ה-KDC.

ה-AS-REP מכילה שני חלקים שמוגנים בנפרד:

• ה-TGT: החלק שלו שמוצפן מוגן בעזרת המפתח של שירות הענקת הכרטיסים, שמנפיק כרטיסים. ב-Active Directory זהו בדרך כלל המפתח של חשבון krbtgt, החשבון המובנה שה-KDC משתמש בו כדי להנפיק אותם.
• חלק מוצפן נפרד בשביל הלקוח, המחשב שמתחבר: הוא מוגן באמצעות המפתח הסודי של הלקוח, שאצל משתמש נגזר מהסיסמה שלו.

רק מי שיודע את הסיסמה אמור להיות מסוגל לפתוח את החלק של הלקוח.

מה אימות מקדים מוסיף

אימות מקדים (pre-authentication) הוא שלב נוסף שבו המחשב צריך להוכיח שהוא יודע את הסיסמה לפני שה-domain controller משיב לבקשה. הבקשה של המחשב מכילה חותמת זמן מוצפנת בעזרת סוד שמחושב מהסיסמה של המשתמש, וכך ה-domain controller יכול לבדוק שהשולח יודע את הסיסמה. MITRE מנסחת את התכלית כך: "אימות מקדים מגן מפני ניחוש לא מקוון של סיסמאות." הוא מופעל כברירת מחדל.

איך עובדת מתקפת AS-REP roasting?

מה התוקף מבקש, ומה חוזר בתשובה

המתקפה מתחילה מחשבון שבו אימות מקדים כבוי. ב-Active Directory זו הגדרה של החשבון, ו-Microsoft מתארת אותה כך: "This account doesn't require Kerberos pre-authentication for logging on."

התוקף שולח את הבקשה הראשונה בתהליך ההתחברות לאותו חשבון, אבל לא מוסיף את חותמת הזמן המוצפנת, שהיא ההוכחה. לכן ה-domain controller לא יכול לדעת מי שולח את הבקשה. מפרט הפרוטוקול (Kerberos specification, RFC 4120), תקן שה-IETF פרסמה, קובע שהשרת "פשוט שולח תשובה, בלי לדעת ובלי להתעניין אם זה אותו הצד". בחשבון רגיל התוצאה אחרת: ה-domain controller משיב בהודעת שגיאה שלפיה נדרש אימות מקדים.

למה אפשר לנחש סיסמאות על סמך התשובה

מסירת התשובה נועדה להיות בטוחה, מכיוון שהחלק שמיועד לחשבון נעול במפתח של החשבון עצמו, ורק בעל החשבון אמור להיות מסוגל להשתמש בו. הפגם הוא שהתוקף לא צריך להשתמש בו: הוא יכול להעתיק את החלק הזה ולבדוק אותו. המפרט מזהיר שהתשובה נותנת לתוקף נתונים מוצפנים שאפשר לתקוף איתם את פרטי ההזדהות, "באמצעות ניחוש הסיסמה של המשתמש". ה-TGT שבאותה תשובה מוגן במפתח אחר, כך שניחוש הסיסמה של המשתמש בודק את החלק של הלקוח, ולא מפענח את ה-TGT.

מה המשמעות של ניחוש לא מקוון

ניחוש לא מקוון (offline guessing) הוא ניסיון סיסמאות אחת אחרי השנייה על בסיס נתונים שהתוקף כבר החזיק, בלי לפנות שוב ל-domain controller. התוקף ממשיך לבדוק עד שהוא מוצא את הסיסמה שפותחת את החלק של הלקוח בתשובה. המפרט מכנה את הפעולה הזו מתקפת מילון לא מקוונת (dictionary attack), כאשר מילון הוא רשימה ארוכה של סיסמאות מועמדות: "ניסיונות חוזרים ונשנים לפענח, עם ערכים עוקבים מתוך מילון". מכיוון שהתוקף פועל על ההעתק שלו, ה-domain controller לא מעורב בשום ניחוש.

התוקף לא צריך בכלל את הסיסמה של המטרה כדי לקבל את התשובה. הוא משתמש בחלק הזה מהתשובה כדי לבדוק סיסמאות. עם זאת, הוא כן צריך לגשת ל-domain controller ולציין שם של חשבון שבו ההגדרה הזו כבויה.

למה בכלל מכבים אימות מקדים בחשבון?

כיבוי אימות מקדים בחשבון אינו פספוס של Windows. הנחיית הביקורת של MITRE אומרת שאימות מקדים מופעל כברירת מחדל. היא גם אומרת שאפשר לכבות את ההגדרה הזו, כי פרוטוקולים ישנים יותר לא בהכרח תומכים באימות מקדים. מערכת ישנה שלא מסוגלת לבצע אימות מקדים היא, אם כן, אחת הסיבות האפשריות לכך שחשבון מסוים יוגדר כחריג.

תופעה כזאת, של בקשה ראשונה שמגיעה בלי אימות מקדים, לא מוכיחה כשלעצמה שהסיבה היא מערכת ישנה. התיעוד של Microsoft אומר שלקוחות MIT Kerberos לא מבקשים אימות מקדים בבקשה הראשונה שלהם. לכן, כשההגדרה דורשת אימות מקדים, ה-domain controller משיב בשגיאה שחוזרת לא פעם בתרחישי תאימות עם מערכות UNIX. רוב הלקוחות האלה מגיבים לשגיאה ומשלימים את האימות המקדים שנדרש, ואז אפשר להתעלם מהשגיאה. אבל חלקם לא בהכרח משלימים את האימות המקדים.

תיעוד האירועים של Microsoft ברור לגבי הסיכון: כל החשבונות צריכים להשתמש באימות מקדים, חוץ מחשבונות שמוגדרים עם "Do not require Kerberos preauthentication". זו הגדרה ש-Microsoft עצמה מגדירה כסיכון אבטחתי.

מה קובע אם אפשר לשחזר את הסיסמה?

שלושה גורמים קובעים את זה:

• הסיסמה עצמה: Kerberos מעולם לא טען שהוא פותר את בעיית ניחוש הסיסמאות. המפרט קובע: "אם משתמש בוחר בסיסמה גרועה, אפשר שתוקף יבצע בהצלחה מתקפת מילון לא מקוונת". המתקפה יכולה להצליח רק אם הסיסמה האמיתית נמצאת בין הסיסמאות שהתוקף מנחש.
• האלגוריתם שמגן על החלק של הלקוח: MITRE אומרת שהנתונים בתשובה עלולים להיות מוצפנים באלגוריתם לא מאובטח כמו RC4, אלגוריתם הצפנה ישן יותר ש-Windows שומר עליו מטעמי תאימות. Microsoft אומרת ש-RC4 "משמש בדרך כלל בסביבות Windows כשחשבונות או מכשירים לא תומכים בסוגי הצפנה חזקים יותר כמו AES-SHA1". היא גם אומרת ש-RC4 "נחשב כיום לא מאובטח ונמצא בתהליך הוצאה משימוש". MITRE מונה את השימוש ב-AES, אלגוריתם הצפנה חזק יותר, במקום RC4, כשאפשר, כאחת המיטיגציות לטכניקה הזו. AES מעלה את העלות של כל ניחוש, כי מפתחות ה-AES נגזרים מהסיסמה בעזרת חישוב חזור ונשנה. לפי RFC 3962, החישוב הזה "נראה מועיל בעיקר כמכפיל למאמצי הניחוש בכוח גס של התוקף". השימוש ב-AES לא מבטל את הפגם: כשאימות מקדים כבוי, התשובה עדיין נמסרת ואפשר עדיין לבדוק אותה.
• האם לחשבון יש בכלל מפתח מהסוג החזק יותר: Microsoft מתארת חשבון משתמש שנוצר לפני שהייתה תמיכה ב-AES. אם הסיסמה שלו לא התאפסה מאז שהתמיכה נוספה, לחשבון הזה אין מפתחות AES-SHA1. החלפת הסיסמה מייצרת את המפתחות האלה. בלי מפתח AES, האלגוריתם הישן אינו בהכרח זה שבו משתמשים. Microsoft מציינת שכאשר RC4 מושבת, האימות עלול להיכשל במערכות מסוימות, כך שהתוצאה תלויה בסוגי ההצפנה שהסביבה מתירה.

מה אפשר לעשות עם סיסמה ששוחזרה?

סיסמה ששוחזרה היא אישור תקף לחשבון אמיתי. לדברי MITRE, סיסמאות ששוחזרו עלולות לאפשר שמירה על גישה (Persistence), הסלמת הרשאות (Privilege Escalation) ותנועה רוחבית (Lateral Movement), דרך הגישה לחשבונות לגיטימיים. במילים פשוטות, התוקף עלול להשתמש בחשבון כדי להמשיך ולהחזיק בגישה, להשיג הרשאות רחבות יותר ולקבל גישה למערכות נוספות. התוקף יכול להתקדם רק עד כמה שההרשאות של החשבון הזה מאפשרות.

פריצה מתועדת

הטכניקה הזו מופיעה גם בפריצות מתועדות. הניתוח של The DFIR Report עוסק בפריצת כופרה שהחלה בדצמבר 2023, והניתוח עצמו פורסם ב-26 באוגוסט 2024. לפי הניתוח, כשש שעות מתחילת הפריצה, התוקפים "ביצעו התקפות AS-REP Roasting ו-Kerberoasting נגד שניים מבין ה-domain controllers". הניתוח מתאר את AS-REP roasting כ"פעילות הגישה הראשונה לפרטי ההזדהות שביצע התוקף". הכופרה נפרסה חמישה עשר יום לאחר הגישה הראשונית.

הניתוח לא קובע שסיסמה כלשהי שוחזרה בפועל, ולכן לא ידוע מה התוקפים השיגו מהבקשות האלה. המקרה הזה מראה מתי ואיפה הטכניקה מופיעה: בשלב מוקדם, נגד ה-domain controllers, בפריצה שבהמשך כללה גם הפצת כופרה.

האם מתקפת AS-REP roasting באמת שקטה?

חלקית. הניחוש הלא מקוון לא נראה ל-domain controller, אבל הבקשה שבאה קודם היא אירוע שהוא יכול לתעד.

מה ה-domain controller מתעד

אירוע 4768 נוצר "בכל פעם ש-Key Distribution Center מנפיק Kerberos Ticket Granting Ticket (TGT)", ורק ב-domain controller. הנפקה שנכשלה מופיעה כאירוע כשל, עם קוד תוצאה שונה מ-0x0. סיסמה שגויה בשלב ההוכחה מתועדת כאירוע אחר, 4771, שנקרא "Kerberos pre-authentication failed". בקשה לחשבון בלי אימות מקדים לא מכילה הוכחה, כך שלא נכשל שום דבר בשלב הזה, וה-domain controller מנפיק את התשובה. ההנפקה הזו מתועדת כאירוע 4768 מוצלח.

אירוע 4768 גם מתעד איזו הוכחה הכילה הבקשה. הטבלה של Microsoft מבחינה בין שני מקרים שחשובים כאן:

• ב-Type 2: "a normal type for standard password authentication".
• ב-Type 0: "Logon without Pre-Authentication".

ההנחיה של Microsoft לגבי type 0 זהה לאזהרה שלמעלה: רק חשבונות שהוגדרו בכוונה בלי אימות מקדים אמורים להציג את הערך הזה. בקשה מוצלחת מסוג type 0 היא אפוא נקודת המוצא לבדיקה. זה מצריך בדיקה בהקשר (האם לחשבון הזה אימות מקדים כבוי בכוונה, ומי שלח את הבקשה?), ולא מסקנה שסיסמה שוחזרה. בפריצה שתוארה למעלה, הערת הזיהוי של הדו"ח עצמו מצביעה על אותו הדבר: "ניתן לאתר סימנים ל-AS-REP roasting על ידי חיפוש אחר windows eventID 4768 ב-domain controller של המטרה."

גם שינוי ההגדרה מתועד. אירוע 4738 נוצר בכל פעם שאובייקט משתמש משתנה, וטבלת הניטור של Microsoft מסמנת את ההגדרה "Don't Require Preauth", כשהיא מופעלת, כדבר ש"Should not be enabled for user accounts because it weakens security" (אין להפעיל את ההגדרה הזו בחשבונות משתמשים, כי היא מחלישה את האבטחה).

מה מראה השדה Ticket Encryption Type

לפי ההגדרה של Microsoft, השדה Ticket Encryption Type מציג את סוג ההצפנה שבו הוצפן ה-TGT שהונפק. המפרט מצפין בנפרד את ה-TGT ואת החלק המיועד ללקוח. לכן השדה הזה לא בהכרח מראה איך הוצפן החלק שהתוקף מנחש נגדו את הסיסמה. ערך AES בשדה הזה לא פוסל את האפשרות שמתבצעת מתקפת AS-REP roasting, וערך RC4 בו גם אינו תנאי הכרחי למתקפה. גם אסטרטגיית הזיהוי של MITRE עוקבת אחרי RC4, וזה הקשר, לא מסקנה.

איפה הזיהוי נעצר

לזיהוי יש מגבלות:

• ביקורת חייבת להיות מופעלת: האירוע קיים רק אם ה-domain controller מבצע ביקורת על בקשות אל Kerberos Authentication Service. Microsoft ממליצה להפעיל ביקורת של אירועים מוצלחים, ואומרת שהנפח הצפוי של האירועים הללו ב-domain controllers גבוה.
• הבקשה אינה הניחוש: האירוע מראה שהוגשה בקשה לחשבון בלי אימות מקדים. שום דבר באירוע הזה לא מגלה אם מישהו מנחש סיסמאות, או אם הניחוש הצליח.

המילה "שקט" מתארת נכון את הניחוש, ולא את הבקשה.

במה AS-REP roasting שונה מ-Kerberoasting?

מתקפת Kerberoasting היא טכניקה אחות של מתקפת AS-REP roasting. MITRE מסווגת את שתיהן כתת-טכניקות T1558.003 ו-T1558.004 של הטכניקה Steal or Forge Kerberos Tickets, בטקטיקת גישה לפרטי הזדהות (Credential Access). ההבדל בין שתי המתקפות הוא השלב בתהליך ה-Kerberos שבו כל אחת מתחילה.

אחרי ההתחברות, המחשב מציג את ה-TGT שלו בפני ה-KDC ומבקש כרטיס שירות. את הכרטיס הזה הוא מציג בהמשך בפני השירות שבו הוא רוצה להשתמש. מתקפת Kerberoasting מתמקדת בשלב השני הזה.

מה מקטין את הסיכון למתקפה, ואיפה הגבול של כל אמצעי הגנה?

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

• הקפידו שאימות מקדים יישאר מופעל, ובצעו ביקורת על ההגדרה: מיטיגציית הביקורת של MITRE ממליצה לדאוג שלכל החשבונות יהיה אימות מקדים במידת האפשר, ולבצע ביקורת על שינויים בהגדרה. היא מציינת שכלי הניהול הסטנדרטיים של Windows מאפשרים לקבל רשימה של החשבונות שבהם ההגדרה כבויה. כך התשובה כבר לא נמסרת לבקשה שאין בה הוכחה. המגבלה היא מקרה המערכות הישנות שהוזכר למעלה: כשמערכת ישנה לא יכולה לתמוך באימות מקדים, החשבון נשאר חשוף לניחוש הלא מקוון שתואר קודם.
• הגדירו סיסמאות שקשה לנחש: מיטיגציית הסיסמאות של MITRE מציעה סיסמאות ארוכות ומורכבות, באופן אידיאלי באורך 25 תווים ומעלה, שמתחלפות מעת לעת, והיא מתייחסת בפרט לחשבונות שמפעילים שירותים. המגבלה היא שהצעד הזה לא מפסיק את מסירת התשובה. הוא רק מקטין את הסיכוי שהסיסמה האמיתית תהיה בין הניחושים.
• השתמשו ב-AES ולא ב-RC4, כשאפשר: השימוש ב-AES מגן על החלק המיועד ללקוח בתשובה באמצעות אלגוריתם חזק יותר, ומעלה את העלות של כל ניחוש. יש לכך שתי מגבלות: ראשית, השימוש ב-AES לא מפסיק את מסירת התשובה כשאימות מקדים כבוי, כך שעדיין אפשר למצוא סיסמה חלשה. שנית, השימוש ב-AES דורש מפתחות AES. בחשבון ישן שהסיסמה שלו לא הוחלפה מאז שנוספה התמיכה ב-AES, אין מפתחות כאלה עד שמחליפים את הסיסמה.
• השתמשו בשיריון (armoring) של Kerberos, כלומר הצפנה מלאה של הודעות Kerberos וחתימה על הודעות השגיאה, שמשאירה למאזין ברשת פחות מידע לבדוק באמצעותו ניחושי סיסמה: אימות מקדים בלבד עדיין משאיר פרצה. המפרט קובע ש"גם כשיש אימות מקדים, תוקפים עשויים לתקוף פרטי הזדהות שנצפו דרך האזנה לרשת, באמצעות מתקפות brute force או מתקפות מילון". השיריון מוגדר במסגרת האימות המקדים של Kerberos (RFC 6113), שקובעת שהוא "מספק כלי שמפחית במידה משמעותית את הפגיעות למתקפות מילון לא מקוונות". Microsoft אומרת שהשיריון מצפין באופן מלא את חילופי ההודעות ב-Kerberos, וחותם על הודעות השגיאה שלו, כך שלמאזין ברשת נשאר פחות חומר לבדוק מולו ניחושים. יש לכך שתי מגבלות: עלות ותאימות. השיריון מאריך את זמן העיבוד, וכשה-domain controller מוגדר לדחות בקשות לא משוריינות, מחשבי לקוח שלא תומכים בשיריון לא מצליחים להזדהות.

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

למי שרוצה הנחיות רחבות יותר, סוכנויות מארצות הברית, בריטניה, קנדה, אוסטרליה וניו זילנד מפרסמות מדריך משותף לטיפול בפריצות נפוצות ל-Active Directory. עמוד המרכז הקנדי לאבטחת סייבר מונה את AS-REP roasting בין הפריצות שהוא מכסה, ועמוד ה-CISA מציג תאריך עדכון מ-15 בספטמבר 2026.