הונאת מנכ״ל והתחזות לספק (BEC): עצירת העברה וחקירת דוא״ל

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

מהו BEC ומה יכול להיראות אותו דבר

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

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

שלושת הנכסים בסיכון

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

30 הדקות הראשונות: מסלול פעולה מקביל

דקות 0–5: עצירה

1. עוצרים העברה שטרם בוצעה או תשלום נוסף.
2. לא משיבים לשרשור החשוד ולא מתקשרים למספר שבהודעה.
3. מאמתים את הבקשה במספר ספק או מנהל שנשמר מראש.
4. אם הכסף יצא, מתקשרים לבנק מיד.
5. פותחים ערוץ אירוע מצומצם עם כספים, אבטחת מידע ומשפט.

דקות 5–15: שימור

1. שומרים הודעה מקורית בפורמט שמכיל כותרות.
2. שומרים את השרשור, הקובץ, החשבונית ופרטי ההעברה.
3. מתעדים מי פתח, אישר ושילם ומתי.
4. משמרים לוגי כניסה, audit וכללי תיבה לפני ניקוי.
5. מקצים מזהי ראיות ומתחילים ציר זמן חקירתי.

דקות 15–30: בלימה ודיווח

1. מנתקים סשנים חשודים ומאפסים גישה לפי נוהל.
2. בודקים forwarding, inbox rules, delegates ואפליקציות מקושרות.
3. מחפשים את חשבון היעד, הנושא והדומיין בתיבות נוספות.
4. מגישים תלונה למשטרה ומדווחים למוקד 119 לפי האירוע.
5. בוחנים חובת דיווח לרשות להגנת הפרטיות ולרגולטור.

חבילת פעולה לבנק

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

פרטי ההעברה

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

מה מבקשים

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

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

תקשורת עם הספק האמיתי

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

שימור הודעות, כותרות ולוגים

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

הודעת המקור

• ייצוא EML או MSG לפי המערכת, בלי העברה מחדש בלבד.
• כותרות מלאות, Message-ID ורצף שרתים.
• From, Reply-To, Return-Path וכתובת מעטפה.
• תוצאות SPF, DKIM ו-DMARC אם קיימות.
• קבצים מצורפים וה-hash שלהם לפי צורך.
• השרשור המלא, לרבות הודעות קודמות אמיתיות.

לוגי ענן ודואר

• כניסות מוצלחות וכושלות.
• IP, מכשיר, מיקום משוער ושיטת אימות.
• יצירה ושינוי של כללי תיבה והעברה.
• delegates, forwarding addresses ו-mailbox permissions.
• אפליקציות OAuth והרשאות צד שלישי.
• שליחה, מחיקה, חיפוש וגישה להודעות לפי זמינות הלוג.
• שינוי סיסמה, MFA ופרטי שחזור.

ראיות כספיות ותהליכיות

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

שומרים גם חומר שמחליש את החשד

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

איך מבדילים בין פריצה, זיוף ופעולה פנימית

דומיין דומה

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

חשבון שנפרץ

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

גורם פנימי

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

שיתוף פעולה בין חוץ לפנים

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

בלימת גישה לתיבה ולסביבה

זהות וחשבון

1. מחליפים סיסמה ממכשיר נקי.
2. מבטלים סשנים וטוקנים פעילים.
3. מאפסים MFA ובודקים שיטות אימות חדשות.
4. בודקים פרטי שחזור ומספר טלפון.
5. מסירים אפליקציות והרשאות לא מוכרות.
6. בודקים delegates ותיבות משותפות.

כללי תיבה והעברה

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

תחנת הקצה

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

הדומיין

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

תקשורת חיצונית

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

קביעת היקף: כמה זמן, אילו תיבות ואיזה מידע

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

חיפוש אינדיקטורים

• חשבון הבנק או IBAN המזויפים.
• דומיין, כתובת Reply-To ומספר טלפון.
• נושא, נוסח קבוע ומילות מפתח.
• Message-ID ו-hash של קבצים.
• כתובות IP, אפליקציות וטוקנים.
• שמות ספקים ותשלומים שנדונו בתיבה.

תיבות קשורות

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

מידע שנחשף

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

אירועים נוספים

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

חקירת מסלול התשלום

שרשרת התהליך

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

מי ידע מה ומתי

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

חשבון היעד

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

תשלומים מקבילים

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

ריאיונות וחקירה פנימית

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

סדר אפשרי

1. מנהל המערכת שמסביר לוגים ושדות.
2. עובד שקיבל את הבקשה.
3. מי שאימת או היה אמור לאמת.
4. מי ששינה פרטי ספק.
5. מי שאישר ושחרר תשלום.
6. הספק האמיתי בערוץ עצמאי.
7. אדם שנבדק כמעורב, לאחר שיש תשתית.

שאלות מרכזיות

• מה היה התהליך הרגיל ומה היה שונה?
• מאיזה ערוץ התקבלה הבקשה?
• איך אומתה הזהות ובאיזה מספר?
• מי ביקש דחיפות או סודיות?
• אילו מסמכים נבדקו?
• מי עוד ידע על מועד התשלום?
• האם הופיעו הודעות או כניסות חריגות?
• האם התהליך נעקף בעבר?

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

פרטיות, חובות דיווח והגבלת מידע

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

אירוע אבטחה חמור

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

דיווחים אינם מחליפים זה את זה

• הבנק מטפל במסלול הכסף.
• המשטרה מטפלת בתלונה על עבירה.
• מוקד 119 מסייע באירוע הסייבר.
• הרשות להגנת הפרטיות מטפלת בחובות לפי דיני מאגרי מידע.
• רגולטור מגזרי יכול לדרוש דיווח נוסף.

הודעה לנושאי מידע

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

בקרות שמונעות את ההעברה הבאה

שינוי פרטי בנק של ספק

1. בקשה נכנסת בערוץ מוגדר ולא בדואר חופשי בלבד.
2. העובד מאתר בעצמו את איש הקשר והמספר הישנים.
3. מתבצעת שיחת callback למספר מוכר.
4. נדרשים שני מאשרים נפרדים לשינוי ולתשלום ראשון.
5. המערכת מתריעה על תשלום סמוך לשינוי master data.
6. קיימת תקופת צינון או בדיקת סכום קטן לפי הסיכון.
7. הספק מקבל אישור שינוי בערוץ נפרד.

בקשת מנהל בכיר

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

בקרות דואר וזהות

• MFA עמיד ככל האפשר לדיוג בחשבונות רגישים.
• חסימת אימות ישן והרשאות עודפות.
• התראה על forwarding, OAuth וכלל תיבה חריג.
• DMARC, DKIM ו-SPF מוגדרים ומנוטרים.
• תצוגה ברורה של שולחים חיצוניים ושל כתובת מלאה.
• שמירת לוגים בהתאם לסיכון ולדרישות.

הפרדת תפקידים

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

תרגול

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

התחזות בקול או בווידאו

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

אימות לפעולה רגישה

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

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

דוח אירוע והפקת לקחים

דוח ביניים בתוך שעות

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

דוח חקירה סופי

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

סיבת שורש מול נקודת כשל

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

מדדי תיקון

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

רשימות בדיקה

חבילת חירום לבנק

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

חבילת ראיות

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

בדיקת סגירה

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

שאלות נפוצות

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

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

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

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

האם למחוק מיד את כלל ההעברה החשוד?

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

אם הבנק לא הצליח לעצור את ההעברה, האם החקירה מיותרת?

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

מי צריך להוביל את האירוע?

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

האם BEC מחייב דיווח לרשות להגנת הפרטיות?

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

מה יכול חוקר פרטי לעשות?

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

איך מונעים חריג של מנכ״ל?

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

מקורות רשמיים להעמקה

• IC3: Business Email Compromise, מאפיינים והגנה.
• IC3: פעולה מהירה לאחר העברת BEC.
• מערך הסייבר הלאומי: אימות בקשות תשלום ועוקץ מנהלים.
• דיווח על אירוע סייבר למוקד 119.
• הגשת תלונה למשטרת ישראל.
• דיווח על אירוע אבטחה חמור לרשות להגנת הפרטיות.

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