Entra ID: טוקנים, סיכונים והשלכות

[ זמן קריאה משוער; 14 דקות. ]

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

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

מגמה זו מתעצמת לאורך השנים ועל פי דוח הגנת הסייבר של מיקרוסופט 2024, אף שמרבית הפרצות עדיין נובעות מתקיפות סיסמאות, זוהתה עלייה של 146% במתקפות דיוג מתקדמות (AiTM) המנסות לגנוב טוקנים, עם מספר לא מבוטל של 39,000 אירועי גניבת טוקן ביום בממוצע.

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

סוגי טוקנים נפוצים

בתשתית Entra ID ישנם מספר סוגי טוקנים עיקריים שנמצאים בשימוש סטנדרטי במסגרת פרוטוקולי OAuth 2.0 ו OpenID Connect:

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

טוקן לטווח הקצר שניתן על ידי Entra ID ומיועד להרשאת גישה למשאב ספציפי. הוא מכיל מידע מוצפן (claims) אודות המשתמש וההרשאות/היקף (scope) עבור המשאב. לדוגמה, לאחר שהמשתמש נכנס,  ה Entra ID עשוי להנפיק Access Token עבור שירות כמו Microsoft Graph, Outlook, Exchange Online או Teams. הטוקן נשלח כ bearer token בכותרת Authorization בכל בקשה ל API או לסרוויס, והמשאב סומך עליו במידה והחתימה הדיגיטלית שלו תקפה. משך החיים של טוקן גישה הוא קצר, עד שעתיים. האחרון תלוי סרוויס, אפליקציה, או פוליסי.

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

דוגמה לבקשת בראוסר מול Graph עם Authorization: Bearer

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

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

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

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

זהו טוקן הניתן במסגרת פרוטוקול OpenID Connect, המכיל פרטי זהות על המשתמש (כגון שם, אימייל, מזהה משתמש, וכו). טוקן זה נשלח בדרך כלל אל האפליקציה מיד לאחר אימות מוצלח, על מנת לאפשר לאפליקציה לזהות את המשתמש שהתחבר (identity claims). בניגוד ל Access Token, טוקן זהות אינו משמש לקריאות API למשאבים אלא רק להוכחת זהות למען האפליקציה (אפשר להשוות זאת לתעודת זהות דיגיטלית המונפקת בעת הכניסה). למשל, אפליקציית וובית שקיבלה ID Token יכולה להשתמש בפרטים שבו כדי ליצור סשן אפליקטיבי עבור המשתמש. ID Token מונפק בדרך כלל יחד עם Access Token במסגרת ה flow של OIDC, ולעיתים בעל תוקף דומה או קצר (מספר דקות). הוא חתום דיגיטלית ע״י ספק הזהויות כדי למנוע זיוף.

Primary Refresh Token (PRT)

טוקן רענון ראשי המשמש SSO במכשירים רשומים אל מול Entra ID. זהו ריפרש טוקן רענון לטווח הבינוני ארוך (תלוי סרוויס, פוליסי ועוד) והוא מונפק בעת שהמשתמש מתחבר למכשיר Windows 10/11 או מכשיר נייד הרשום ב Entra ID. ה PRT נשמר באופן מאובטח במכשיר ומוגן ע״י TPM או הצפנה אחרת במערכת (תלוי פוליסי) ומשמש להנפקת טוקנים לשירותי ענן שונים מבלי לדרוש כניסה חוזרת בכל אפליקציה במכשיר. במקרה כזה, היתרון שהוא כללי (לא ספציפי למשאב אחד) והוא יכול לדרוש טוקן לכל משאב של המשתמש. עם זאת, הוא תקף רק במכשיר אליו הוא קשור (מתואר בחלק של Device-Bound). תוקפו הבסיסי לרוב 14 יום עם הארכה מתגלגלת כל פעם שהשתמשו בו.

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

תרחישי גניבת טוקנים – שיטות והשלכות

גניבת טוקן (Token Theft) היא מתקפה בה גורם עוין מצליח להשיג טוקן תקף של משתמש או שירות, ולהשתמש בו כדי להתחזות אל אותו משתמש בגישה למשאבים מוגנים. למעשה, התוקף ״גונב את הזהות הדיגיטלית״ של הקורבן בכך שהוא משתמש בטוקן ההזדהות שלו. במצב כזה, התוקף עוקף את כל מנגנוני ההזדהות בין אם המשתמש כבר עבר אימות MFA וקיבל טוקן, התוקף לא צריך את הסיסמה או ה החלק הנוסף של mfa של המשתמש, אלא פשוט מציג את הטוקן הגנוב כדי לקבל גישה. זו גניבת זהות במובן של אימוץ זהות המשתמש ללא ידיעתו, ו-חטיפת Session (Session Hijacking) כי התוקף משתלט על סשן ההתחברות החוקי של המשתמש.

ישנן מספר דרכים נפוצות לגניבת טוקנים:

Adversary-in-the-Middle (AiTM)

מתקפת איש בתווך מתקדמת בה התוקף משלב התקפת דיוג עם פרוקסי ומתחזה לשער לגיטימי. המשתמש מכוון לאתר דיוג שנראה זהה לדף ההתחברות של Microsoft 365, אך בפועל האתר מפנה (proxy) את תעבורת הכניסה דרך שרת של התוקף. כך, המשתמש מזין את הקרדס בעמוד המזויף, עובר אפילו שלב MFA אמיתי, וכל תהליך ההזדהות מתבצע מול Entra ID תוך כדי שהתוקף מצותת לתקשורת וגונב את טוקני הסשן (לדוגמה, Cookie session או Access Token) שהונפקו בסיום ההתחברות.

מתקפות AiTM מודרניות מסוגלות ללכוד גם את ה Session Cookie שמוכיח שהמשתמש ביצע MFA, ובכך התוקף יכול לדמות את הסשן במכשיר שלו ולהיכנס ללא צורך באימות נוסף. מתקפות אלו הפכו שכיחות עם הופעת כלים כגון Evilginx, Modlishka וכד׳ (פרוקסי דיוג אוטומטיים).

התרשים מטה מדגים באופן פשוט את אופן פעולת תקיפת AiTM. אתר דיוג מתווך בין המשתמש לבין אתר היעד האמיתי, ומשמש כפרוקסי זדוני. התוקף מריץ שרת Proxy שמעביר הודעות HTTP בין המשתמש לאתר האמיתי, כך שהמשתמש רואה דף התחברות אותנטי. בכך, התוקף לוכד את פרטי ההתחברות, כולל סיסמה ופרטי MFA, וגם את ה Session Cookie שהונפק לאחר ההתחברות המוצלחת. את ה Cookie הזה התוקף שומר ומזריק לדפדפן שלו, מה שמאפשר לו לדלג על התהליך האימות כולו ולהיכנס כמשתמש לקונסולאפליקציות ענניות. למעשה, ה Cookie הגנוב מכיל כבר את ה Claims של MFA, ולכן גם הגנת MFA לא תעצור את התוקף בשלב זה.

גניבת טוקנים באמצעות נוזקות (Infostealers)

תוקפים רבים מפיצים נוזקות ורוגלות שתכליתן לשלוף טוקנים מהזיכרון או מהדפדפן של המשתמש. לאחר שהתוקף מפעיל קוד זדוני על תחנת הקורבן (באמצעות קובץ נגוע, קישור זדוני או ניצול פרצה), הנוזקה יכולה לסרוק קבצי Cookies ודפדפנים, Dump לזיכרון של תהליכים כמו דפדפן או יישומי Office, ולחפש אסימוני session, טוקני גישה או רענון השמורים בזיכרון. למשל, נוזקות מסוג InfoStealer (כגון Redline, Raccoon) כבר תוכננו במיוחד כדי לחלץ Cookies של דפדפני כרום/Edge, טוקני OAuth וכו’. לכן, תוקפים יכול אף לחלץ טוקנים מה LSASS או מקבצי Token cache של Entra ID במכונה. ברגע שהטוקנים נגנבו, הנוזקה שולחת אותם חזרה לתוקף, שיכול להתחבר לשירותי הענן כהתחזות למשתמש.

מתקפות Session Fixation / Replay

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

ניצול ישיר של תצורה שגויה או דליפת טוקנים לוגית

לעיתים טוקן עלול להיחשף עקב באג או תצורה לא נכונה, למשל אפליקציה שמשמרת טוקנים בצורה גלויה (לוגים, כתובות URL), או שימוש ב-redirect לא מאובטח שמעביר טוקן לצד שלישי בטעות. תוקף שמוצא טוקן בכתובת redirect או בקובץ log יכול לנצל אותו.

השלכות

ההשלכות של גניבת טוקנים הן חמורות. קודם כל, כפי שצוין, התוקף מקבל גישה מלאה למשאבים שהטוקן מעניק, תוך עקיפת אימותים. אין צורך יותר בסיסמה או ב MFA כי הטוקן הגנוב כבר מוכיח למערכת שהמשתמש אומת. בכך, מתקפת טוקן דומה להשגת מפתח מאסטר, התוקף יכול להיכנס לדוא״ל של המשתמש, לקריאת קבצים, לצ׳אטים, או לכל שירות שאליו הונפק הטוקן. לדוגמה, בתרחישי Business Email Compromise (BEC) נפוצים, התוקפים משתמשים בטוקן Session Cookie גנוב כדי להיכנס לתיבת ה Outlook Web של הקורבן, ומשם תוך דקות בודדות לבצע פעולות כגון שליחת מייל תרמית לנמענים, והכל ממייל המשתמש החוקי.

גניבת טוקן משמעותה התחזות מלאה למשתמש וכל פעולה שהתוקף יבצע עם הטוקן תירשם במערכת כאילו המשתמש החוקי ביצע אותה. הדבר מקשה על זיהוי מהיר במיוחד אם התוקף מבצע פעולות זהירות, הוא יכול לפעול תחת הזהות הגנובה לפרק זמן משמעותי לפני שיתגלה. למשל, תוקף יכול להשתמש בטוקן גנוב כדי למשוך נתוני אימייל רגישים, קבצים מ-OneDrive/SharePoint, נתוני לוח שנה, שיחות Teams ועוד כל זאת בלי להפעיל שום אזעקה של סיסמה שגויה או כישלון MFA. לעיתים הגילוי מגיע רק כשיש אינדיקציה צדדית (כמו התראה על כניסה ממיקום בלתי צפוי, או פעילות חריגה כגון יצירת rules חשודים בתיבת הדוא״ל).

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

דבר נוסף הוא פגיעה במעקב והבנת התיעוד כי מערכות SIEM וניתוח סיכונים מסתמכות על אירועי כניסה (Login events) כדי לזהות אנומליות (למשל כניסה ממדינה לא צפויה). אך תוקף המשתמש בטוקן גנוב עשוי להימנע מטריגר של אירוע כניסה חדש אם הוא משתמש באותו Session באופן שקוף. למשל, אם התוקף גונב Cookie Session של Outlook Web, הוא עשוי להשתמש בו ע"י פתיחת דפדפן במצב דומה ולא יתרחש אירוע כניסה נוסף ב Entra ID מכיוון שה Session כבר מאומת. כך ייתכן שרק פעולות האפליקציה עצמן, כגון, גישה לפריטי דואר יירשמו, אך לא כניסה בולטת. זה מקשה על זיהוי באמצעות כלים סטנדרטיים, ודורש ניטור מעמיק יותר של דפוסי שימוש.

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

טוקנים שקשורים למכשיר

אחד החלקים המשמעותיים בהתמודדות עם גניבת טוקנים הוא הרעיון של ״קשירת טוקן למכונה״ (Token Binding / Device-Bound Tokens). המשמעות היא טוקן ההתחברות של המשתמש יהיה מקושר קריפטוגרפית לחומרה של המכונה המסוימת שבו בוצעה ההזדהות, כך שאם ייגנב לא יהיה ניתן להשתמש בו ממכונה אחרת.

ב Entra ID יישום עיקרי לרעיון זה הוא בין היתר מנגנון Token Protection במסגרת מדיניות Conditional Access. כאשר מדיניות זו מופעלת, Entra ID יוודא שמתקבלות רק בקשות גישה המשתמשות בטוקן סשן שהוא Device-bound. למעשה, כאשר משתמש מחבר ומרשום מכשיר Windows 10/11 ל Entra ID, המערכת מנפיקה Primary Refresh Token (PRT) ומקשרת אותו לקריפטוגרפיה למכונה, למשל, חתום או מוצפן בעזרת המפתח של המכונה/TPM. הקשירה הזאת פירושה, בתוך ה PRT או בתהליך הנפקת הטוקנים מה PRT, נכלל מרכיב שמזהה את המכונה או משתמש במפתח ייחודי מהמכונה. כתוצאה, אם תוקף יגנוב את הטוקן הזה, למשל, יעתיק את ה-PRT או יבצע יירוט וינסה להשתמש בו ממחשב אחר, ה Entra ID יזהה שהטוקן אינו מגיע מהמכונה הנכונה וידחה את הגישה. אפשר לומר שטוקן כזה הוא חתום ביולוגית למכונה כמו מפתח של רכב יזהה אם הוא משוכפל ולא המקורי.

איך זה עובד בפועל? בעת הנפקת הטוקן במכשיר הרשום, המכשיר משתמש ברכיב חומרה בטוח, כגון, TPM ב Windows או Secure Enclave ב macOS כדי ליצור מפתח הצפנה ייחודי. ה PRT או הטוקן מסומן (חתימה/הצפנה) עם המפתח הזה. Entra ID שומר את המפתח הציבורי המתאים, כך שבהמשך כאשר נעשית בקשת גישה שמשתמשת בטוקן, Entra ID מאמת את החתימה אל מול זהות המכונה. רק אם הבקשה מגיעה מהמכונה שהטוקן הונפק עבורו כלומר, חתומה נכון היא תתקבל. באופן זה, גם אם טוקן יזלוג, הוא יכול להיות חסר ערך לתוקף מרוחק ללא אותו קשר למכונה שנמצאת רק בחומרה של המכשיר המקורי.

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

כיצד Device-bound tokens מונעים גניבה? בפשטות, הם חוסמים מתקפות replay מרחוק. התוקף כבר לא יכול לקחת טוקן ממכונת הקורבן ולהשתמש במכונה שלו כי הבקשה תידחה. זה סותם פרצה אדירה שבמתקפות AiTM או malware, התוקף אמנם גונב את הטוקן, אבל כשינסה להשתמש בו מהמכונה שלו Entra ID יסרב כי הטוקן לא שייך למכונה הזאת. בתיאוריה, אכיפת Token Protection מסוגלת לחסום סוגים נפוצים של תקיפות BEC מתקדמות, שבהן תוקפים המשיכו להשתמש בטוקנים גם אחרי שהסיסמאות שונו. זה מפחית מאוד את הערך של טוקן גנוב כי התוקף לא יוכל להתחזות מרחוק אם אינו נגיש למכונה הפיזית.

עם זאת, יש למנגנון מגבלות ומתקפות שנותרו אפשריות. חשוב להכיר שגם Device-Bound אינו הפתרון המושלם:

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

לא כל אפליקציה או תרחיש תומך בקישור טוקן. נכון להיום, ישנן אפליקציות שלא עובדות עם טוקן מוגן ולכן יחסמו אם נאכוף Token Protection. למשל, מיקרוסופט ציינה שקיימות הגבלות עם PowerShell עבור SharePoint, תוספי Excel וכד׳ שאינם תומכים עדיין וייחסמו תחת מדיניות זו. גם מכשירים מיוחדים כמו Surface Hub, או תרחישי Hybrid Join מסוימים, אינם  נתמכים. פירוש הדבר שאי אפשר כרגע להגן באמצעות Device-Bound בכל מצב, ותוקף יכול לנסות לנצל דווקא את הערוצים הלא-מוגנים.

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

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

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

בשורה התחתונה, Device-Bound הינה התפתחות משמעותית שמקשה מאוד על תוקפים לנצל טוקנים גנובים. מחקרים מראים שזה מפחית את שטח ההתקפה בצורה ניכרת, והתוקף כבר לא ירוויח הרבה מלגנוב טוקן אם אינו יכול להריץ אותו בסביבה הנכונה. יחד עם זאת, חשוב להדגיש שיש להתייחס לזה כעוד שכבת הגנה, ולא כפתרון יחיד. ההמלצה היא לשלב קישור טוקנים עם אמצעים נוספים, כמו, המשך שימוש ב MFA מתקדם, ניהול מכשירים וקיום דרישת תאימות (Compliant devices) ב Conditional Access, וחוקים לניטור וזיהוי ניסיונות Replay שנכשלו המעידים על תקיפה. במילים אחרות, Token Protection מצמצם את ערך הטוקנים הגנובים, אך עדיין נדרש מערך הגנה הוליסטי כדי לעצור את התוקפים העקשנים ואת אלה שכבר חדרו למכשירים עצמם.

השלכות על אפליקציות Microsoft 365

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

Outlook / Exchange Online

כשטוקן גישה או רענון של משתמש נגנב, התוקף יכול לקבל גישה מלאה לתיבת הדואר של המשתמש ב Exchange Online. המשמעות המיידית היא שהתוקף יכול לקרוא את כל הדוא״ל הנכנס והיוצא, לחפש מידע רגיש (שיחות פיננסיות, מידע מסחרי, מידע אישי), ולהשתמש בתיבה כדי לשלוח הודעות בשמו של המשתמש. הדבר מאפשר מתקפות BEC והונאות, למשל, שינוי פרטי תשלום בהצעת מחיר כפי שקורה בקמפייני AiTM למינהם, או שליחת הודעת התחזות לעמיתים כדי לקבל גישה נוספת. יתרה מכך, Outlook ו Exchange חושפים ממשקי Graph/REST חזקים טוקן גנוב יכול לאפשר לתוקף לבצע פעולות כגון יצירת כללים להפניית דוא״ל (Forwarding Rules) לחשבון חיצוני, מחיקת הודעות מסוימות כדי להסתיר את עקבותיו, או הורדת כל תיבת הדואר (למשל באמצעות פקודת EWS/Graph לייצוא). אין כמעט מגבלה על מה שהתוקף יכול לעשות בדוא״ל של המשתמש עם טוקן תקף, כל עוד זה במסגרת ההרשאות של המשתמש.

אחת הפעולות הנפוצות בשטח היא יצירה של חוקי Outlook מוסתרים.

Microsoft Teams

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

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

Microsoft Graph API ושירותי M365 כלליים

Graph API הוא הממשק המאוחד של Microsoft 365 ו Entra ID. טוקן גישה ל Graph עם Scopes מתאימים יכול לאפשר פעולות רבות, החל מביצוע פעולות Recon פנימיות, עדכון קבצים ב OneDrive, יצירת אתרים ב SharePoint, ואפילו קריאות ניהוליות מסוימות אם למשתמש היו תפקידי אדמין מתאימים. לכן, אם תוקף משיג טוקן גישה או רענון שמאפשר קריאות Graph, הוא יכול לנצל זאת כדי לשאוב נתונים מכל שירות כמעט שהמשתמש משתמש בו. לדוגמה, טוקן עם הרשאת Files.Read.All יאפשר לתוקף להוריד את כל קבצי ה OneDrive של המשתמש. טוקן עם Mail.Read או Mail.ReadWrite יאפשר לקרוא, למחוק או לשלוח מיילים דרך Graph, כלומר, גם ללא ממשק Outlook. למעשה, פעמים רבות תוקפים אוטומטיים מעדיפים את Graph API כדי למשוך נתונים שיטתית כי קל להם בתסריט אוטומטי להשתמש בטוקן גנוב ולקרוא מידע רב באמצעות קריאות API מהירות, במקום ממשק משתמש.

חשוב להדגיש, טוקן גנוב נושא עמו את כל ההרשאות של המשתמש הקורבן. לכן ההשפעה תלויה מאוד מי המשתמש: אם מדובר בטוקן של אדמין הנזק גדול בהרבה. למשל, טוקן של Global Admin או אפילו Owner של Subscription שייפול בידי תוקף, מאפשר לו קרוב לוודאי שליטה מלאה בסביבת הענן. באמצעות Graph API, התוקף יכול אולי ליצור משתמשים חדשים, להעניק לעצמו הרשאות נוספות, לערוך הגדרות אבטחה, או להתפשט לתשתיות ענן (כמו משאבי Azure). גם טוקן של משתמש רגיל יכול להסב נזק משמעותי, אך טוקן של אדמין מאפשר לתוקף לבטל התראות, לכבות מדיניות, ליצור דלתות אחוריות נוספות.

שירותים נוספים שנפגעים משימוש בטוקן גנוב כוללים:

• SharePoint Online / OneDrive: גישה לקבצי החברה, אתרי צוות, מסמכים רגישים. תוקפים רבים גונבים מסמכי PDF, Word, מצגות וכד’ כאשר יש להם גישה.

• Power Platform / Azure Resources: במקרים מסוימים, טוקן משתמש יכול לתת גישה ליישומים עסקיים (PowerApps, Flows) שהמשתמש מחזיק, או אפילו לSubscriptions ב Azure (אם אותו identity מאוחד). תוקף יכול לבצע מניפולציות במכונות וירטואליות, לחלץ Data אם לטוקן יש הרשאות מתאימות, וכו’.

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

מידע נוסף

Understanding tokens in Microsoft Entra ID

Token tactics: How to prevent, detect, and respond to cloud token theft