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

ביולי 2026 התגלו במקביל שתי תגליות שהראו עלייה חדה במתקפות פישינג מתוחכמות נגד Microsoft 365, העוקפות אימות דו-שלבי (MFA) בשתי שיטות שונות מיסודן: מתקפות פרוקסי מסוג adversary-in-the-middle (AiTM) וניצול לרעה של מנגנון אימות קוד מכשיר (device code authentication). התגלית הראשונה נבעה מטעות של תוקף אחד – שרת Python לא מאובטח שחשף שלושה קמפיינים פעילים. התגלית השנייה הגיעה מחוקרים שעקבו אחר פלטפורמת פישינג מסחרית חדשה בשם Forg365. הבנת אופן הפעולה של כל התקפה היא הצעד הראשון לפריסת ההגנות הנכונות, משום שהפתרון לאחד לא עוצר את השני.

השרת הלא מאובטח שחשף שלוש מבצעי Evilginx

ב-13 ביולי 2026, חוקרים בחברת האבטחה הצרפתית Lexfo חשפו שלוש מתקפות פישינג מבוססות Evilginx שפעלו בזמן אמת נגד Microsoft 365, לאחר שתוקף השאיר שרת Python חשוף על פורט ציבורי עם רישום תיקיות פעיל (directory listing). הפקודה python3 -m http.server 8080 נותרה גלויה בהיסטוריית ה-.bash_history של השרת . מתוך התיקייה הפתוחה, Lexfo אספה את ערכת הכלים המלאה של המפעיל, יומני פעילות, מידע על קורבנות שנלכדו, והצליחה לאתר שני מפעילי פישינג נוספים שניהלו קמפיינים נפרדים .

שלושת הקמפיינים היו מתקפות AiTM מבוססות Evilginx שהשתמשו בפרוקסי שקוף כדי להעביר את דפי ההתחברות של Microsoft 365 ולגנוב אסימוני הפעלה (session tokens) לאחר שהמשתמש השלים את אימות ה-MFA . אחד משלושת הקמפיינים תיעד 218 חשבונות שנלכדו מ-12 מדינות, כאשר 94% מהם היו תיבות דואר ארגוניות . הקמפיינים השתמשו בשני נתיבי תקיפה נפרדים: גניבת אסימוני הפעלה של Evilginx (דרך פרוקסי AiTM) ופישינג קוד מכשיר – ערכה אחת שלחה קורבנות לדף ההתחברות האמיתי של מיקרוסופט, שם הם אישרו גישה בעצמם, והמערכת האחורית של התוקף חיפשה את האסימון .

Forg365: פלטפורמת פישינג-כשירות מסחרית

בנפרד, פלטפורמת Forg365 (PhaaS) זוהתה על ידי חוקרי ZeroBEC (שדווח ב-9–13 ביולי 2026) כערכה מסחרית המופצת דרך טלגרם, שעולה 400 דולר לחודש (או 3,800 דולר לשנה). בניגוד לגרסאות ה-Evilginx המותאמות אישית שנמצאו בשרת החשוף, Forg365 מקבצת מספר שיטות התקפה וכלים ללוח בקרה אחד .

Forg365 משלבת שלוש יכולות ליבה:

• פרוקסי AiTM – פרוקסי הפוך שקוף הלוכד אסימוני הפעלה לאחר שהמשתמש משלים אימות MFA
• פישינג קוד מכשיר – מנצלת את זרימת ה-OAuth הלגיטימית של מיקרוסופט, כלומר המשתמש משלים את האימות בדף מיקרוסופט האמיתי מבלי שהתוקף רואה אי פעם את הסיסמה שלו
• יצירת פיתיונות בסיוע AI – משתמשת בינה מלאכותית ליצירת מיילים פישינג ודפי נחיתה משכנעים, המתחזים ל-SharePoint, OneDrive, DocuSign ו-Adobe Acrobat Sign

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

מתקפה אחת גונבת אסימונים אחרי MFA; השנייה מנצלת פרוטוקול לגיטימי

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

• מתקפות פרוקסי AiTM (בסגנון Evilginx): התוקף מקים דף התחברות מזויף שמתעל תעבורה לדף ההתחברות האמיתי של מיקרוסופט. המשתמש מזין את הסיסמה ומשלים את אימות ה-MFA בפרוקסי של התוקף. לאחר אימות מוצלח, מיקרוסופט מנפיקה עוגיית הפעלה לדפדפן של המשתמש הלגיטימי – אבל העוגייה הזו נוחתת למעשה בפרוקסי של התוקף, לא בדפדפן של המשתמש. התוקף יכול לשחזר את העוגייה הזו כדי לגשת לחשבון Microsoft 365 של הקורבן .

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

ההגנות המומלצות: אילו בקרות עוצרות כל התקפה

הגנות נגד מתקפות פרוקסי AiTM (בסגנון Evilginx)

ההגנה היעילה ביותר נגד מתקפות AiTM היא MFA עמיד בפני פישינג, במיוחד FIDO2/WebAuthn ומפתחות גישה (passkeys). אלה קושרים את פרטי האימות לשם הדומיין הלגיטימי, כך שכאשר הדפדפן של המשתמש מתחבר לאתר הפרוקסי של התוקף (בעל דומיין שונה), פרוטוקול האימות מזהה את אי-ההתאמה וחוסם אוטומטית את החלפת פרטי האימות .

הגנות נוספות כוללות:

• מדיניות Conditional Access (Entra ID): דרישת התאמה של מכשיר ומיקום מהימן כדי למנוע הנפקת אסימונים מפרוקסי לא מהימנים
• Continuous Access Evaluation (CAE): מאפשרת ביטול אסימון כמעט בזמן אמת כאשר מתגלים תנאים מסוכנים
• ניטור שימוש חריג באסימונים: חיפוש אסימונים בשימוש מכתובת IP או מדינה שונה מזו שבה הונפקו, נסיעות בלתי אפשריות ומאפייני כניסה לא מוכרים
• חסימת דומיינים חדשים שנרשמו לפישינג: ניטור דומיינים שנרשמו ב-30 הימים האחרונים ונפתרים לטווחי IP ידועים של תשתיות פישינג

הגנות נגד ניצול לרעה של אימות קוד מכשיר

פישינג קוד מכשיר אינו דורש מהתוקף להערים על המשתמש להזין פרטים בדף מזויף – המשתמש מתקשר עם דף ההתחברות האמיתי של מיקרוסופט. משמעות הדבר היא ש-FIDO2/Passkeys לבדם אינם מגנים לחלוטין מפני התקפה זו, מכיוון שנעשה שימוש בזרימת OAuth לגיטימית .

ההגנה העיקרית היא לחסום את הרשאת קוד המכשיר עבור משתמשים שאינם זקוקים לה, באמצעות Microsoft Entra ID Conditional Access:

• צרו מדיניות באמצעות התנאי "Authentication Flows" לחסימת זרימת קוד מכשיר עבור כל המשתמשים, למעט קבוצת חריגים מתועדת
• לפני החסימה, הריצו במצב "report-only" או בדקו יומני כניסה היסטוריים כדי לזהות שימוש לגיטימי בקוד מכשיר (למשל, טלוויזיות חכמות, מכשירי חדרי ישיבות)
• תכננו חריגה עבור Device Registration Service (DRS), מכיוון שחסימת זרימת קוד מכשיר עלולה להפריע ל-Autopilot ולרישום מכשירי Windows

הגנות נוספות:

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

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

ההודעה הציבורית של ה-FBI ממאי 2026 על פלטפורמת Kali365 PhaaS המליצה במיוחד על חסימת זרימת קוד מכשיר כהגנה העיקרית . ככל שפלטפורמות פישינג כמו Forg365 ממשיכות להפוך טכניקות התקפה אלו לזמינות מסחרית, הדחיפות התפעולית עבור מגינים ברורה: פרוסו FIDO2/Passkeys עבור כל החשבונות המורשים כדי לעצור מתקפות AiTM, והשתמשו ב-Conditional Access כדי להשבית את הרשאת קוד המכשיר עבור משתמשים שאינם זקוקים לה. תיקייה אחת לא מאובטחת אולי חשפה שלושה קמפיינים – אבל הלקחים תקפים לכל דייר Microsoft 365.