תחקור הודעת דואר

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

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

מאמר נוסף בסדרה – ביצוע פרונזיקה ותחקור הודעה בתיבת דואר.

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

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

מבנה Internet Message Headers

למבנה פריט הדואר שמתקבל בדואר ישנם מושגים שונים: Message Header, Email Header, Internet Message Header, SMTP Header ונוספים. המושג המקורי הוא Internet Message Headers.

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

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

כל המידע לגבי תצורת הודעת הדואר, מאפיינים בהודעה, צורת קידוד, פורמט וכן הלאה זמינים בקישור הבא המבוסס על RFC 2076 – Common Internet Message Headers

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

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

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

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

ארכיטקטורה וניתוב הדואר

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

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

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

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

1. משתמש עם Client כשלהוא אשר שולח את ההודעה
2. שרת דואר שממנו מוציאים את ההודעה
3. רכיב Email Gateway שמוציא את הדואר ליעד (אינו מתואר בתרשים)
4. רכיב סינון דואר אשר מקבל את הדואר למשל Ironscales
5. רכיב דואר מסוג Exchange Online אשר מקבל את הודעת הדואר
6. משתמש נמען אשר מקבל את הודעת הדואר

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

כאשר הודעה נשלח מתוך משתמש קצה אשר שולח את ההודעה באמצעות אפליקציה מסוימת, כאשר אפליקציה יכולה להיות Outlook, OWA או מכשיר חכם (באמצעות ActiveSync).

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

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

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

אם נקח לדוגמה ניתוח הודעה באמצעות Message Analyzer )נדון בכלים מאוחר יותר), יהיה ניתן לראות חלוקה של מספר קטגוריות, כאשר ההקטוגריות החשובות לנו בשלב הארכיטקטורה וניתוב הודעת הדואר הוא:

• Summary
• Received Headers

בחלק של Summary נוכל לראות מידע כללי אודות הודעת הדואר עם ערכים כללים, בחלק השני של Received Headers נוכל לראות מידע מעניין מעט יותר והוא ניתוב הדואר והרכיבים שבהם ההודעה עברה החל מרגע שליחת הדואר ועד להדעה אל שרת הדואר של הנמען.

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

בדוגמה שלפנינו מודבר על תהליך של התראה מתוך שירות של Office 365 לנמען ולכן התהליך הוא יחסית קצר ללא המון HOP.

הערה: מה הסיבה שהוזכר דווקא רכיב MTA ולא SMTP עצמו? המנגנון שמבצע את את העברת הדואר בתוך הרכיב הכללי של SMTP הוא MTA או Mail Transfer Agent. רכיב MTA עובד עם רכיבים נוספים כדוגמת: Hub Selector, Queue Submission, Queue Deliver, Mailbox Delivery Agent ורכיבי סף נוספים.

מאפיינים במבנה הודעת הדואר

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

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

• מאפיין From – מאפיין המתאר את שולח ההודעה
• מאפיין To – מציג את הנמען שאליו נשלחה ההודעה, לא בכל מצב מציג את הנמען
• מאפיין Return-Path – מציג את כתובת הדואר שאליה משיבים את ההודעה, שווה ערך למאפיין Reply-To
• מאפיין Sender – מציג את שולח ההודעה, בדומה למאפיין From
• מאפיין Received – מציג באיזה שרתים ורכיבי דואר עברה ההודעה
• מאפיין X-Originating-IP – מציג את כתובת IP שממנה נשלחה הודעת הדואר
• מאפיין X-Mailer – מציג את האפליקצתיה שממנה נשלחה ההודעה (בשיוך אל Originating), לעיתים יכול להופיע במאפיין User-Agent
• מאפיין Loop – נחלק מספר מאפייני Loop, מצבים הם ישנו Forward או חוקים מסוימים הגורמים למצב Loop.
• מאפיין Autoforwarded – בודמה למאפיין Loop נמצא במצבים של העברת דואר או Loop.
• מאפיין Subject – חלק מתוכן ההודעה אשר נכתב ע"י המשתמש
• מאפיינים מבוססי תקנים – ישנם מאפיינים מבוססי תקנים כדוגמת SPF, DKIM וכן הלאה המציגים את מצב התנקים של השולח והאם עברו את תהליך הבדיקה התקין מול שרתי הנמען

ישנם המון מאפיינים מבוססים Header שעמם ניתן להיעזר בעת תחקור הודעת הדואר, לרשימה המלאה אשר מכילה מאות מאפיינים מבוססים Header בקישור הבא Reference to Internet Message Headers.

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

כלומר ישנו הבדל בין דואר שנשלח ממערכת ששולחת התראות לבין הודעת דואר שנשלחת בין נמענים.

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

קטגוריות של אותם מאפיינים חשובים בשלב זה הם:

• Forefront Antispam Report Header
• Microsoft Antispam Header
• Other Headers – החשוב שבהם

מאפיינים ספציפיים ומציאת ראיות

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

בשלב ראשון נחפש את המאפיינים הבאים הנדרשים למציאת ראיות:

• ארכיקטרוה וניתוב הודעת הדואר
• From – שולח ההודעה
• To – הנמען אשליו נשלחה ההודעה
• Return-Path – כתובת הדואר שאליה נשיב (במקרי פישינג עלול להיות שונה)
• Received-SPF – באיזה תקני דואר נעשתה בדיקה במהלך העברת הדואר
• X-Mailer – באיזה אפליקציה נעשה שימוש בעת שליחת ההודעה
• מאפיין X-Authenticated-IP – מציג כתובת IP של שרת השולח

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

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

בשלב שני נוכל לגשת למאפיינים נוספים המכילים מאפיינים המציגים:

• קבצים מצורפים Has-Attach
• שרתי דואר אשר מהם נשלחה ההודעה
• אופן ביצוע שליחת הדואר
• מאפייני Abuse
• מאפיין על סמך חוקים והעברה Rules-Loop

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

המציאות ומקרים מהשטח

אפשר לקחת מקרים רבים אשר מתרחשים מידי יום (כן מידי יום) והם מקרים כדוגמת:

• פישינג ממוקד ומושקע
• פעולות של Account Takeover
• מייל עם כתובת מבוססת HTML קוד אשר עוקף את מנגנוני ההגנה
• הודעת דואר עם קובץ נגוע שירד למכונה המקומית

מקרים אלה נוספים חייבים בתחקור ולכן נקח מקרה של ביצוע Account Takover

תרחיש של ATO

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

התרחיש הוא שליחת הודעת אשר יורטה בידי צד שלישי ולאחר תחקור מעמיק נמצאו מספר ראיות שהציגו תמונה מדאיגה של Account Takeover.

מאפייני Message Header באירוע

במקרה נבדקו המאפיינים הבאים:

• ארכיטקטורה וניתוב הדואר בקטגוריה של Summary ושל Received Header
• מאפייני Header מתוך Other Headers של :
  • From
  • To
  • Return-Path
  • X-mailer
  • Sender
  • X-Source-Sender
  • User Agent
  • Recieved-SPF
  • DKIM-Signature
  • Forward
  • Loop
  • Attach

מציאת ראיות

בגלל שנעשו מספר השוואות בין הודעות דואר שונות נמצאו מספר הבדלים מהותיים אשר הובילו להבדלים הבאים:

• כאשר תוקף מבצע שליחה מתות תיבת הדואר ועובד עם Webmail ההודעות From אינן מוסדרות לפי Display Name מסודר
• כאשר תוקף שולח מתוך Webmail ההודעה נשלחת עם המייל ולא מתוך אנשי הקשר ולכן אין From נדרש ומסודר
• User Agent – התנהגות חשודה בעת שליחת דואר מתוך Webmail מאולתר
• X-Mailer – שליחת דואר מתוך מערכת שאינה תואמת ליתר הודעות הדואר התקינות

דגשים במציאת ראיות

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

• השוואה של מספר הודעות דואר שונות מתקופות זמן שונות
• עבודה עם כלי Message Analyzer של Microsoft מתוך EXRCA – הסיבה לעבודה עם הכלי הזה כי הוא מציג את המאפיינים הרבים בהשוואה לכלים אחרים
• בדיקת כתובות השולח ואימות מול כלים לבדיקת תקינות כתובת דואר (Check Email למינהם וישנם רבים)
• בדיקת רכיבי שרת הדואר השייכים לארכיטקטורה כולל כתובות דואר באמצעות כלים שונים בין היתר Cisco Talos
• בדיקת מאפיינים מול Message Header בקישור הבא Exchange Headers
• בדיקה מול מאגר חשבונות דואר Dark Web
• בדיקה מול מאגר HIBP

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

תרחיש לאירוע פישינג

תרחיש נפוץ מאוד בימינו הוא פישינג ומתקפות פשיניג נחלקות לסוגים רבים: ממוקדות (spear), בכירים (whale), מבוססות תוכן נגוע (phishing based malware), מבוססות הודעות קוליות (vishing) ועוד רבים בעלי סיכון.

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

מאפיינים באירוע 

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

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

• מאפיינים של Content-Disposition
• מאפיינים של filename
• מאפיינים של X-Attachment-Id
• מאפיינים של Content–Transfer-Encoding

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

המאפיין Content-Disposition נחלק לשניים: Attachment + Inline ושם ניתן לראות את האם המשתמש פתח את הקובץ או שביצע פעולה אחרת.

דגשים חשובים באירוע

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

• From & Return-Path מכילים את אותו מזהה
• To – מציג מידע מסוג undisclosed-recipients ולכן נשלח לנמענים רבים
• BCC – ניתן לראות את כתובת הנמען ואם נעשה קורלציה מול To נבין שבוצעה כאן שליחה למספר נמענים. אגב מיילים שנשלחים עם BCC יודעים לעקוף מנגנונים שונים.

כאן נבצע בדיקה אימות מול השולח ומול כתובת הדואר הבאה
database-securemailbox8682893@pukulratabussines.me

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

באופן אישי מעדיף את השיטה של בדיקה באמצעות פקודות, אך ישנם כלים (verify mail) נחמדים Online אשר מבצעים את הבדיקה, וכאן ניתן לראות כי הדומיין וכתובת הדואר אינם תקינים.

במידה ואבצע בדיקה נוספת מתוך CMD או כמו שאני מעדיף באמצעות PowerShell אקבל את המידע הבא, ושימו לב למידע שאני מקבל. 

ממשיך בבדיקה כי הדומיין אינו תקין אך כן רוצה לדעת מהיכן נשלח הדואר ומי השולח. מכיוון שאין לי מידע אודות X-Mailer או User Agent אני ממשיך לבדוק מהיכן נשלח הדואר ומוצא את המאפיין X-Sender-IP עם כתובת מסוימת.

בבדיקה של הכתובת מול talosintelligence ניתן לראות מהיכן נשלחה ההודעה – מאיזה שרתים נשלחה ההודעה.

מכיוון שיש לי Sender IP אבצע בדיקת אימות מול MX של השולח מתוך Received Header ושם ניתן למצוא כי שרתי הדואר של גוגל הם אלה שדרכם בוצעה השליחה.

כאן מבצעים בדיקה נוספת מול מאפיין נוסף Message-ID שמציג שייכות למאפיינים של Reply-To וניתן לראות כי הכתובת הנ"ל אינה נכונה.

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

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

לסיכום

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

בכל שלב בתחקור המידע אנו חייבים להתייחס לדגשים הבאים:

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

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

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