זיהוי ומנע בחשבון שנפרץ Office365

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

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

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

• שינוי הגדרות כלליות ברמת חשבון Office 365
• שינוי הגדרות מסוימות מול חשבון הדואר
• הוספת חוקי דואר מבוססים Exchange Transport Rule

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

לאחר תחקור של כל אותם אירועים שונים נמצאו ממצאים ומסקנות שונות:

• משתמשי הקצה הם אלה שהתריעו על “בעיה” מסוימת בחשבון
• אנשי אבטחת המידע לא ידעו על המקרים והיו אחרונים לקבל את המידע
• כל אותם מערכות אבטחה של “חמש-שש ספרות” לא זיהוי את אירועי הסייבר כלל
• במקרים מסוימים נגנב מידע אך לא ידוע מהו היקף המידע שנלקח
• נמענים התלוננו שמקבלים ספאם מתוך אותם חשבונות שנפרצו
• לוגין וכניסות בשעות חריגות מהתקנים לא ידועים (לא של החברה)
• המתקפות נעשו על משתמשים ללא אמצעי הקשחה מתקדמים כדוגמת Multi Factor Authentication
• המתקפות נעשו מתוך מכשירים חכמים שאינם מקבלים פוליסי מסוג Prevention
• אין מדיניות מוגדרת וברורה לגבי התחברות של משתמשים חיצוניים עם התקנים שונים
• משתמשי קצה ללא מודעות בנושא אבטחת מידע וסייבר וכתוצאה מכך “לוחצים על כל דבר”
• מכיוון שאין מערכות תואמות כדוגמת אנומליות אין אפשרות לדעת ב100% האם ישנו Lateral Movement ברשת

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

על פניו נראה שכל אותם ממצאים הם דגשים ונקודות חשובות שהיו ידועות לכל אותם אנשי אבטחת מידע וסייבר אך בפועל כל אותם נהלים/דגשים/מדיניות לא הופעלה על המשתמשים ולכן חוו את החלק הראשון של מתקפת Kill Chain קלאסית שכללה בין היתר:

• External Recon
• Internal Recon
• Local Privilege Escalation
• Compromise Creds

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

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

איך ניתן למנוע, לזהות פעילות חשודה ולסדר חשבון שנפרץ

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

הפעלת MFA

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

ביטול Mail Forwarding

לרוב לאחר פריצה התוקף מגדיר Mail forwarding ברמת OWA ולכן החל מאותו רגע מקבל את כל המידע של המשתמש מתוך תיבת הדואר ללא ביצוע פעולות נוספות.
מומלץ לבטל את האפשרות של הגדרת Mail Forwarding ברמת משתמש מתוך הפורטל בהרשאות User Roles.
*מומלץ לבצע על Role Assignment בנפרד

דוחות ומעקב בפורטל Office 365 Security & Compliance

פורטל הניהול של Office365 מציע מגוון יכולות מעקב אחר פעילות משתמשים כדוגמת Audit Log מתוך Security & Compliance באפשרויות Search & investigation.
הפורטל מציג אפשריות חיפוש, יצירת פוליסי ובין היתר תצוגה של משתמשים אקטיביים וע”י לזהות פעילות חשודה של משתמשים.
*מאפשר תצוגה על כלל הפעילויות לש משתמשים בישרותי הענן השונים

החלפת סיסמאות

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

• דלגציה – תוקפים מנצלים דלגציות מול תיבות דואר אחרות או בכלל דלגציה ולכן בחשבון אשר נפרץ מומלץ להסיר את כלל הדלגציות ולהגדירם מחדש
• מעקב אחר תיבה באמצעות Exchange Audit – אפשרויות המעקב והתצוגה בין Exchange Audit לבין Audit Log מעט שונות ולכן מומלץ לבצע מעקב באמצעות Exchange Audit מתוך ממשק Exchange Online Admin
  
• זיהוי ותגובה עם CASB\ASM – היכולות של Cloud App Security מאפשרות לזהות כל פעילות חשודה ברמת המשתמש ובהתאם לכך לבצע זיהוי, להתריע ולבצע Prevention באופן אוטומטי.
  ההבדל העיקרי בין Cloud App Security לבין Advanced Security Management הוא באפליקציות SaaS, עבודה מול פרוקסי וחוקים מתקדמים.
  מומלץ מאד להפעיל חוקים לגבי אנומליות ברמת CASB\ASM ולהתריע על כך.
  
• הפעלתRemediateBreachedAccount.ps1 – במידה וחשבון נפרץ ניתן ע”י סקריפט ניתן להפעיל מספר פעולות באופן אוטומטי של איפוס סיסמא, ביטול העברת פריטי דואר, הפעלת MFA, הפעלת Audit לתיבת דואר והסרת דלגציה.
  להורדה RemediateBreachedAccount

לסיכום

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