AiTM Phishing

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

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

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

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

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

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

המונחים AiTM ו-MITM, ולמה השם חשוב

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

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

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

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

ההבדל הזה גם שובר את העצה הנפוצה ביותר על פישינג AiTM: לבדוק את שורת הכתובת ולחפש דומיין עם שגיאת כתיב. המרכז הקנדי לאבטחת סייבר (Canadian Centre for Cyber Security) חקר למעלה מ-100 קמפייני AiTM שכוונו אל חשבונות Microsoft Entra ID בין 2023 לתחילת 2025, ומצא שפישינג AiTM מבוסס LOTS, כלומר פישינג שחי על אתרים מהימנים, היווה למעלה ממחצית מהקמפיינים שהמרכז הצליח לסווג. בקמפיינים האלה, הקישור לאתר הפישינג נמצא בתוך קובץ שמתארח ב-SharePoint, ב-Dropbox או בספק דומה. אין כאן שגיאת כתיב לשים לב אליה, כי הדומיין שהמשתמש מתבקש לסמוך עליו הוא הדומיין שהוא כבר סומך עליו.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שום דבר מכל זה לא רואה שרת web באינטרנט הציבורי שמשתמש בחר לבקר בו.

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

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

הטכניקה T1111 Multi-Factor Authentication Interception רחוקה עוד יותר. כללי הזיהוי שלה, AN0687 עד AN0689, מתארים תוכנות שמתעדות הקשות מקלדת, גישה ל-/dev/input ופרוקסי לכרטיסים חכמים.

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

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

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

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

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

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

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

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

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

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

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

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

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

שיטת הגיבוי היא החור. ההוראה הבאה שנותן ה-Cyber Centre עצמו היא "להסיר את כל שיטות הגיבוי שאינן עמידות בפני פישינג בחשבונות האלה". פריסת מפתח אבטחה תוך השארת SMS פעיל משאירה את הנתיב החלש פנוי.

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

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

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

לביטול (revocation) יש מגבלה מוחלטת. Microsoft Entra ID "לא יכולה לבטל ישירות טוקן סשן שהונפק על ידי אפליקציה". האפליקציה עצמה צריכה לבטל את הגישה לפי המדיניות שלה. Continuous Access Evaluation מצמצם את המגבלה הזו בשירותים שתומכים בו, ומבטל טוקנים כמעט בזמן אמת באירועים כמו השבתת חשבון או שינוי סיסמה, אבל היכולת הזו דורשת תמיכה גם בצד הלקוח וגם בצד המשאב.

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

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

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

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

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

שאלות נפוצות

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

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

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

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

מאיפה להתחיל

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

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

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

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

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