Consent Phishing

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

המשפט האחרון הוא כל הבעיה. פישינג של פרטי הזדהות מייצר סוד גנוב, וסודות אפשר להחליף. Consent phishing מייצר אובייקט הרשאה שיושב בטננט שלכם, מחובר לאפליקציה, ואדיש לסיסמת המשתמש ולאופן שבו הוא הוכיח את זהותו. Device code phishing שואל סשן שהמשתמש כבר נמצא בעיצומו של תהליך ההתחברות אליו; consent phishing לוקח הענקה מואצלת קבועה ששורדת מעבר לסשן. שניהם מנצלים לרעה את OAuth, ורק אחד משאיר אחריו משהו בספרייה שלכם.

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

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

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

איך ההענקה עובדת בפועל

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

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

מה האפליקציה מחזיקה אחר כך

ברגע שהמשתמש בוחר Accept, האפליקציה מקבלת authorization code ופודה אותו תמורת access token. מכאן והלאה היא פועלת בתוך ההרשאות שהוענקו לה, והתוצאה, בניסוח של Microsoft עצמה, היא שהאפליקציה ממשיכה לעבוד ברקע גם אם המשתמש מתנתק. הגישה נמשכת עד שמישהו מבטל אותה, ו-refresh token שנמצא בשימוש פעיל אין לו גיל מקסימלי ב-Entra ID - אורך החיים המתועד שלו הוא "Until-revoked".

אילו הרשאות מתבקשות הוא הדבר הקרוב ביותר שיש לנו כאן למדידה. צוות התגובה לאירועים של Microsoft מדווח שתוקפים השתמשו בשילוב של שש משפחות הרשאות מואצלות - דואר, אנשי קשר, הגדרות תיבת דואר, אנשים, קבצים והערות - ב99% ממתקפות ה-consent phishing שצפה בהן. קראו את המספר בזהירות: הוא מתאר את הרכב העומס של צוות אחד, לא את תדירות המתקפה, ולא פורסמו איתו גודל מדגם, חלון זמן או מתודולוגיה.

שם האפליקציה הוא הסימן שחוזר שוב ושוב, ושלושה מקורות בלתי תלויים מתארים אותו:

• MITRE מציגה דוגמאות procedure לטכניקה הזו שבהן אפליקציות התחזו ל-"Google Defender" ול-"McAfee Email Protection".
• Microsoft דיווחה על פעילות עד אמצע 2026 שבה עובדים הונחו דרך תהליך consent כדי לאשר אפליקציה שהתחפשה לכלי נתונים לגיטימי של Salesforce.
• המרכז הקנדי לסייבר מתאר אפליקציה מחוברת חדשה שמופיעה בלוגי הביקורת עם שמות מעורפלים כמו "Support Tool" או "Data Loader".

השם צריך לשרוד מבט חטוף, לא חקירה.

מה הגדרת ה-consent שלכם אומרת עכשיו בפועל

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

הובטחו שינויים נוספים, והם הגיעו. התיעוד הנוכחי קורא למדיניות הזו "Let Microsoft manage your consent settings", קובע שהיא גם ברירת המחדל לטננט חדש, ומפרט מה היא חוסמת מ-consent של משתמשי קצה: 36 הרשאות שמכסות דואר, קבצים, אתרים, לוחות שנה, צ'אט, אנשי קשר ומשימות, בנוסף לפרוטוקולי הגישה הוותיקים יותר של Exchange Online.

החריג שמגיע מופעל

ברירת המחדל אינה "user consent כבוי". היא user consent מוגבל בהיקף, והיא מגיעה עם מדיניות שנייה שגם היא מופעלת כברירת מחדל: כזו שמאפשרת למשתמשי קצה לתת consent לאותן הרשאות דואר עבור רשימה קצרה של לקוחות דואר נקובים, ובהם Thunderbird ו-Apple Mail. אלה אפליקציות לגיטימיות ב-allow-list של Microsoft, לא חולשה. אבל מנהל מערכת שמאמין ש-consent כבוי, ומוצא בלוג הביקורת הענקה של הרשאות דואר, צריך לדעת שהפלטפורמה עצמה שמה שם את החריג הזה.

בקרה נוספת כבר פועלת. Risk-based step-up consent מתייחס לבקשה מאפליקציה multi-tenant שנרשמה לאחרונה בלי verified publisher, שמבקשת הרשאות שאינן בסיסיות, כמסוכנת, ומכריח אותה לעלות לאישור מנהל. התנאי שלה חשוב: היא מופעלת כברירת מחדל, אבל משנה התנהגות רק כש-user consent מופעל מלכתחילה.

ועכשיו החלק המביך. שני עמודי Microsoft עדכניים מתארים שתי ברירות מחדל שונות.

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

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

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

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

האם MFA עוצר consent phishing?

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

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

לשאלה אם איפוס סיסמת המשתמש עוזר יש תשובה דו-צדדית. Refresh tokens שורדים שינוי סיסמה בפני עצמם. במקומות שבהם Continuous Access Evaluation חל, tokens ארוכי טווח מבוטלים כמעט בזמן אמת על אירועים קריטיים כולל שינויי סיסמה - אבל זה תלוי בכך שהלקוח והמשאב תומכים בזה, ואפליקציה בשליטת תוקף לא מחויבת לכך.

איך מזהים את זה

הזיהוי כאן הוא מבני לפני שהוא טכני: מדובר בשני אירועים, ו-MITRE מסווגת אותם כשתי טכניקות תחת שתי טקטיקות שונות. השגת ה-token היא Steal Application Access Token תחת Credential Access, והתיאור שלה מציין במפורש את המתקפה הזו - הנדסה חברתית שגורמת למשתמשים להעניק לאפליקציות זדוניות גישה.

שימוש ב-token אחר כך הוא Application Access Token תחת Use Alternate Authentication Material, והטקטיקה שלו היא Lateral Movement. צוות שכיסה אחד מהם לא כיסה את השני.

שתי הטכניקות

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

מה לחפש בלוג הביקורת

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

• `Consent to application` - שם הפעילות לסנן לפיו.
• `IsAdminContent` - מוגדר ל-true כשה-consent מכסה את כל הארגון ולא משתמש בודד.
• `ConsentType` - אותה הבחנה בייצוא הרשאות, שבו `AllPrincipals` אומר שמנהל נתן consent עבור כל הטננט ו-`Principal` אומר שמשתמש בודד נתן consent עבור עצמו. ההנחיה של Microsoft חדה לגבי הראשון: כל אפליקציה שאינה של Microsoft ומחזיקה `AllPrincipals` צריכה להיבדק בקפידה.

שני מגבלות מגיעות מאותו עמוד, ושתיהן צריכות לשבת בראש לפני אירוע ולא במהלכו. הפורטל מציג הענקות admin consent עבור 90 הימים האחרונים בלבד. ואם auditing לא הופעל לפני המתקפה, אין מה לחקור, כי הנתונים לא קיימים.

השכבה ברישוי

ארגונים שמרשיינים את Defender for Cloud Apps מקבלים שכבה נוספת - ברישוי, לא הגדרה שיש לכולם. סיווג ה-Community use שלה מדרג עד כמה נפוץ שאפליקציה מקבלת הרשאה, כ-common, uncommon או rare, וזה מה שהופך אפליקציה נדירה שמבקשת הרשאות בחומרה גבוהה לשווה התראה. היא גם מגיעה עם זיהוי לשם OAuth מטעה: סימן השם מלמעלה, עם בקרה מחוברת.

הערת שוליים למבט הארוך. מודל האיום שמתאר את המתקפה הזו, כולל אפליקציה שמדמה consent של משתמש באמצעות screen-scraping, הוא מסמך IETF מינואר 2013. נוהג האבטחה העדכני של OAuth, שפורסם ב-2025, לא נושא את החומר הזה, ואף אחד משני המסמכים לא מופיע בעמוד הראשון של תוצאות החיפוש למונח הזה.

מה באמת מבטל את הגישה

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

1. שינוי הגדרת ה-user consent לא מבטל כלום. עדכונים להגדרות consent משפיעים רק על פעולות consent עתידיות; הענקות קיימות נשארות ללא שינוי והאפליקציה שומרת על הגישה שכבר יש לה.
2. השבתת האפליקציה עוצרת tokens חדשים, לא נוכחיים. כשהפלטפורמה משביתה אפליקציית OAuth זדונית, בקשות token חדשות ובקשות refresh נדחות, אבל access tokens קיימים נשארים בתוקף עד שפג תוקפם.
3. הסרת ההענקה היא הפעולה שמסירה את הגישה - עם סייג, בהמשך.

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

יש גם מלכודת במקום שבו מתבצעת ההסרה. Consent phishing מייצר מעצם הגדרתו הענקות consent של משתמש, כי הקורבן הוא בדרך כלל משתמש רגיל, ואת ההענקות האלה אי אפשר לבטל בממשק ה-admin center בכלל - הפורטל חושף ביטול רק בלשונית ה-admin consent, והענקות משתמש יוצאות דרך Graph API או PowerShell. מנהל מערכת שבודק את האפליקציה בפורטל, לא רואה הרשאות הניתנות לביטול ומסיק שהיא נקייה, פשוט קרא לא נכון את המסך.

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

הבקרות, ואיפה כל אחת נעצרת

רשימת הבדיקה החזקה ביותר שפורסמה בנושא הזה היא ממשלתית, והיא לא מופיעה בשום מקום בתוצאות החיפוש למונח. ה-secure configuration baseline של CISA ל-Microsoft Entra ID נושא כאן שלוש מדיניות, כולן מחייבות עבור סוכנויות אזרחיות פדרליות בארה"ב תחת הנחיה תפעולית מחייבת: רק מנהלים יורשו לרשום אפליקציות, user consent יוגבל, ותהליך admin consent יוגדר. אף אחד מחוץ לסוכנויות האלה לא כפוף לזה, וזו בדיוק הנקודה - זו הצהרה ציבורית וחופשית של מה "הגבילו user consent" אומר כשמישהו צריך לעמוד בביקורת מולה. המתחזקים שלה גם פתחו בנובמבר 2025 בדיקה האם מדיניות ה-consent דורשת עדכון אחרי השינויים של Microsoft, וזה אות הוגן לכך שהסטייה שתוארה למעלה אמיתית.

איפה כל בקרה נעצרת

• Publisher verification כבר נוצח בדיוק במתקפה הזו. זה אות האמון שגם ההנחיות של Microsoft וגם סיכום ה-AI של Google ממליצים עליו, ובינואר 2023 מרכז התגובה האבטחונית של Microsoft עצמה דיווח על קמפיין consent phishing שבו הגורם השיג מעמד verified publisher דרך חשבונות שותף מזויפים, בעיקר מול לקוחות בבריטניה ובאירלנד. Microsoft השביתה את האפליקציות וחיזקה אחר כך את תהליך הבדיקה. הבקרה עדיין שווה שתהיה; היא לא הוכחת כוונה.
• ל-Conditional Access יש נקודה עיוורת מתועדת כאן. מדיניות שממוקדת למשתמשים לא חוסמת קריאות שמבצעים service principals, ואפליקציה שקיבלה consent פועלת כ-service principal. כדי לכסות אותה נדרש Conditional Access ל-workload identities, וזו קונפיגורציה נפרדת.
• המשקל הנגדי הכנה, שחותך נגד אזעקה ולא בעדה: צוות הזהויות של Microsoft קובע שהמתקפה הזו נפוצה הרבה פחות מפישינג של פרטי הזדהות, ומסיק מסקנה תפעולית שלפיה משתמשים מוכנים אליה פחות. זו סיבה להסביר אותה לאנשים, לא סיבה להתייחס אליה כחשיפה הגדולה ביותר שלכם.

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

שתי הפלטפורמות לא מוגדרות באותו אופן

התיקון במאמר הזה ספציפי ל-Microsoft Entra ID, והמתקפה לא. Microsoft דיווחה ב-2026 על קמפיין ניצול לרעה של OAuth שחצה גם את Entra ID וגם את Google Workspace, שם ברירת המחדל המתועדת לגישת אפליקציות צד שלישי עדיין מתירנית: משתמשים רשאים לגשת לכל אפליקציית צד שלישי, ומנהלים יכולים להעביר אפליקציות ל-Trusted, Limited, Specific Google data או Blocked, ו-scopes מוגבלים נגישים רק לאפליקציות שמסומנות Trusted או שהוגדרו במפורש. העמוד הזה עודכן לאחרונה ב-14 באוגוסט 2026. אם אתם מריצים את שתי הפלטפורמות, בדקו את הגדרת Workspace בנפרד - השינוי של Microsoft לא אומר עליה כלום.

מה לא הצלחנו לאמת

שלושה דברים חסרים, ושימושי יותר לנקוב בהם מאשר לכתוב מסביבם. לא קיים נתון שכיחות שפורסם ל-consent phishing, לא חלק יחסי מאירועים ולא ספירת קמפיינים; ה-99% למעלה הוא מדד הרכב מעומס העבודה של צוות אחד. לא פורסם נתון על כמה טננטים קיימים באמת הועברו למדיניות ה-consent המנוהלת של Microsoft. ולא אותרה הצהרה בשאלה האם Google מתכננת שינוי מקביל לברירת המחדל שלה.

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

שאלות נפוצות על consent phishing

האם consent phishing זהה ל-illicit consent grant? הם מתארים את אותו אירוע מזוויות שונות. "Consent phishing" ממנה את ההנדסה החברתית, "illicit consent grant" ממנה את האובייקט שהיא מייצרת, ו-"OAuth phishing" הוא הקיצור הלא פורמלי. תיעוד התגובה לאירועים של Microsoft משתמש בשני, ושווה לדעת את זה כשאתם מחפשים בתיעוד של הספק שלכם.

איך רואים לאילו אפליקציות המשתמשים שלנו כבר נתנו consent? דרך מלאי ה-enterprise applications ותצוגת ההרשאות שלו, שמציגה admin consent ו-user consent בנפרד, או דרך ייצוא הרשאות לתמונה רוחבית של הטננט. לוג הביקורת עונה על שאלה אחרת: מתי התרחשה הענקה, ומי אישר אותה.

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

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

ההגדרה היא התשובה, אז לכו וקראו אותה

Consent phishing מוכרע בגבול ה-consent ולא בהתחברות, ולכן ההגנה היא הגדרת טננט ולא שיטת אימות חזקה יותר. להגדרה הזו יש ערך נוכחי, הערך הזה השתנה ביולי 2025, והתיעוד שמנהל מערכת הכי סביר שיקרא עדיין מתאר את הסידור שהוא החליף.

אז הצעד השימושי הבא קטן מספיק כדי לעשות אותו היום: פתחו את הגדרות ה-consent וקראו מה הן אומרות. אם Microsoft מנהלת אותן, אתם על ברירת המחדל המוגבלת עם חריג לקוחות הדואר שלה. אם הן מציינות verified publishers והרשאות low-impact, מישהו בחר בזה במכוון. אם הן מאפשרות user consent לכל אפליקציה, זה הסידור שלפני 2025 ושווה לנהל עליו שיחה. מה שלא יהיה כתוב שם, עכשיו אתם יודעים מה זה אומר - ותשובה טובה יותר מכל רשימת בדיקה, כי היא על הטננט שלכם ולא על ברירת המחדל של מישהו אחר.