כאשר מדברים על טוקנים ובפרט מול Entra ID, איזה אסוציאציה עולה לך? גניבת עוגיות, אולי Browser Session או CSRF token, או בכלל איך תוקפים או מנטרים? ישנם סוגים שונים של טוקנים, החל מטוקן גישה, דרך טוקן ברמת MFA ועד טוקן ״משפחתי״ ולאלה יש ערכי משנה. בקיצור, לא כל הטוקנים נוצרו שווים.

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

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

סוגי טוקנים

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

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

טוקן גישה (Access Token)

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

טוקן רענון (Refresh Token)

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

טוקן זיהוי (ID Token)

• נועד לאמת את זהות המשתמש מול יישומי הענן.
• מכיל את פרטי המשתמש (כמו,UPN, מזהה ייחודי ועוד), ונמסר לאחר שהמשתמש מאמת את זהותו מול Entra ID.
• משמש בעיקר בתהליכי SSO ומכיל נתונים אשר מזהים את המשתמש מול היישום.

טוקן SAML – טוקן המבוסס על פרוטוקול SAML, המשמש להעברת מידע של הזהות בין Service Provider לבין Entra ID (רכיב Identity Provider).

תהליך לוגין – היבטי טוקן

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

בקשת אימות (Authentication Request)

כאשר משתמש מתחבר לשירות הענן של Microsoft 365 או ליישום הוא עושה זאת דרך Entra ID. בזמן גישה המשתמש שולח בקשה לאימות מול Entra ID. בקשה זו כוללת:

• מזהה האפליקציה (Client ID).
• כתובת החזרה (Redirect URI) לאן לשלוח את התשובה לאחר האימות.
• סוג הטוקן המבוקש (למשל, id_token או code בהתאם לפרוטוקול).

אימות זהות המשתמש

• Entra ID מציג דף כניסה שבו המשתמש מזין את פרטי ההזדהות (כמו, UPN וסיסמה, MFA וכן הלאה).
• תהליך זה מסתיים באימות זהות המשתמש מול Entra ID, ובמידה והאימות הצליח, יונפק Authorization Code או ID Token.

קבלת טוקן זיהוי (ID Token)

לאחר שהמשתמש מזוהה, Entra ID מנפיק ID Token המועבר חזרה ליישום וזה ייעשה דרך ערך חשוב מאוד של Redirect URI שמוחזר בבקשה המקורית. טוקן זה מכיל מידע בעל ערך על המשתמש, בין היתר:

• שם המשתמש.
• מזהה ייחודי (User ID).
• תוקף הטוקן (מדקות ועד שבועות/חודשים).

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

בקשת טוקן גישה (Access Token)

לאחר קבלת ID Token, הסרוויס/אפליקציה שולח בקשה להנפקת Access Token על מנת לאפשר למשתמש גישה ליישום הנדרש. בקשה זו כוללת את Authorization Code שהוחזר מוקדם יותר ואת מזהה האפליקציה.

קבלת טוקן גישה (Access Token)

בשלב זה, Entra ID מנפיק Access Token, אשר נועד לגישה ישירה ליישום הנדרש. טוקן זה הוא בעל תוקף קצר (לרוב כשעה) וכולל בין היתר את הערכים הבאים:

• מזהה המשתמש.
• דרישות (Claims) המייצגות הרשאות.
• הרשאות גישה לשירותים השונים.

שימוש בטוקן גישה

היישום עושה שימוש בערך Access Token כדי לבצע גישה, ולכן, בכל פעם שהיישום פונה למשאב, הוא מצרף את הטוקן ברמת header, זה נעשה ברמת הערך של  Authorization: Bearer <Access Token>.

רענון טוקן גישה (Refresh Token)

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

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

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

איזה טוקן שווה לתקוף?

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

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

בעולם המגוון ואולי הסבוך של טוקנים ישנו מושג נוסף שנקרא bearer token. אפשר לראות אותו בכל הסנפה וובית, ובטח במקרים של תקיפות מסוג pass the cookie או pass the prt. הערך יהיה בשימוש כאשר מעתיקים את כלל הדרישה וכוללים את הערך של bearer.

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

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

השאלה המתבקשת היא, מהם הטוקנים שהוזכרו מעלה עושה בשימוש או משולב בו bearer token? ובכן, כמעט בכל אחד.

• ID Token – תוקף של שעה אחת בלבד. טוקן זה משמש לאימות ומכיל מידע על זהות המשתמשים והמשאבים.
• Access Token – משמש לטובת הרשאות גישה (authZ) ליישומים בענן.
• Refersh Token – תוקף של 90 יום. משמש ל refresh token שפג תוקפו.

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

טוקן Primary Refresh Token

טוקן מסוג Primary Refresh Token או בקצרה PRT הוא טוקן גישה ראשי ונוצר בעקבות חיבור מכונות שונות אל Entra ID, מערכות הפעלה אלה יכולות להיות Windows 10 ומעלה וגם מכשירים חכמים כמו אייפון, אנדרואיד וכן הלאה. ב PRT ישנה תצורת עבודה ספציפית מבוססת תרחישים (Hybrid / Entra Joined / PTA ונוספים) ואינספור ערכים ולכן הרבה מהם ניתנים לניצול, שוב על גבי JWT.

מאחורי הקלעים ישנו JWT שהונפק עי ידי ברוקר (חלק מובנה בתוך Entra ID שניתן לראות בהסנפה וובית), אותו JWT מורכב משלושה חלקים. בנוסף לכך מתרחש תהליך SSO כדי לאפשר כניסה אחידה לכלל היישומים מתוך עמדת הצקה או המכשיר החכם. במצב כזה ה PRT יכיל בין היתר דרישות ספציפיות, החשובות שבהן: מזהה מכונה ומפתח הפעלה.

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

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

התרשים מטה מתאר את תהליך ההתחברות הראשונית וקבלת Primary Refresh Token בסביבת Windows שמחובר אל Entra ID.

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

גניבת Primary Refresh Token – תוקף יכול לנסות לגנוב את ה PRT ברמת הזיכרון או ממיקומים אחרים בהם נשמר, תוך שימוש בכלים כמו Mimikatz, או RoadTools או AADINTERNALS או אפילו ללא כלים (האחרון בהחלט אפשרי). גניבת ה-PRT מאפשרת לתוקף להשתמש באותו ה token כדי לקבל גישה למשאבים ללא הצורך בסיסמה של המשתמש.

ניצול אמצע (AITM) – במידה והתוקף מצליח לשמש ״להיות באמצע״ בין המכונה לענן ולנצל את הרכיב המובנה של CloudAP, הוא יכול ליירט בקשות אימות או לשנות את המידע הנשלח כדי להשיג גישה. תקיפה זאת היא נפוצה וקיימת בשטח.

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

איך בודקים מהו ה PRT? ואיפה הוא נמצא? ומה אפשר לעשות איתו? הדרך המהירה והקצרה לבדיקה של PRT ללא כלים הם דרך הפקודות הבאות:

Dsregcmd.exe /status

Get-WmiObject -Namespace root\cimv2\mdm\dmmap -Class MDM_RegisteredCertificates

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

בנוסף לכך, ערך חשוב הוא הערך של x-ms-RefreshTokenCredential  והערך הזה משויך ל JWT.

טוקן PRT בפועל מקושר או מותנה בתוך refresh_token, והאחרון מוצפן על ידי מפתח בשליטת Entra ID, מה שהופך את תוכנו לסגור ובלתי ניתן לפענוח. השדה is_primary מסמל את השיוך ל refresh token. ולכן, כאשר הדרישה תגיע, למשל, ״עוגיה״ (מי אמר pass the cookie), היא תישאר קשורה ללוגין הספציפי שאליו היא נועדה, וכאן, הערך של request_nonce יהיה מקשור לדך logon.microsoftonline.com.

תרחישי תקיפה מבוססי PRT יכולים להיות בין היתר:

• Pass the cookie
• Pass the PRT
• Browser session attack
• PRT with Windows Hello
• Session Hijacking
• AITM
• ונוספים

אלה יכולים להיות מנוצלים ברמת מכונה כולל תרחישי lsass (ממש memory dump), בראוסר, סשן וכן הלאה. חלק מהתרחישים יכולים להיות טובים לסוגי טוקנים אחרים גם כן.

Refresh Token

אולי סוג הטוקן הכי מנוצל בשטח – Refresh token.

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

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

• חטיפת טוקן שמאפשרת גישה למשאב אחד.
• חטיפת טוקן שמאפשרת גישה למשאבים מרובים.

מצורף מטה אחת הדוגמאות בהם פוורשל נכנס לפעולה ומאפשר גניבת טוקן באמצעות Device Code Flow על גבי אפליקציה גנרית של Entra ID. הפעולה נעשית מתוך תרחיש נוסף שבו אפשר לייצא refresh token לאחר לוגין של משתמש רגיל. לאחר מכן, הטוקן יכול להיות יעיל מתוך מכונה אחרת וללא מעורבות של המשתמש.

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

גישה בלתי מורשית לשירותים באמצעות Access Token – כאשר כתוקף מצליח להשיג Access Token של משתמש, הוא יכול להשתמש בו כדי לגשת ליישומים מוגנים על ידי Entra ID (כמו Microsoft 365, Azure Management API, או כל יישום אחר). בעזרת Access Token, התוקף יכול לבצע פעולות ולמשוך מידע כאילו הוא המשתמש הלגיטימי, כל עוד ה Access Token בתוקף.

שימוש ב-Refresh Token לגישה מתמשכת – תוקף יכול להשיג Refresh Token (למשל דרך פישינג או ניצול חולשות ביישומים צד שלישי). Refresh Token מאפשר לייצר Access Tokens חדשים, ולכן שימוש ב Refresh Token מספק לתוקף גישה מתמשכת לחשבון גם אם Access Token התקף כבר לא זמין. תוקף יכול להשתמש ב Refresh Token כדי לקבל Access Token תקף ולשמור על גישה מתמשכת ללא צורך באימות מחדש.

השתלטות אפליקטיבית (Service Principal) – אם תוקף מצליח להשיג טוקן שמייצג Service Principal או Managed Identity, הוא יכול לבצע פעולות מול יישומים בתשתית Azure בהתאם להרשאות מוגדרות מראש. תוקפים יכולים להשתמש בטוקן זה כדי להרחיב גישה למידע ארגוני או לבצע פעולות בתשתית Azure.

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

שימוש בטוקן להרחבת הרשאות – במקרים בהם לתוקף יש גישה ראשונית עם הרשאות נמוכות, הוא יכול להשתמש בטוקן כדי לחפש אחר אפליקציות שבהם יש לו הרשאות נוספות ולהסלים להרשאות גבוהות יותר בתוך הסביבה היברידית ועננית. תוקפים עשויים לנסות למצוא אפליקציות עם OAuth שמכילות הרשאות יתר. תרחיש מהשטח persistence-via-app-registration-in-entra-id.

טוקן מסוג Family of Refresh Tokens

הכל נשאר במשפחה… סוג טוקן נוסף הוא Family of Refresh Tokens או בקצרה FRT. אפשר לומר שהוא לא מהטוקנים המוכרים אבל הוא מוכח בשטח. המשפחה הזאת תקפה גם כן למשך זמן של 90 יום.

הטוקנים האלה יכולים לשמש תוקף כדי להשיג אחיזה מול טוקנים אחרים ולכל היישומים בתוך "המשפחה". מי זאת המשפחה? בכתובים של Microsoft אין אפשרות למצוא מידע יעיל, אבל ישנו תיעוד חלקי בקישור הבא Abusing FRT for Unauthorized.

המימוש של  FRTs על ידי מיקרוסופט סותר במעט את פרוטוקול OAuth 2.0 (מוזכר קודם לכן במאמר). בהתאם ל OAuth2.0, ה bearer token אמור לשמש לטובת השגת טוקנים אל מול הלאפליקציה שעבורה הוא הונפק. זה לא המקרה עם FRTs.

המשמעות היא שאם תוקף גונב refresh token עבור כל יישום בתוך ה"משפחה" הזו – הוא יכול לעשות שימוש בכל היישומים בתוך המשפחה הזו (מה שמאפשר תנועה רוחבית). במונחים של תהליך תוקף, המשמעות כאן היא: בהתאם ליעד התוקף שלך, אפשר לקבל FRT על פני refresh token, שכן זה מאפשר מקום לתנועה לרוחב ולהסלמה של הרשאות.

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

משהו משהטח. במקרים שבהם ביצעתי Cloud PT והתמקדתי בזהויות, הגעתי למצב של 100% הצלחה בגניבת טוקנים ושימוש חוזר לאחר ימים ארוכים. ללא יוצא מן הכלל!

קישורים נוספים

What is a Primary Refresh Token?

Abusing Azure AD SSO with the Primary Refresh Token

Token theft playbook

token lifetimes