פישינג ב-Microsoft 365: שדה שולח ריק עוקף את חסימת ה-Direct Send
חוקרי ReliaQuest הראו ב-3 בספטמבר שמיילים מזויפים בשם עובדי החברה עוברים את ההגדרה RejectDirectSend של Exchange Online אם שדה השולח הטכני נשאר ריק. כך סוגרים את הפרצה.
TL;DR בקצרה
- Direct Send מאפשר למדפסות, סורקים ומערכות לשלוח מייל בתוך הארגון בלי הזדהות, ותוקפים מנצלים אותו כדי להתחזות לעובדים.
- RejectDirectSend בודק רק את הדומיין בשולח הטכני של המעטפה, ושולח ריק משאיר לו מה לבדוק.
- ReliaQuest תיעדה מקרים כאלה מספטמבר 2025 עד אוגוסט 2026, בעיקר נגד מנהלים, כספים ורכש.
- ההגנה שעבדה בבדיקה: מחבר נכנס שמתיר Direct Send רק מכתובות IP מאושרות, וניקוי חריגות סינון.
מייל שנראה כאילו הגיע מהתמיכה הטכנית שלכם מבקש מכם לפתוח מסמך משותף או לאשר תשלום. הוא עוקף את חסימת Direct Send, ההגנה שהארגון הפעיל בדיוק נגד זה.
חוקרי חברת האבטחה ReliaQuest פרסמו ב-3 בספטמבר ממצא על ההגדרה RejectDirectSend ב-Exchange Online. לפי הממצא, היא לא חוסמת מיילים מזויפים כששדה השולח הטכני שלהם ריק. לדבריהם זו לא חולשה בתוכנה של Microsoft, אלא מגבלה בהיקף של מנגנון ההגנה.
איך שדה ריק אחד עוקף את ההגנה על Direct Send
כדי להבין את הבעיה צריך להכיר שני מונחים. Direct Send הוא מנגנון ב-Microsoft 365 שמאפשר למכשירים ולמערכות לשלוח מיילים בלי להזדהות. אלה למשל מדפסות, סורקים ומערכות התראה, והנמענים הם משתמשים באותו ארגון.
תוקפים גילו מזמן שאפשר לנצל אותו כדי לשלוח מבחוץ מיילים שנראים פנימיים. RejectDirectSend היא הגדרה ש-Microsoft הוסיפה כדי לחסום מיילים כאלה כשהם מתחזים לדומיין של הארגון. הבעיה היא שההגדרה בודקת את הדומיין בשולח של מעטפת ה-SMTP. זו הכתובת הטכנית שהשרתים רואים, ולא שדה ״מאת״ שהנמען רואה.
לפי ReliaQuest, כשהתוקף משאיר את השולח הטכני ריק, אין דומיין להשוות, והמייל מתקבל. בניסיון שערכו החוקרים בסביבה שלהם, ההגדרה דחתה מייל עם הדומיין של הארגון בשולח הטכני. אבל היא קיבלה את אותו מייל כשהשולח הטכני ריק. בשדה ״מאת״ עדיין הופיעה כתובת פנימית של התמיכה הטכנית.
בבדיקה הזו המייל הגיע לתיקיית דואר הזבל. הוא לא קיבל תוצאת SPF ו-DKIM, נכשל ב-DMARC וקיבל את ציון הספאם הגבוה ביותר. החוקרים מדגישים שזה לא אומר שההגנה עבדה. הסינון נבע מגורמים אחרים, ומייל שנבנה אחרת יכול להגיע לתיבה הראשית.
מה ראו בתקיפות אמיתיות של Direct Send
ReliaQuest בדקה מקרי פישינג אמיתיים מספטמבר 2025 עד אוגוסט 2026 בכמה ארגונים. רוב המיילים הגיעו לתיבות הדואר בגלל חריגות סינון ונתיבי דואר פנימיים שהוגדרו כאמינים. במקרה אחד, מייל שנכשל בכל בדיקות האימות וסווג כפישינג בוודאות גבוהה הגיע בכל זאת לתיבה. הסיבה: כתובת המנהל שהתוקפים התחזו אליה הופיעה ברשימת השולחים המותרים.
הפיתיונות היו מוכרים. אלה הודעות על שיתוף קבצים, בקשות תשלום והעברה, הזמנות להגיש הצעות מחיר והזמנות לפגישות. בכמה מקרים התוקפים צירפו קובצי SVG שהתחזו להודעות קוליות.
היעדים העיקריים היו מנהלים בכירים, אנשי כספים, רכש ותפקידים מול לקוחות. כלומר, אלה שמאשרים חשבוניות ותשלומים. זה בדיוק הפרופיל של הונאות ״מייל מהמנכ״ל״, שגורמות לעסקים להעביר כסף לחשבונות של תוקפים.
ReliaQuest מסרה שעדכנה את Microsoft בכמה פניות, ולא פירטה תגובה. החוקרים מעריכים ברמת ביטחון גבוהה שתוקפים ימשיכו להשתמש בשיטה ב-6 עד 12 החודשים שאחרי הפרסום. לפי ההערכה, הם יעברו לתשתיות שליחה שמעוררות פחות חשד.
מה זה אומר עבורכם
- השאירו את RejectDirectSend פעיל, אבל אל תסמכו רק עליו. מי שעוד לא הפעיל אותו יכול לעשות זאת ב-PowerShell של Exchange Online. הפקודה:
Set-OrganizationConfig -RejectDirectSend $true. - הגבילו את Direct Send לכתובות IP: מפו אילו מדפסות, סורקים ומערכות באמת שולחים בלי הזדהות. הגדירו מחבר נכנס (inbound connector) שמתיר זאת רק מכתובות ה-IP הציבוריות שלהן. בבדיקה של ReliaQuest מחבר כזה חסם כל ניסיון, גם כשהשולח הטכני ריק.
- נקו חריגות סינון: עברו על רשימות השולחים והדומיינים המותרים ועל Tenant Allow/Block List. בדקו גם את כללי זרימת הדואר שמורידים את ציון הספאם ואת רשימות ה-Safe Senders. הסירו במיוחד כתובות של מנהלים בכירים.
- הגדירו התראות: חפשו מיילים שבהם השולח הטכני ריק ושדה ״מאת״ בדומיין של הארגון. התריעו על מיילים שנכשלו ב-SPF, DKIM או DMARC ובכל זאת נמסרו בזכות חריגה.
- הדריכו את הכספים: כל בקשה לא צפויה לתשלום, לשינוי פרטי חשבון או לפתיחת מסמך. מאמתים אותה בטלפון או בערוץ מוכר, גם כשהיא נראית כאילו הגיעה מבפנים.
מקורות והרחבה
- Threat Spotlight: One Blank Field Bypasses Direct Send ControlReliaQuest
- Microsoft 365 Phishing Technique Uses Empty Envelope Sender to Evade Direct Send BlockingCyber Security News
הכתבה נכתבה במקור בעברית על ידי מערכת GEEKLIK, על בסיס המקורות שלמעלה ובדיקת העובדות מולם.
מצאתם טעות? דווחו לנו
