Consent Phishing

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

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

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

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

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

איך ההענקה באמת עובדת

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

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

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

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

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

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

• המסגרת MITRE מציגה דוגמאות ביצוע לטכניקה הזו, שבהן אפליקציות התחזו ל"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 כבויה", אלא מצב שבו הגדרת ה-consent של המשתמשים מוגבלת בהיקפה. הגדרה זו מגיעה יחד עם מדיניות שנייה שגם היא מופעלת כברירת מחדל. המדיניות השנייה מתירה למשתמשי קצה לתת consent לאותן הרשאות דואר, לגבי רשימה קצרה של תוכנות דואר ספציפיות, ובהן Thunderbird ו-Apple Mail. מדובר באפליקציות לגיטימיות שברשימת ההיתרים של Microsoft, ולא בפגיעות. אבל מנהל מערכת שמאמין שהגדרת ה-consent כבויה, ומוצא בלוג הביקורת הענקה של הרשאת דואר, צריך לדעת שהפלטפורמה הוסיפה את החריג הזה.

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

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

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

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

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

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

האם MFA עוצר Consent phishing?

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

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

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

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

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

השימוש בטוקן בהמשך הוא הטכניקה Application Access Token תחת הטכניקה Use Alternate Authentication Material, והטקטיקה שלה היא תנועה רוחבית (Lateral Movement). צוות שכיסה טכניקה אחת לא כיסה את השנייה.

שתי הטכניקות

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

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

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

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

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

השכבה שדורשת רישיון

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שאלות נפוצות

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

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

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

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

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

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

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