Vishing

מתקפת Vishing היא פישינג שמתבצע בשיחת טלפון. התוקף מתקשר ומתחזה למישהו מהימן, לעתים קרובות לצוות ה-IT הפנימי או למוקד התמיכה. הוא משכנע את מי שעונה לו למסור מידע או להעניק גישה. המסגרת MITRE ATT&CK מסווגת אותה תחת שתי טכניקות נפרדות, לפי מה שהמתקשר רוצה.

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

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

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

תסבירו לי כמו לילד בן 10

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

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

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

שני מזהי טכניקה, שיחת טלפון אחת

ל-MITRE ATT&CK יש שני אובייקטים למתקפה הזו, ואף עמוד בתוצאות שנאספו לא מציין את השני.

הראשון הוא T1566.004, Phishing: Spearphishing Voice. הטקטיקה שלו היא גישה ראשונית (Initial Access). הפלטפורמות שלו הן Identity Provider, Linux, Windows ו-macOS. גרסה 1.2, נוצר ב-7 בספטמבר 2023, עודכן לאחרונה ב-12 במאי 2026.

השני הוא T1598.004, Phishing for Information: Spearphishing Voice. הטקטיקה שלו היא איסוף מידע (reconnaissance). הפלטפורמה שלו היא PRE. גרסה 1.0, נוצר באותו היום, עודכן לאחרונה באותו היום.

הפיצול לא עוסק בערוץ

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

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

שדות הפלטפורמה אומרים את אותו הדבר פעמיים. האחד נוקב ב-Identity Provider, וזו הצהרה על המקום שבו המתקפה הזו נוחתת. האחר נוקב ב-PRE, הסימון של ATT&CK לפעילות שמתרחשת עוד לפני שיש בכלל מערכת להגן עליה.

בתיאור של T1598.004 יש עוד פרט אחד ששווה לציון. הוא אומר שאת השיחות האלה "אפשר לבצע ידנית בידי תוקפים, מוקדי שיחות שכורים, או אפילו דרך שיחות אוטומטיות", וזה גם המקום שבו ATT&CK מסווגת את callback phishing, הגרסה שבה הודעה אומרת לכם להתקשר למספר במקום שהתוקף מתקשר אליכם.

באיזו תדירות מתקפת Vishing היא דרך הכניסה

הנה הנתון שאף עמוד מבין התוצאות שנאספו לא כולל.

ב-M-Trends 2026 report, תיעדה Mandiant בהתבסס על מאגר נתוני תגובה לאירועי אבטחה מהשטח: "פישינג קולי אינטראקטיבי ברמה גבוהה עלה בחדות ל-11%, והפך לווקטור השני הנפוץ ביותר שנצפה". הנתון מתייחס לוקטורי הדבקה ראשוניים בפריצות שספק תגובה לאירועי אבטחה (IR) אחד חקר במהלך שנת הכיסוי 2025. האחוז הזה מבטא חלק מנקודות הכניסה לפריצה שנצפו, ולא שיעור שכיחות של המתקפה עצמה.

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

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

אירוע אחד, שהחברה הנפגעת פרסמה בעצמה

באוגוסט 2022, Cisco Talos פרסמה תיאור של פריצה לרשת של Cisco עצמה. התוקף "ביצע סדרה של מתקפות פישינג קוליות מתוחכמות, תוך התחזות לארגונים מהימנים שונים, בניסיון לשכנע את הקורבן לאשר התראות דחיפה של אימות רב-שלבי (MFA)", ו"הצליח בסופו של דבר לקבל אישור להתראת דחיפה של MFA, מה שהעניק לו גישה ל-VPN".

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

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

המתקשר לא תמיד מתקשר אליכם

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

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

קבוצת התקיפה LAPSUS$ "התקשרה למוקד התמיכה של הקורבנות כדי לשכנע את נציגי מוקד התמיכה לאפס פרטי הזדהות של חשבון בעל הרשאות מיוחדות." קבוצת התקיפה Scattered Spider "השתמשה בפישינג קולי מול מוקד התמיכה, וגם התקשרה לעובדים בארגוני היעד, ואילצה אותם לנווט לפורטלי התחברות מזויפים באמצעות כלי adversary-in-the-middle".

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

גם בצד הגישה הראשונית הדפוס חוזר על עצמו. קבוצת התקיפה Scattered Spider "התחזתה לצוות ה-IT הלגיטימי בשיחות טלפון והנחתה קורבנות להוריד כלי לניטור וניהול מרחוק (RMM)", וקבוצת התקיפה Storm-1811 "יזמה שיחות קוליות עם קורבנות תוך התחזות לתמיכת ה-IT כדי לדחוק במשתמשים להוריד ולהריץ סקריפטים וכלים אחרים לגישה ראשונית."

מי שעונה לשיחה הוא בקרת האבטחה שנעקפת

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

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

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

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

קמפיין Salesforce הוא סמן שימושי לכמה זה עדכני: MITRE מתארכת את תחילתו לאוקטובר 2024 ומתעדת את Vishing כנקודת הכניסה. הערת שוליים קטנה באותו עמוד מוזכרת רק כי כל השיטה של המאמר הזה היא לקרוא מקורות ראשוניים במקום סיכומים שלהם. שדה ה-"First Seen" שלו מציג אוקטובר 2004, עשרים שנה לפני התיאור ישירות מתחתיו. גם לעמודי המסגרת יש שגיאות הקלדה.

האם יש בכלל מה לזהות?

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

המסגרת ATT&CK מפרסמת אסטרטגיית זיהוי לטכניקת T1566.004, DET0245, הכוללת ארבעה כללי זיהוי. הכלל הראשון מבקש מכם "לנטר לוג שיחות ממכשירים ארגוניים ולאתר בהם מספרים חריגים או לא מורשים", בהצלבה עם מה שקרה בהמשך. הכלל השני מבקש "לבקר לוגים של VoIP/SIP ולאתר בהם שיחות יוצאות חשודות או הודעות הקמת שיחה ליעדים חריגים". הכלל השלישי מתייחס ל"לוגים של Facetime, iMessage או תוכנת לקוח SIP".

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

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

הכלל הרביעי הוא השימושי

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

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

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

האם מישהו בכלל תיקן את מזהה המתקשר?

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

נקודת ההתחלה היא RFC 7340, מסמך הבעיה של ה-IETF בנושא Secure Telephone Identity, שפורסם בספטמבר 2014. התקציר שלו מסביר את הסיבה. חיבור הטלפוניה של האינטרנט לרשת הטלפון המסורתית, כך הוא קובע, "הפחית את רמת האמינות הכוללת של מספר המתקשר ושל מזהה המתקשר, בכך שהעניק לתוקפים כלים חדשים וזולים להתחזות למספרי המתקשר או להסוות אותם בעת ארגון תוכניות שיחות מסחריות בהיקף גדול, פריצה לתאים קוליים, ואפילו עקיפה של מערכות אימות רב-שלבי שבנקים סומכים עליהן."

שימו לב לתאריך שמופיע בסעיף האחרון הזה. עקיפת MFA באמצעות טלפון נכתבה במסמך תקן של האינטרנט ב-2014.

שתי מטרות, סימפטום אחד

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

מה התקן באמת טוען שהוא עושה

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

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

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

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

המעצבים אמרו את זה ראשונים

הניסוח הברור ביותר של המגבלה מופיע במסמך הבעיה משנת 2014, כמה שנים לפני שהתקן פורסם:

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

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

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

מאיפה המספר הגיע

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

• חיפוש בפחי אשפה (Dumpster diving) "כרוך בשליפת מסמכים שהושלכו או רשימות של מספרי טלפון".
• חיוג שיטתי לטווח מספרים (War dialling) "משתמש במערכות אוטומטיות כדי לחייג לטווח מספרי טלפון באזור חיוג מסוים".
• חיפוש באינטרנט "אוסף מידע ממקורות מקוונים הזמינים לציבור, כמו רשתות חברתיות".
• פריצות מידע "חושפות מספרי טלפון, רשימות אנשי קשר ומידע אישי או ארגוני".

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

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

הבקרה היחידה שמישהו בכלל מפרסם

בשתי הטכניקות, ATT&CK מונה בקרה אחת בדיוק. לא הבקרה הטובה ביותר, אלא בקרה אחת בסך הכול: M1017 User Training, המתוארת כהדרכת משתמשים "לזהות ולדווח על טכניקות הנדסה חברתית וניסיונות spearphishing, וגם לחשוד ולוודא את ה-identify של המתקשרים." השגיאה בביטוי האחרון היא של MITRE עצמה, ומובאת כאן כלשונה.

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

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

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

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

ארבע השאלות האלה לא עולות כלום, וזה כל מה שהעדות הזאת תומכת בו.

מה העמוד הזה לא יכול להגיד לכם

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

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

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

ה-11% משקפים את התיקים של ספק IR אחד, מתוך חדירות שנחקרו ושבהן היה אפשר לקבוע את נקודת הכניסה.

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

הגרסה הקצרה

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

ספק IR אחד מדד אותה ב-11% מתוך וקטורי ההדבקה הראשוניים שראה ב-2025, השני בשכיחותו מביניהם ולפני פישינג באימייל שעמד על 6%. ובמקרים המתועדים, המתקשר לעתים קרובות מחייג למוקד התמיכה ולא לקורבן ומתחזה לצוות ה-IT הפנימי ולא לבנק.

אימות מזהה המתקשר אמיתי והוא עובד. הוא מאמת מספר, לא אדם. מי שעיצבו אותו פרסמו את המגבלה הזאת ב-2014.

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