AiTM Phishing

פישינג AiTM הוא מתקפת פישינג שבה פרוקסי יושב בין המשתמש לבין שירות ההתחברות האמיתי ומעביר את הסשן בזמן אמת. הקורבן מתחבר ומשלים MFA בהצלחה. התוקף לוכד את ה-session cookie שספק הזהויות (IdP) מנפיק, ומנגן אותו מחדש כדי להיכנס לחשבון בתור אותו משתמש.

לפישינג מסוג adversary-in-the-middle יש מוניטין של מי שעוקף אימות רב-שלבי (MFA). המוניטין הזה מטעה, והטעות יקרה.

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

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

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

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

AiTM, MITM, ולמה השם חשוב

האותיות מייצגות adversary-in-the-middle, תחליף ניטרלי ל-"man-in-the-middle". שני השמות מתארים תוקף שממוקם בין שני צדדים שמאמינים שהם מדברים ישירות. כאן נגמר הדמיון, וההבדל חשוב יותר מהעדפת שם.

מתקפת MITM קלאסית עוסקת ב-network position. התוקף צריך להיכנס לנתיב: הרעלת name resolution בסגמנט מקומי, זיוף תשובות ARP, הפעלת נקודת גישה זדונית. לפישינג AiTM אין צורך באף אחד מאלה. הקורבן נכנס לרלאי מרצונו החופשי בלחיצה על קישור, והרלאי הוא שרת web באינטרנט הציבורי שהתוקף שוכר כמו כל שרת אחר.

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

העצה שלא שורדת את הנתונים

הוא גם שובר את העצה הנפוצה ביותר שניתנת לגבי פישינג AiTM, שהיא לבדוק את שורת הכתובת לדומיין עם שגיאת כתיב. המרכז הקנדי לסייבר בחן מעל 100 קמפיינים של AiTM שתקפו חשבונות Microsoft Entra ID בין 2023 לתחילת 2025, ומצא ש-LOTS-based AiTM phishing, כלומר פישינג שחי על אתרים מהימנים, היווה מעל מחצית מהקמפיינים שהוא הצליח לסווג. בקמפיינים האלה הקישור לאתר הפישינג יושב בתוך קובץ שמתארח ב-SharePoint, Dropbox או ספק דומה. אין שגיאת כתיב להבחין בה, כי הדומיין שהמשתמש מתבקש לסמוך עליו הוא דומיין שהוא כבר סומך עליו.

איך פישינג AiTM באמת עובד

המנגנון פשוט ורוב ההסברים מכסים אותו כראוי. התוקף מקים אתר שמעביר תעבורה לשירות ההתחברות האמיתי, המשתמש מאמת מול השירות האמיתי דרך הרלאי הזה, ובתיאור של ה-Cyber Centre הפעולה "מחזירה token מאומת ו-session cookie לאתר ה-AitM".

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

הסשן מוארך בכוונה תחילה. רשומת הקטלוג של MITRE ל-framework הקוד הפתוח המוכר ביותר במחלקה הזו, evilginx2, מתעדת שהוא "מזריק ארגומנטים מותאמים ב-POST כדי להפעיל בשקט אפשרויות 'Remember Me' במהלך האימות". האפקט המעשי הוא cookie עם תוחלת חיים ארוכה יותר וחלון replay רחב יותר ממה שהבחירות של המשתמש עצמו היו מייצרות.

reverse proxy אינו הצורה היחידה. זה המודל המנטלי שכמעט כל הסבר מלמד, והדיווח על אירועים של Microsoft עצמה סותר אותו. בתיאור קמפיין שייחסה ל-Storm-1167, Microsoft כתבה ש"בניגוד לקמפיינים שדיווחנו עליהם בעבר, המתקפה הזו לא השתמשה בשיטת ה-reverse proxy", אלא בשיטת indirect proxy. אם לוגיקת הזיהוי שלכם מניחה עותק מועבר של הדף האמיתי, ההנחה הזו כבר נכשלה פעם אחת בקמפיין מתועד.

מה שהסשן משמש לו בדרך כלל זה דוא"ל. בקורפוס של ה-Cyber Centre, business email compromise היווה 91% מהקמפיינים שנותחו. זו אינה השתלטות גנרית על חשבון; זה בעיקר נתיב לתיבת דואר.

ה-MFA שלכם לא שבור

המסגור שמופץ הופך את זה על הראש.

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

Microsoft ניסחה את זה בדיוק במונחים האלה כשתיעדה לראשונה את הטכניקה בקנה מידה ביולי 2022: "זו אינה פגיעות ב-MFA; מכיוון שפישינג AiTM גונב את ה-session cookie, התוקף מתאמת לסשן בשם המשתמש, ללא קשר לשיטת ההתחברות שהאחרון משתמש בה."

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

מה המספרים באמת אומרים

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

קמפיין 35,000 המשתמשים. במאי 2026 Microsoft פרסמה ניתוח של קמפיין שרץ מ-14 עד 16 באפריל 2026, שתואר כ"תקיפה ממוקדת של יותר מ-35,000 משתמשים ביותר מ-13,000 ארגונים ב-26 מדינות", עם 92% מהיעדים בארה"ב. כיסוי של אגרגטורים מציג את זה כ-35,000 משתמשים "שנפגעו", ובלפחות כותרת אחת כ-35,000 התחברויות ש"נחטפו". אלה טענות שונות. Microsoft פרסמה ספירת מיקוד. היא לא פרסמה כלל ספירת חדירות לקמפיין הזה, כך שמספר החשבונות שנלקחו בפועל אינו ברשומה הציבורית.

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

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

המגמה שרצה בכיוון ההפוך

המספר השלישי הוא המעניין.

על פני הקורפוס שלו, ה-Cyber Centre מדווח שחדירות full-session ירדו מכמעט 20% בסוף Q3 2023 לפחות מ-10% מכלל החדירות עד תחילת 2025. הבקרות עובדות, וחלק החדירות שמסתיימות כסשן תוקף מאומת במלואו ירד בערך בחצי.

שתי הסתייגויות שייכות לאותה נשימה. מערך הנתונים הזה מוטה לקנדה, ב-77% קנדה ו-18% ארה"ב, כך שזו אינה מדידה גלובלית. וזה חלק מהחדירות, לא שיעור הצלחה מול ניסיונות: הוא אומר איזה חלק מהאירועים שהתרחשו היו השתלטויות full-session, לא איזה חלק ממיילי הפישינג עבד. להמיר אחד לשני יהיה טעות.

בעיית המיפוי, ולמה הזיהויים שלכם היו שקטים

אם מיפיתם אירוע AiTM ל-T1557 Adversary-in-the-Middle, עשיתם את הדבר הסביר. MITRE ממפה את evilginx2 לטכניקה הזו בעצמה, בין ארבע עשרה הטכניקות ברשומת התוכנה שלה. המיפוי אינו שגוי.

הוא חלקי, ולפער יש השלכת זיהוי שקל לבדוק.

T1557 מתפרק לארבע sub-techniques: Name Resolution Poisoning and SMB Relay, ARP Cache Poisoning, DHCP Spoofing, ו-Evil Twin. כל אחת מהן דורשת network position מקומי. אסטרטגיית הזיהוי שלה DET0296 נובעת מכך. האנליטיקות שמתחתיה, AN0823 עד AN0826, מחפשות הרעלת DNS ו-ARP, עריכות לא מורשות ל-/etc/hosts ו-/etc/resolv.conf, שידורי ARP חשודים, שינויי אמון בתעודות והזרקת מסלולים. המיטיגציות הרשומות שלה הן סגמנטציית רשת, מניעת חדירות רשת וסינון תעבורה.

אף אחד מאלה לא צופה בשרת web באינטרנט הציבורי שמשתמש בחר לבקר בו.

לשתי הטכניקות האחרות יש אותה בעיה

T1539 Steal Web Session Cookie הוא הבית הקונספטואלי הנכון, והתיאור שלו מציין במפורש frameworks ש"אוספים session cookies דרך פרוקסי זדוני". אבל אסטרטגיית הזיהוי שלה, DET0509, מכוונת לארטיפקטים של קבצים, זיכרון ורשת, וארבע מתוך חמש האנליטיקות שלה מתארות גניבה ב-endpoint: קריאת מסד הנתונים SQLite של Cookies ב-Chrome, גישה לזיכרון הדפדפן דרך /proc/[pid]/mem או ptrace, קריאות task_for_pid ב-macOS, מאקרו שקוראים נתיבי קבצי דפדפן. במתקפת AiTM אף אחד מאלה לא קורה. ה-cookie אף פעם לא נקרא מהדיסק של הקורבן, כי ספק הזהויות מנפיק אותו דרך הפרוקסי. רק האנליטיקה החמישית, AN1406, מתאימה, והיא מתארת את ה-replay ולא את הגניבה.

T1111 Multi-Factor Authentication Interception רחוק עוד יותר. האנליטיקות שלו, AN0687 עד AN0689, מתארות keyloggers, גישה ל-/dev/input ו-proxying של smart card.

הטכניקה שבאמת מתאימה

הטכניקה שהאנליטיקות שלה כן מתאימות היא T1550.004 Web Session Cookie. אסטרטגיית הזיהוי שלה DET0074 נושאת שלוש אנליטיקות שמתארות את המתקפה הזו במדויק: AN0201, גישה חריגה ליישומי ענן באמצעות session tokens בלי אימות MFA; AN0202, שימוש חוזר ב-session cookie בדפדפנים או מכשירים לא מנוהלים שחורגים מ-baseline של המשתמש; ו-AN0203, web session tokens שמשמשים מחדש באפליקציות Office native בלי token refresh משויך.

הטקטיקה שלה היא Lateral Movement (תנועה רוחבית). הזיהוי שמתאים למתקפת פישינג מתויק במקום שרוב הצוותים לעולם לא יחשבו לצוד בו.

אותו עמוד מתעד לצד מי זה מציב אתכם. MITRE מציינת את Star Blizzard, קבוצת הריגול הרוסית שמנוטרת גם כ-SEABORGIUM, Callisto ו-COLDRIVER, כמי ש"השתמשה ב-EvilGinx כדי לגנוב session cookies ולעקוף MFA" נגד יעדים אקדמיים, ביטחוניים, ממשלתיים ו-NGO במדינות נאט"ו.

למה אבטחת הדוא"ל שלכם העבירה את הקישור

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

רשומת MITRE ל-evilginx2 מפרטת את ההתנהגויות שמייצרות את התוצאה הזו. כל אחת אומרת למגן מה שווה באמת פסיקה נקייה של סורק.

• בקשות מסוננות לפי user agent. ה-framework "דוחה בקשות אם ה-User-Agent לא תואם ל-filter REGEX ברשימת ההיתרים" (T1480). סורק שלא נראה כמו הקורבן המיועד פשוט עלול לא לקבל את תוכן הפישינג.
• הפיתיון מוגבל בזמן. הוא "מסתיר פיתיוני פישינג לפרק זמן מוגדר כדי להימנע מסריקת sandbox" (T1497.003). קישור שהוא אינרטי כשמפוצצים אותו יכול להיות חי כשהמשתמש לוחץ עליו.
• הקישור עצמו מתנגד להתאמה סטטית. פרמטרים נוצרים באקראי ומקודדים ב-Base64 "כדי לנצח זיהוי סטטי" (T1132).
• התעודה תקפה. ה-framework משיג תעודת TLS אמיתית מרשות תעודות חינמית דרך ACME (T1553.004). המנעול אמיתי, ותמיד היה: הוא מאשר את החיבור, אף פעם לא את הכוונה.

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

מה באמת לעשות, ואיפה זה נעצר

ה-Cyber Centre מנסח את התיקון במשפט אחד: גם phishing-resistant MFA וגם מדיניות conditional access למכשירים רשומים "שוברים את זרימת האימות כשיש ערכת פישינג AitM באמצע החיבור". הנחיית CISA מדרגת שיטות FIDO/WebAuthn ושיטות מבוססות PKI בראש היררכיית החוזק שלה מאותה סיבה. הרלאי לא יכול להשלים אימות שקשור קריפטוגרפית ל-origin האמיתי.

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

ארבעת המקומות שבהם זה נעצר

ה-fallback הוא החור. ההוראה הבאה של ה-Cyber Centre עצמו היא "להסיר כל שיטות גיבוי שאינן phishing-resistant בחשבונות האלה". לפרוס security key תוך השארת SMS מופעל משאיר את הנתיב החלש זמין.

ולנתיב הזה יש מסלול מתועד אליו. החוקר יניב מירון (Yaniv Miron) מ-Proofpoint חשף טכניקת downgrade באוגוסט 2025 שבה תוקף מזייף user agent שמימוש ה-FIDO של Entra ID לא מזהה, מייצר שגיאה שמזמינה את המשתמש לבחור שיטה אחרת, ומנחיתה אותו על אפליקציית ה-authenticator, קוד SMS או OTP. Proofpoint דיווחה שלא נצפו מקרים של הטכניקה בשטח בזמן הגילוי, ועמדת Microsoft היא שזו אינה פגיעות במוצר אלא מתקפת פישינג, שנענית באכיפת שיטות phishing-resistant דרך authentication strength ב-Conditional Access.

תיקון אחד רץ בכיוון ההפוך. הסיפור המצוטט ביותר על "passkeys הובסו", קמפיין PoisonSeed מיולי 2025, הוערך בהמשך כלא bypass של FIDO בכלל: גורם הסיסמה עבר, האתגרים המאוחרים נכשלו, ובדיקת הקרבה בזרימת cross-device החזיקה.

Token binding עדיין לא מכסה את הדפדפן. Token Protection של Microsoft הוא בקרת סשן ב-Conditional Access שמקבלת רק sign-in session tokens קשורים למכשיר, כך ש-token גנוב "לא יכול לשמש ממכשיר אחר". זו התשובה הישירה ביותר ל-replay שקיימת. הכיסוי הוא הבעיה. תמיכה באפליקציות native זמינה באופן כללי ב-Windows וב-preview ב-macOS ו-iOS. תמיכה מבוססת דפדפן היא preview בלבד, ומוגבלת ליישומי web נבחרים שניגשים ל-Azure Resource Manager. פישינג AiTM הוא מתקפת דפדפן. ההנחיה של Microsoft עצמה היא לפרוס את המדיניות במצב report-only קודם ולנתח גם לוגי התחברות אינטראקטיביים וגם לא-אינטראקטיביים לפני אכיפה.

לביטול יש מגבלה קשה. Microsoft Entra ID "לא יכול לבטל ישירות session token שהונפק על ידי אפליקציה"; האפליקציה צריכה לבטל גישה תחת המדיניות שלה עצמה. Continuous Access Evaluation מצמצם את זה לשירותים שתומכים בו, מבטל tokens כמעט בזמן אמת באירועים כמו השבתת חשבון ושינויי סיסמה, אבל זה דורש תמיכה גם ב-client וגם ב-resource.

מה העמוד הזה לא יודע

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

MITRE מפרסמת אנליטיקות זיהוי, לא את שיעורי התפיסה שלהן או פרופילי false-positive. AN0201 עד AN0203 מתארות את האותות הנכונים; כמה הן רועשות זה משהו שרק הסביבה שלכם יכולה להגיד לכם.

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

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

שאלות נפוצות

האם פישינג AiTM אומר ש-MFA חסר תועלת? לא. אתגר ה-MFA מצליח; לא עוקפים אותו. מה שנגנב הוא הסשן שמונפק אחרי שהוא מצליח. הניסוח של Microsoft עצמה הוא שזו "אינה פגיעות ב-MFA". נתיב השדרוג הוא לשיטות phishing-resistant, לא הרחק מ-MFA.

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

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

מה כדאי לצוד קודם? שימוש חוזר בסשן: סשן מאומת שמופיע ממכשיר או דפדפן לא מנוהל שלא תואם את ה-baseline של המשתמש, וגישה ליישום ענן באמצעות session token בלי אימות MFA תואם.

מאיפה להתחיל

שלוש בדיקות, לפי הסדר, שאף אחת מהן לא דורשת רכישה.

קראו את האנליטיקות שמתאימות. פתחו את T1550.004 וקראו את AN0201, AN0202 ו-AN0203. אם תוכן הזיהוי שלכם נבנה מ-T1557, זה הפער.

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

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

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