.jpg)
לאחרונה נתקלתי במספר מקרים בהם נפרצו חשבונות Office365 של משתמשי קצה שונים החל מעובדים רגילים ועד הנהלה עם פישינג ממוקד, בכל אותם חשבונות נעשו שינויים שונים בין היתר הגדרת Mail Forward, הגדרת חוקים ברמת OWA, הוספת או שינוי של קישורים בתוך החתימה ועוד.
ברוב המקרים המתקפות היו קצרות יחסית ומשתמשים שמו לב להתנהגות שונה בפעולות שהם מבצעים ולכן פנו לאנשי הסיסטם, אך בחלק מהמקרים המתקפה ארכה מספר שבועות עד שאותו משתמש קצה פנה לאנשי הסיסטם.
לאחר תחקור של כל אותם אירועי סייבר שונים נמצאו ממצאים מטרידים:
• משתמשי הקצה הם אלה שהתריעו על “בעיה” מסוימת
• אנשי אבטחת המידע לא ידעו על המקרים והיו אחרונים לקבל את המידע
• כל אותם מערכות של “חמש-שש ספרות” לא זיהוי את אירועי הסייבר כלל
• במקרים מסוימים נגנב מידע אך לא ידוע מהו היקף המידע שנלקח
• נמענים התלוננו שמקבלים ספאם מתוך אותם חשבונות שנפרצו
• לוגין וכניסות בשעות חריגות מהתקנים לא ידועים (לא של החברה)
• המתקפות נעשו על משתמשים ללא אמצעי הקשחה מתקדמים כדוגמת 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 בגישה חיצונית לפחות ומענה להתקנים שאינם שייכים לארגון.
לאחרונה נתקלתי במספר מקרים בהם נפרצו חשבונות Office365 של משתמשי קצה שונים החל מעובדים רגילים ועד הנהלה עם פישינג ממוקד, בכל אותם חשבונות נעשו שינויים שונים בין היתר הגדרת Mail Forward, הגדרת חוקים ברמת OWA, הוספת או שינוי של קישורים בתוך החתימה ועוד.
ברוב המקרים המתקפות היו קצרות יחסית ומשתמשים שמו לב להתנהגות שונה בפעולות שהם מבצעים ולכן פנו לאנשי הסיסטם, אך בחלק מהמקרים המתקפה ארכה מספר שבועות עד שאותו משתמש קצה פנה לאנשי הסיסטם.
לאחר תחקור של כל אותם אירועי סייבר שונים נמצאו ממצאים מטרידים:
• משתמשי הקצה הם אלה שהתריעו על “בעיה” מסוימת
• אנשי אבטחת המידע לא ידעו על המקרים והיו אחרונים לקבל את המידע
• כל אותם מערכות של “חמש-שש ספרות” לא זיהוי את אירועי הסייבר כלל
• במקרים מסוימים נגנב מידע אך לא ידוע מהו היקף המידע שנלקח
• נמענים התלוננו שמקבלים ספאם מתוך אותם חשבונות שנפרצו
• לוגין וכניסות בשעות חריגות מהתקנים לא ידועים (לא של החברה)
• המתקפות נעשו על משתמשים ללא אמצעי הקשחה מתקדמים כדוגמת 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 בגישה חיצונית לפחות ומענה להתקנים שאינם שייכים לארגון.
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר
