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

איזו גישה התוקף יכול לקבל

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

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

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

למה אתר אמיתי ואימות חזק אינם סוף הבדיקה

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

גם MFA נשאר חיוני. אלא שהצלחת האימות מוכיחה שהמשתמש השלים את דרישות ההזדהות; היא אינה מוכיחה שהבין איזו בקשה הוא מאשר. מחקר של Push Security על פישינג בתהליכי הרשאה הדגים את הסיכון גם בחשבונות המוגנים באמצעות Passkeys. מפתח ההתחברות עצמו אינו צריך להיגנב כדי שהמשתמש יאשר בקשה שהתחילה אצל התוקף. לכן אימות עמיד לפישינג צריך לפעול לצד הגבלה מפורשת של מסלולי ההרשאה המותרים.

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

ההחלטה הארגונית: למי בכלל נחוץ המסלול הזה

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

הנחיית Microsoft לחסימת תהליכי אימות ממליצה להתקרב ככל האפשר לחסימה של המסלול, ולהשאיר שימושים נחוצים ומתועדים. ב Microsoft Entra ID ניתן להגדיר מדיניות Conditional Access שבוחרת בתנאי Authentication flows, מסמנת Device code flow ומחילה Block access. לפני אכיפה מתחילים במצב דיווח בלבד ובוחנים את ההשפעה.

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

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

חדר ישיבות אחד אינו סיבה לפתוח את כל הארגון

בחלק ממכשירי Teams המסלול נחוץ לרישום, להגדרה מחדש או להזדהות חוזרת. ההנחיות הייעודיות של Microsoft למכשירי Teams מתייחסות לחשבונות המשאב של הציוד ולמשאב Device Registration Service. יש להתאים את החריגות לתרחיש ולבדוק אותן לפני אכיפה. חשבון המשאב של חדר הישיבות והחשבון האישי של הטכנאי הם שני חשבונות שונים.

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

מה צריך לראות ביומני הכניסה

לא כל שימוש בקוד מכשיר מעיד על תקיפה. המטרה היא לזהות שימוש שאינו מתאים לתפקיד, למכשיר או לתהליך שהארגון אישר. לפי תיעוד Microsoft על Authentication flows, אפשר לסנן את יומני הכניסה לפי פרוטוקול האימות. בחקירת בקשות המשך, השדה Original transfer method יכול לעזור לזהות תהליך שהתחיל ב Device Code גם כאשר הפעולה הנוכחית משתמשת במסלול אחר.

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

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

העובד כבר הזין קוד ואישר. מה עכשיו

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

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

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

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

מה כדאי לבדוק השבוע

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

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

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