Knight Office מדגים: גניבת סשן Microsoft 365 אחרי MFA היא אירוע זהות

אימות רב־גורמי (MFA) מאשר את הכניסה לחשבון, אך אינו מגן בהכרח על כל סשן שנוצר אחריה. במקרה שתיעדה Huntress, ערכת הפישינג Knight Office השתמשה ב־Adversary-in-the-Middle ‏(AiTM) — תווך זדוני בין המשתמש לשירות האמיתי — כדי ללכוד חומר סשן של Microsoft 365. בהמשך נרשם מכשיר לא מורשה ב־Microsoft Entra ID. לכן, המסגור המבצעי הנכון הוא פשרת זהות, ולא גניבת סיסמה נקודתית. 640

כך פועלת שרשרת התקיפה של Knight Office

האירוע שנחקר החל בהודעת פישינג בסגנון DocuSign. הקישור עבר דרך שירות המעקב של Monday.com ולאחר מכן דרך אתר Joomla שנפרץ. שרשרת ההפניות הסתירה את יעד הפישינג הסופי ממערכות מוניטין ומבדיקה בסיסית של קישורים בדוא״ל. 6

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

רכיב ה־AiTM פועל כ־reverse proxy בין הקורבן לשירות הכניסה האמיתי של Microsoft:

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

אין פירוש הדבר שהתוקף פרץ את ההצפנה של MFA. הוא גנב את מצב ההרשאה שנוצר אחרי ה־MFA. Microsoft מגדירה גניבת טוקנים כפשרה ושחזור של טוקנים שהונפקו למשתמש, גם אם אותו משתמש כבר השלים אימות רב־גורמי. 40

מדוע איפוס סיסמה אינו בהכרח מסיים את החדירה

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

Knight Office מחריפה את הסיכון: לפי הדיווח, הפעילות לאחר הפשרה כללה רישום מארח לא מורשה ל־Microsoft Entra ID והגדרת אישורי Windows Hello for Business שבשליטת התוקף. 6 מצב כזה עשוי ליצור נתיב אימות נפרד. גם אחרי ביטול סשן אינטרנט או איפוס סיסמה, על צוות ההגנה לוודא שלא נשארו מכשיר לא מורשה או שיטת אימות חדשה.

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

פישינג בקוד מכשיר קשור ל־AiTM, אך אינו זהה לו

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

בשתי השיטות, יעד התוקף אינו רק הסיסמה אלא השגת פריטי הרשאה שימושיים. לכן תוכניות גילוי צריכות לכסות את שני המסלולים. Elastic ממליצה לבדוק כניסות אינטראקטיביות מוצלחות ל־Entra המשתמשות בפרוטוקול קוד מכשיר, עם לקוח Microsoft Authentication Broker ובקשות למשאבי Microsoft צד־ראשון כגון Exchange Online, ‏Microsoft Graph או SharePoint. 17

הפעילות שנצפתה וההקשר הרחב של PhaaS

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

Knight Office משתלב בשוק רחב יותר של ערכות Phishing-as-a-Service ‏(PhaaS), שנועדו לגנוב סשני זהות של Microsoft 365:

• Mirage2FA משתמשת בתשתית AiTM כדי ללכוד פרטי הזדהות וסשנים מאומתים. ANY.RUN דיווחה על 9,332 אירועי פשרה פוטנציאליים בין 2024 ל־2026, ובהם 4,561 אירועי גניבת עוגיות. אלה נתוני טלמטריה של אירועים פוטנציאליים, ולא ספירה של קורבנות מאומתים. 4
• Kali365, שנצפתה לראשונה באפריל 2026 והופצה בעיקר דרך Telegram, עמדה במוקד אזהרת FBI בשל יכולתה להשיג טוקני גישה וטוקני רענון של OAuth עבור Microsoft 365. 1

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

סדרי עדיפויות לגילוי ב־Entra ID וב־Microsoft 365

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

1. איתור שחזור חשוד של סשנים

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

2. ציד פעילות חשודה של קוד מכשיר

בדקו אימותים מוצלחים באמצעות קוד מכשיר, והעריכו אם הלקוח, כתובת ה־IP המקורית, המשאב המבוקש והתנהגות המשתמש הגיוניים. ביומני הכניסה של Entra ניתן לזהות פעילות זו, בין היתר, באמצעות השדות authenticationProtocol: deviceCode ו־originalTransferMethod: deviceCodeFlow. 26

3. מעקב אחר שינויי התמדה

תנו עדיפות לאירועי ביקורת ב־Entra הכוללים:

• רישום מכשירים חדשים, צירוף מכשיר, שינויי בעלות או מזהי מכשיר חריגים.
• הוספת שיטות אימות חדשות: Windows Hello for Business, מפתחות FIDO2 או passkeys, ‏MFA ושיטות שחזור.
• הענקת הסכמה לאפליקציות, שינויים באפליקציות ארגוניות, service principals או הקצאת תפקידים מורשים.
• שינויים ב־Conditional Access, מיקומים בעלי שם, פדרציה, העברת דואר או כללי תיבת דואר נכנס.

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

4. חיבור בין ראיות דוא״ל וזהות

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

תגובה לאירוע: להכיל את הזהות, לא רק את הסיסמה

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

1. חסמו או השביתו את הזהות שנפגעה לפי הצורך. השביתו חשבונות משתמש ומכשיר מושפעים בעת בירור ההיקף. 40
2. בטלו סשנים וטוקני רענון קיימים. השתמשו בתהליך ביטול סשני הכניסה של Entra ולאחר מכן אכפו אימות מחדש. Microsoft ממליצה במפורש לבטל טוקני רענון באמצעות revokeSignInSessions בתגובה לפישינג בקוד מכשיר. 27
3. אפסו סיסמאות, אך אל תעצרו שם. איפוס סיסמה הוא פעולת הכלה משלימה; הוא אינו הוכחה לכך שהגישה של התוקף הסתיימה. 4042
4. הסירו התמדה. אתרו והסירו מכשירי Entra לא מורשים; בדקו בעלות על מכשירים; הסירו אישורי Windows Hello for Business, ‏FIDO2, ‏MFA, שחזור ואפליקציות שנוספו לאחרונה; ובחנו הענקות הסכמה. 628
5. בצעו ציד בכלל הדייר. חפשו אצל כל המשתמשים כתובות פיתיון, תשתיות הפניה, כתובות IP חשודות, אירועי קוד מכשיר, חריגות כניסה לאחר MFA ורישומי מכשירים חדשים.
6. העריכו השפעה עסקית. בדקו פעילות ב־Exchange, ‏SharePoint, ‏OneDrive, ‏Teams, ‏Microsoft Graph, ‏OAuth ויומני ניהול: גישה לנתונים, כללי תיבת דואר, העברת דואר, שיתוף חיצוני, ניצול הסכמה, שינויי הרשאות וגישה לאפליקציות המחוברות ב־SSO.
7. שמרו ראיות לפני ניקוי. שמרו הודעות פישינג וכותרות, מעקבי דואר, שרשראות הפניה, יומני כניסה וביקורת של Entra, רשומות מכשירים, רישומי הסכמת OAuth וטלמטריית דפדפן או נקודת קצה.

צמצום החשיפה לפני הפיתיון הבא

אימות עמיד לפישינג הוא בקרה חשובה למשתמשים בסיכון גבוה, אך עליו להיות חלק מהגנה בשכבות. Microsoft ממליצה על שיטות עמידות לפישינג כגון מפתחות אבטחה FIDO2, ‏Windows Hello for Business ואימות מבוסס תעודות, לצד בקרות שמקצרות את משך החיים השימושי של סשנים במכשירים לא מנוהלים. 39

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

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