Golden SAML

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

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

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

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

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

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

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

Golden SAML זה בדיוק זה, רק עם תעודת חתימה קריפטוגרפית במקום שעווה.

שתי הטכניקות, ואיזו מהן היא golden SAML

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

ההבדל הוא מה התוקף היה צריך להשיג קודם.

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

T1606.002 Forge Web Credentials: SAML Tokens מתארת את הזיוף עצמו, ונפתחת כך: "גורם איום עשוי לזייף טוקני SAML עם כל טענות ההרשאות וכל משכי התוקף אם ברשותו תעודת חתימה תקפה על טוקני SAML." זה גם העמוד שבו MITRE מצטטת את מחקר 2017 שטבע את השם golden SAML.

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

MITRE עצמה מפרידה ביניהן, באותו קמפיין

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

• תחת T1484.002, APT29 "שינתה את הגדרות אמון ה-federation של הדומיין באמצעות הרשאות ניהול ב-Azure AD, כדי להגדיר שהדומיין יקבל טוקני הרשאה שנחתמו על ידי תעודת החתימה על SAML שלהם".
• תחת T1606.002, הקבוצה "יצרה טוקנים באמצעות תעודות חתימה על SAML שנפרצו".

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

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

גבול אחד כנה. T1606.002 מציינת גם שגורם איום עם מספיק הרשאות "כדי להקים יחס federation חדש מול שרת Active Directory Federation Services (AD FS) משלו" עשוי "לייצר תעודת חתימה מהימנה משלו", כך שיש חפיפה בקצוות. השאלה שמפרידה ביניהן היא האם התעודה הקיימת שלכם נפרצה.

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

איך golden SAML עובדת בפועל

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

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

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

התיעוד של MITRE על מה ש-APT29 לקחה בפועל הוא הגרסה המוחשית: תחת טכניקה נפרדת לפרטי הזדהות לא מאובטחים, הקבוצה "השיגה מפתחות PKI, קבצי תעודות ואת מפתח ההצפנה הפרטי משרת Active Directory Federation Services". חומר החתימה הוא היעד, ושרת ה-AD FS הוא המקום שבו הוא נמצא.

הטקטיקה זזה, ורוב המקורות עוד לא

תיקון קטן יותר, וקל לבדוק אותו.

T1484.002 היא כרגע גרסה 3.0, עודכנה לאחרונה ב-12 במאי 2026, והטקטיקות שלה הן עכשיו Defense Impairment ו-Privilege Escalation. Defense Impairment היא TA0112, טקטיקה שנוצרה ב-14 באפריל 2026 ונושאת כיום 18 טכניקות. MITRE מתארת אותה ככזו שמכסה יריבים ששוברים מנגנוני אבטחה וכלי הגנה "כדי שמגינים לא יוכלו לראות או לסמוך על מה שקורה".

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

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

למה כלל הזיהוי שלכם נשאר שקט

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

אסטרטגיית הזיהוי של T1484.002, DET0458, מכסה שינויים ביחסי אמון. שני ה-analytics שלה מחפשים בדיוק את זה:

• AN1259 מנטר שינויים בהגדרות אמון דומיין ב-Active Directory דרך `netdom`, `nltest` או PowerShell, ושינויים במאפייני אובייקטים כמו `trustDirection`, `trustType` ו-`trustAttributes`.
• AN1260 מנטר הוספה של ספק זהויות מאוגד (federated), או מעבר של דומיין ב-tenant מ-Managed ל-Federated, דרך אירועים כמו `Set domain authentication`, `Add federated identity provider` ו-`Update-MsolFederatedDomain`.

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

ה-analytics שמתאימים יושבים תחת T1606.002, באסטרטגיית הזיהוי DET0148. חמישה מהם, והראשון הוא הרעיון שעליו נשען כל העמוד:

• AN0418 מתאם טוקנים עם חתימה תקפה מול היעדר אירועי הזדהות Kerberos. החתימה טובה, אבל ההזדהות שהייתה אמורה לייצר אותה מעולם לא קרתה.
• AN0419 מחפש הזדהות חוצת-ענן או חוצת-חשבון בלי אירועי STS תואמים.
• AN0420 מחפש גישה ליישום מאוגד בלי פעילות Kerberos רגילה.
• AN0421 מחפש התחברויות SaaS שמצליחות בלי MFA, או עם טענות טוקן לא עקביות.
• AN0422 מחפש token replay בין יישומי Microsoft 365, או גישה לתיבת דואר עם הרשאות גבוהות בלי התחברות אינטראקטיבית.

שום דבר מזה לא הופך את ה-analytics של שינוי האמון לחסרי ערך. הם מדויקים בדיוק למסלול השני, והמסלול הזה חי וקיים: בייעוץ של CISA על Scattered Spider מתועד שאותם תוקפים הוסיפו ספק זהויות מאוגד ל-tenant ה-SSO של היעד. תוכנית זיהוי בוגרת רוצה את שניהם. הם מכסים חצאים שונים.

פגיעות ה-AD FS בחדשות, בפרופורציה

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

CVE-2026-56155 אמיתית והיא רצינית. CISA הוסיפה אותה לקטלוג Known Exploited Vulnerabilities ב-14 ביולי 2026 עם מועד יעד לתיקון ב-28 ביולי 2026, והמוצר הוא Active Directory Federation Services.

מה שהיא לא, זה פגם בזיוף טוקנים. CISA מכנה אותה "Insufficient Granularity of Access Control Vulnerability" ומתארת אותה ככזו שמאפשרת "לתוקף מורשה להסלים הרשאות באופן מקומי". גם רשומת ה-NVD מסכימה, ומדרגת אותה CVSS 7.8 עם הווקטור `AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`: וקטור תקיפה מקומי, שדורש הרשאות שכבר בידי התוקף. כמה סיכומים שמסתובבים קוראים לה zero-day לזיוף טוקנים ב-AD FS. אף אחד משני התיעודים הסמכותיים לא תומך בתיאור הזה.

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

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

מה לשנות, וכמה זה עולה

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

בדקו את `federatedIdpMfaBehavior`, והבינו את ברירת המחדל שלו. בהגדרות ה-federation של Microsoft יש הגדרת אבטחה שקובעת האם Entra ID סומך על הטענה של ספק זהויות מאוגד ש-MFA כבר בוצע. היא מקבלת שלושה ערכים: `acceptIfMfaDoneByFederatedIdp`, `enforceMfaByFederatedIdp`, ו-`rejectMfaByFederatedIdp`, כשהאחרון אומר ש-Entra ID "תמיד מבצעת MFA ודוחה MFA שספק הזהויות המאוגד ביצע". התיעוד של Microsoft עצמה מנסח את המטרה בבהירות: אכיפת MFA בכל פעם "מבטיחה שגורם זדוני לא יוכל לעקוף את Microsoft Entra multifactor authentication על ידי חיקוי של ספק הזהויות שכבר ביצע MFA".

ואם לא הוגדרו מעולם לא ההגדרה הזו ולא המאפיין הישן יותר `SupportsMfa`, Entra ID נופלת לברירת המחדל `acceptIfMfaDoneByFederatedIdp`. טוקן מזויף טוען בדיוק ש-MFA כבר בוצע. זה גם ההיקף הכנה של הטענה הנפוצה ש-golden SAML מדלגת על MFA לגמרי: עם הגדרת ה-reject במקום, Entra מבצעת MFA משלה בלי קשר למה שהטוקן טוען. אפשר לקרוא את הערך הנוכחי שלכם עם `Get-MgDomainFederationConfiguration`.

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

צדו לפי ה-analytics שמתאימים, החל מהתיאום מול היעדר Kerberos ב-AN0418, והפעילו auditing מתקדם ב-AD FS כדי שאירועים כאלה בכלל יהיו קיימים לתיאום.

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

כמה זה עולה, ואיפה זה נעצר

ההגירה היא עבודה אמיתית, וההנחיות של Microsoft עצמה כנות לגביה:

• המרת הדומיין "עשויה להימשך עד 60 דקות", שבמהלכן ייתכן שמשתמשים לא יתבקשו להזין פרטי הזדהות.
• התאמות `onload.js` "לא ניתנות לשכפול ב-Microsoft Entra ID".
• חוויית ההתחברות משתנה, ואי אפשר להתאים אותה באותו אופן.
• Rollback אומר להמיר דומיינים מנוהלים בחזרה ל-federated, וזה דורש תכנון לפני שמתחילים ולא אחרי.

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

וגם ה-CVE למעלה לא מצדיק, כשלעצמו, הגירת חירום. תיקנו אותו, ואז תכננו את המעבר לפי השיקולים שלו.

מה העמוד הזה לא יודע

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

עוד שלושה גבולות:

• זרם העבודה הממשלתי הנוכחי הוא טיוטה. NIST ו-CISA פרסמו את "Protecting Tokens and Assertions from Forgery, Theft, and Misuse" ב-22 בדצמבר 2025 להערות ציבור עד 30 בינואר 2026. גרסה סופית לא אותרה, ולכן העמוד מתאר אותה כטיוטה ולא מעבר לכך.
• MITRE מפרסמת analytics לזיהוי, לא את שיעורי התפיסה שלהם וגם לא פרופילי false-positive. כמה רועש AN0418 בסביבה גדולה, רק הסביבה הזו יכולה לענות.
• מחקר 2017 שטבע את המונח כבר לא נפתח. שני הפוסטים המקוריים מפנים עכשיו לעמוד מוצר אחרי רכישה. הייחוס שורד דרך הציטוט של MITRE, אבל טקסט המקור לא קריא בכתובת המקורית, ולכן שום דבר כאן לא מצטט אותו. זו בעיית link-rot, לא ביקורת על אף אחד.

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

שאלות נפוצות

האם golden SAML היא T1484.002 או T1606.002? T1606.002, אם התוקף השתמש בתעודת החתימה על הטוקנים הגנובה של הארגון שלכם. T1484.002 אם הוא הוסיף יחס אמון או תעודה משלו. פריצות אמיתיות רבות כוללות את שתיהן, ולכן MITRE ממפה את פעילות APT29 ב-SolarWinds לשתי הטכניקות.

האם צריך לבנות מחדש את מיפויי ה-ATT&CK הקיימים? בדרך כלל לא. אם המיפוי שלכם כבר נושא את שתי הטכניקות, הוא תקין. מה שכן שווה לבדוק מחדש זה את הטקטיקה, כי T1484.002 עברה ל-Defense Impairment בתיקון מאי 2026, וכל תוכן זיהוי שנבנה רק על ה-analytics של שינוי האמון.

האם CVE-2026-56155 היא פגיעות golden SAML? לא. זו הסלמת הרשאות מקומית ב-AD FS, מדורגת CVSS 7.8 עם וקטור תקיפה מקומי. היא חשובה כאן כי שרת ה-AD FS מחזיק את מפתח החתימה, כך שהיא נתיב אל התעודה ולא דרך לזייף טוקנים.

האם מעבר מ-AD FS ל-Entra ID פותר את זה? הוא מסיר את השרת המקומי שמחזיק את מפתח החתימה, וזו הפחתה משמעותית. הוא לא מבטל זיוף SAML כקטגוריה, כפי ש-Silver SAML הראתה עבור tenants שמשתמשים בתעודות חתימה שנוצרו חיצונית.

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

מאיפה מתחילים

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

קראו את הגדרת ה-federation שלכם. הריצו `Get-MgDomainFederationConfiguration` עבור כל דומיין מאוגד ובדקו את `federatedIdpMfaBehavior`. אם הוא מעולם לא הוגדר, אתם על ברירת המחדל שסומכת על טענת ה-MFA שבטוקן.

קראו את ה-analytics שמתאימים. פתחו את T1606.002 ועברו על AN0418 עד AN0422. אם תוכן הזיהוי שלכם למתקפה הזו נבנה מה-analytics של T1484.002, הפער הזה הוא העבודה.

אמתו את התיקון. מועד היעד של CVE-2026-56155 ב-KEV עבר ב-28 ביולי 2026.

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