Golden SAML

מתקפת Golden SAML היא מתקפה שבה תוקף גונב את המפתח הסודי שארגון משתמש בו כדי לחתום על טוקני ההתחברות היחידה (single sign-on) שלו. באמצעות המפתח הגנוב, התוקף מזייף טוקנים חדשים. שירותים שנותנים אמון במפתח הזה מקבלים טוקן מזויף כהוכחה לכך שמשתמש שהתוקף בחר התחבר, אף שמערכת הזהויות של הארגון מעולם לא ביצעה את ההתחברות הזו.

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

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

איך עובדת התחברות בשיטת SAML, ומה התפקיד של מפתח החתימה?

ארגונים רבים מאפשרים לאנשים להתחבר פעם אחת, ואז לגשת לשירותים רבים. השירות עצמו לא בודק את האדם. הוא מסתמך על טוקן ההתחברות, הצהרה חתומה וקטנה שספק הזהויות של הארגון מנפיק אחרי שבדק מי האדם. SAML (Security Assertion Markup Language) הוא תקן שמגדיר את הפורמט של הטוקן הזה, שהתקן מכנה assertion. טוקן טיפוסי אומר שהמשתמש הוא אדם נקוב בשמו, עם כתובת אימייל, שהזדהה באמצעות סיסמה.

ההסתמכות הזו נקראת אמון, וקבוצת דומיינים שביניהם נוצר אמון כזה נקראת פדרציה (federation).

תצורה נפוצה אחת משאירה את האימות על שרתי הארגון עצמו, בעזרת תוכנה כמו Active Directory Federation Services (AD FS). תצורה כזו גם מקיימת פדרציה עם Microsoft Entra ID, שירות הזהויות בענן של Microsoft.

למה שירות מאמין לטוקן?

אמון חייב להתבסס על משהו שהשירות יכול לבדוק, והדבר הזה הוא חתימה דיגיטלית. שרת הפדרציה חותם על כל טוקן שהוא מפיק, באמצעות מפתח פרטי. השירות בודק את החתימה באמצעות המפתח הציבורי המתאים, שהשירות מקבל בתוך תעודה שהוא מוגדר לתת בה אמון. AD FS מכנה את התעודה הזו תעודת חתימת הטוקנים (token-signing certificate). לפני שהשירות קורא את תוכן הטוקן, הוא בודק את תקינות החתימה.

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

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

איך עובדת מתקפת Golden SAML?

מתקפת Golden SAML היא מתקפת שלב שני, שמחייבת דריסת רגל עמוקה מראש במערכת שמחזיקה את מפתח החתימה. ההתראה של CISA על קמפיין ה-SolarWinds מתארת תוקף שפרץ לתעודת החתימה של SAML, בעוד שכבר השיג הרשאות גבוהות ברשת הקורבן. ההנחיות של Mandiant אומרות שאם תוקף משיג גישה בדרגה הגבוהה ביותר לשרת AD FS, יש להתייחס למפתח החתימה כאל מפתח נפרץ.

מה המפתח מאפשר לתוקף לעשות

עם המפתח, התוקף יכול לזייף טוקנים. MITRE ATT&CK, הקטלוג הציבורי של טכניקות תקיפה, אומרת שתוקף יכול לזייף טוקני SAML "עם הצהרות הרשאה ומשכי תוקף כלשהם", בתנאי שיש לו תעודת חתימת טוקנים תקפה. העמידה בתנאי הזה דורשת גם את המפתח הפרטי התואם, כיוון שרק המפתח הפרטי חותם. ההצהרות שבטוקן (claims) הן מה שהטוקן מציין על המשתמש, למשל לאיזה חשבון הוא מתייחס ומה אותו חשבון מורשה לעשות. התוקף הוא זה שבוחר את ההצהרות, ויכול לבחור גם הצהרות של חשבון עם הרשאות גבוהות.

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

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

האם מתקפת Golden SAML עוקפת אימות רב-גורמי?

מתקפת Golden SAML יכולה לעקוף אימות רב-גורמי - במקרה שבו השירות בענן מאמין לטענה של הטוקן לגבי איך המשתמש התחבר. אימות רב-גורמי (MFA) הוא שיטת התחברות שמחייבת גורמים משתי קטגוריות שונות לפחות: משהו שאתם יודעים, כמו סיסמה; משהו שיש לכם, כמו טלפון או מפתח חומרה; או משהו שאתם, כמו טביעת אצבע. שתי סיסמאות שייכות לאותה קטגוריה, ולכן שימוש בהן לא נחשב אימות רב-גורמי. MITRE מתעדת שבקמפיין ה-SolarWinds קבוצת התקיפה APT29 השתמשה בטוקני SAML מזויפים "שאפשרו לתוקפים להתחזות למשתמשים ולעקוף את האימות הרב-גורמי".

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

מה ההגדרה של Microsoft משנה

התשובה של Microsoft היא הגדרה שנקראת federatedIdpMfaBehavior. כשההגדרה מוגדרת לערך rejectMfaByFederatedIdp, Microsoft Entra ID תמיד מבצע בעצמו את האימות הרב-גורמי, ודוחה אימות רב-גורמי שהספק המקומי בפדרציה מבצע. Microsoft אומרת שכאשר Entra ID אוכף בעצמו אימות רב-גורמי בכל פעם, זה מבטיח שתוקף לא יכול לעקוף אותו בהתחזות לספק שכבר ביצע אימות רב-גורמי. Microsoft גם ממליצה בחום להשתמש בהגדרה הזו, אלא אם ספק אימות רב-גורמי של צד שלישי מבצע את האימות מטעם המשתמשים המחוברים לפדרציה. התיעוד מגביל את ההגנה הזו לאפליקציות שמנהל המערכת הגדיר להן מדיניות Conditional Access המחייבת אימות רב-גורמי.

ההגדרה הזו היא של Microsoft, ונוגעת להתחברויות ל-Entra ID; היא לא קובעת מה שירותים אחרים עושים עם טוקן מזויף. Mandiant מציינת שמפתח חתימה של AD FS שנפרץ משפיע על כל שירות שסומך עליו, ולא רק על שירותי Microsoft עצמה.

האם טוקן מזויף זהה לסשן שנגנב?

לא. בפישינג מסוג adversary-in-the-middle (AiTM), עמוד התחברות מזויף מעביר את ההתחברות של המשתמש. התוקף מעתיק את עוגיית הסשן, ההוכחה של השירות לכך שהמשתמש התחבר. בכך הוא גונב סשן (session), כלומר המצב שבו האתר מזהה את המשתמש כמחובר. MITRE אומרת שהטוקנים במתקפת Golden SAML "חדשים, והתוקף זייף אותם, ולא גנב או יירט אותם ממשתמשים לגיטימיים". גניבה מעתיקה הוכחת התחברות שהנפיק שירות אמיתי. זיוף יוצר הוכחת התחברות שאף אחד לא הנפיק.

לאיזו טכניקה של MITRE שייכת מתקפת Golden SAML?

את הזיוף מתעדת MITRE תחת T1606.002, Forge Web Credentials: SAML Tokens. מתקפת Golden SAML מופיעה לרוב לצד מזהה אחר, T1484.002, Trust Modification, אך מדובר בשתי טכניקות נפרדות.

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

שני המסלולים, נבדלים זה מזה

לכן יש שני מסלולים המובילים לטוקן שהשירות מקבל: להשתמש במפתח הקיים, או לגרום לשירות לתת אמון במפתח חדש. העמוד של MITRE על קמפיין SolarWinds מבחין ביניהם לפי הניסוח: טוקנים שנוצרו "בשימוש בתעודות חתימת SAML שנפרצו" משתייכים ל-T1606.002. הגדרת הדומיין כך שיקבל טוקנים "חתומים בתעודת חתימת SAML משלהם" משתייכת ל-T1484.002. מתקפת Golden SAML היא המסלול הראשון, זה שמשתמש במפתח החתימה הנפרץ. השם מגיע ממחקר של CyberArk שפורסם בנובמבר 2017, ו-MITRE מצטטת אותו. חברת האבטחה Semperis מתארת את הטכניקה כשימוש בתעודות חתימה שנלקחו מ-AD FS לזיוף תגובות התחברות.

מה הקמפיין של SolarWinds הראה?

את הפריצה של SolarWinds מתעדת MITRE כאירוע שאותר לראשונה באוגוסט 2019 ונראה לאחרונה בינואר 2021, ומייחסת אותה ל-APT29. היא מתעדת גם את שני המסלולים כחלק מהקמפיין הזה. התראת CISA, שעודכנה לאחרונה ב-15 באפריל 2021, מתארת אחת משיטות התוקף - את המסלול הראשון. בשיטה הזו, התוקף פורץ לתעודת החתימה של SAML, יוצר טוקנים "לא מורשים אך תקפים", ומציג אותם בפני שירותים שסומכים על טוקני SAML מהסביבה. CISA מציינת שלאחר מכן אפשר להשתמש בטוקנים האלה כדי לגשת למשאבים כמו אימייל.

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

איך מגינים מזהים טוקן מזויף?

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

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

האותות האלה תלויים ברישום לוגים שמתעד את האירועים שמשווים ביניהם. MITRE מפרסמת את כללי הזיהוי, לא את התדירות שבה הם תופסים זיוף.

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

אילו הגנות משנות את התוצאה, ואיפה הגבול שלהן?

ההגנות שלהלן מתמקדות בשתי נקודות: מפתח החתימה, ומה שהשירות מאמין לגבי הטוקן.

• להשאיר את המפתח בלתי נגיש: MITRE מונה את הגבלת ההרשאות והגישה לשרת AD FS, ואת הפעלת הביקורת המתקדמת ב-AD FS. Mandiant ממליצה להתייחס ל-AD FS כאל תשתית זהויות מהדרג הגבוה ביותר, ולהעביר את תעודות חתימת הטוקנים למודול אבטחת חומרה (hardware security module). כך המפתח הפרטי לא יהיה קיים באחסון בשרת שתוכנה יכולה לגשת אליו. Mandiant דיווחה ביולי 2026 על ממצא מתוך תרגיל Red Team. כאשר מבטלים רוטציה אוטומטית של תעודות ומחליפים אותן ביד, נוצרת סטייה בתצורה (configuration drift), כלומר מצב שבו ההגדרות בפועל אינן תואמות את ההגדרות שהוגדרו במקור. סטייה כזו יכולה להשאיר מפתח חתימה פעיל חשוף. למגינים, האופן שבו מחליפים ומאחסנים את המפתחות יכול לקבוע אם המפתח יישאר בלתי נגיש.
• להחליף את תעודת החתימה פעמיים אחרי חשד לזיוף: כדי לבלום את ההשפעה של טוקן מזויף, MITRE ממליצה להחליף את התעודה פעמיים ברצף מהיר. לטענתה, הפעולה הזו הופכת לבלתי תקפים טוקנים שנוצרו באמצעות התעודה הקודמת. Microsoft מסבירה מדוע נדרשת החלפה כפולה: Entra ID ממשיך לשמור מידע על התעודה הקודמת. בלי תעודה שנייה, יכול להיות שהתעודה הישנה עדיין יכולה לאמת משתמשים. הרוטציה יכולה גם לגרום להפסקת שירות בזמן שיחסי האמון מתעדכנים. הסרת האמון במפתח הנפרץ נועדה לגרום לשירותים להפסיק לקבל assertions שנחתמו באמצעותו, אבל היא לא בהכרח מסיימת סשנים או טוקנים שהונפקו קודם לכן, אחרי התחברות מוצלחת. לכן מוסיף המדריך של Microsoft שלב נפרד: ביטול טוקני הרענון של המשתמשים (revocation of refresh tokens). לפי המדריך, הפעולה הזו מחייבת את המשתמשים להתחבר מחדש, ומנתקת אותם מטלפונים, מסשני דואר אינטרנטי נוכחיים ומכל מקום אחר שמשתמש בטוקנים. ההתאוששות כוללת גם ניתוק גישת התוקף, וביטול סשנים וטוקנים שנפגעו בכל שירות שמאפשר זאת; רוטציית התעודה בלבד לא משלימה את התהליך.
• לגרום לשירות הענן לבקש אימות רב-גורמי בעצמו: ההגדרה federatedIdpMfaBehavior שתוארה לעיל, עם המגבלות שניתנו שם.
• לעבור מפדרציה להתחברות בענן: Microsoft מפרסמת מדריך למעבר מדומיין שמשתתף בפדרציה להתחברות בענן. Mandiant מציינת שההתרחקות מפדרציה המבוססת על AD FS מסירה את דרך התקיפה הספציפית הזו.

המעבר הזה לא מסיר את המגבלה המרכזית: טוקן מזויף מתבסס על מי שמחזיק במפתח החתימה. Entra ID מספק תעודת חתימה משלו, אבל ארגון יכול לייבא תעודה שנוצרה במקום אחר. חברת האבטחה Semperis הראתה בפברואר 2024, בשם Silver SAML, שתוקף שמשיג את המפתח הפרטי של התעודה המיובאת יכול לזייף תגובות SAML באותה צורה. Microsoft השיבה שהמקרה הוערך כפעולה לפי התכנון המקורי, ולא עמד בסף הדרוש לטיפול מיידי.

בספטמבר 2026 NIST ו-CISA פרסמו הנחיות סופיות להגנה על טוקני זהות ועל assertions מפני זיוף, גניבה ושימוש לרעה. ההנחיות כוללות המלצות בנושא ניהול מפתחות, בדיקת תקינות הטוקנים ובקרות מחזור חיים.