זה בדיוק מה שקרה לאחד הלקוחות שלנו, חברת סטארט-אפ. בוקר אחד Exchange סימן פעילות חשודה בחשבון של אחת העובדות: מהחשבון שלה יצאו יותר מ-700 מיילים לנמענים שונים. הנושא היה מסמכי השקעה של החברה, והקישור הוביל לדומיין שנרשם חודש קודם לכן, עם תת-דומיין שנבנה במיוחד על שם החברה.
הצוות שלנו חסם את החשבון, ביטל את הסשנים ואיפס את הסיסמה כ-30 דקות אחרי ההתראה. אבל ביומני ההתחברות לא נמצאה שום התחברות חריגה. הסיבה: התוקף לא התחבר עם סיסמה בכלל. הוא השתמש ב-Device Code Flow.
מה זה Device Code Flow, ולמה הוא עוקף סיסמה ו-MFA
Device Code Flow הוא מנגנון התחברות לגיטימי לגמרי. הוא נועד למכשירים שאין להם דפדפן או מקלדת נוחה, כמו טלוויזיה חכמה, מכשיר IoT או כלי שורת פקודה. המכשיר מציג קוד קצר, המשתמש נכנס מהטלפון או מהמחשב לדף ההתחברות של Microsoft, מקליד את הקוד ומתחבר. מאותו רגע המכשיר הראשון מקבל טוקן גישה תקף.
בפישינג Device Code, התוקף הוא "המכשיר". הוא מבקש קוד בעצמו ושולח אותו לקורבן בתוך תואנה משכנעת: הזמנה לפגישה, מסמך משותף או חדר צ׳אט מאובטח. הקורבן נכנס לדף האמיתי של Microsoft, מקליד את הקוד, מאשר MFA כרגיל, והטוקן נשלח לתוקף.
לכן הסיסמה לא נגנבה, ה-MFA עבד כמו שצריך, וגם אין דף התחברות מזויף שכלי הגנה יכולים לזהות. התוקף נשאר עם גישה כל עוד הטוקנים תקפים.
זו לא תיאוריה. Microsoft פרסמה בפברואר 2025 מחקר על קבוצה שהיא מכנה Storm-2372, שמפעילה קמפיין כזה מאז אוגוסט 2024 נגד ממשלות, ארגונים וחברות טכנולוגיה. לפי Microsoft, אחרי ההשתלטות התוקפים שלחו מהחשבון הנפרץ הודעות פישינג נוספות לעובדים אחרים, בדיוק הדפוס שראינו אצל הלקוח.
איך נראתה התקיפה, צעד אחרי צעד
כשבדקנו את הקישור שנשלח מהחשבון של הלקוח, זה מה שמצאנו:
- הפיתיון: מייל בנושא סבב גיוס ומסמכי השקעה של החברה, שנשלח מכתובת אמיתית של עובדת, ולכן נראה אמין לכל מי שקיבל אותו.
- דף ראשון: הקישור מוביל לדף עם "החלק כדי לאמת", שנראה כמו בדיקת אבטחה רגילה ומסנן סורקים אוטומטיים.
- הקוד: אחרי האימות מופיע קוד, וכפתור אדום "המשך ל-Microsoft OneDrive".
- הדף האמיתי: הכפתור פותח חלון עם דף ההתחברות הלגיטימי של Microsoft להזנת קוד מכשיר.
- ההשתלטות: המשתמש מקליד את הקוד ומשלים התחברות, והתוקף מקבל סשן פתוח לחשבון.
- ההתפשטות: מהחשבון הנפרץ יוצאים מאות מיילים לכתובות נוספות, עם אותו קישור.
שני סימנים נוספים בלטו בחקירה. הדומיין נרשם כחודש לפני האירוע, סימן מובהק לאתר פישינג. ונבנה בו תת-דומיין עם שם החברה, כלומר אותה תשתית משמשת כנראה לתקיפת ארגונים נוספים.
למה Security Defaults לא הספיק
אצל הלקוח, ה-MFA הוגדר דרך Security Defaults, ההגדרה הבסיסית והחינמית של Entra ID. היא עדיפה בהרבה על כלום, אבל היא לא מאפשרת שליטה: אי אפשר לקבוע מתי נדרש MFA, מאילו מכשירים מותר להתחבר, ואילו שיטות התחברות חסומות.
בבדיקות שעשינו מול הלקוח ראינו בפועל ש-MFA לא נדרש בכל התחברות חדשה (התנתקות והתחברות מחדש). Security Defaults מחליט בעצמו מתי לבקש אימות נוסף, ולכן ההתנהגות שלו קשה לחיזוי.
וחשוב מזה: Security Defaults לא מאפשר לחסום את Device Code Flow. את זה אפשר לעשות רק עם Conditional Access, שדורש רישוי Entra ID P1, כלול למשל ב-Microsoft 365 Business Premium.
איך מתגוננים
ההמלצה הראשונה של Microsoft עצמה היא לחסום את Device Code Flow בכל מקום שלא צריך אותו. ברוב הארגונים אף אחד לא משתמש בו, כך שהחסימה כמעט לא מורגשת.
| שכבה | מה עושים | למה זה עוזר |
|---|---|---|
| חסימת Device Code Flow | מדיניות Conditional Access עם התנאי Authentication flows, שחוסמת Device Code לכל המשתמשים, עם חריגים מוגדרים בלבד | סוגרת את הדלת שדרכה התקיפה עובדת |
| מכשיר מנוהל ותואם | מדיניות Conditional Access שדורשת מכשיר Compliant ב-Intune לגישה לנתוני הארגון | ההתחברות מגיעה מהמכשיר של התוקף, שאינו מנוהל, ולכן Conditional Access חוסם אותה |
| MFA דרך Conditional Access | מעבר מ-Security Defaults למדיניות MFA מפורשת שחלה על כל ההתחברויות | התנהגות צפויה ואחידה, בלי "חורים" |
| הגנת דוא"ל | Defender for Office 365 עם Safe Links, שבודק כל קישור ברגע הלחיצה | מקטין את הסיכוי שהמייל והקישור יגיעו למשתמש מלכתחילה |
| זיהוי סיכון | Entra ID Protection עם מדיניות סיכון משתמש וסיכון התחברות | מזהה התנהגות חריגה אחרי ההשתלטות ומחייב אימות מחדש |
| מודעות משתמשים | הדרכה קצרה: לעולם לא להקליד קוד שהתקבל במייל או בהודעה בדף של Microsoft | העובד הוא קו ההגנה האחרון |
נקודה חשובה: גם MFA עמיד לפישינג, כמו מפתחות FIDO2 או passkeys, לא עוצר לבדו את התקיפה הזו, כי המשתמש מתחבר בדף האמיתי. לכן חסימת ה-Flow ודרישת מכשיר תואם הן השכבות הקריטיות כאן.
מה עושים כשזה כבר קרה
באירוע כזה, הזמן קובע כמה נמענים ייפגעו. אלה הצעדים שביצענו מול הלקוח, לפי הסדר:
- עוצרים קודם כול: ביטול כל הסשנים של המשתמש (Revoke sessions), איפוס סיסמה וחסימת התחברות. איפוס סיסמה לבד לא מספיק, צריך לבטל גם את הסשנים. וגם אז, טוקן שכבר הונפק יכול לעבוד עד כשעה.
- בדיקת היקף: מעקב הודעות ב-Exchange כדי לדעת כמה מיילים יצאו, לאן, ואם עוד משתמשים בארגון שלחו הודעות חריגות.
- בדיקת מכשירים וחיבורים: לוודא שהתוקף לא רשם מכשיר משלו ב-Entra ID ולא נתן הרשאות לאפליקציה. Microsoft מתארת תוקפים שעושים בדיוק את זה כדי לשמור על גישה.
- טיפול בנמענים: הודעה לנמענים שקיבלו את המייל, ובתוך הארגון ביטול סשנים ואיפוס סיסמה לכל מי שלחץ על הקישור.
- הורדת האתר: דיווח לרשם הדומיין על אתר שמתחזה לארגון, עם בקשה להסרה מהירה.
- שיחה עם המשתמש: לברר על אילו קישורים לחץ ומה הזין בשבוע שלפני האירוע.
- סגירת הפרצה: בדיקה שכל המשתמשים רשומים ל-MFA, ומעבר ל-Conditional Access עם חסימת Device Code Flow.
בשורה התחתונה
פישינג Device Code לא גונב סיסמאות ולא שובר MFA. הוא פשוט משתמש במנגנון לגיטימי שרוב הארגונים לא צריכים ולא חסמו. מדיניות Conditional Access אחת שחוסמת אותו, יחד עם דרישה למכשיר מנוהל, סוגרת את רוב הסיכון. ארגון שעדיין עובד עם Security Defaults לא יכול להגדיר אף אחת מהן.
לא בטוחים מה מוגדר אצלכם? Griffin31 בודק את הגדרות האבטחה בטננט שלכם באופן רציף ומראה מה לתקן קודם.