MFA Fatigue (Push Bombing): איך ההתקפה עובדת, איך מזהים אותה ואיך עוצרים אותה

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

רוב ההסברים נעצרים ב־"אל תלחצו Approve". כאן הולכים רחוק יותר: אות הלוג המדויק שכל מתקפה משאירה אצל ספק הזהויות, והבקרה הספציפית שעוצרת אותה. נפרק את הטכניקה ואת המיפוי ל־MITRE, נעבור על שרשראות התקיפה האמיתיות מתוך דוחות האירוע המקוריים, נציין את מחרוזות הזיהוי ש־SOC צד, נגדיר את בקרות הספקים שמנטרלות אותה, ונמקם את הכול בתוך היררכיית העמידות לפישינג של CISA — שבה number matching הוא שלב הביניים ו־passkeys הם היעד הסופי.

מה זה MFA Fatigue?

MFA Fatigue — נקראת גם MFA bombing או Push Bombing — היא מתקפה שבה מי שכבר מחזיק בסיסמה שלכם מציף את אפליקציית ה־authenticator בבקשות אישור התחברות חוזרות עד שמאשרים אחת מתוך בלבול או עצבנות. לחיצה אחת כזו עוקפת את אימות רב־הגורמים ומוסרת את החשבון. MITRE מקטלגת אותה כטכניקה T1621.

לטכניקה יש כמה שמות, וחשוב להכיר את כולם. ספקים קוראים לה MFA prompt spamming או MFA bombing; CISA משתמשת במונח "push bombing". כולם מתארים את אותו התנהגות: הפצצת המשתמש בהתראות push עד שאחת מתקבלת. ב־MITRE ATT&CK זה T1621, Multi-Factor Authentication Request Generation, טכניקת Credential Access. השם חשוב כי הוא מקבע את ההיקף: זה עקיפת גורם שני שמתחילה אחרי שהסיסמה כבר בידי התוקף — לא שיטה לגניבת הסיסמה עצמה.

איך עובדת מתקפת MFA Fatigue?

המתקפה נשענת על עובדה אחת: אדם אמיתי חייב לאשר את ה־prompt. כל השאר מתוכנן כדי לגרום לאישור הזה לקרות. השרשרת קצרה:

1. התוקף כבר מחזיק באישורים תקפים. הם נגנבו בפישינג, נרכשו בשוק פלילי, או נשלפו ע״י infostealer. MFA Fatigue מניחה שהשלב הזה כבר מאחורינו.
2. הם מפעילים הצפה של בקשות אישור push באמצעות ניסיונות התחברות חוזרים ונשנים, ושולחים התראה אחרי התראה ל־authenticator של הקורבן.
3. לעיתים קרובות מוסיפים דחיפה של הנדסה חברתית — שיחה או הודעה שמתחזות לתמיכת IT כדי לשכנע את היעד לאשר. בפריצה ל־Uber התוקף התחזה לתמיכת IT של Uber כדי לשכנע את העובד לקבל.
4. הקורבן מאשר prompt אחד מתוך בלבול, עצבנות או רפלקס, והתוקף יורש את הסשן המאומת.

למה הצפה בכלל עובדת? כי הסיכויים לטובת התוקף כשיש מספיק prompts. הטלמטריה של Microsoft עצמה מצאה ש־כ־1% מהמשתמשים יאשרו בקשת אישור פשוטה כבר בניסיון הראשון, ו־Microsoft מדווחת שהמתקפות האלה בעלייה. אחוז אחד נשמע קטן — עד שמכפילים אותו בהצפה שמכוונת לאדם אחד, או לכל כוח העבודה. יעד הבקרה, אם כך, הוא לא כוח הרצון של המשתמש. זה האישור העיוור עצמו — בדיוק מה שהתיקון בחלק מאוחר יותר מסיר.

איך נראית מתקפת MFA Fatigue אמיתית?

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

• Uber, ספטמבר 2022: תוקף השתמש באישורים גנובים של קבלן חיצוני, הציף את החשבון בבקשות 2FA עד שאחת אושרה, ו־Uber קשרה את הפריצה לקבוצת Lapsus$. לפי הדיווח של Uber עצמה, הסיסמה הארגונית של הקבלן כנראה נרכשה בדארק ווב אחרי שנוזקה חשפה אותה. זו פריצת ה־MFA Fatigue הקנונית.
• Cisco, מאי 2022: לפי Cisco Talos, התוקף הריץ שיחות voice-phishing תחת מעטה של ארגונים מהימנים כדי לשכנע את הקורבן לאשר התראות MFA push, ובסופו של דבר הצליח לקבל אישור push שפתח גישת VPN.
• Microsoft / Lapsus$ (DEV-0537): צוות המודיעין של Microsoft תיעד את אותה קבוצה משתמשת ב־session-token replay ובסיסמאות גנובות כדי להפעיל prompts של אישור פשוט, ולהציף את היעד עד שניתנה הסכמה.
• Scattered Spider, עדיין פעילה: ה־advisory המשותף של CISA ו־FBI ממפה את Scattered Spider ל־T1621 וקובע שהקבוצה שולחת בקשות MFA חוזרות כדי להוביל עובדים לאישור. ה־advisory עודכן לאחרונה ביולי 2025 עם ממצאי FBI עדכניים מיוני 2025, ודוח M-Trends 2026 של Mandiant מתעד voice phishing — וקטור המסירה השכיח — כשהוא מזנק לווקטור הגישה הראשונית השני בשכיחותו.

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

איך מזהים MFA Fatigue?

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

ציד ה־burst

לוגיקת הציד היא burst. push אחד שנדחה הוא שגרתי; אשכול של אירועי דחייה למשתמש בודד בחלון זמן קצר הוא אות ה־fatigue. תוכן הזיהוי של Splunk, למשל, מתריע על יותר מעשרה ניסיונות MFA כושלים בתוך עשר דקות — סף שכדאי לכוון לסביבה שלכם.

מה אותות הדחייה מפספסים

יש כאן מגבלה כנה אחת. המחרוזות האלה תופסות דחיות ודיווחי הונאה — כלומר הן נורות כשהמתקפה נכשלת. מתקפת fatigue מוצלחת מסתיימת באישור, שנראה כמו התחברות רגילה. לכן צריך לצמד את bursts הדחייה לאותות שתופסים את המקרה המוצלח: impossible travel, מכשיר חדש, או סשן חריג מיד אחרי רצף דחיות. זיהוי אומר לכם שחשבון מותקף; הוא לא אומר, לבדו, שהתוקף נכנס.

הערה קצרה על מחרוזת Entra: 500121 מופיעה בלוגי ההתחברות כסיבת כשל, והניסוח "Authentication failed during strong authentication request" מגיע מתשובות התמיכה של Microsoft — לא ממראה השגיאות הקנוני של AADSTS. התייחסו אליה כאות בלוג התחברות, וכך גם תוכן הזיהוי משתמש בה.

איך עוצרים מתקפות MFA Fatigue?

זיהוי אומר לכם שזה קורה; הבקרות הבאות גורמות לזה להפסיק לעבוד. כל אחת תוקפת את אותו חולשה — האישור העיוור — וכל אחת מוגדרת אחרת.

Microsoft Authenticator: number matching

כשמשתמש מגיב ל־push, האפליקציה מציגה מספר ממסך ההתחברות שהמשתמש חייב להקליד כדי לאשר. Number matching מופעל לכל התראות ה־push של Authenticator, ומשתמשים לא יכולים לבטל אותו. צרפו לזה additional context, שמציג את שם האפליקציה המבקשת ואת מיקום ההתחברות על ה־prompt — כך שבקשה חריגה קלה יותר לדחייה.

Okta Verify: number challenge

Okta מציגה מספר ב־Sign-In Widget שהמשתמש בוחר באפליקציה. בניגוד להגדרה המחייבת של Microsoft, כאן זה לבחירת האדמין: אפשר לאכוף אף פעם, רק בהתחברויות בסיכון גבוה, או בכל אתגרי ה־push. אכפו על כל אתגרי ה־push כשהסיכון מצדיק, והוסיפו ThreatInsight — שמעריך בקשות התחברות מול מוניטין IP ויכול לרשום ולחסום תעבורה מכתובות זדוניות מוכרות לפני האימות.

Cisco Duo: Verified Duo Push

Duo יכול לדרוש מהמשתמש להזין קוד בן שלוש עד שש ספרות, עם ברירת מחדל של שלוש, לפני אישור ה־push. שימו לב לברירות המחדל: Verified Push כבוי כברירת מחדל ב־Duo Advantage ו־Premier, והוא דורש גרסת Duo Mobile עדכנית — אז ודאו את שניהם לפני שסומכים על זה.

לצד אלה, rate-limiting ונעילה של ניסיונות push חוזרים מרסנים את ההצפה, ודיווח הונאה הופך משתמש מותקף למקור התראות. כל בקרה עובדת באותו מנגנון: היא מחליפה אישור בלחיצה אחת בפעולה שהתוקף לא יכול להשלים מבחוץ. אמתו את האפשרויות המדויקות מול גרסת ה־IdP שלכם — ברירות מחדל והגדרות זמינות משתנות בין מהדורות.

האם number matching מספיק כדי לעצור MFA Fatigue?

Number matching היא בקרה חזקה, והיא לא קו הסיום. ההנחיה של CISA מדויקת בעניין הזה. בדירוג חוזק ה־MFA שלהם, app-based push עם number matching מופיע כעמיד ל־push bombing, בעוד שאותו push בלי number matching פגיע אליו. זה שיפור אמיתי, וזו הסיבה שהפעלת number matching היא הצעד הראשון הנכון.

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

ההיררכיה, והיעד הסופי

CISA ממקמת את התיקון העמיד מעליו. ההיררכיה רצה משיטות עמידות לפישינג בראש — FIDO/WebAuthn ואימות מבוסס PKI, שבהן CISA מכנה phishing-resistant MFA כ־"gold standard" ו־push bombing פשוט לא רלוונטי — דרך app-based push עם number matching באמצע, ועד SMS וקול בקצה החלש. היעד הסופי הוא מעבר ל־passkeys עמידים לפישינג, והמעבר כבר בעיצומו: FIDO Alliance מעריכה ש־5 מיליארד passkeys בשימוש ברחבי העולם, ו־75% מהאנשים הפעילו passkey בלפחות חשבון אחד. במקום שבו number matching מסיר את האישור העיוור, passkey מסיר לחלוטין את ה־prompt שניתן לאשר.

השורה התחתונה

MFA Fatigue עובדת רק כי אדם אמיתי נמצא בלולאה כדי ללחוץ Approve. התלות הבודדת הזו היא גם כל ההגנה. תנו ללחיצה משמעות עם number matching, number challenge או Verified Push; עקבו אחרי אירועי הדחייה שהניסיונות משאירים בלוגים; ותכננו את המעבר ל־passkeys עמידים לפישינג — שמוציאים את ה־prompt הניתן לאישור מהשולחן.

שלושה צעדים קונקרטיים נובעים מזה. בדקו בלוגי דחיית ה־push של ספק הזהויות את האירועים למעלה והגדירו התראה על burst. הפעילו number matching, את ה־number challenge של Okta, או Verified Duo Push, ואמתו את ההגדרות מול המהדורה שלכם. ושימו את מיגרציית ה־passkeys על ה־roadmap — כי שם המתקפה מפסיקה להיות אפשרית, ולא רק קשה יותר.