Consent Phishing

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

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

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

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

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

איך עובדת מתקפת פישינג מסוג Consent

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

מסך האישור הוא המסך שאנשים רואים כל פעם שאפליקציה מבקשת להתחבר לחשבון. הדוגמה של Google היא אפליקציית כושר שמבקשת לצפות ב-Google Calendar שלכם, כדי שתוכל להציג לכם את השיעורים שקבעתם. המערכת שעומדת מאחורי המסכים האלה היא OAuth. היא נותנת לאפליקציה שאושרה טוקן, סוג של אישור מעבר, כך שהיא יכולה להשתמש בחשבון "בלי לקבל את פרטי ההזדהות של המשתמש". כך מתארת זאת MITRE ATT&CK, קטלוג ציבורי של שיטות התקיפה.

איך התוקף משתמש במסך האישור

ב-Consent phishing, התוקף בונה את האפליקציה. MITRE מתארת תוקפים "שבונים אפליקציה זדונית שנועדה לכך שתוענק לה גישה" ושולחים קישור ליעד "כדי לשדל אותו להעניק גישה לאפליקציה". מסך האישור עצמו אמיתי, וזו הסיבה שהשיטה עובדת. Microsoft מסבירה שבגלל שהוא "מגיע מ-IdP גדול ומהימן כמו Microsoft, Meta או Google, הוא נראה לגיטימי אפילו יותר". ספק הזהויות (IdP) הוא השירות שמטפל בהתחברות. לחיצת המשתמש על Accept היא זו שנותנת לאפליקציה של התוקף את הגישה שלה.

מה האפליקציה יכולה לעשות אחרי שאושרה

האפליקציה יכולה לפעול גם כשהמשתמש לא נמצא. Microsoft כותבת שהאפליקציה יכולה "לבצע קריאות API מטעם המשתמש, בכל ההרשאות שהמשתמש האציל לאפליקציה", כלומר היא שולחת בקשות לשירות כאילו היא המשתמש עצמו. היא יכולה גם "להמשיך לפעול ברקע גם אם המשתמש מתנתק", ו"לפעול בתוך היקף ההרשאות שהוענקו לה". MITRE ATT&CK מתעדת את המתקפה הזו תחת הקוד T1528, Steal Application Access Token, ומציינת שהאפליקציה "יכולה לקבל גישה שעשויה להיות ארוכת טווח למאפייני חשבון המשתמש".

למה הגישה יכולה להימשך: ההענקה והטוקנים

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

למה אימות רב-גורמי וסיסמה חדשה לא מבטלים את הגישה של האפליקציה

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

מתקפת פישינג מסוג Consent לעומת AiTM phishing, Device code phishing ו-Vishing

• פישינג: השיטה הכללית. מתקפת פישינג מסוג Consent מבקשת הרשאה במקום סיסמה.
• מתקפת AiTM phishing: עמוד מזויף מעביר את ההתחברות של המשתמש, ותופס את הסשן שנוצר ממנה. סשן (session) הוא המצב שבו האתר מזהה את המשתמש כמשתמש מחובר. במתקפת פישינג מסוג Consent מסך האישור אמיתי, והתוקף מקבל במקום זאת אפליקציה מאושרת.
• מתקפת Device code phishing: השיטה הזו מנצלת לרעה חלק אחר של OAuth, שנקרא device grant. המשתמש מקליד קוד בעמוד ההתחברות האמיתי של ספק הזהויות, ועצם הקלדת הקוד היא מה שמאשר את הסשן שהתוקף התחיל. במתקפת פישינג מסוג Consent, לעומת זאת, המשתמש מאשר הרשאות של אפליקציה זדונית. גם עמוד מזויף של התוקף יכול להוביל את המשתמש לאותו עמוד ההתחברות האמיתי. ההבדל הוא באיזה חלק של OAuth מנוצל, ולא בשאלה אם מעורב אתר מזויף.
• מתקפת Vishing: פישינג שמתבצע בשיחת טלפון. מתקשר יכול להדריך מישהו, שלב אחר שלב, באישור אפליקציה, כמו בדוגמה שבהמשך.

דוגמה מ-2025-2026: כלים מזויפים של Salesforce שאושרו בשיחות טלפון

לפי Microsoft, מתקפת פישינג מסוג Consent "נפוצה הרבה פחות מפישינג לפרטי הזדהות", ומשום כך אנשים "מכירים אותה פחות ולכן גם פגיעים לה יותר". היא עדיין בשימוש. ביולי 2026 Microsoft תיארה קמפיינים שהחלו באמצע 2025, ובהם מתקשרים התחזו לצוות ה-IT. ב"כמה מקרים מאומתים" הם הדריכו את העובדים, שלב אחר שלב, באישור, ובכך "אפליקציה זדונית שמתחזה לכלי Salesforce Data Loader לגיטימי קיבלה גישה". Microsoft אומרת שזיהתה פעילות עם "שיטות פעולה חופפות שמזוהות בדרך כלל עם ShinyHunters" - תיאור של שיטות דומות, לא ייחוס חד-משמעי.

האפליקציה הייתה בשליטת התוקף והתחזתה לכלי אמין. לאפליקציה זדונית יכולים להיות רישום אמיתי ומסך האישור של הפלטפורמה עצמה, ולכן מסך אמיתי לא מבטיח אפליקציה אמיתית. המרכז הקנדי לאבטחת סייבר (Canadian Centre for Cyber Security) הזהיר מפני התקפה מהסוג הזה במאי 2026, וציין מה כדאי לשים לב אליו לאחר מכן: "אפליקציה מקושרת חדשה מופיעה בלוג הביקורת בשמות מעורפלים כמו 'Support Tool' או 'Data Loader'."

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

לפני שאתם לוחצים על Accept

• מסך האישור שלא ציפיתם לו: אם לא התכוונתם לחבר את האפליקציה הזו, אל תאשרו אותה.
• שיחת טלפון או הודעה שמבקשות מכם לאשר אפליקציה: בעבודה, פנו לצוות ה-IT דרך איש קשר שאתם כבר מכירים, לפני שאתם מאשרים משהו.
• מה האפליקציה מבקשת: קראו את הבקשה. Microsoft ממליצה לבדוק ש"ההרשאות המבוקשות תואמות את התרחיש שהאפליקציה נועדה לאפשר", גם אם האפליקציה מציגה מפרסם מאומת (verified publisher). Google מציעה לקרוא קודם את "מדיניות הפרטיות וגילויי האבטחה" של האפליקציה.

אם כבר אישרתם אפליקציה

• חשבון Google פרטי: עברו לעמוד האפליקציות המקושרות בחשבון Google שלכם, בחרו ב-Access to your Google Account, בחרו את האפליקציה, ואז לחצו על See details ו-Remove access. לאחר הסרת הגישה, "האפליקציה לא יכולה לגשת לחשבון Google שלכם", כך לפי דף העזרה של Google.
• חשבון עבודה: דווחו לצוות ה-IT מיידית. צוות ה-IT צריך לבדוק אילו הרשאות האפליקציה קיבלה ומה היא עשתה אחר כך, לבטל את ההסכמה (consent) הזדונית, ולהשבית או לחסום אפליקציה שאומתה כזדונית כשמתאים. הצוות צריך גם לטפל בטוקנים או בסשנים לפי הנחיות התגובה לאירועים של הספק, כמו מדריך Microsoft לחקירת הענקת הסכמה לאפליקציה. המהירות שבה טוקנים קיימים מפסיקים לעבוד משתנה בהתאם לפלטפורמה ולסוג הטוקן, ולכן אי אפשר להניח שפעולת ביטול אחת מסיימת את כל הגישה בבת אחת.
• נתונים שכבר הועתקו: הסרת הגישה לא מוחקת נתונים שהאפליקציה כבר העתיקה. Google מציינת שאפליקציה יכולה "להעתיק ולשמור את הנתונים שלכם בשרתים שלה".
• הסיסמה שלכם: מומלץ להחליף את הסיסמה הזו, וגם בכל חשבון אחר שמשתמש באותה סיסמה. זה צעד נוסף ומומלץ, אבל כשלעצמו הוא לא מסיר את הגישה של האפליקציה.

למנהלי מערכת

• הגבילו מי יכול לאשר אפליקציות: CISA פרסמה מסמך בשם secure configuration baseline for Microsoft 365. המסמך דורש כי "יש להגביל את הסכמת המשתמשים לאפליקציות", וכי "יש להגדיר לאפליקציות תהליך הסכמה שעובר באישור מנהל מערכת". מדיניות ההסכמה המנוהלת (managed consent policy) של Microsoft הוכרזה כפעילה כברירת מחדל מיולי 2025. היא מגבילה את ההסכמה שמשתמשים נותנים לרשימה מוגדרת של הרשאות רגישות, כמו הרשאות לקבצים, לאתרים, לדואר וללוחות שנה. Microsoft יכולה לעדכן את המדיניות הזו כשההמלצות שלה משתנות. משתמשים עדיין יכולים לאשר אפליקציות שמבקשות הרשאות שאינן ברשימה הזו, ולכן המדיניות אינה חסימה גורפת על גישה לקבצים או לאתרים, וגם לא על Consent phishing. המדיניות היא "ברירת המחדל לטננט חדש", כלומר לארגון שהוקם לאחרונה. בדקו את ההגדרות בפועל של הארגון שלכם.
• בדקו אישורים שניתנו לפני השינוי: Microsoft מציינת שעדכונים בהגדרת ההסכמה "משפיעים רק על פעולות הסכמה עתידיות לגבי אפליקציות". משמעות הדבר היא שאפליקציות שאושרו מוקדם יותר שומרות את ההרשאות שלהן, ודורשות בדיקה נפרדת.
• עברו על האפליקציות המקושרות: חפשו אפליקציות חדשות עם שמות עמומים, וכפי שממליץ המרכז הקנדי לאבטחת סייבר: "לבדוק ולצמצם אינטגרציות SaaS של צדדים שלישיים, להחליף פרטי הזדהות ולבטל טוקנים שלא בשימוש".

דיווח על הניסיון

• בישראל: דווחו על ניסיון פישינג בשירות "דיווח על אירוע סייבר" של מערך הסייבר הלאומי, דרך טופס מקוון לאזרחים או לארגונים, ותקבלו מענה מקצועי ראשוני. אפשר גם להתקשר בחינם למרכז 119, לדיווח ולסיוע ראשוני.
• בארצות הברית: דווחו על ניסיון הפישינג ל-FTC בכתובת ReportFraud.ftc.gov, והעבירו אימיילי פישינג ל-Anti-Phishing Working Group בכתובת reportphishing@apwg.org.
• בבריטניה: העבירו אימייל חשוד לכתובת report@phishing.gov.uk.
• במדינות אחרות: חפשו את השירות הלאומי של המדינה שלכם לדיווח על פישינג.