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

המאמר מתמקד בניצול כללי דואר בתשתית Office 365 ותרחישי תקיפה.

אחד הווקטורים הנפוצים לתקיפה הוא תשתיות דואר ועל אחת כמה וכמה תשתית הדואר של Office 365. תוקפים מנצלים את התשתית לביצוע פעולות תקיפה מסוג Business Email Compromise (המוכר כ BEC) במטרה לבסס התמדה או לאסוף מידע ממוקד. תוקף ינצל לרעה את תיבת הדואר על מנת ליצור כללים שונים בתיבת הדואר של המשתמש, כמו גם, תוקף לרוב יבצע פעולות שהן לקיחת בעלות על תיבת דואר, תנועה מתוך תיבת דואר ושלל פעולות דואר. סיווג ראשי ב MITRE הוא הטקטיקה T1114.003.

הבעיה של חדירה באמצעות תשתית הדואר מחמירה בכל תקופה שהיא, ואחוזי ההצלחה של תקיפות אלה נמצאות במגמת עלייה במרחב הטכנולוגי. לאחרונה פורסם דוח חקירה עם שיטה ישנה/חדשה שמנוצלת במרחב הדואר של תשתית Office 365. מדובר על ניצול מנגנון הצפנה של O365/RMS עם קבצים מסוג RPMSG (נועד לבצע הצפנה והגבלת הרשאות) והצורך באימות וקריאת קבצים לטובת קריאת ההודעה המוצפנת. בפועל, מתרחש אחרת, וישנו ניתוב מחדש עם בקשה לפתוח את הקובץ ומשם מתחילות פעולות תקיפה של איסוף מידע, משיכת טוקן ועוד.

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

בעיה ישנה‎ שממשיכה להתפוצץ בשטח

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

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

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

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

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

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

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

טיפ מהשטח: אחד הכלים שאני עובד איתם ביומיום הוא 365-Stealer. כלי שיכול לבצע פעולות רבות כולל יצירה והסתרת חוקים (בחלק של חוקים מצריך ביצוע התאמות והגדרות).  

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

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

כל הקסם בהפיכת הכלל למוסתר, הוא לרוקן את שני המאפיינים הבאים של “התוכן המשויך” של תיבת הדואר הנכנס:

• PR_RULE_MSG_NAME  – מחרוזת ANSI ריקה
• PR_RULE_MSG_PROVIDER  – מחרוזת ANSI ריקה

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

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

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

טיפ: הפקודות והערכים המובאים מתוך Get-InboxRule מציינת דגל בשם “IncludeHidden”. עם זאת, כאשר מנסים להבין ולהציג את הפרטים המלאים, ניתן לראות שהדגל שמור לשימוש פנימי של Microsoft. לכן לא ניתן להשתמש בזיהוי כללים שהוסתרו.

תרחישי תקיפה

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

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

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

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

מיפוי התנהגות

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

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

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

טיפ: ביצוע Threat Hunting בגישה פרואקטיבית יכול לסייע רבות במקרים כאלה. 

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

הטבלה הבאה מציגה את האפשרויות מול תשתית Exchange Online ומציינת את הממשקים שנדרגם ניתן לפעול, בין אפ מדובר על פעולה לגטימית או זדונית.

זיהוי ומיגור

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

הדרך הטובה ביותר להסיר כללי תיבת דואר מוסתרים היא באמצעות עורכי MAPI למינהם, כגון, MFCMapi. לחלופין, אפשר להפעיל את Outlook עם הפרמטר “/cleanrules” – פעולה ברוטלית שמסירה את כל הכללים בתיבת הדואר ולא רק את המוסתרים. שיטה זאת אינה ישימה ביומיום, אלא אם כן אנו בתקרית אבטחה שמאפשרת זאת, ולכן צריך לפעול ידנית עם כלי MFCMapi שעדיין עובד מול Exchange Online.

איפה PowerShell במקרים אלה? לא יעזור הרבה כי חוקים מוסתרים לא יגיעו לפלט של הממשק וזאת בגלל הנגשה של המערכת לפרמטרים אלה.

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

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