NTLM Relay (T1557.001)

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

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

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

מה זה NTLM, ואיך עובדת ההתחברות שלו?

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

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

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

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

אין ל-NTLM שירות רשת משלו. ההודעות שלו עוברות בתוך התוכנה שמבקשת את ההתחברות, למשל חיבור לשיתוף קבצים (SMB, הפרוטוקול ש-Windows משתמש בו כדי לשתף קבצים ברשת) או בקשת אינטרנט. Microsoft מתארת את NTLM כפרוטוקול שחוזרים להשתמש בו לרוב, כש-Kerberos, פרוטוקול ההתחברות האחר של Windows, לא זמין.

איך עובדת מתקפת NTLM relay

לפי Microsoft, מתקפת NTLM relay מתבצעת בשני שלבים: התוקף גורם לקורבן להזדהות מול נקודת קצה שהתוקף בוחר, ולאחר מכן מעביר את האימות הזה למטרה פגיעה. העברת פרטי הזדהות מאפשרת לתוקף להזדהות ולפעול בשם הקורבן.

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

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

למה התוקף לא צריך את הסיסמה

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

למה השרת מקבל התחברות שהועברה?

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

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

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

איך הקורבן מתחבר בסוף אל התוקף?

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

המשימה של התוקף, אם כך, היא לגרום לכך שהחיבור הזה יתבצע למכונה שבשליטתו. Microsoft ו-MITRE מתארות ביחד כמה דרכים:

• פגיעות או מיקום ברשת: ה-advisory של Microsoft מ-2009 אומר שהתוקף צריך פגיעות נוספת שמעמידה אותו בין שתי המכונות (מתקפת man-in-the-middle), או שעליו לשכנע את הקורבן להתחבר לשרת שבשליטתו.
• הודעה או מסמך: Microsoft אומרת שמסמכי Office והודעות אימייל שנשלחות דרך Outlook הן נקודות כניסה יעילות, כי הן יכולות להטמיע נתיבי רשת שגורמים למכונה של הלקוח להתחבר.
• הרעלת חיפושי שם (name resolution poisoning): MITRE מתארת תוקף שעונה על חיפושי שם ברשת, כך שקורבנות מתקשרים עם מכונה שבשליטת התוקף.

המסגרת ATT&CK מסווגת את הדרך השלישית, יחד עם SMB relay, תחת T1557.001, Name Resolution Poisoning and SMB Relay. הכותרת צרה יותר מהמתקפה עצמה: התיאור קובע ששלב ה-relay יכול לקרות בשילוב עם ההרעלה, אבל יכול גם להתקיים בלעדיה, וכן שאפשר להעביר את ההתחברות גם לפרוטוקולים אחרים, ולא רק ל-SMB.

מקרה מתועד אחד: פגיעות ב-Outlook מ-2023

במרץ 2023 Microsoft דיווחה על ניצול לרעה מוגבל וממוקד של פגיעות ב-Outlook for Windows, CVE-2023-23397. הודעה שנוצרה בכוונה גרמה ל-Outlook לפנות לשרת שהתוקף שלט בו, ולשלוח את ה-NTLM negotiation message של המשתמש, בלי מעורבות של המשתמש. Microsoft אומרת שהתוקף יכול היה אז להעביר את ההודעה הזו למערכות אחרות שתומכות ב-NTLM, ובהמשך היא תיארה את הרצף הזה כנקודת כניסה ב-Outlook שהועברה נגד שרת דואר Exchange. CISA מגדירה את הפגיעות הזו כפגיעות שנוצלה. הדיווח של Microsoft לא נוקב במספר הקורבנות, בנתון כולל, או בתקופת הזמן שבה זה קרה.

התיקון ב-Outlook שינה את האופן שבו Outlook משתמש בנתיב הזה. הוא לא שינה את השאלה אם שרת מקבל התחברות שהועברה - וזו השאלה שההגנות המתוארות בהמשך נותנות לה מענה.

מה התוקף יכול לעשות אחרי ה-relay?

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

• שיתוף קבצים: שרת SMB שמקבל את ההתחברות של הקורבן ב-NTLM מאפשר לתוקף לפעול שם בתור הקורבן.
• ה-directory: Active Directory מחזיקה את חשבונות המשתמשים של הרשת. LDAP הוא הפרוטוקול שמשמש לאימות משתמשים ולשליפת מידע מה-directory. התחברות שמועברת אל ה-directory נותנת לתוקף את המעמד של הקורבן ב-directory.
• שירות התעודות: Active Directory Certificate Services (AD CS) מנפיק תעודות שמשמשות להוכחת זהות. ההנחיות של Microsoft אומרות ששרת שמפעיל את שירותי ה-web enrollment שלו עלול להיות פגיע ל-NTLM relay. ההנחיות נותנות את Extended Protection for Authentication (מוסבר בהמשך, בפרק על ה-channel binding) יחד עם השבתת HTTP, כאמצעי ההפחתה המרכזי.

איך זה שונה מפיצוח סיסמאות ומ-pass the hash?

בשלוש הטכניקות האלה מעורב חומר התחברות של NTLM, אבל התוקף משתמש בחומר אחר בכל אחת מהן. רק ה-relay מצריך שההתחברות של הקורבן תתרחש בזמן שהתוקף משתמש בה.

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

מה עוצר NTLM relay, ואיפה כל הגנה מפסיקה לעבוד?

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

ה-signing

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

מפתח הסשן עצמו נגזר מהסיסמה של המשתמש. תוקף שמבצע רק relay, כלומר רק מעביר הודעות, לעולם לא מחזיק בו. בלי מפתח הסשן, התוקף לא יכול ליצור חתימות תקפות לבקשות שהוא בוחר, ולכן כשהמטרה מחייבת signing, היא דוחה את כל מה שמגיע אחרי ההתחברות שהועברה. מסמך ה-advisory של Microsoft משנת 2009 מסווג את ה-signing כאמצעי הפחתה (mitigating factor): אפליקציות שמשתמשות ב-signing של הסשן לא מושפעות מהעברת פרטי הזדהות.

המגבלות נוגעות למקום שבו הכלל הזה חל:

• ב-SMB: ה-relay מכוון לשרת, ולכן הכלל של השרת לגבי תעבורה נכנסת הוא הקובע. מהדורות Enterprise, Pro ו-Education של Windows 11 גרסה 24H2 מחייבות signing בשני הכיוונים. Windows Server 2025 מחייבת signing רק בתעבורה היוצאת, ובמהדורת Home אין חובת signing. לדרישת signing יש מחיר: Microsoft מציינת שלקוח לא יכול להתחבר לשרת של צד שלישי שלא תומך ב-signing.
• ב-LDAP: ה-signing חלה רק על סשנים שלא משתמשים ב-TLS. Windows Server 2025 מחייבת signing כברירת מחדל בפריסות חדשות של Active Directory, ואילו ב-Windows Server 2022 ובגרסאות מוקדמות יותר היא אופציונלית. שדרוג משמר את המדיניות הקיימת.

ה-channel binding

מנגנון ה-channel binding משלים את הקשר שהיה חסר. הלקוח והשרת גוזרים כל אחד טוקן מתוך סשן ה-TLS. הלקוח כולל את הטוקן שלו בהתחברות, והשרת משווה אותו לטוקן שלו. Microsoft מסבירה שסשן ה-TLS הנפרד שהתוקף מקיים מול השרת מניב טוקן שונה. לכן, כשהשרת בודק את הטוקן, בהתחברות שהועברה מופיע טוקן שלא תואם, והיא נדחית. Microsoft קוראת למנגנון הרחב יותר Extended Protection for Authentication (EPA).

גם למנגנון ה-channel binding יש מגבלות. ה-channel binding של LDAP חל רק על סשנים מוצפנים (TLS) שמשתמשים באימות SASL, שכולל גם התחברויות NTLM וגם Kerberos. ב-Windows Server 2025 מפעילים את EPA כברירת מחדל עבור AD CS. בפריסות Active Directory חדשות, מפעילים כברירת מחדל גם את ה-channel binding של LDAP, במצב ש-Microsoft מכנה "When supported". לקוחות שלא יכולים לשלוח טוקן עדיין מתקבלים, וההגדרה המחמירה יותר היא "Always". ב-Windows Server 2022 ובגרסאות שקדמו לו, מדיניות ה-channel binding של LDAP מוגדרת כברירת מחדל ל-"Never".

ה-Kerberos וכיבוי NTLM

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

סגירת נקודות הכניסה

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

מה המגינים יכולים לראות?

חלק מהתיעוד מראה איפה ההגנה חסרה. לוגי ה-domain controller של Microsoft מסכמים את פעולות ה-LDAP bind הלא חתומות שאישר. ביקורת ה-channel binding מתעדת לקוחות שמתחברים בלי טוקן. Microsoft מציגה את שניהם כאמצעי לבדיקת תאימות לקוחות, לפני אכיפת הדרישה.

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

למה עדיין משתמשים ב-NTLM, ומה משתנה?

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

פוסט שפרסמה Microsoft ב-29 בינואר 2026 מתאר תוכנית בת שלושה שלבים: השלב הראשון הוא ביקורת, שלדברי הפוסט זמינה עכשיו. השלב השני מביא תיקונים ב-Kerberos שמטפלים בסיבות הנפוצות שבגללן נדרש NTLM, ולפי אותו פוסט הוא מתוכנן למחצית השנייה של 2026. בגרסה הגדולה הבאה של Windows Server ובגרסאות הלקוח המתאימות, NTLM ברשת צפוי להיות מכובה כברירת מחדל, ולהיות מופעל מחדש רק באמצעות מדיניות מפורשת. Microsoft אומרת שהשינוי הזה לא מסיר את NTLM מ-Windows, ושלוחות הזמנים עשויים להשתנות. Windows Server 2025 ו-Windows 11 24H2 כבר הסירו את NTLMv1, והכריזו על NTLMv2 (הגרסה הנפוצה יותר מבין השתיים) כגרסה שמיועדת להוצאה משימוש.

כל עוד NTLM לא כבוי, מטרה שלא מחייבת signing ולא בודקת channel binding עדיין יכולה לקבל התחברות שהועברה.