העברת מיילים אוטומטית שלא אתם הגדרתם: איך מזהים תיבת דואר עסקית שנפרצה

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

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

למה תוקפים מגדירים העברת מיילים אוטומטית

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

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

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

ההגדרה שרוב העסקים בטוחים שסגורה — ולא בדקו

ב-Microsoft 365 קיימת הגדרה שקובעת אם מותר להעביר דואר אוטומטית לכתובת חיצונית. היא יושבת במדיניות סינון הדואר היוצא (Outbound spam filter policy), ויש לה שלושה מצבים. לפי התיעוד הרשמי של מיקרוסופט:

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

מה מיקרוסופט מתריעה עליו, ומה היא מפספסת

יש שתי מדיניות התראה מובנות שרלוונטיות כאן, ושתיהן זמינות ברישיונות E1, E3 ו-E5 — כלומר גם לעסקים קטנים. לפי תיעוד מדיניות ההתראות:

• Creation of forwarding/redirect rule — מתריעה כשמישהו יוצר כלל העברה. רמת החומרה: Informational.
• Suspicious email forwarding activity — מתריעה כשדואר מועבר אוטומטית לחשבון חיצוני חשוד. רמת החומרה: High.

וכאן הפרט שחשוב להכיר: לפי אותו תיעוד, ההתראה הראשונה עוקבת רק אחרי כללים שנוצרו ב-Outlook באינטרנט או דרך Exchange Online PowerShell. כלל שנוצר מתוך אפליקציית Outlook המותקנת במחשב לא נכלל שם. אם ההנחה שלכם היא „אם משהו כזה יקרה נקבל התראה”, ההנחה הזאת נכונה חלקית בלבד — וזו בדיוק הסיבה שניטור Microsoft 365 רציף עדיף על הסתמכות על התראות ברירת המחדל.

בדיקה שלוקחת עשר דקות

1. בדקו מה הערך של הגדרת ההעברה החיצונית אצלכם. אם הוא Automatic, קבעו אותו במפורש ל-Off אלא אם יש תהליך עסקי שדורש אחרת.
2. הריצו סריקה של כללי תיבת דואר בכל התיבות. חפשו כללים שמעבירים החוצה, וכללים שמעבירים הודעות לפריטים שנמחקו או ל-RSS Feeds — תיקייה שכמעט אף אחד לא פותח, ולכן פופולרית מאוד אצל תוקפים.
3. שימו לב לכללים בעלי שם ריק, שם באות בודדת או נקודה. משתמש אמיתי נותן שם לכלל שהוא יוצר.
4. הגדירו במפורש את שתי מדיניות ההתראה שלמעלה ובדקו לאן ההתראות נשלחות בפועל. התראה שנוחתת בתיבה שאיש לא קורא שווה לאפס.
5. אם מצאתם כלל חשוד — מחיקת הכלל לבדה לא מספיקה. צריך לאפס סיסמה, לבטל את כל אסימוני ההתחברות הפעילים, ולעבור על הדואר היוצא כדי לראות מה כבר נשלח בשם העסק.

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

שאלות שחוזרות

יש לנו אימות דו-שלבי. עדיין רלוונטי?

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

איך אני יודע שהכלל לא נוצר על ידי העובד עצמו?

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

לחסום העברה חיצונית לכל הארגון זה לא יישבור תהליכים?

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

כמה זמן תוקף יושב בתיבה לפני שהוא פועל?

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

מה עושים עכשיו

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