NTLM Relay (T1557.001)

מתקפת NTLM relay מעבירה את אימות ה-NTLM של הקורבן לשירות אחר במקום לענות עליו. התוקף לעולם לא לומד את הסיסמה או את ה-hash; הוא משתמש בחילופי ההודעות החיים כדי לפעול בתור הקורבן מול SMB, LDAP, AD CS או שירות אחר שמקבל NTLM. MITRE ATT&CK עוקב אחרי נתיב ה-poisoning-plus-relay כ-T1557.001.

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

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

הערה אחת על המזהה עצמו. MITRE שינתה את שם תת-הטכניקה: T1557.001 נקראת כעת Name Resolution Poisoning and SMB Relay, בגרסה 2.0, עודכנה לאחרונה ב-12 במאי 2026, תחת Credential Access ו-Collection.

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

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

איך ה-relay עובד בפועל, ולמה NTLM עדיין כאן

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

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

• Name-resolution poisoning. התיאור של MITRE מכסה מענה לתעבורת LLMNR, NBT-NS ו-mDNS כדי "להתחזות למקור סמכותי לפתרון שמות ולכפות תקשורת עם מערכת בשליטת היריב". זה הנתיב שכותרת תת-הטכניקה מתארת.
• Coercion. משהו גורם למכונה לבצע אימות החוצה לפי דרישה. Microsoft מפורשת לגבי אחד מהם: "PetitPotam is a classic NTLM Relay Attack." המכניקה של הפעלת coercion חורגת מהיקף העמוד הזה; מה שמגן צריך לדעת הוא שהוקטור קיים, שהוא מתוקן ויש לו שם, ושהוא לא מייצר בכלל תעבורת name-resolution.

ברגע שחילופי ההודעות בידי התוקף, היעד הוא כל דבר שמקבל NTLM. MITRE מציינת שיריבים "may encapsulate the NTLMv1/v2 hashes into various other protocols, such as LDAP, MSSQL and HTTP". הייעוץ של Microsoft עצמה מוסיף את שני שירותי AD CS שחשובים ביותר בפועל, Certificate Authority Web Enrollment ו-Certificate Enrollment Web Service. קראו את זה כמלאי של דברים להגן עליהם, לא כמסלול תקיפה.

למה NTLM בכלל עדיין מופעל

דיוק חשוב כאן, כי הטון של רוב הסיקור מרמז על רשלנות. ההסבר של Microsoft עצמה מונה שלוש תכונות שהפכו את NTLM לשימושי וקשה להסרה: הוא "doesn't require local network connection to a Domain Controller", הוא "is the only protocol supported when using local accounts", והוא "works when you don't know who the target server is". התוצאה, שוב במילות Microsoft, היא ש-"these benefits have led to some applications and services hardcoding the use of NTLM". סביבה שעדיין מריצה NTLM בדרך כלל מריצה החלטת תכנון של מישהו אחר.

איזו טכניקה היא NTLM relay, בעצם?

המזהה שמצמידים למתקפה הזו הוא כמעט תמיד T1557.001 - גם התשובה ש-Bing מייצרת קוראת לו כך - והמיפוי הזה ניתן להגנה. הוא גם צר יותר מהמתקפה שהמונח מתאר, ותת-הטכניקה עצמה אומרת זאת: שלב ה-relay "can happen in conjunction with poisoning but may also be independent of it."

קראו את האנליטיקות שפורסמו ליד המשפט הזה.

השורה השלישית היא השוואה של טקסט אנליטיקה שפורסם, לא טענה שאף אחד לא מזהה coercion. כללי ספקים קיימים, והאירועים הניתנים לצפייה מפורטים בהמשך. הנקודה צרה יותר וניתנת לבדיקה: מטריצת כיסוי שמסמנת V על T1557.001 כיסתה את הנתיב שהאנליטיקה שלה צופה בו, ושרשרת ה-coercion ש-Microsoft עצמה מתעדת לא מייצרת אף אחד מהאותות שהאנליטיקה הזו מתארת.

האם Windows Server 2025 תיקן את NTLM relay?

ההודעה של Microsoft מדצמבר 2024 היא התקדמות אמיתית וראויה להיקרא ככזו. היא מתעדת שעדכון Exchange Server מפברואר 2024 "enabled Extended Protection for Authentication (EPA) by default for new and existing installs of Exchange 2019", וש-Windows Server 2025 הביא את אותה גישה לשני שירותים נוספים: EPA מופעל כברירת מחדל עבור AD CS, ו-LDAP עם channel binding מופעל כברירת מחדל. הסיכום של Microsoft הוא שהשינויים האלה "mitigate risk of of NTLM relaying attacks by default across three on-premise services" - Exchange Server, AD CS ו-LDAP. הכפילות במילה מופיעה במקור.

ואז מגיעים הסייגים, כולם מעמודי Microsoft עצמה.

שורת הכיוון היא המקום שבו יושב אי-ההבנה היקר ביותר. Relay נחסם כשהיעד דורש signing, לא כשהלקוח מציע אותו. SpecterOps, שהמחקר שלה מ-2025 הוא הטיפול המפורט ביותר בעמוד הראשון של כל אחד מהמנועים, מנסחת זאת ישירות: "configuring SMB clients to require SMB signing does not affect NTLM relay attacks."

גם כדאי לדעת מה דומיין משודרג שמר. לפני Server 2025, ברירות המחדל המתועדות של Microsoft היו LDAP signing "Optional by default; domain controllers accept both signed and unsigned LDAP binds" ו-LDAP channel binding "Set to 'Never' by default". אם בקרי הדומיין שלכם שודרגו ולא נפרסו מחדש, אלה ההגדרות שעדיין בתוקף אלא אם מישהו שינה אותן.

למה signing ו-channel binding הם התיקון

Channel binding סוגר בדיוק את הפער שהאנלוגיה מתארת. token שנגזר מערוץ ה-TLS - בפועל hash של תעודת השרת - נישא בתוך הודעת האימות, כך שהשרת המקבל יכול להשוות אותו מול התעודה שלו ולדחות כל דבר שהגיע מחיבור אחר. SpecterOps מתארת את המנגנון כך, וזו הסיבה ש-EPA הוא תיקון מבני ולא תיקון נקודתי.

הרעיון קדם לכלי התקיפה

RFC 5929, "Channel Bindings for TLS", שפורסם ביולי 2010, מגדיר את סוגי ה-binding שמאפשרים את זה, "in accordance with RFC 5056 (On Channel Binding)". אף אחד מהמנועים לא מצטט אותו בעמוד הראשון למונח הזה.

זה גם מסביר שורה בהנחיות AD CS של Microsoft שבלי זה נראית כמו חגורה וכתפיות. EPA זמין מעל HTTPS ולא מעל HTTP רגיל, כי ל-HTTP אין ערוץ מאובטח לקשור אליו. לכן הייעוץ של Microsoft קובע את שני החצאים: "enabling EPA and disabling HTTP on AD CS servers", ועוד "Enable Require SSL".

Signing ו-channel binding עונים על חצאים שונים של אותו פער מבני. Signing מגן על הסשן אחרי האימות; channel binding מגן על האימות עצמו.

ה-CVEs, מול המקורות הראשוניים

שלושה מזהים מסתובבים בסיקור של המתקפה הזו. בבדיקה ב-NVD וב-JSON feed של Known Exploited Vulnerabilities של CISA, ולא בסיכום משני, לא כולם אומרים את מה שהסיקור מרמז.

שני דברים נובעים מהטבלה הזו. שניים מתוך השלושה נמצאים בקטלוג KEV, עם מועדי תיקון פדרליים שכבר חלפו - וזו טענת דחיפות שניתנת להגנה הרבה יותר מכל הערכת ספק. והרשומה של CISA עצמה ל-CVE-2025-33073 מתארת את חצי ה-coercion במילים פשוטות, ומציינת שתוקף "could execute a specially crafted malicious script to coerce the victim machine to connect back to the attack system".

השלישי הוא התיקון. כותרת שהסתובבה בהרחבה קוראת ל-CVE-2025-54918 עקיפת אימות LDAP; NVD מתעדת אותה כ-improper authentication ב-Windows NTLM, על ידי תוקף מורשה, והיא לא בקטלוג הפגיעויות המנוצלות.

איך מזהים מתקפת NTLM relay?

התחילו ממה שהאנליטיקות שפורסמו צופות בו, כי זה קובע כמה שווה טענת הכיסוי הקיימת שלכם: `AN1274` מתארת תעבורת name-resolution בפורטי LLMNR ו-NBT-NS, ו-`AN0065` מתארת קובץ פיתיון ואחריו אימות יוצא. שניהם אותות אמיתיים. אף אחד מהם לא נוכח ב-relay שנכפה דרך RPC.

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

• אימות שלא תואם את מקורו. חשבון שמבצע אימות ממארח שאינו המארח הרגיל שלו הוא הצורה הגנרית של logon שעבר relay, כי האימות אמיתי ורק המקור שגוי.
• חשבונות מכונה שמגיעים ליעדים שאין להם מה לחפש בהם. Coercion גורם לשרת או לבקר דומיין לבצע אימות החוצה לפי דרישה, וזו בדיוק ההתנהגות שתיאור ה-KEV של CVE-2025-33073 מאפיין.
• הנפקת תעודה ממבקש לא צפוי בשני ה-endpoints של AD CS ש-Microsoft מציינת, כי enrolment שעבר relay מייצר תעודה לגיטימית שהונפקה למבקש הלא נכון.

פיסת עזרה אחת מהפלטפורמה כדאי להפעיל לפני שאוכפים משהו: ב-Windows Server 2025, LDAP channel binding auditing מופעל כברירת מחדל, וכך מוצאים את הלקוחות שלא יכולים לתמוך בבקרה שאתם מתכננים לדרוש.

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

NTLM relay מול pass-the-hash מול coercion

שלושת אלה מופיעים באותם דוחות, וההבדל הכי קל להחזיק אם שואלים שאלה אחת: מה התוקף באמת מחזיק ביד?

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

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

מה המחיר של הפעלת זה

לאכיפה יש מחיר אמיתי, ו-Microsoft מציינת אותו במקום להסתיר אותו: "if your environment uses third-party servers and the third-party server doesn't support SMB signing, you can't connect to the remote share." שימו את המשפט הזה בבקשת השינוי. זה המשפט שמנבא את התקרית.

הנתיב המומלץ של Microsoft עצמה הוא מדורג ולא מיידי. הנחיות ה-LDAP שלה אומרות להתחיל ב-"Start with 'When supported' for channel binding and 'Negotiate signing' for signing, then move to full enforcement after validating compatibility", עם ניטור אירועים באמצע. הספקית ששחררה את ברירות המחדל המוקשחות אומרת לכם לבצע audit לפני שאתם אוכפים.

איפה "כיבוי NTLM" באמת יושב

ב-Windows Server 2025 ו-Windows 11 24H2, NTLMv1 הוסר ו-NTLMv2 הוצא משימוש (deprecated), ומנהלי מערכת יכולים כעת להגדיר את SMB לחסום NTLM. Deprecated אינו כבוי, ועבודת ההחלפה עדיין נוחתת: התשובה של Microsoft למקרים שבהם לא ניתן היה קודם להשתמש ב-Kerberos היא IAKerb ו-local KDC, והטענה שלה לגבי הראשון היא שהוא "relies on the cryptographic security guarantees of Kerberos to protect the messages in transit through the server to prevent replay or relay attacks".

כיבוי NTLM הוא תוכנית, לא אחר צהריים של יום שישי. הוא מתחיל במלאי, וזה אותו מלאי שנתוני ה-audit למעלה מייצרים.

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

אין נתון שכיחות שפורסם. אין חלק מדוד של סביבות שחסרות בהן inbound SMB signing, EPA או LDAP channel binding, עם גודל מדגם ושיטה מצורפים. אם צריך מספר לשיחת סיכונים, הפיקו אותו מהסביבה שלכם במקום לאמץ מספר ממקור אחר.

יש מקור ממשלתי ראשוני שהמאמר הזה לא נשען עליו. שש סוכנויות, בראשות 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". המסמך עצמו לא היה ניתן לשליפה מהמקום שבו בוצע המחקר הזה, כך ששום דבר כאן לא לקוח ממנו. קראו אותו ממקור ראשון.

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

שאלות נפוצות

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

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

אנחנו על Windows Server 2022. האם משהו מההגנה החדשה כברירת מחדל חל עלינו? לא. ברירות המחדל שמתוארות כאן מגיעות עם Windows Server 2025, ועבור Exchange עם עדכון 2019 מפברואר 2024. ב-Windows Server 2022 אותן הגנות זמינות אבל צריך להגדיר אותן, וזה מה שהייעוץ של Microsoft על AD CS מתאר.

אם משדרגים בקר דומיין מ-2019 ל-Server 2025, האם ברירות המחדל החדשות של LDAP חלות? לא. התיעוד של Microsoft מפורש: התקנות שדרוג שומרות על הגדרות אבטחת ה-LDAP הנוכחיות שלהן כדי למנוע שיבוש. ברירות המחדל המוקשחות מיועדות לפריסות חדשות, כך שבקר דומיין משודרג שומר על מה שהיה לו אלא אם מישהו משנה זאת במכוון.

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

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

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

1. בדקו inbound SMB signing על המערכות שיהיו יעדי relay, לא על הלקוחות. הכיוון הוא החלק שמתפספס.
2. בדקו את רמת הגדרת ה-EPA ב-AD CS web enrollment וב-LDAP, במקום רק האם EPA קיים בכלל. "When Supported" ו-"Always" הן בקרות שונות.
3. קבעו האם כל דומיין נפרס מחדש על Server 2025 או שודרג אליו. שדרוגים שמרו על הגדרות ה-LDAP הישנות.
4. אמתו ששתי רשומות ה-KEV מתוקנות - CVE-2025-24054 ו-CVE-2025-33073, שתיהן אחרי מועדי היעד הפדרליים שלהן.
5. בדקו למה תוכן הזיהוי שלכם ממופה, והאם האנליטיקה הזו תופעל עבור הנתיב שאכפת לכם ממנו.

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