AS-REP Roasting (T1558.004)

AS-REP roasting היא מתקפת Kerberos נגד חשבונות Active Directory שמוגדרים עם "Do not require Kerberos preauthentication". מכיוון שהחשבון פטור, בקר התחום מחזיר AS-REP שמכיל חומר מוצפן במפתח של החשבון עצמו, והתוקף מפצח אותו offline. MITRE ATT&CK מסווגת אותה כ-T1558.004, תחת Credential Access.

חפשו את הטכניקה הזו ותיתקלו בשתי טענות על אותו מסך. הראשונה אומרת שהמתקפה שקטה, בלי לייצר failed logons על בקר התחום. השנייה אומרת לעקוב אחרי Event ID 4768 עם pre-authentication type של 0. רק אחת מהן יכולה להיות התמונה המלאה.

העמוד הזה מיישב את זה. הוא מכסה מה החילופי הודעות באמת מייצרים, מה צריך להפעיל לפני שכל זה מגיע ללוגים שלכם, ולמה האינדיקטור היחיד שרוב ההנחיות ממליצות עליו קשור לברירת מחדל של Windows ש-Microsoft מפסיקה בהדרגה עד 2026. הערך של MITRE ל-T1558.004 נמצא בגרסה 1.2, עודכן לאחרונה ב-24 באוקטובר 2025, והטקטיקה שלו היא Credential Access.

הסבירו לי כאילו אני בן 10

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

איך הבקשה והתשובה באמת עובדות

Kerberos pre-authentication קיים בדיוק כדי לעצור את זה. התיאור של MITRE עצמה ישיר: "Preauthentication offers protection against offline Password Cracking." בזרימה הרגילה, לקוח שולח Authentication Server Request, או AS-REQ, שנושא timestamp מוצפן עם ה-hash של סיסמת המשתמש. בקר התחום מנפיק את ה-Authentication Server Response, ה-AS-REP, רק אם הוא מצליח לפענח את ה-timestamp.

כשמפעילים את דגל הפטור, החצי הראשון של החילופים נעלם. ה-AS-REQ מגיע בלי ה-timestamp המוצפן, ובקר התחום עונה בכל זאת ומחזיר AS-REP שנתוני הכרטיס שלו, בניסוח של MITRE, "may be encrypted with an insecure algorithm such as RC4". שום דבר לא שבור. ה-directory עושה בדיוק מה שהוגדר לו לעשות.

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

למה ההגדרה בכלל קיימת

הדגל אינו מחדל, ומנהל מערכת שיש לו אותו מופעל בדרך כלל יורש החלטה ולא עושה טעות. מיטיגציית ה-audit של MITRE קובעת ש-"Kerberos preauthentication is enabled by default" וש-"older protocols might not support preauthentication". Microsoft ספציפית יותר. בתיעוד שלה לקוד התוצאה 0x19, KDC_ERR_PREAUTH_REQUIRED, היא מסבירה שהשגיאה "often occurs in UNIX interoperability scenarios. MIT-Kerberos clients do not request pre-authentication when they send a KRB_AS_REQ message."

שני מקורות ראשוניים, סיבה אחת. על אובייקט החשבון ההגדרה מופיעה כביט userAccountControl בשם DONT_REQ_PREAUTH, הקסדצימלי 0x400000, שמפרט הפרוטוקול של Microsoft מגדיר כמשמעות שהחשבון "is not required to present valid preauthentication data".

האם AS-REP roasting באמת לא משאיר עקבות?

הטענה הזו מעצבת איך צוותים מתעדפים את הממצא, ולכן היא זו שצריך לבדוק. ה-AI Overview של Google קובע שהמתקפה "generates zero failed login logs on the domain controllers", והתוצאה האורגנית השלישית נושאת את הכותרת "How AS-REP Roasting Steals Passwords Without a Trace".

הטענה הראשונה נכונה. השנייה לא שורדת מגע עם תיעוד האירועים של Microsoft עצמה.

Event 4768 "generates every time Key Distribution Center issues a Kerberos Ticket Granting Ticket (TGT)", והוא "generates only on domain controllers". Microsoft מוסיפה ש-"if TGT issue fails then you will see Failure event with Result Code field not equal to 0x0". קוראים את אלה יחד והתיקון כותב את עצמו. Roast אינו failed logon, כי שום דבר לא נכשל. התוקף שאל שאלה שה-directory מוגדר לענות עליה, ובקר התחום ענה. האירוע נרשם כהצלחה.

אז הפיצול אינו בין גלוי לסמוי. הוא בין שני חצאים של המתקפה:

• הבקשה נרשמת. כל AS-REP שמונפק עבור אחד מחשבונות הפטור האלה מייצר אירוע עם שדה pre-authentication type בערך 0, שטבלת Microsoft עצמה מגדירה כ-"Logon without Pre-Authentication".
• הפיצוח לא נרשם. הוא קורה על חומרה שאינה שלכם, מול קובץ שאינכם רואים, בלי שעון ובלי אירוע בשום מקום בסביבה שלכם.

התנאי המוקדם שאף אחד לא מציין

שום דבר מזה לא מגיע ללוגים שלכם מעצמו. האירועים האלה מגיעים מתת-הקטגוריה Audit Kerberos Authentication Service, ש-"determines whether to generate audit events for Kerberos authentication ticket-granting ticket (TGT) requests", וההמלצה של Microsoft לבקרי תחום היא Success auditing, עם ההערה הכנה לידה: "Event volume: High on Kerberos Key Distribution Center servers."

צוות שמבצע audit רק ל-Failure בתת-הקטגוריה הזו לא יראה כלום, וצוות שמחפש failed authentications כראיה ל-AS-REP roasting מחפש בזרם הלא נכון.

איך מזהים AS-REP roasting

MITRE מפרסמת אסטרטגיית זיהוי לטכניקה הזו, DET0113, עם analytic יחיד, AN0316. קראו אותו על מה שהוא באמת צופה, כי זה לא תמיד מובן מאליו: כאן ה-analytic צופה בשכבה שעליה המתקפה מתרחשת. הוא מתאר ניטור של "Kerberos AS-REQ/AS-REP authentication patterns where preauthentication is disabled (Event ID 4768 with Pre-Auth Type 0)", מתאם את הבקשות האלה עם פעילות service ticket ב-Event ID 4769, ומסמן "requests using weak RC4 encryption (etype 0x17)".

שום דבר בעמוד הראשון של אף אחד משני מנועי החיפוש הגדולים לא מזכיר את האסטרטגיה הזו או את ה-analytic הזה.

הדגל לא רק מורש

השורה האחרונה היא זו שרוב ההנחיות מדלגות עליה, והיא משנה את צורת הבעיה. זו לא רק קונפיגורציית legacy שמנקים פעם אחת. Event 4738 מופעל בכל פעם שאובייקט משתמש משתנה, ו-Microsoft מציינת את דגל ה-pre-authentication בין שינויי החשבון ששווה לנטר. כלל הזיהוי שפרסמה Elastic מציג את תרחיש היריב ישירות: תוקף "with GenericWrite/GenericAll rights over the account can maliciously modify these settings to perform offline password cracking attacks such as AS-REP roasting".

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

בדקו מה הכללים שלכם קוראים

מאז ה-cumulative update של 14 בינואר 2025, Event 4768 ב-Windows Server 2016 ואילך נושא שדות נוספים, כולל סוגי ההצפנה הנתמכים של החשבון והמפתחות הזמינים שלו. כלל שנכתב לפני התאריך הזה מפרסר אירוע קטן יותר מזה שבקרי התחום שלכם רושמים עכשיו.

האינדיקטור שכולם ממליצים עליו יוצא משימוש

שאלו את השטח איך לזהות את זה בביטחון גבוה, והתשובה היא encryption type 0x17. Semperis, המתחרה המפורט ביותר על המונח, ממליצה בדיוק על השילוב הזה, והתשובה שמייצר Bing חוזרת עליו.

האינדיקטור הזה מאבד את חדותו, לפי לוח זמנים מפורסם.

• 8 בנובמבר 2022: בתגובה ל-CVE-2022-37966, עדכוני Windows שינו את ברירת המחדל של סוג הצפנת Kerberos "to use Advanced Encryption Standard (AES)-SHA1 instead of RC4 for accounts where an encryption type wasn't explicitly set".
• Windows Server 2025: בקרי תחום "don't issue RC4 Ticket Granting Tickets".
• 14 באפריל 2026: עדכונים משנים את ברירת המחדל של ה-KDC עבור DefaultDomainSupportedEncTypes ל-"AES-SHA1 only: 0x18".
• יולי 2026: עדכוני Windows "programmatically enable Enforcement Phase", ומצב audit מוסר.

שלבי 2026 יושבים תחת CVE-2026-20833, ש-Microsoft מטפלת בו כפריסה מדורגת ולא כתיקון בודד: שלב פריסה ראשוני מינואר 2026, ואז enforcement.

NVD רושם אותו כ-CWE-327, ציון בסיס 5.5, וקטור AV:L, ומתואר כמאפשר ל-"an authorized attacker to disclose information locally". זו אינה פגיעות מרוחקת ללא הזדהות, ואין לתאר אותה ככזו.

שום דבר שבניתם לא הפסיק לעבוד

היקף השינוי הזה חשוב לא פחות מהתאריכים. השינוי של Microsoft משנה את סוגי ההצפנה הנתמכים המשוערים לחשבונות שאין להם ערך מפורש ב-msDS-SupportedEncryptionTypes, ומסמך הפריסה ממסגר אותו סביב הנפקת כרטיסים לחשבונות שירות. הוא לא מסיים את AS-REP roasting, והוא לא ממיר כל תשובה ל-AES.

לצורכי זיהוי, הקריאה המעשית צרה. כלל שמבוסס על pre-authentication type 0 לא מושפע, כי השדה הזה מתאר את קונפיגורציית החשבון, לא את הקריפטוגרפיה שלו. מה שנשחק הוא משקל הביטחון של סעיף ה-RC4: ככל שהסביבה עוברת ל-AES, 0x17 מופיע פחות, כך שהיעדרו מפסיק להיות ראיה ששום דבר לא קרה. התייחסו לזה כהסקה צופה פני עתיד מלוח הזמנים שפרסמה Microsoft, לא כתצפית מדודה, ובדקו מחדש את ההנחה בסביבה שלכם.

מה קובע אם AS-REP שנתפס באמת משנה

שני משתנים מפרידים בין ממצא לאירוע, ואת שניהם אפשר לבדוק היום אחר הצהריים.

משתנה ראשון: סוג ההצפנה

msDS-SupportedEncryptionTypes הוא מאפיין Active Directory ש-"denotes the encryption types the account supports", וכשהוא לא מוגדר ה-KDC נופל לברירת המחדל של ה-domain. המיטיגציה של MITRE לטכניקה הזו היא "enable AES Kerberos encryption (or another stronger encryption algorithm), rather than RC4, where possible", וזה אותו מנוף בניסוח של בקרה.

מאחורי המספר הזה יושבת אינטראקציה לא נוחה, והיא הסקה ולא עובדה. Microsoft מתעדת שמפתחות AES "are generated during password sets and password changes", והם זמינים כשרמת הפונקציונליות של ה-domain היא 2008 ומעלה "and accounts have had at least one password rotation". החשבונות שסביר ביותר שיישאו דגל תאימות ישן הם לעתים קרובות גם החשבונות שסביר פחות שביצעו רוטציה לסיסמה מאז שהוגדרה. אמתו את זה לכל חשבון במקום להניח.

משתנה שני: הסיסמה

ההנחיה של MITRE ספציפית: "Ensure strong password length (ideally 25+ characters) and complexity for service accounts and that these passwords periodically expire", והיא מצביעה על Group Managed Service Accounts כתשובה הטובה יותר במקומות שבהם הם מתאימים.

אף אחד משני המשתנים לא הופך את החשבון לבטוח. שניהם משנים את העלות של החצי ה-offline, שהוא החצי היחיד שאינכם יכולים לצפות בו.

האם הפעלת pre-authentication מספיקה?

העצה הסטנדרטית נכונה, והיא ישנה בהרבה מהכלים. RFC 4120, מפרט Kerberos V5 שפורסם ביולי 2005, מתאר את המתקפה הזו בשיקולי האבטחה שלו. בלי pre-authentication נדרש, הוא אומר, "the availability of the response encrypted in the client's secret key provides the attacker with ciphertext that may be used to mount brute force or dictionary attacks to decrypt the credentials, by guessing the user's password". המסקנה שלו היא העצה שההסברים חוזרים עליה: "it is strongly encouraged that Kerberos realms require the use of pre-authentication."

ואז מגיע המשפט הבא, שאף אחד לא מצטט:

"Even with pre-authentication, attackers may try brute force or dictionary attacks against credentials that are observed by eavesdropping on the network."

המשך מ-2011 בוטה עוד יותר. RFC 6113, שנכתב בשיתוף מהנדס Microsoft, מדרג pre-authentication מבוסס timestamp מוצפן כמנגנון ש-"ameliorates the situation somewhat by requiring that an attacker observe a successful authentication", ואז מגדיר מה שהוא רואה כתשובה החזקה יותר: Kerberos FAST, ש-"provides a tool to significantly reduce vulnerability to offline dictionary attacks".

FAST, armoring, ומה זה עולה

Windows מממשת FAST כ-Kerberos armoring, והוא כבר נמצא בסכמת האירועים שלכם. Pre-authentication type 138, PA-ENCRYPTED-CHALLENGE, מוגדר על ידי Microsoft כ-"logon using Kerberos Armoring (FAST)", והנחיית הניטור שלה ל-4768 כבר אומרת למנהלים לעקוב אחרי ערכים שאינם 138 במקומות שבהם armoring אמור להיות אוניברסלי.

להגדרה המחמירה יש שיניים וגם חשבון. במדיניות ה-KDC, האפשרות "Fail unarmored authentication requests" גורמת לבקר התחום לדחות "unarmored Kerberos messages". שלוש עלויות מגיעות איתה, כולן מתועדות על ידי Microsoft באותו מקום:

• לקוחות unarmored מפסיקים לעבוד. "Client computers which don't support Kerberos armoring will fail to authenticate to the domain controller."
• האפשרויות המחמירות דורשות Windows Server 2012 domain functional level. מתחת לזה, בקרי תחום מתנהגים כאילו נבחרה האפשרות המתירנית.
• שני הקצוות חייבים להיות מוגדרים, וזה לא בחינם. גם מדיניות צד הלקוח צריכה להיות מופעלת, ו-armoring מוסיף עיבוד על בקר התחום.

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

AS-REP roasting מול kerberoasting

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

דמיון המשפחה אמיתי: שתיהן תת-טכניקות של T1558, שתיהן יושבות תחת Credential Access, ו-MITRE עדכנה את שני העמודים באותו יום, 24 באוקטובר 2025. אבל תנאי הכניסה שונים מספיק כדי שכיסוי של אחת לא אומר כלום על הכיסוי של השנייה. ל-Kerberoasting מגיע עמוד משלו, והוא יקבל אחד.

מה אנחנו לא יודעים

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

אין נתון שכיחות מפורסם. אין חלק מדוד של directories שנושאים לפחות חשבון אחד עם pre-authentication כבוי, בצורה שניתן לצטט, עם גודל מדגם ושיטה מצורפים. מי שמצטט אחד מצטט רושם של ספק. אם נרטיב הסיכון שלכם צריך מספר, השתמשו בספירה שלכם מה-audit שלכם.

יש מקור ממשלתי ראשוני שהמאמר הזה לא נשען עליו. שש סוכנויות, בראשות Australian Signals Directorate ובהן CISA ו-NSA, פרסמו "Detecting and Mitigating Active Directory Compromises" ב-25 בספטמבר 2024, שמכסה "the 17 most common techniques used by adversaries and malicious actors to compromise Active Directory". המסמך עצמו לא היה זמין מהמקום שבו בוצע המחקר הזה, ולכן שום דבר כאן לא נלקח ממנו. קראו אותו ישירות.

מגבלות הזיהוי שצוינו למעלה שייכות לאותה רשימה: תת-קטגוריית ה-audit חייבת לרשום Success, סעיף ה-RC4 נחלש ככל שהסביבות עוברות ל-AES, והחצי ה-offline של המתקפה אינו ניתן לצפייה מעצם התכנון (by design).

שאלות נפוצות

האם AS-REP roasting זהה ל-password spraying? לא. Password spraying בודק ניחושים מול ה-directory, מה שמייצר failed authentications ויכול להפעיל נעילות. כאן שום דבר לא מנוחש מול ה-directory בכלל. הבקשה הבודדת מצליחה, וכל ניחוש אחריה קורה offline, מול חומר שנתפס, במקום שבו שום מדיניות לא חלה.

האם התוקף צריך להיות בתוך הרשת? הוא צריך להגיע לבקר תחום ולדעת שם חשבון תקף. ה-AS-REQ עצמו לא נושא credential, וזה מה שהופך את הטכניקה לזולה, אבל מניית חשבונות זכאים ביעילות כן דורשת חשבון ב-domain.

אם יש לי רק לוגים היסטוריים, אפשר לבדוק אם זה כבר קרה? כן, אם Success auditing היה מופעל עבור שירות האימות של Kerberos באותו זמן. חפשו אירועי 4768 עם pre-authentication type 0, במיוחד אשכולות שמכסים כמה חשבונות ממקור אחד. אם תת-הקטגוריה לא ביצעה audit ל-Success, הראיה מעולם לא נכתבה.

אפשר פשוט למחוק את החשבונות עם הדגל? לפעמים, אבל בררו קודם למה הדגל שם. לעתים קרובות הוא מוגדר לתאימות עם לקוחות שלא שולחים pre-authentication, אז הרצף הוא audit, שאלו למה, ואז החליטו. הסרת הדגל היא המטרה; הסרה עיוורת היא הדרך שבה אינטגרציה עובדת נשברת.

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

מה לבדוק השבוע

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

1. בצעו audit ל-directory על חשבונות עם pre-authentication כבוי. המיטיגציה של MITRE עצמה מציינת שכלי Windows סטנדרטיים מוצאים אותם, והמאפיין לחפש הוא DONT_REQ_PREAUTH.
2. אמתו שתת-קטגוריית ה-audit רושמת Success, לא Failure בלבד, על בקרי התחום. בלעדיה, שאר העמוד הזה הוא תיאוריה.
3. בחשבונות שחייבים לשמור את הדגל, בדקו את msDS-SupportedEncryptionTypes ואת מצב הסיסמה, כולל האם Group Managed Service Account יכול להחליף חשבון סטטי.
4. הגדירו התראה על הדלקת הדגל, באמצעות Event 4738, כדי שיעד שיוצר במכוון יכריז על עצמו.

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