Device Code Phishing

מה זה Device Code Phishing?

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

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

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

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

תסבירו לי כמו לילד בן 10

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

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

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

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

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

• סעיף 5.4 נקרא "Remote Phishing". לא הערת שוליים, אלא סעיף עם שם משלו בתוך שיקולי האבטחה.
• המפרט מתאר את המתקפה שכולם דנים בה כרגע. "ייתכן שה-device flow יופעל ממכשיר שנמצא בידי תוקף. לדוגמה, תוקף עשוי לשלוח הודעת אימייל שמנחה את משתמש היעד לבקר ב-verification URL ולהזין את ה-user code."
• המפרט מגדיר את הגבול של אמצעי ההגנה המובן מאליו. קודים קצרי חיים עוזרים, לפי המפרט, אבל "זה לא מונע מתוקף להציג token חדש, בייחוד אם הוא מתקשר עם המשתמש בזמן אמת."

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

באפריל 2026 ניתחה Microsoft קמפיין שהיא הגדירה כייחודי, כי הוא עבר "מסקריפטים סטטיים וידניים לתשתית מונעת AI". החידוש ש-Microsoft ציינה היה יצירה דינמית של ה-device code: ה-device code מופעל ברגע שהקורבן לוחץ, כך שחלון הזמן של 15 דקות אף פעם לא פג באמצע ההעברה.

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

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

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

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

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

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

"גורם האיום מייצר בקשת device code לגיטימית, ומערים על היעד כדי שיזין אותו בדף ההתחברות הלגיטימי. זה מעניק לתוקף access, ומאפשר לו ללכוד את ה-authentication tokens - access ו-refresh"

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

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

הניסוח של המסגרת שולח אתכם לכיוון הלא נכון

הרשומה של MITRE ל-T1566.002 היא המקום היחיד ב-ATT&CK שמזכיר במפורש את "device code phishing", והתיאור שלה אומר שהתוקף שולח קישור "שמפנה את הקורבן לדף הרשאה זדוני". הדוח של Microsoft אומר שהקורבן מזין את ה-device code בדף ההתחברות הלגיטימי. אם תאמינו לניסוח של המסגרת, תצאו לחפש דומיין דמוי שמעולם לא נרשם. מלבד זה, הרשומה היא המיפוי הנכון והיחידה שנוקבת בשם המונח, אז כדאי לקרוא את המשפט הזה כלא מדויק ולא כשגוי, ולצוד בהתאם.

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

המספר הנפוץ הוא 90 יום. ה-AI Overview של Google למונח הזה מתאר גישה "שלרוב נמשכת עד 90 יום." 90 יום הוא נתון אמיתי מתוך התיעוד של Microsoft, אבל הוא לא אומר את מה שחושבים שהוא אומר. הנה מה שהתיעוד על משכי החיים של הטוקנים מפרסם בפועל:

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

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

הסלוגן של איפוס הסיסמה, בהיקף הנכון

הטענה השכנה זקוקה לאותה גישה, בכיוון ההפוך. הטענה ש"איפוס סיסמה לא עוזר" חוזרת שוב ושוב ב-SERP הזה (עמוד תוצאות החיפוש), והיא נכונה לגבי refresh tokens. היא לא נכונה בכל מקום: אותו תיעוד אומר ש-access tokens ארוכי טווח תחת CAE "יבוטלו כמעט בזמן אמת בתגובה לאירועים קריטיים כמו השבתת חשבון ושינויי סיסמה." ל-CAE נדרשת תמיכה גם מצד הלקוח וגם מצד המשאב. הגרסה השימושית: תניחו שאיפוס סיסמה הוא לא בלימה (containment), ותתייחסו לסשן שתומך ב-CAE כאל היוצא מן הכלל.

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

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

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

זה לא תיאורטי. ב-30 ביולי 2026 MITRE פרסמה רשומת software על ערכת ה-phishing-as-a-service בשם Kali365, שנצפתה לראשונה באפריל 2026 ותוארה ככזו שמשלבת יצירת device code. דוגמת ה-procedure שלה תחת הרצה אומרת: "יצרה באופן דינמי device codes לגיטימיים שמוצגים על מסך הקורבן, לצד הוראות להעתיק ולהדביק את ה-device code."

כללי הזיהוי תחת הטכניקה הזו מסתכלים בכיוון הלא נכון

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

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

מה לצוד

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

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

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

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

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

העמדה של Microsoft ישירה באופן חריג. הנחיית ה-Conditional Access שלה אומרת שארגונים צריכים "להתקרב כמה שאפשר לחסימה חד-צדדית של device code flow," ולאפשר את ה-grant רק "במקרי שימוש מתועדים היטב ומאובטחים, כמו כלים legacy שאי אפשר לעדכן." לבקרה יש שם ומיקום, וזה מה שהופך אותה למעשית:

1. היכנסו ל-Entra ID > Conditional Access > Policies > New policy.
2. ב-Assignments: כל המשתמשים, חוץ מ-break-glass accounts שלכם.
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 הזה: הוא מראה מי משתמש ב-grant היום, וזאת בדיוק רשימת האנשים שהחסימה הייתה פוגעת בהם בלי אזהרה.

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

• ה-break-glass accounts מוחרגים, ולכן החסימה לעולם לא מוחלטת, מעצם התכנון (by design). בצעו audit לרשימת ההחרגה הזאת בקביעות.
• ה-service principals לא מכוסים. בניסוח של Microsoft: "קריאות שמבצעים service principals לא נחסמות על ידי מדיניות Conditional Access שההיקף שלה מוגבל למשתמשים." חסימה בהיקף משתמשים לא עושה כלום ל-workload identities, שדורשים Conditional Access for workload identities במקום זאת. אם ה-CI runners, הסקריפטים או האינטגרציות שלכם מזדהים כ-service principals, המדיניות הזו לא משפיעה עליהם.

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

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

הכותרת שמסתובבת אומרת שמתקפת Device Code Phishing עלתה ב-1,500% ב-2026. הנה המשפט שממנו נלקחה הכותרת, מתוך CrowdStrike's 2026 Threat Hunting Report, שפורסם ב-3 באוגוסט 2026:

"ניסיונות Device Code Phishing חודשיים קפצו פי 15 בתוך ששת החודשים האחרונים."

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

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

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

איפה הטיעון של העמוד הזה נעצר

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

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

שאלות נפוצות

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

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

לאילו טכניקות ATT&CK משתייכת מתקפת Device Code Phishing?

מתקפת Device Code Phishing משתרעת על כמה טכניקות: T1566.002 אחראית למסירה, והיא הרשומה היחידה שנוקבת בשם המונח. T1204.004 מתייחסת להדבקת הקוד. T1528 מתייחסת לגניבת ה-access token וה-refresh token. T1550.001 מתייחסת לשימוש בהם בהמשך. T1683.001 מתייחסת לתוכן הפיתיון.

האם איפוס סיסמה בולם את מתקפת Device Code Phishing?

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

למי יש צורך לגיטימי ב-device code flow?

התשובה, לפי התיאור של Microsoft עצמה, היא "כלים legacy שאי אפשר לעדכן." מצב Report-only יגיד לכם אם יש לכם כאלה, וזו תשובה טובה יותר מניחוש.

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

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

מה להגיד להם

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

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

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