Device Code Phishing

מה זה device code phishing?

Device code phishing מנצל לרעה את OAuth 2.0 device authorization grant. התוקף מתחיל תהליך התחברות של מכשיר, שולח לקורבן את הקוד שנוצר, והקורבן מזין אותו בדף ההתחברות האמיתי של הספק ומשלים MFA - ובכך מעביר לתוקף access token ו-refresh token. אין אתר מזויף ואין סיסמה שנגנבה.

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

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

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

הסבירו לי כאילו אני בן 10

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

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

המתקפה כתובה במפרט, וכבר מאז 2019

ה-device flow מוגדר ב-RFC 8628, מפרט standards-track שפורסם באוגוסט 2019 על ידי ארבעה מחברים מ-Google, Ping Identity, Microsoft ו-ARM. שווה לקרוא אותו, כי הוא לא רק מאפשר את המתקפה הזו. הוא מתאר אותה.

שלושה דברים יושבים במסמך הזה:

• סעיף 5.4 נקרא "Remote Phishing". לא הערת שוליים. סעיף מפורש בשיקולי האבטחה.
• הוא מתאר את המתקפה שכולם מדברים עליה עכשיו. "It is possible for the device flow to be initiated on a device in an attacker's possession. For example, an attacker might send an email instructing the target user to visit the verification URL and enter the user code."
• הוא מציין את גבול אמצעי המיטיגציה המובן מאליו. משך חיים קצר לקוד עוזר, אומר המפרט, אבל "this doesn't prevent a phisher from presenting a fresh token, particularly if they are interacting with the user in real time."

החידוש של 2026 כבר היה במודל האיומים של 2019

באפריל 2026 Microsoft ניתחה קמפיין שתיארה כחריג כי עבר "away from static, manual scripts toward an AI-driven infrastructure". החידוש שציינה היה יצירת קוד דינמית: להפעיל את הקוד ברגע שהקורבן לוחץ, כך שחלון 15 הדקות לא פג בדרך.

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

אמצעי המיטיגציה של המפרט עצמו שווים קריאה זה לצד זה:

• להגיד למשתמש מה הוא מאשר. שרת ההרשאות אמור לציין שמכשיר מאושר ולוודא שהוא שלו. הניסוח הוא RECOMMENDED ו-SHOULD, לא MUST.
• לא לשלוח את הווריאנט עם מילוי מראש. המפרט מסמן פיצ'ר אופציונלי, verification URL עם הקוד כבר מוטמע, כמסוכן במיוחד כי המשתמש אף פעם לא מקליד כלום. הפלטפורמה של Microsoft לא תומכת בשדה הזה בכלל.

משהו חסר, עם זאת. ה-developer reference של Microsoft ל-flow הזה מקשר ל-RFC 8628 פעמיים, ובקריאה מקצה לקצה ב-12 באוגוסט 2026 אין בו שום הערת אבטחה על פישינג. תיבת האזהרה היחידה שלו עוסקת באי-פרסור של tokens שאינכם מחזיקים. מפתח שמפעיל את ה-flow מתוך התיעוד אף פעם לא נחשף למה שסעיף 5.4 אומר.

למה בקשת ה-MFA נענית נכון ועדיין מפסידים

הנה התיאור של Microsoft עצמה לקמפיין Storm-2372, שהיא עוקבת אחריו מאז אוגוסט 2024:

"the threat actor generates a legitimate device code request and tricks the target into entering it into a legitimate sign-in page. This grants the actor access and enables them to capture the authentication - access and refresh - tokens"

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

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

הניסוח של ה-framework שולח אתכם לכיוון הלא נכון

הרשומה T1566.002 של MITRE היא המקום היחיד ב-ATT&CK שקורא ל-"device code phishing" במפורש, והתיאור שלה אומר שהיריב שולח קישור "that directs the victim to a malicious authorization page". הדוח של Microsoft אומר שהקורבן מזין את הקוד בדף לגיטימי. אם מאמינים לניסוח של ה-framework, יוצאים לצוד דומיין דמוי שמעולם לא נרשם. מלבד זאת הרשומה היא המיפוי הנכון והיחיד שנוקב בשם, אז קראו את המשפט כלא מדויק ולא כשגוי, וצודו בהתאם.

כמה זמן התוקף באמת שומר על הגישה

המספר שמסתובב הוא תשעים יום. ה-AI Overview של Google למונח הזה נותן גישה "often lasting up to 90 days". תשעים יום הוא נתון אמיתי מתיעוד Microsoft, והוא לא אומר את מה שמשתמשים בו בשבילו. הנה מה ש-ה-token lifetime reference באמת מפרסם:

• Refresh Token Max Inactive Time: 90 days. זה timeout של חוסר פעילות. כמה זמן refresh token יכול לשבת בלי שימוש לפני שהוא מת.
• Multi-Factor Refresh Token Max Age: "Until-revoked". לא תשעים יום. עד שמישהו מבטל אותו.
• Access tokens: 60 עד 90 דקות אקראיות, בממוצע סביב 75. כש-Continuous Access Evaluation פעיל, 24 עד 28 שעות.
• כלום מזה לא ניתן לכוונון. משכי החיים של refresh ו-session tokens הפסיקו להיות ניתנים להגדרה ב-30 בינואר 2021, ומדיניות קיימת שמגדירה אותם מולכת להתעלמות.

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

סלוגן איפוס הסיסמה, עם היקף

הטענה השכנה צריכה את אותו טיפול בכיוון ההפוך. "איפוס סיסמה לא עוזר" חוזר שטוח בכל ה-SERP הזה, והוא נכון לגבי refresh tokens. הוא לא נכון בכל מקום: אותו תיעוד אומר ש-access tokens ארוכי חיים תחת Continuous Access Evaluation "will be revoked in near real time in response to critical events such as account disablement and password changes". CAE דורש שגם הלקוח וגם המשאב יתמכו בו. אז הגרסה השימושית היא: הניחו שאיפוס סיסמה הוא לא הכלה, והתייחסו ל-session שתומך ב-CAE כחריג.

למי שעוקב אחרי כמה זמן חדירה יושבת בלי שזיהו אותה, השעון כאן מתחיל כשה-token מונפק, לא כשההתראה מופעלת.

שרשרת ה-ATT&CK, והפער שבתוכה

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

זה לא תיאורטי. ב-30 ביולי 2026 MITRE פרסמה רשומת software ל-Kali365, ערכת phishing-as-a-service שנצפתה לראשונה באפריל 2026 ומתוארת ככזו שמשלבת יצירת device code. דוגמת ה-procedure שלה תחת טכניקת ה-Execution קוראת: "has dynamically generated legitimate device codes that displays on the victims screen alongside instructions to copy and paste the device code."

ה-analytics מתחת לטכניקה הזו צופים על המשטח הלא נכון

אסטרטגיית הזיהוי של T1204.004 נושאת שלושה analytics. אחד מתאר משתמש שפותח Run, PowerShell או CMD ומדביק one-liner מעורפל (obfuscated). אחד מתאר הדבקה ל-bash או zsh. אחד מתאר הדבקה ל-Terminal.app או iTerm2. שלושתם צופים על פקודה שנכנסת ל-shell, והווריאנט של device code שמסווג תחת אותה טכניקה אף פעם לא נוגע ב-shell. הקורבן מדביק קוד בדפדפן.

אז צוות עם זיהוי ClickFix מוצק יכול לסמן את T1204.004 כמכוסה, ובפועל אין לו שום דבר שיראה את זה. זו השוואה שנמשכת בין שני עמודי MITRE, לא טענה ש-MITRE עצמה מעלה, אז בדקו בעצמכם. שניהם במרחק קליק אחד.

מה לצוד

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

• חפשו קוד שגיאה 50199 ואחריו הצלחה לאותו חשבון בתוך חלון של חמש דקות. זו הצורה שהנחיית ה-advanced hunting של Microsoft עצמה מאמתת מולה.
• טבלאות לשאילתה: EntraIdSigninEvents לאימות עצמו, UrlClickEvents ללחיצה שקדמה לו, CloudAppEvents למה שה-token עשה אחר כך.
• שדות שנושאים את הקורלציה: ErrorCode, RiskLevelDuringSignin, AccountUpn, IPAddress, SessionId, CorrelationId.
• ואז הסתכלו מיד אחרי. בקמפיין שנצפה, רישום מכשיר הגיע בתוך עשר דקות מהחדירה, ובחלק מהמקרים הופיעו חוקי inbox שעות אחר כך. אות בודד הוא דו-משמעי; הרצף לא.

הכול ברשימה הזו הוא משהו לחפש, אף פעם לא משהו להגדיר.

פרט אחד על שכבת ההתראות שווה לדעת. Microsoft נוקבת בכמה זיהויים של Defender XDR לזה, אחד מהם "Anomalous OAuth device code authentication activity". אותו מחרוזת מדויקת היא גם אחת מהחיפושים הקשורים ש-Google מחזיר לנושא הזה - אנשים מגיעים לכאן כי ההתראה הופעלה ב-tenant שלהם והם הדביקו את השם בשורת החיפוש. הזיהוי לא היפותטי.

איך לחסום את זה, ומה זה עולה

העמדה של Microsoft ישירה בצורה חריגה. הנחיית ה-Conditional Access שלה אומרת שארגונים צריכים "get as close as possible to a unilateral block on device code flow", ולאפשר אותו רק "in well documented and secured use cases, like legacy tooling that can't be updated". לבקרה יש שם ומיקום, וזה מה שהופך אותה לברת-ביצוע:

1. Entra ID > Conditional Access > Policies > New policy.
2. Assignments: כל המשתמשים, למעט חשבונות ה-break-glass שלכם.
3. Target resources: כל המשאבים.
4. Conditions > Authentication Flows > Configure: Yes > בחרו Device code flow.
5. Access controls > Grant > Block access.
6. הפעילו קודם כ-Report-only, ואז העבירו למצב פעיל.

Report-only הוא לא פורמליות. הוא התשובה ל-"מה זה ישבור". ההנחיה של Microsoft עצמה היא לבצע audit לשימוש הקיים לפני החסימה, ו-report-only הוא ה-audit הזה: הוא מראה מי משתמש ב-flow היום, וזו בדיוק רשימת האנשים שאתם אחרת תהרסו להם את יום שני.

שני גבולות כנים, שניהם מאותו עמוד, והשני הוא זה שנושך.

• חשבונות break-glass מוחרגים, כך שהחסימה אף פעם לא מוחלטת לגמרי מעצם התכנון (by design). בצעו audit לרשימת ההחרגות בלוח זמנים קבוע.
• Service principals לא מכוסים. בניסוח של Microsoft: "Calls made by service principals aren't blocked by Conditional Access policies scoped to users." חסימה בהיקף משתמשים לא עושה כלום ל-workload identities, שדורשים Conditional Access for workload identities במקום. אם ה-CI runners, הסקריפטים או האינטגרציות שלכם מזדהים כ-service principals, המדיניות הזו לא נוגעת בהם.

כל עוד אתם ב-blade הזה: אותו תנאי Authentication Flows חוסם גם authentication transfer, שמעביר session ממחשב לטלפון. שום דבר באיסוף לא מזכיר אותו, וזו אותה קטגוריה של דבר.

מה הנתון 1,500% באמת מדד

הכותרת שמסתובבת היא ש-device code phishing עלה ב-1,500% ב-2026. הנה המשפט שממנו זה הגיע, ב-CrowdStrike 2026 Threat Hunting Report, שפורסם ב-3 באוגוסט 2026:

"Monthly device code phishing attempts jumped 15x in the past six months."

שלושה דברים השתנו בדרך לכותרת. היחידה: attempts, כלומר פיתיונות שנשלחו, לא חשבונות שנפרצו. החלון: שישה חודשים מתגלגלים, לא שנת לוח שנה. החשבון: עלייה פי 15 היא גידול של 1,400%, לא 1,500%.

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

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

איפה הטיעון הזה נעצר

ארבעה גבולות.

• טענת המפרט מוגבלת לאיסוף אחד. RFC 8628 לא מופיע בשום מקום באיסוף החיפוש הדו-מנועי שעליו נבנה המאמר, שנלקח ב-12 באוגוסט 2026. מישהו בוודאי כתב על זה; הנקודה היא שאף אחד שדורג על המונח באותו יום לא עשה זאת.
• אין נתון שכיחות, ולכן העמוד הזה לא מעלה טענת שכיחות. שום דבר כאן לא אומר איזה חלק מה-tenants משאירים device code flow מופעל, או איזה שיעור מהתחברויות device code הן זדוניות: לא נמצא נתון מדוד בר-ציטוט לאף אחד מהם. מי שמצטט לכם אחד כזה, תשאלו מאיפה הוא הגיע.
• פער הזיהוי הוא השוואה נגזרת. MITRE לא אומרת שה-analytics של ClickFix מפספסים את וריאנט ה-device code. שלושת ה-analytics מתארים הדבקות ל-shell והווריאנט עובר בדפדפן; הקריאה הזו ברורה אבל היא שלנו, לא של ה-framework.
• רק מקור אחד למעלה הוא ספק אבטחה, בנושא שבו עשרה מתוך שנים-עשר העמודים שחזרו הם כאלה, והוא מצוטט רק כמקור למספר שכבר הסתובב. זה מכוון אבל לא טוהר: כל טענה נושאת כאן עמדה מאחוריה מפרט, מסמך פלטפורמה, רשומת framework או דוח קמפיין first-party, כך ששכבת הספקים הייתה מיותרת ולא מביכה. כמה ספקים שמתחרים על המונח הזה יושבים גם בקטגוריות הספונסרים של האתר עצמו, וזה בדיוק למה ה-primaries עשו את העבודה.

שאלות נפוצות

האם דף ההתחברות מזויף?

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

איזו טכניקת ATT&CK היא device code phishing?

היא חוצה כמה. T1566.002 למסירה והיא הרשומה היחידה שנוקבת בשם, T1204.004 להדבקה, T1528 לגניבת ה-token, T1550.001 לשימוש ב-tokens אחר כך, ו-T1683.001 לתוכן הפיתיון.

האם איפוס סיסמה מכיל את זה?

הניחו שלא. איפוס לא מבטל refresh tokens, וביטול שלהם הוא פעולה נפרדת. החריג הוא session של Continuous Access Evaluation, שבו שינוי סיסמה כן מפעיל ביטול כמעט בזמן אמת, אבל זה דורש תמיכה גם בלקוח וגם במשאב.

מי באמת צריך device code flow?

לפי התיאור של Microsoft עצמה, "legacy tooling that can't be updated". מצב report-only יגיד לכם אם יש לכם כאלה, וזו תשובה טובה יותר מניחוש.

האם חסימה תשבור את ה-CI או את הסקריפטים שלי?

ייתכן, ומדיניות בהיקף משתמשים לא תגיד לכם, כי service principals לא נחסמים על ידי Conditional Access שמוגדר על משתמשים. אוטומציה שמזדהה כ-workload identity צריכה Conditional Access for workload identities במקום. זה החלק שהכי סביר להפתיע אתכם.

מה להגיד להם

מישהו שלח לכם כותרת ושאל אם אתם חשופים. הנה התשובה, לפי הסדר.

1. הריצו את מדיניות ה-report-only. Conditions > Authentication Flows > Device code flow > Block access, ב-report-only. היא עונה על "האם אנחנו משתמשים בזה" ועל "מה יישבר" במהלך אחד, וזה הצעד הראשון ש-Microsoft עצמה ממליצה עליו.
2. ואז הריצו את הציד. קוד שגיאה 50199 ואחריו הצלחה בתוך חמש דקות, בקורלציה מול לחיצות URL וכל רישום מכשיר שבא אחרי.

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