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

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

פרטי האירוע

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

ממצאים

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

המלצות

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

לסיכום

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