NTLM מול Kerberos בהדגמה — למה האימות "נופל" ל-NTLM

גם ברשת ארגונית שמתוארת כ”סביבת Kerberos”, איסוף audit logs תמיד מעלה NTLM. ומה שעולה בדרך כלל הוא אפליקציה שאמורה לתמוך ב-Kerberos.

“נפילה ל-NTLM” כאן אינה אומרת שהאימות נעצר בשגיאה; היא אומרת מעבר ל-NTLM מפני שאי אפשר להשתמש ב-Kerberos. מערכת עסקית יכולה לעבוד מצוין ובכל זאת לא להשתמש בשיטת האימות שציפיתם לה.

המאמר הזה משווה תחילה, עם דיאגרמות, במה NTLM ו-Kerberos משתמשים כחומר האימות, ושל מי כל אחד מהם מאמת את הזהות. ברגע שההבדל הזה ברור, אותו מנגנון מסביר גם למה האימות עובר ל-NTLM בהתאם לשם היעד או לסוג החשבון, וגם למה מתקפת relay ו-Pass-the-Hash עובדות.

סדר הקריאה הוא איך המנגנונים שונים → התנאים שגורמים למעבר → ההחלטות לגבי הגנה והגירה. אם המטרה שלכם היא חקירת תקלה, הפרידו קודם בין “זה עובד על NTLM” לבין “האימות עצמו נעצר”, ואחר כך השתמשו במדריך לפי מטרה בסעיף 1 כדי לעבור לסעיף 6.

הנוהל לתיעוד המצב של המערכות שלכם (הגדרת audit policies, מעקב אחרי האירועים, הסדר שבו מתקנים) מופיע במאמר הנלווה “האם ביטול NTLM יעצור את האפליקציות העסקיות שלכם?”.

1. קודם המסקנה

יש שלושה דברים לתפוס קודם: החומר שבו כל פרוטוקול מאמת, התנאים שמעבירים את האימות ל-NTLM, והמדיניות לאבטחה ולהגירה.

להבין איך המנגנונים שונים

NTLM בונה response מתוך hash; Kerberos משתמש בכרטיס שנושא את שם היעד. ה-credentials של NTLM הם שם domain, שם משתמש ו-hash חד-כיווני של הסיסמה.¹ ב-NTLMv2 משתמשים במפתח שנגזר מה-hash הזה כדי לחשב HMAC על ה-challenge של השרת, חתימת זמן, challenge מצד הלקוח ומידע על היעד (סעיף 2.2).²

Kerberos, לעומת זאת, מנפיק service ticket לפי ה-SPN — שם השירות של היעד — ובכך קובע “מי, לאיזה שירות”.³ מכאן נובעים שלושה הבדלים: mutual authentication, הפנייה ל-DC בזמן אימות חשבון domain, ו-delegation לשירותים אחרים (סעיף 5).⁴

להפריד בין נפילה לבין שגיאת אימות

“זה עובד על NTLM” ו”זה נעצר בשגיאת Kerberos” מתחילים במקומות שונים בחקירה. הסיבות העיקריות למעבר ל-NTLM הן כתובות IP מוקשחות בקוד, SPNs לא רשומים, workgroups ונתיבים שאינם מגיעים ל-DC. השאלה אם אפשר להפיק SPN משם היעד היא החשובה מכולן (סעיף 6).⁵⁶

בעיות שמתעוררות אחרי ש-Kerberos נבחר, כמו הפרש שעון, הן עניין אחר: האימות עצמו נעצר. אל תניחו שכשל מנוסה תמיד שוב עם NTLM (סעיף 6.5).⁷

לתפוס את המדיניות של אבטחה והגירה

גם עם NTLMv2 נשארות מתקפת relay ו-Pass-the-Hash. ה-relay נובע מכך שחילוף האימות אינו כובל יעד; Pass-the-Hash נובע מכך שה-hash עצמו הוא חומר האימות. סעיף 7 מכסה את התנאים שבהם כל אחד מהם עובד, כולל השאלה אם היעד דורש SMB signing או channel binding.⁸¹

NTLMv1 כבר הוסר ב-Windows 11 גרסה 24H2 וב-Windows Server 2025. NTLMv2 עדיין עובד, אבל הוא deprecated (סעיף 8).⁹ אפליקציות לא אמורות לקרוא ל-NTLM ישירות: הן צריכות להשתמש ב-Negotiate, שמעדיף Kerberos, ואחר כך לסדר את השמות, ה-SPN ואת נתיבי הרשת שמאפשרים ל-Kerberos לעבוד.¹

לקרוא לפי מטרה או לפי סימפטום

המאמר הזה מסביר את המנגנונים ואת ההחלטות. לנוהל של הגדרת audit והרצת inventory, עברו למאמר המעשי הנלווה שמוצג למעלה.

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 35, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

2. מה NTLM בעצם עושה

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

NTLM (Windows Challenge/Response) הוא, כפי ששמו אומר, פרוטוקול אימות מבוסס challenge/response. סיכום התיאור של Microsoft: ה-credentials מורכבים משם domain, שם משתמש ו-hash חד-כיווני של הסיסמה שהתקבל ב-logon אינטראקטיבי (רק הסיסמה עוברת hash), וכדי לאמת בלי לשלוח את הסיסמה ברשת, הצד שמבקש אימות מבצע חישוב שמוכיח שהוא “יכול לגשת ל-credentials של NTLM המאוחסנים באופן מאובטח”.¹

הנקודה החשובה כאן היא שחומר האימות אינו הסיסמה עצמה אלא ה-hash שלה. העובדה הזאת לבדה היא מה שמאפשר Pass-the-Hash, כפי שנראה בהמשך.

2.1. בחשבון domain משתתפים שלושה צדדים

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

נקודת המפתח היא ששרת המשאב אינו מאמת בעצמו את ה-response של משתמש domain: הוא מבקש מה-DC לעשות את החישוב.

איור 1 ושבעת השלבים שלאחריו הם הנוהל המושגי שמופיע בעמוד ה-overview של Microsoft. החישוב המדויק של ה-response ב-NTLMv2 נמצא בסעיף 2.2. קראו את איור 1 בשביל “מי מבקש ממי לאמת” ואת איור 2 בשביל “איך זה מחושב”, וכך השניים לא יתערבבו.¹

sequenceDiagram
    autonumber
    participant C as Client
    participant S as Server
    participant DC as Domain controller

    Note over C: ב-logon מחשב hash של<br/>הסיסמה וזורק את הסיסמה עצמה
    C->>S: שם משתמש (בטקסט גלוי)
    S->>C: מספר אקראי של 8 בתים (challenge)
    Note over C: מצפין את ה-challenge<br/>עם ה-hash של הסיסמה
    C->>S: Response
    S->>DC: שם משתמש / challenge / response
    Note over DC: שולף את ה-hash מה-SAM<br/>ומבצע את אותו חישוב
    DC-->>S: האימות מצליח אם הם זהים
    S-->>C: מעניק גישה

איור 1: אימות NTLM לא אינטראקטיבי (עם חשבון domain)

אם קוראים את איור 1 כנוהל, הוא הופך לשבעת השלבים האלה. החישוב של ה-response ב-NTLMv2 עצמו מוצג שוב בסעיף 2.2 שלהלן.

1. (רק באימות אינטראקטיבי) המשתמש מזין שם domain, שם משתמש וסיסמה. הלקוח מחשב hash קריפטוגרפי של הסיסמה וזורק את הסיסמה עצמה.
2. הלקוח שולח לשרת את שם המשתמש בטקסט גלוי.
3. השרת מייצר מספר אקראי של 8 בתים (ה-challenge, nonce) ושולח אותו ללקוח.
4. הלקוח מצפין את ה-challenge הזה עם ה-hash של סיסמת המשתמש ומחזיר את התוצאה (ה-response).
5. השרת שולח שלושה דברים ל-domain controller: את שם המשתמש, את ה-challenge ששלח ללקוח, ואת ה-response שקיבל.
6. ה-domain controller משתמש בשם המשתמש כדי לשלוף את ה-hash של הסיסמה ממסד הנתונים SAM ומצפין איתו את ה-challenge.
7. הוא משווה את התוצאה שחישב ל-response של הלקוח; אם הם זהים, האימות מצליח.

2.2. החישוב בפועל — NTLMv2 קצת יותר מורכב

שבעת השלבים למעלה הם הצורה הבסיסית שמתוארת בעמוד ה-overview של Microsoft. NTLMv2, שבו Windows של ימינו באמת משתמש, הולך צעד אחד מעבר ל”הצפנת ה-challenge עם ה-hash של הסיסמה”. ה-spec ([MS-NLMP]) מגדיר אותו כך.²

לגזור response key ואז לחשב HMAC על ה-challenge ועוד

• ה-response key הוא NTOWFv2 = HMAC_MD5( MD4(UNICODE(password)), uppercased user name + domain name )
• הלקוח בונה temp, שרשור של גרסת ה-response, חתימת זמן, challenge של 8 בתים שנוצר בצד הלקוח, ומידע על היעד (AV pairs)
• הליבה של ה-response היא NTProofStr = HMAC_MD5( response key, server challenge + temp )

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

flowchart TD
    PW["Password"] --> MD4["MD4(UNICODE(password))<br/>= NT hash"]
    UD["שם משתמש באותיות גדולות<br/>+ שם domain"] --> H1["HMAC_MD5"]
    MD4 -->|"used as the key"| H1
    H1 --> KEY["Response key NTOWFv2"]

    MAT["גרסת ה-response / חתימת זמן /<br/>challenge של 8 בתים מצד הלקוח /<br/>מידע על היעד (AV pairs)"] --> TEMP["temp"]

    SC["Server challenge"] --> H2["HMAC_MD5"]
    TEMP --> H2
    KEY -->|"used as the key"| H2
    H2 --> PROOF["NTProofStr"]
    PROOF --> RESP["NtChallengeResponse<br/>= NTProofStr + temp"]
    TEMP --> RESP

איור 2: איך נוצר response של NTLMv2 (סיסמה → NT hash → response key → HMAC)

אז מה שמחושב בפועל הוא HMAC שמערבב לא רק את ה-challenge של השרת אלא גם מספר אקראי מצד הלקוח, חתימת זמן ומידע על היעד. הצד המאמת משחזר את אותו חישוב. אם החשבון נמצא ב-Active Directory, צמד ה-challenge/response נשלח ל-domain controller לאימות; אם החשבון מקומי בשרת, השרת מחשב את הערך המצופה מה-OWF שהוא עצמו מאחסן.²

שני דברים שלא משתנים, כמה שהחישוב נעשה מורכב

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

1. החומר של המפתח הוא עדיין ה-hash של הסיסמה. נקודת המוצא של NTOWFv2 היא MD4(UNICODE(password)), שהוא ה-NT hash עצמו.² זו הסיבה ש-Pass-the-Hash עובד (סעיף 7.2).
2. הלקוח לא מאמת שהשרת אמיתי. הקביעה של Microsoft של-NTLM אין mutual authentication נכונה גם ל-NTLMv2.⁴

כל מה שבא בהמשך נשען על שתי הנקודות האלה.

2.3. בחשבון מקומי שני צדדים מספיקים

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

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

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

ההבדל הזה זורם ישירות ל-inventory של תלויות מסוג “אי אפשר להשתמש ב-Kerberos כי זה חשבון מקומי” שמכוסה בסעיף 6.3. NTLM שנוקט בנתיב הזה לא מופיע ב-audit logs של domain controller.

2.4. שלוש תוצאות של התכנון הזה

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

הפנייה בשורה השנייה נדרשת בכל פעם ששרת המשאב צריך access token חדש. בחשבון domain הוא בודק את שירות האימות ב-DC; בחשבון מקומי הוא בודק את מסד החשבונות המקומי.¹⁰

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

3. למה השרת שואל domain controller

NTLM מבקש אימות ממי שמחזיק ב-hash

ה-hash של סיסמת משתמש domain נמצא במסד החשבונות ב-DC. שרת המשאב לא מכיר את ה-hash של אותו משתמש, ולכן אינו יכול לאמת בעצמו את ה-response שקיבל.

Pass-through authentication הוא אפוא מסירת שם המשתמש, ה-challenge וה-response ל-DC ובקשה שיחליט. חלוקת העבודה הזאת היא הסיבה שאימות NTLM עם חשבון domain דורש פנייה ל-DC.¹⁰¹

בחשבון מקומי, ה-hash נבדק מול ה-SAM של השרת עצמו. הקביעה “NTLM שואל את ה-DC” נכונה רק לחשבונות domain.

Kerberos מחליף את הפנייה בכרטיס

Kerberos מחליף את ה-pass-through authentication הזה בכרטיסי session שמתחדשים. Microsoft מסבירה שב-NTLM שרת אפליקציה היה חייב להתחבר ל-DC בכל פעם שאימת, ואילו ב-Kerberos הפנייה הזאת נעשית מיותרת.⁴

עם זאת יש חריג: כשנדרש אימות של ה-PAC (privilege attribute certificate). זה לא אומר שב-Kerberos אין בכלל תעבורה מהשרת ל-DC.

המעבר ל-Kerberos נושא אפוא גם תועלת תפעולית — הפחתת התלות ב-DC בכל אימות — מעבר לשיפור האבטחה שבאפשרות לאמת את הצד שמולכם. הסעיף הבא בודק איך כרטיס ממלא את התפקיד הזה.

4. מה Kerberos בעצם עושה

היכן של-NTLM יש response שמאומת בכל אימות, Kerberos מוכיח את הזהות מראש, מקבל כרטיס, ומשתמש בכרטיס הזה לאימות הבא. איור 3 מציג את כל הזרימה, מהוכחת הזהות הראשונית ועד ההתחברות לשירות.

ה-KDC (Key Distribution Center) פועל על domain controller ומשתמש במסד הנתונים של Active Directory Domain Services כמסד החשבונות האבטחתי שלו.⁴

לפני קריאת הדיאגרמה: להפריד בין שמות לכרטיסים

לאיור 3 יש שלושה שלבים: להוכיח זהות ולקבל TGT → לציין SPN ולקבל service ticket → להציג אותו לשירות. המפתח הוא לא לקרוא את ה-TGT ואת ה-service ticket כאותו דבר.

sequenceDiagram
    autonumber
    participant C as Client
    participant KDC as KDC (domain controller)
    participant S as שירות (מזוהה לפי SPN)

    Note over C,KDC: חילוף AS — הוכחת זהות וקבלת TGT
    C->>KDC: KRB_AS_REQ<br/>(שם משתמש + חתימת זמן מוצפנת עם המפתח ארוך הטווח)
    Note over KDC: אמיתי אם זה מפוענח עם המפתח ארוך הטווח
    KDC-->>C: KRB_AS_REP<br/>TGT (מוצפן עם מפתח krbtgt) + session key

    Note over C,KDC: חילוף TGS — קבלת service ticket
    C->>KDC: KRB_TGS_REQ<br/>(TGT + SPN של היעד + authenticator)
    Note over KDC: מאתר את חשבון השירות לפי ה-SPN<br/>ומצפין את הכרטיס עם המפתח ארוך הטווח שלו
    KDC-->>C: KRB_TGS_REP<br/>Service ticket + session key

    Note over C,S: חילוף AP — הצגה לשירות
    C->>S: KRB_AP_REQ<br/>(service ticket + authenticator)
    Note over S: ניתן לפענוח עם המפתח ארוך הטווח שלו<br/>= הכרטיס מיועד אליו
    S-->>C: KRB_AP_REP (כשנתבקש mutual authentication)

איור 3: שלושת חילופי Kerberos (AS / TGS / AP)

מקרא — AS = Authentication Service, TGS = Ticket Granting Service, AP = Application. בשמות ההודעות, _REQ הוא בקשה ו-_REP הוא תשובה. לדוגמה, KRB_TGS_REQ פירושו “בקשה ל-Ticket Granting Service”.

4.1. חילוף AS — הוכחת זהות פעם אחת

מה נשלח: חתימת זמן מוצפנת עם המפתח ארוך הטווח

הלקוח שולח ל-KDC את שם המשתמש ושם ה-domain שלו יחד עם חתימת זמן מוצפנת עם המפתח ארוך הטווח שלו, המפתח שנגזר מהסיסמה. זהו pre-authentication. אם ה-KDC מצליח לפענח אותה עם המפתח ארוך הטווח הזה וחתימת הזמן תקפה, הוא מסיק שזהו המשתמש האמיתי.³

מה מתקבל: TGT ו-session key

ה-KDC מחזיר שני דברים עם תפקידים שונים. שניהם “דברים שהלקוח מקבל”, אבל הם שונים בשאלה אם הלקוח יכול לקרוא את מה שבתוכם.³

להחזיק TGT ולהיות מסוגל לקרוא את מה שבתוכו הם שני דברים שונים. ההבחנה הזאת מובילה לשלב הבא, “לשלוח את הבקשה עם ה-TGT וה-authenticator”.

אם השעונים סוטים, Kerberos עצמו נכשל

הנקודה שצריך לתפוס כאן היא שחתימת הזמן היא חלק מהאימות. זו הסיבה ש-Kerberos מקפיד על סנכרון שעון: הפרש הזמן המותר הוא חמש דקות כברירת מחדל.⁷ מחוץ לחלון הזה ה-pre-authentication לא עובר, ואימות Kerberos עצמו נכשל בשגיאה (סנכרון זמן ב-Windows מכוסה ב”מדריך לסנכרון זמן ב-Windows (w32time)”). “Kerberos נכשל” ו”נופל ל-NTLM” הם שני דברים שונים. סעיף 6.5 מכסה את ההבחנה.

4.2. חילוף TGS — להצהיר לאיזה שירות מתחברים

ברגע שללקוח יש TGT, הוא מבקש כרטיס לשירות היעד. רק בנקודה הזאת השם שאומר לאיזה שירות אתם מתחברים, ה-SPN, עולה למרכז הבמה.³

הלקוח שולח ל-KDC את ה-SPN של היעד, את ה-TGT ואת ה-authenticator. ה-KDC מאתר את חשבון השירות שמתאים ל-SPN, מצפין service ticket עם המפתח ארוך הטווח של אותו חשבון ומחזיר אותו.³

קריאה של הזרימה הזאת בכיוון ההפוך חושפת את הבעיות שמכוסות בסעיף 6.

• אם אי אפשר להפיק את ה-SPN, אי אפשר להנפיק כרטיס. אם לא רשום SPN על חשבון השירות, ה-KDC לא יכול לקבוע באיזה מפתח להשתמש. גם התחברות לפי כתובת IP היא תנאי שבו Kerberos לא מנוסה כברירת מחדל (סעיף 6.1).
• כרטיס נוצר עבור היעד שלו. מכיוון שהוא מוצפן עם המפתח ארוך הטווח של אותו שירות, שירות שמחזיק מפתח ארוך טווח אחר לא יכול לפענח אותו. זו הסיבה שאי אפשר להשתמש שוב בכרטיס מול יעד אחר.

4.3. חילוף AP — הצגה לשירות ו-mutual authentication

החילוף האחרון הוא עם שירות היעד ולא עם ה-KDC. גם כאן, קראו בנפרד את הבדיקה בצד השירות ואת הבדיקה בצד הלקוח.

בצד השירות: לפתוח כרטיס שמיועד אליו

הלקוח מציג את ה-service ticket ואת ה-authenticator. השירות מפענח את הכרטיס עם המפתח ארוך הטווח שלו ומחלץ ממנו את ה-session key ואת נתוני ההרשאה. היכולת לפענח אותו עם המפתח שלו היא מה שמאשר שהכרטיס מיועד אליו.³

בצד הלקוח: לאמת את הצד שמולך כשנתבקש mutual authentication

אם הלקוח ביקש mutual authentication, השירות מצפין את חתימת הזמן שקיבל עם ה-session key ומחזיר אותה. הלקוח מאמת את התשובה הזאת ומאשר שהצד שמולו הוא השירות האמיתי.³

לא רק שהשירות מאמת את הלקוח — הלקוח יכול גם לאמת את השירות. זהו ה-mutual authentication שחסר ל-NTLM.

5. ההבדלים המכריעים

הסעיף הזה משווה את המנגנונים של סעיפים 2 עד 4 מהזוויות שחשובות לתפעול ולתכנון. הפנייה ל-DC שונה בין חשבון domain לחשבון מקומי, ול-Kerberos יש חריג משלו באימות PAC. קראו את התנאים יחד עם השורות.

לתכנון שמשתמש ב-delegation יש עוד בחירה של סוג

Delegation הוא המנגנון שבו, למשל, אפליקציית web front-end מתחברת ל-SQL Server ב-back-end בשם המשתמש. התחזות למשתמש בתוך שרת אחד והעברת זהות המשתמש הלאה לשירות אחר הם שני דברים נפרדים.⁴

Kerberos delegation מגיע ב-unconstrained delegation, בconstrained delegation ובresource-based constrained delegation (RBCD). ההחלטה “להשתמש ב-Kerberos” אינה סוף הסיפור; איזה סוג delegation להשתמש בו הוא שאלת תכנון בפני עצמה.

המאמר הזה לא נכנס להגדרה של כל סוג. שמרו את שלושת השמות האלה כמונחי החיפוש הבאים שלכם כשאתם חוקרים הגדרה שדורשת delegation.

תנאי השם וה-domain מובילים לחקירה הבאה

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

6. למה האימות “נופל” ל-NTLM

הסעיף הזה חוקר למה “המערכת העסקית עובדת, אבל האימות הוא על NTLM”. בדקו את שם היעד, את רישום ה-SPN, את החשבון ואת הנתיב ל-KDC, בסדר הזה. אם האימות עצמו נכשל בשגיאה, בדקו קודם את סעיף 6.5 כדי לראות אם צריך קו חקירה אחר.

משתמשים ב-NTLM גם כשהאפליקציה לא קוראת ל-NTLM ישירות, כי כך מתנהג Negotiate. Microsoft מתארת את Negotiate כמי שבוחר בין Kerberos ל-NTLM, ובוחר ב-Kerberos אלא אם אחת המערכות שמעורבות באימות לא יכולה להשתמש בו.¹

לכן גם כשמשתמשים ב-Negotiate, NTLM נבחר אם לא כל התנאים ל-Kerberos מתקיימים. אפליקציה שתומכת ב-Kerberos וכך ש-Kerberos באמת נמצא בשימוש בחיבור נתון הם שני דברים שונים.

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

flowchart TD
    START["האימות מתחיל עם Negotiate"]
    Q1{"חשבון<br/>domain?"}
    Q2{"אפשר לבנות SPN<br/>משם היעד?"}
    Q3{"ה-SPN הזה<br/>רשום?"}
    Q4{"ה-KDC<br/>נגיש?"}
    KRB["לאמת עם Kerberos"]
    NTLM["ליפול ל-NTLM"]

    START --> Q1
    Q1 -->|"לא<br/>(workgroup / חשבון מקומי)"| NTLM
    Q1 -->|כן| Q2
    Q2 -->|"לא<br/>(כתובת IP מוקשחת בקוד)"| NTLM
    Q2 -->|כן| Q3
    Q3 -->|"לא<br/>(SPN לא רשום / גישה דרך alias)"| NTLM
    Q3 -->|כן| Q4
    Q4 -->|"לא<br/>(אתר סניף / VPN / firewall)"| NTLM
    Q4 -->|כן| KRB

איור 4: ההסתעפויות שבהן Negotiate נופל ל-NTLM

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

6.1. החיבור משתמש בכתובת IP

התנהגות ברירת המחדל: לא מנסים Kerberos עם כתובת IP

זו הסיבה הנפוצה ביותר. Microsoft מציינת במפורש שכברירת מחדל, כששם המארח הוא כתובת IP, Windows לא מנסה אימות Kerberos מול אותו מארח ונופל לפרוטוקול אימות תקף אחר, כמו NTLM.¹¹ גם הנחיות ה-audit אומרות אותו דבר מצדן: Kerberos לא נכנס לשימוש אם “Target Server” באירוע 8001 אינו בצורת NetBIOS ואינו בצורת FQDN.⁵

הסיבה לכך מופיעה גם היא: אפליקציות שמשתמשות בכתובת IP ולא בשם DNS בגלל הגדרה שגויה או תיעוד של הספק.⁵ בפועל נפוץ מאוד למצוא הגדרה שמישהו שינה לכתובת IP לפני שנים “כי ה-name resolution לא היה אמין”, ומאז היא נשארה כך.

החריג: להגדיר TryIPSPN ואת ה-SPN שבאמת מתבקש

לא לנסות Kerberos עם כתובת IP הוא התנהגות ברירת מחדל, לא מגבלה מוחלטת. מ-Windows 10 גרסה 1507 ומ-Windows Server 2016 ואילך יש מנגנון שמאפשר כתובת IP כשם מארח ב-SPN.¹¹

שני הדברים הבאים נדרשים כאחד.

1. להגדיר את ערך הרישיות TryIPSPN ל-1 בלקוח.
2. לרשום ידנית SPN שמשתמש בכתובת ה-IP, בצורה Setspn -s <service class>/<IP address> <account>.

ה-SPN שאתם רושמים חייב להתאים לסוג השירות שהלקוח באמת מבקש. גם לאותה כתובת IP של יעד, השם הנדרש שונה משירות לשירות.

רישום של host/ בלבד לא יגרום ל-Kerberos לעבוד אם הוא לא מתאים ל-SPN שמתבקש. Microsoft מציגה את התכונה הזאת כדרך לצמצם את השפעת התאימות של השבתת NTLM.¹¹

לתקן ל-FQDN קודם, ולשמור את החריג כמוצא אחרון

עם זאת, זו אינה הבחירה הראשונה. Microsoft עצמה אומרת שכתובות IP הן זמניות ועלולות לגרום להתנגשויות ולכשלי אימות כשהחכירות מסתיימות ומתחדשות, ולכן בדרך כלל לא משתמשים בהן במקום שמות מארח, ושהרישום SPN לפי כתובת IP הוא עבודה ידנית שצריך להשתמש בה רק כשאי אפשר לעבור לשם מארח מבוסס DNS.¹¹ לכל כתובת IP מוקשחת ש-audit מעלה, חשבו קודם לשנות אותה ל-FQDN. TryIPSPN הוא מוצא אחרון לצדדים שבהם זה באמת לא אפשרי.

6.2. לא רשום SPN

הדבר הבא לבדוק הוא אם השם שבאמת משמש לגישה רשום כ-SPN. Microsoft מפרטת אפליקציות שה-SPN שלהן לא הוגדר נכון כקטגוריה של אפליקציות שמשתמשות ב-NTLM למרות שהן תומכות ב-Kerberos.⁵

בחילוף ה-TGS באיור 3, ה-KDC מאתר את חשבון השירות לפי ה-SPN ומצפין את הכרטיס עם המפתח ארוך הטווח שלו. בלי SPN, אי אפשר לזהות את “המפתח של השירות הזה”.

אותו דבר קורה כשהחיבור משתמש ב-DNS alias (CNAME) או בשם מארח מותאם, ולא רשום SPN לשם הזה. היכולת להגיע לשרת לפי שם והיכולת לקבל כרטיס Kerberos לאותו שם הם שני דברים שונים.

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

6.3. אתם מחוץ ל-Active Directory מלכתחילה

למצוא את הנתיבים שבאמת צריכים NTLM היום

מחשבים ב-workgroup, וגישת share עם חשבון מקומי, אינם על מגרש המשחקים של Kerberos בכלל. Microsoft אומרת שב-NTLM משתמשים, וחייבים להשתמש, לאימות Windows במערכות שמוגדרות כחברות ב-workgroup ולאימות logon מקומי במחשבים שאינם domain controllers.¹⁰

להפריד בין מה שה-local KDC יכסה לבין מה שלא

זו הסיבה שאי אפשר פשוט לאסור את NTLM. ה-local KDC המתוכנן לשלב 2 הוא בדיוק התכונה שנועדה למלא את הפער הזה.⁶

עם זאת, הניחו שהוא ממלא את הפער רק בין גרסאות Windows שתומכות בו. אימות עם חשבון מקומי מול Windows ישן יותר, או מול התקני צד שלישי כמו מכשירי NAS ומדפסות משולבות, לא יהפוך אוטומטית ל-Kerberos כשהש-local KDC יגיע. סעיפים 5 ו-6 במאמר המעשי הנלווה מכסים את המיון הזה.

6.4. אי אפשר להגיע ל-KDC

אתר סניף או VPN שמהם אי אפשר להגיע ל-DC, או firewall שחוסם את התעבורה ש-Kerberos צריך, הם גם סיבה למעבר ל-NTLM.⁶ הסיבה היא שכשאי אפשר לקבל מה-KDC את הכרטיס הנדרש, אי אפשר להניח את התשתית לשימוש ב-Kerberos.

כאן, פִתחו את “האם אפשר להגיע ל-DC” לפי מי שמייצר את התעבורה.

“הלקוח לא יכול להגיע ל-KDC” ו”ל-NTLM לא צריך DC” הם לא אותו משפט. כפי שסעיף 3 הראה, NTLM עם חשבון domain דורש פנייה מהשרת ל-DC.¹⁰ גם כשנבחר NTLM, האימות לא יכול להסתיים אם גם נתיב האימות הזה אבד.

6.5. לא להתבלבל בין כשל של Kerberos לבין נפילה ל-NTLM

Kerberos שלא התחיל בכלל, לעומת Kerberos שנכשל אחרי שנבחר

לסיום, נפריד משהו שקל להתבלבל בו אבל הוא שונה באמת. סעיפים 6.1 עד 6.4 הם כולם מקרים שבהם אי אפשר היה להתחיל את Kerberos. מכיוון שאי אפשר להתחיל אותו, Negotiate בוחר ב-NTLM.

בעיות שבהן Kerberos נכשל אחרי שנבחר נחקרות בנפרד. הדוגמה הקלאסית היא הפרש השעון שהוזכר בסעיף 4.1.

אם ה-SPN נפתר וה-KDC נגיש, Negotiate בוחר תחילה ב-Kerberos. אבל אם הפרש הזמן עולה על הסבילות, חמש דקות כברירת מחדל, ה-pre-authentication לא עובר וזה נכשל כשגיאת Kerberos.⁷

“לבחור ב-NTLM כי Kerberos לא זמין” ו”לנסות שוב עם NTLM כי ה-Kerberos שנבחר נכשל” הם לא אותו דבר. Negotiate לא בהכרח הולך עד לשם, ומקרה שבו האפליקציה מנסה שוב במפורש עם שיטה אחרת צריך להיבחן בנפרד.

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

המשמעות המעשית פשוטה. לא תמצאו כשל של הפרש שעון בחיפוש אחרי אירוע 8001. גם הסימפטומים שונים.

הפרידו בין “האם זה נפל ל-NTLM” לבין “האם Kerberos שבור” לפני שאתם חוקרים. הסימפטום “זה עובד, אבל על NTLM” שמתואר כאן מניח הגדרה שבה NTLM זמין. הגבלות על NTLM וחסימת NTLM נבדקות בנפרד, בסעיף 8 ובסעיף 9.

7. ההבדל מנקודת המבט של התוקף — relay ו-Pass-the-Hash

relay ו-Pass-the-Hash נדונים שניהם כבעיות של NTLM, אבל מה שכל אחד מהם משתמש בו שונה.

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

Microsoft מציינת במפורש בתיעוד של הגדרת המדיניות שאימות NTLM ו-NTLMv2 פגיע למגוון תקיפות זדוניות, כולל SMB relay, מתקפות man-in-the-middle ומתקפות brute force.⁸ איור 1 מסביר למה.

7.1. מתקפות relay — התוצאה של אי-כבילה ליעד

sequenceDiagram
    autonumber
    participant V as המחשב של הקורבן
    participant A as השרת של התוקף
    participant T as השרת האמיתי

    Note over V,A: הקורבן מנותב לשרת של התוקף
    V->>A: מתחיל אימות (שם משתמש)
    A->>T: מתחיל אימות כאותו משתמש
    T-->>A: Challenge
    A-->>V: מעביר את ה-challenge הזה כמו שהוא
    Note over V: לא יכול לדעת אם זה בא<br/>מהשרת האמיתי
    V->>A: Response (מחושב עם מפתח שנגזר מה-hash)
    A->>T: מעביר את ה-response הזה כמו שהוא
    Note over T: כשגם signing וגם channel<br/>binding אינם נדרשים
    T-->>A: האימות מצליח → נוצר חיבור כקורבן

איור 5: איך עובד NTLM relay (מול צד שלא דורש signing ולא channel binding)

relay עובד בלי לגנוב סיסמה או hash

התוקף לא צריך לדעת לא את הסיסמה ולא את ה-hash. כל מה שהוא עושה הוא להעביר את ה-challenge ואת ה-response מצד אחד לשני. זה עובד כי ללקוח אין דרך לבדוק אם ה-response שלו באמת הולך לצד שהתכוון אליו.

אם זה עובד תלוי בהגנות של היעד

עם זאת, relay לא עובר לכל צד. האם חילוף שעבר relay הופך ל-session שמיש תלוי בהגנות של היעד.

• זה לא עובר לצד שדורש SMB signing. Microsoft מציינת שה-signature שמצורף לכל הודעת SMB מכיל hash של כל ההודעה ומאשר את הזהויות של השולח ושל המקבל, וכך מונע מתקפות relay.¹² שימו לב ש-domain controllers דורשים SMB signing כברירת מחדל מכל מי שמתחבר אליהם.¹²
• זה גם לא עובר לשירות שאוכף Extended Protection for Authentication (channel binding). מכיוון שזה כובל את האימות לערוץ ה-TLS שמתחתיו, אימות שעבר relay לערוץ אחר לא עובר יותר.

איור 5 מניח צד שמקבל NTLM ולא דורש לא signing ולא channel binding. אל תקראו בו ש-relay הזה עובר ללא תנאי בכל חיבור שמשתמש ב-NTLM.

מה שצריך לבדוק כאן הוא לא רק אם תכונות ההגנה “נתמכות” אלא אם הן באמת נדרשות ונאכפות. לצד ה-inventory של NTLM, כדאי לבדוק אם ההגדרה דורשת SMB signing.

לשקול מעבר ל-Kerberos יחד עם ההגנות בצד SMB

ב-Kerberos, relay באותה צורה אינו אפשרי מלכתחילה. service ticket מוצפן עם המפתח ארוך הטווח של שירות היעד, ולכן העברה שלו לשירות אחר משאירה אותו בלתי ניתן לפענוח.³ מעבר לכך, mutual authentication מאפשר ללקוח לבדוק אם הצד שמולו אמיתי.⁴

זו בדיוק הסיבה ש-Microsoft סיפקה חסימת NTLM בצד לקוח SMB. המטרה המוצהרת היא למנוע טכניקות שגורמות לשליחת בקשות NTLM לשרת זדוני.¹³

בין ההמלצות שלה סביב SMB signing, Microsoft גם מפרטת להשתמש ב-Kerberos ולא ב-NTLMv2 כדי שה-session key יתחיל חזק, ולא להתחבר ל-shares לפי כתובת IP או רשומת CNAME, כי זה גורם לשימוש ב-NTLM במקום ב-Kerberos.¹² זו אותה נקודה כמו סעיפים 6.1 ו-6.2.

7.2. Pass-the-Hash — ה-hash שקול לסיסמה

flowchart LR
    P["Password"] -->|"hash חד-כיווני"| H["Password hash"]
    H -->|"לגזור את ה-response key<br/>ולחשב HMAC"| R["Response"]
    R --> AUTH["האימות מצליח"]
    STEAL["ה-hash נגנב<br/>ממחשב"] --> H
    NOTE["הסיסמה בטקסט גלוי<br/>אינה נדרשת"] -.-> STEAL

איור 6: מה שהאימות צריך הוא ה-hash, לא הסיסמה בטקסט גלוי

הבעיה היא שאפשר לבנות response מתוך ה-hash

החומר של ה-credentials של NTLM הוא hash חד-כיווני של הסיסמה.¹ גם ב-NTLMv2 ה-response key נגזר כשמשתמשים ב-MD4(UNICODE(password)) כמפתח, וה-response נבנה בחישוב HMAC עם המפתח הזה.²

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

מורכבות סיסמה לבדה לא סוגרת את הנתיב הזה

לעשות סיסמאות ארוכות ומורכבות הוא עניין אחר מלמנוע שימוש ב-hash גנוב. סיסמאות מורכבות עדיין משאירות פתוח את הנתיב של גניבת ה-hash והשימוש בו. Microsoft מפרטת את Pass-the-Hash, לצד brute force ו-cracking, בין התקיפות שחסימת NTLM ב-SMB מתמודדת איתן.¹³

ל-Kerberos גם יש מפתחות ארוכי טווח. אבל מה שמוחלף באימות היומיומי הוא כרטיסים ו-session keys שפגים.³ ההשוואה חייבת להתרחב עד כמה רחוק מה שנגנב באמת מקדם את התוקף.

8. NTLMv1, NTLMv2 ו”הסרה”

NTLM אינו פרוטוקול אחד אלא משפחה של פרוטוקולי אימות שכוללת את LAN Manager גרסאות 1 ו-2 ואת NTLM גרסאות 1 ו-2.¹⁰

ההבחנה שצריך לעשות כאן היא בין deprecation ל-removal. Deprecated פירושו מחוץ לפיתוח פעיל של תכונות; removed פירושו בלתי שמיש בגרסאות המדוברות.

הטבלה שלהלן מציבה את הודעת ה-deprecation מיוני 2024 לצד ההסרה שלאחריה של NTLMv1. אל תקראו את הניסוח “עדיין עובד” בשורה הראשונה כאילו NTLMv1 שמיש במערכות ההפעלה שבשורה השנייה. ל-NTLMv1 חלה ההסרה המאוחרת.⁹

למצוא קודם את הצדדים שיודעים רק NTLMv1

לכן “אנחנו על NTLMv2, אז אפשר להשאיר את זה לעכשיו” לא מחזיק. סדר העדיפויות ברור, עם זאת: התקנים ומארחים שיודעים לדבר רק NTLMv1 באים קודם. מארח שנרשם כ-NTLM V1 ב-audit יפסיק לאמת ברגע שיעבירו אותו ל-Windows חדש יותר במצבו הנוכחי. איך להבדיל בין הגרסאות, לפי “Package Name (NTLM only)” ב-Security log, מכוסה בסעיף 4.4 של המאמר המעשי הנלווה.⁵

מדיניות ההגבלה חלה על v1 ועל v2 כאחד

שימו לב שמדיניות ה-audit ומדיניות החסימה שמגבילות את NTLM משפיעות באותה מידה על NTLMv1 ועל NTLMv2.⁵ ההתנהגות לא משתנה לפי גרסה כשאתם מחילים הגבלה.

9. לאן זה הולך

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

זמני האספקה של IAKerb ושל ה-local KDC שלהלן, והשינוי בברירת המחדל, מתוארים כתוכניות במפת הדרכים של Microsoft שמצוטטת כאן. אין להתייחס אליהם כתכונות ששוחררו, או כתכונות שיעבדו אוטומטית בכל התקן.⁶

ראשית: להשתמש ב-Negotiate בצד האפליקציה

החלפת קריאות ל-NTLM בקריאות ל-Negotiate היא הוראה שנמצאת בהודעת ה-deprecation עצמה.⁹ נאמר במפורש גם שאפליקציות לא אמורות לגשת ישירות לחבילת האבטחה NTLM.¹

שנית: לצמצם את המצבים שצריכים NTLM בכלל

IAKerb וה-local KDC המתוכננים לשלב 2 (המחצית השנייה של 2026) נכנסים לכאן.⁶ הם ניסיון למלא, ברמת הפרוטוקול, את שני הפערים שראינו בסעיף 6.3: “אי אפשר להשתמש ב-Kerberos כי זה חשבון מקומי” ו”אי אפשר להשתמש ב-Kerberos כי אי אפשר להגיע ל-domain controller”.

אבל מה שהם ממלאים מוגבל. מה ש-IAKerb פותר הוא נגישות ל-domain controller, ולא אם הצד שמולך תומך בפרוטוקול. גם ה-local KDC עובד רק בין גרסאות Windows שתומכות בו.

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

שלישית: לשנות את ברירת המחדל של אימות NTLM ברשת

בשלב 3, אימות NTLM ברשת מתוכנן להיות מושבת כברירת מחדל בשחרור המרכזי הבא.⁶ נאמר גם שאפשר להפעיל אותו מחדש דרך policy.

מה לעשות עכשיו: למיין תלות בין מה שהתכונות החדשות אולי יכסו לבין מה שחייבים לתקן בעצמכם

התוכנית הולכת בסדר של “להסיר את הסיבות להשתמש ב-NTLM, ואז לשנות את ברירת המחדל”. מיון התלויות שלכם באותו אופן משאיר בנפרד את מה שכדאי לחכות לו ואת מה שצריך לתקן קודם.

הדבר החשוב הוא לא לגרוף את האימות מול Windows ישן יותר ומול התקני צד שלישי לדלי אחד של “מחכים לשלב 2”. זה לא יהפוך ל-Kerberos מעצמו, ואם משאירים את זה כך זה יצוף ככשל כשהברירת מחדל תושבת.

הנוהל הקונקרטי של inventory ומיון מופיע במאמר המעשי הנלווה.

10. סיכום

ולסיום, תזכורת לפי סדר ההחלטות.

מנגנון: response מבוסס hash, או כרטיס ליעד

NTLM בונה response ל-challenge מתוך ה-hash של הסיסמה. מה שמאמת אותו הוא DC בחשבון domain, או ה-SAM של השרת עצמו בחשבון מקומי.¹¹⁰

Kerberos משתמש בכרטיס שמוצפן עם המפתח ארוך הטווח של שירות היעד.³ תפיסה של ההבדלים בmutual authentication, בפנייה ל-DC בכל אימות וב-delegation חושפת את ההנחות לבחירה בין שתי השיטות.⁴

מיון: זה עובד על NTLM, או שהאימות נעצר?

אם האימות עבר ל-NTLM, בדקו את ארבעת התנאים: כתובות IP מוקשחות בקוד, SPNs לא רשומים, הימצאות מחוץ ל-Active Directory, ונגישות ל-KDC.⁵⁶¹¹

בעיות שמפיקות שגיאת אימות אחרי ש-Kerberos נבחר, כמו הפרש שעון, הן עניין נפרד. במקום לרדוף רק אחרי אירוע 8001 ב-NTLM/Operational, בדקו את אירועי Kerberos ואת סנכרון השעון.⁷ נקודת הפתיחה של החקירה היא לא להסיק “זה עובד, אז זה בטח Kerberos” או “זה נעצר, אז בטח נפל ל-NTLM”.

תגובה: לבדוק את ההגנות, ואז לעבור ל-Negotiate ולשמות

relay, שמעביר חילוף NTLM, ו-Pass-the-Hash, שמשתמש ב-hash גנוב, שונים גם בסיבה שהם עובדים וגם במה שהם צריכים.⁸¹¹³ בדקו את תנאי ההגנה בכל יעד תוך צמצום תלות ה-NTLM עצמה.

NTLMv1 הוסר ב-Windows 11 24H2 וב-Windows Server 2025, וכל הגרסאות כולל NTLMv2 הן deprecated.⁹ באפליקציות, השתמשו ב-Negotiate, תקננו את היעדים על FQDNs, ורשמו SPNs.¹⁵ אחר כך קדמו את ההגירה כשהתלויות שהתכונות החדשות אולי יכסו נשמרות בנפרד מהתלויות שעליכם לתקן בעצמכם.

מאמרים קשורים

• האם ביטול NTLM יעצור את האפליקציות העסקיות שלכם? — איך לאסוף audit logs, ובאיזה סדר לחסל תלויות
• מלכודות של כונני רשת ונתיבי UNC — עבודה עם שרתי קבצים (תיקיות משותפות) מאפליקציה עסקית
• מדריך לסנכרון זמן ב-Windows (w32time)
• חקירת Event Log בפועל עם Get-WinEvent — מהירות הסינון קובעת כמה זמן תימשך החקירה
• טיפול בטוח ב-credentials ב-PowerShell — להרחיק סיסמאות בטקסט גלוי מהסקריפטים שלכם
• מהו ה-TPM ב-Windows? — מדריך מאויר ל”כספת שלא מוציאה מפתחות החוצה” ול-measured boot
• עשרת האיומים הגדולים באבטחת מידע 2026 — איך לקרוא את הדירוג, ומה עסקים קטנים באמת צריכים להגן עליו

תחומי ייעוץ קשורים

KomuraSoft LLC מטפלת בשינויים באפליקציות עסקיות של Windows הנובעים מבחינה מחודשת של שיטות אימות, ובחקירת שורש של בעיות אימות סביב Kerberos ו-NTLM.

• פיתוח אפליקציות Windows
• חקירת תקלות וניתוח שורש
• תמיכה בשימוש חוזר ובהגירת נכסים ישנים
• יצירת קשר

מקורות

מאמרים קשורים

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

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

מה בעצם ההבדל בין NTLM ל-Kerberos?

ההבדל הגדול ביותר הוא אם אפשר לאמת את זהות הצד שמולכם. Microsoft מציינת במפורש שב-NTLM הלקוח אינו יכול לאמת את זהות השרת, וגם שרת אחד אינו יכול לאמת את זהותו של שרת אחר. NTLM תוכנן לסביבות שבהן אפשר להניח שהשרתים אמיתיים; Kerberos לא מניח הנחה כזו. ההבדל השני הוא אם השרת צריך לפנות ל-domain controller. ב-NTLM, כשמאמתים חשבון domain, שרת האפליקציה מתחבר ל-domain controller בכל פעם שהוא מאמת לקוח (בחשבון מקומי בשרת, השרת מתייעץ עם מסד החשבונות שלו ומחליט בעצמו, וה-domain controller לא נכנס לתמונה כלל). ב-Kerberos, כרטיסי session שמתחדשים מחליפים את ה-pass-through authentication הזה, ולכן השרת לא פונה ל-domain controller אלא כשנדרש אימות PAC. ההבדל השלישי הוא ש-Kerberos תומך ב-delegation על ידי שירותים — מנגנון להתחברות לשירות אחר בשם הלקוח.

Kerberos אמור להיות נתמך, אז למה בסוף יוצא NTLM?

Kerberos מנפיק כרטיסים לפי "שם היעד", ולכן הוא לא מתקיים אם אי אפשר לפתור את השם. הלקוח מציג ל-KDC את ה-SPN (service principal name) של היעד כדי לבקש service ticket, אבל כברירת מחדל Windows לא מנסה אימות Kerberos כששם המארח הוא כתובת IP, ואם לא רשום SPN על חשבון השירות ה-KDC לא יכול להנפיק כרטיס. גם הנחיות ה-audit של Microsoft אומרות ש-Kerberos לא נכנס לשימוש אם "Target Server" באירוע 8001 אינו בצורת NetBIOS ואינו בצורת FQDN. (בכתובות IP אפשר להעמיד Kerberos כחריג על ידי הגדרת TryIPSPN בלקוח ורישום ידני של SPN לכתובת ה-IP, אבל זה מתואר כמוצא אחרון למקרים שבהם אי אפשר להשתמש בשם DNS.) תנאים נוספים שבהם Kerberos לא מתקיים: אימות במחשבי workgroup או עם חשבונות מקומיים (מחוץ ל-Active Directory מלכתחילה), אתרים שאינם יכולים להגיע ל-domain controller, ואימות מול צד שאין איתו יחסי אמון. Negotiate בוחר ב-NTLM כש-Kerberos לא זמין, וזו המשמעות של "נפילה" במקרים האלה.

מהי מתקפת NTLM relay, ולמה היא עובדת?

התוקף מפתה את הקורבן לשרת שלו ומעביר את חילוף האימות של NTLM שמגיע לשם ישירות לשרת האמיתי, ובכך מתחזה לקורבן. זה עובד כי ל-challenge/response של NTLM אין מנגנון שכובל את "למי אתם מאמתים את עצמכם". הלקוח פשוט מחשב response מה-challenge שהשרת הנפיק ומחזיר אותו, בלי דרך לבדוק אם ה-response הזה מיועד לשרת האמיתי או מועבר על ידי תוקף. Microsoft עצמה כותבת בתיעוד של הגדרת המדיניות שאימות NTLM ו-NTLMv2 פגיע למגוון תקיפות זדוניות, כולל SMB relay, מתקפות man-in-the-middle ומתקפות brute force. עם זאת, relay לא עובר לכל אחד. אם היעד דורש SMB signing, ה-signature מאשר את זהות השולח והמקבל ולכן ה-relay נכשל; כך גם בשירותים שאוכפים Extended Protection for Authentication (channel binding). מנגד, היעדים הם צדדים שמקבלים NTLM בלי signing ובלי channel binding. ב-Kerberos, ה-service ticket מוצפן עם המפתח ארוך הטווח של אותו שירות, ולכן כרטיס שמיועד לשירות אחד לא יכול להיות מפוענח על ידי אחר.

Pass-the-Hash אומר שאפשר להתחזות למישהו בלי לפצח את הסיסמה שלו?

בדיוק. ה-credentials של NTLM מורכבים משם domain, שם משתמש ו-hash חד-כיווני של הסיסמה. ב-NTLMv2, שבו Windows של ימינו משתמש, ה-response key נגזר כ-HMAC עם מפתח שהוא ה-hash של MD4 של הסיסמה (ה-NT hash), ואותו מפתח משמש לחשב HMAC על צירוף של ה-challenge של השרת, חתימת זמן, challenge מצד הלקוח ומידע על היעד. זה לא הצפנה פשוטה של ה-challenge, אבל נקודת המוצא היא עדיין ה-hash של הסיסמה. במילים אחרות, מה שהאימות צריך הוא ה-hash, ולא הסיסמה בטקסט גלוי. לכן תוקף שמצליח לחלץ את ה-hash, למשל מהזיכרון של מחשב, יכול לאמת כאותו משתמש בלי לפצח את הסיסמה. הפיכת הסיסמאות לארוכות ומורכבות יותר לא סוגרת את הנתיב הזה. אחת הסיבות ש-Microsoft מציינת לאספקת חסימת NTLM בצד לקוח SMB היא ההתמודדות עם מתקפות Pass-the-Hash.

אם אנחנו על NTLMv2, אנחנו לא מוגנים לעת עתה?

NTLMv2 חזק מ-NTLMv1, אבל הוא לא מחוץ ל-deprecation. רשימת התכונות ה-deprecated של Microsoft אומרת שכל הגרסאות של NTLM, כולל LANMAN, NTLMv1 ו-NTLMv2, נמצאות מחוץ לפיתוח פעיל של תכונות והן deprecated. מדיניות ההגבלה מתנהגת אותו דבר: מדיניות ה-audit ומדיניות החסימה מתוארות כבעלות אותה השפעה על שתי הגרסאות. לעומת זאת NTLMv1 מטופל אחרת: הוא עבר את ה-deprecation לשלב ה-removal, והוסר מ-Windows 11 גרסה 24H2 ומ-Windows Server 2025. לכן הניסוח אינו "אנחנו על NTLMv2, אז אפשר להשאיר את זה", אלא "NTLMv1 הוא דדליין כבר עכשיו; NTLMv2 צריך inventory לקראת השבתה כברירת מחדל".

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.