איפוס MFA עלול להפוך בקשת תמיכה להשתלטות על חשבון. כך מאמתים את זהות המבקש, מגנים על שחזור גישה ומזהים שינוי חשוד לפני שהנזק מתרחב.
זאת יכולה להיות פנייה אמיתית לחלוטין. נציג התמיכה רוצה לעזור, העובד נשמע לחוץ, והפתרון נמצא במרחק כמה לחיצות. אלא שאם האדם שפנה הוא מתחזה, אותה פעולה יכולה להעביר אליו את השליטה בחשבון. הארגון עצמו מאפשר לו לרשום את אמצעי האימות הבא.
זה הסיכון באיפוס MFA, כלומר איפוס או החלפה של אמצעי אימות רב גורמי: ההחלטה הטכנית נשענת על החלטה אנושית בשאלה מי עומד בצד השני. מי שמורשה להחליף את אמצעי האימות של עובד מחזיק בסמכות שיכולה להעניק גישה בשמו. את הסמכות הזאת צריך לנהל בהתאם לנזק שהיא מסוגלת לגרום.
התוקף יכול לבקש מהארגון לבצע את השינוי
התרחיש הזה מתועד. באזהרה משותפת של ה FBI, CISA וגופים נוספים, שעודכנה ביולי 2025, מתוארת פעילות של Scattered Spider שבה תוקפים התחזו לעובדים ושכנעו מוקדי תמיכה לאפס סיסמאות ולהעביר את האימות למכשירים שבשליטתם. המסמך מתאר גם רצף של שיחות שנועד ללמוד את תהליך השחזור ולאסוף מידע שיסייע לעבור אותו.
המשמעות הארגונית מטרידה: נוהל מוכר, אנשי שירות אדיבים ומידע נכון על העובד יכולים להשתלב לאירוע אחד. שם המנהל, המחלקה והתפקיד עשויים לעזור למתחזה להישמע אמין. הלחץ לסגור את הקריאה מספק את הדחיפה האחרונה.
לכן אנחנו ממליצים לבחון את תהליך השחזור כחלק ממערך ההרשאות. בדקו מי יכול לשנות אמצעי אימות, באילו חשבונות, באמצעות איזה ממשק ועל בסיס איזה אישור. הבדיקה צריכה לכלול גם ספק תמיכה חיצוני ופעולות שמתבצעות דרך אוטומציה, אם קיימת אצלכם כזאת.
שכחת סיסמה ואובדן כל אמצעי האימות דורשים טיפול שונה
עובד ששכח סיסמה אך עדיין מחזיק אמצעי אימות תקף נמצא במצב שונה מעובד שטוען שאיבד את כל דרכי ההזדהות. במקרה הראשון אפשר להסתמך על אמצעי קיים, בהתאם למדיניות. במקרה השני נדרש לבסס מחדש את הזכאות לקבל גישה.
הנחיות NIST לניהול אמצעי אימות ושחזור חשבונות מבחינות בין המצבים האלה. הן גם מתייחסות להודעה עצמאית לבעל החשבון כאשר נוסף אמצעי אימות או מתבצע שחזור. זהו מודל מקצועי שימושי לבניית תהליך, בלי להניח שכל בקשת ״איפוס״ מייצגת אותה רמת סיכון.
מכאן נובעת גם מסקנה לגבי Passkeys ומפתחות אבטחה: אמצעי אימות עמיד לפישינג זקוק לתהליך החלפה מוגן. אם גורם מורשה בארגון מאפשר למתחזה לרשום אמצעי חדש, חוזקו של האמצעי המקורי אינו מתקן את טעות הזיהוי. במאמר האימות עבר. התוקף כבר בפנים עסקנו בגניבת סשנים. כאן נקודת הכשל היא האישור לשנות את הדרך שבה החשבון מזדהה.
מידע על העובד יכול להיות נכון גם כשהמבקש מתחזה
מספר עובד או שם מנהל מועילים לאיתור הרשומה הנכונה. כאשר משתמשים בהם כהוכחה יחידה לזהות, כל מי שמשיג אותם עשוי לעבור את אותה בדיקה. השאלה שצריך לשאול היא מה מוכיחה הבדיקה: היכרות עם פרטים על העובד, או שליטה באמצעי שכבר נקשר אליו באופן מהימן.
גם אישור מנהל דורש הקשר. מנהל יכול לאשר שהעובד נמצא בנסיעה ושיש צורך עסקי דחוף בגישה. אם הוא מסתמך על אותה הודעה שהגיעה למוקד, האישור שלו אינו מוסיף ראיה עצמאית לזהות המבקש. שני אנשים שאישרו את אותו סיפור עדיין עלולים להסתמך על מקור אחד.
שיחה חוזרת למספר שנרשם ואומת מראש יכולה להוסיף בקרה. צריך לבדוק שהמספר לא שונה כחלק מהבקשה, ולהימנע מהסתמכות בלעדית עליו בחשבונות רגישים. אזהרת הגופים הממשלתיים מתארת גם השתלטות על מספרי טלפון באמצעות החלפת SIM. מספר מוכר מחזק בדיקה, אך אינו מסיים אותה בכל מצב.
הכלל שאנחנו ממליצים לקבוע במפורש: פרטי קשר חדשים שמסר מבקש השחזור לא ישמשו לבדם לאישור אותו שחזור. אחרת הארגון מבקש מהמתחזה להוכיח שליטה במספר שהמתחזה עצמו בחר.
בונים מראש מסלול גם למי שאיבד הכול
נוהל שעובד רק כאשר הטלפון זמין יוצר לחץ לאלתר בדיוק כשהוא נחוץ. הגדירו מראש כיצד מטפלים באובדן כל אמצעי האימות, מי מוסמך לבדוק את הזהות, אילו ראיות מתקבלות ומתי חייבים להסלים. לעובדים מרוחקים צריך להיות מסלול ישים, ובחשבונות רגישים ייתכן שיידרש אימות מחמיר יותר או מפגש פיזי.
הטבלה הבאה מציגה מדיניות מומלצת שאפשר להתאים לסיכון ולמערכות הארגון:
| מצב הבקשה | הבקרה הנדרשת | גבול הסמכות |
|---|---|---|
| החלפת טלפון כשאמצעי אימות תקף עדיין זמין | אימות באמצעות האמצעי הקיים ותהליך רישום מאובטח | החלפת האמצעי הדרוש בלבד, בלי להחליש את מדיניות הגישה |
| אובדן כל אמצעי האימות | תהליך הוכחת זהות מוגדר מראש, תיעוד והסלמה לפי הסיכון | אישור בידי גורם שהוסמך לשחזור מסוג זה |
| שחזור חשבון ניהול או חשבון בעל גישה רגישה | בדיקת זהות מחמירה ואישור נוסף המבוסס על בדיקה עצמאית | הפרדה מסמכויות מוקד התמיכה הרגיל, ככל שהמערכת מאפשרת |
כדאי גם להכין חלופה לפני אובדן: אמצעי אימות נוסף שאושר במדיניות ונשמר בנפרד מהמכשיר העיקרי. שני אמצעים שנמצאים על אותו טלפון לא בהכרח יספקו חלופה כשהטלפון אובד. בחשבונות ניהול, בדקו שהחלופה שומרת על רמת ההגנה שנדרשת מהם.
לאחר שינוי, שלחו הודעה לערוץ שהוגדר מראש ובנפרד מתהליך השחזור, עם דרך ברורה לדווח על פעולה שלא התבקשה. הודעה שמגיעה רק לכתובת החדשה שהוזנה בבקשה עלולה להשאיר את בעל החשבון האמיתי מחוץ לתמונה.
גישה זמנית דורשת זהירות גם כשהיא מוגבלת בזמן
בסביבות Microsoft Entra ID אפשר להשתמש ב Temporary Access Pass, או TAP, כדי לאפשר כניסה ורישום אמצעי אימות. זהו קוד מוגבל בזמן שאפשר להגדיר לשימוש יחיד או למספר כניסות. במסגרת שחזור מתאים, אנחנו ממליצים לבחור תוקף קצר ושימוש יחיד כשאלה עונים לצורך.
ההנפקה צריכה להתבצע רק לאחר אימות זהות. יש לבדוק למי נמסר הקוד, מי מוסמך להנפיק אותו ואילו פעולות מתאפשרות באמצעותו בסביבה שלכם. אין להניח שהקוד מעניק גישה אך ורק למסך רישום האימות.
מיקרוסופט מבהירה שתפוגת TAP אינה מבטלת בדיעבד חיבורים שכבר נוצרו. בנוסף, אמצעי אימות שנרשם באמצעותו עשוי להמשיך לשמש אחרי פקיעת הקוד. לכן ״נתנו גישה לעשר דקות״ אינו תיאור מספק של גבול הסיכון. צריך לבדוק גם מה נוצר בזמן הזה.
בקשת התמיכה והכניסה שאחריה צריכות להיבדק יחד
לצורך המחשה, נניח שמוקד התמיכה מאפס אמצעי אימות של מנהלת כספים. זמן קצר לאחר מכן נרשם אמצעי חדש, מתבצעת כניסה ממכשיר לא מוכר ומתחילה הורדה חריגה של מסמכים. החלפת טלפון אמיתית יכולה להסביר חלק מהרצף. היא עדיין מצריכה בדיקה כשהפעילות שאחריה אינה מתאימה לעובדת.
מיקרוסופט מתארת מקרים של הנדסה חברתית נגד צוותי תמיכה וממליצה לזהות שינוי בפרטי שחזור או MFA שאחריו מופיעה התחברות מסוכנת או לא מוכרת. היישום המעשי שאנחנו מציעים הוא לחבר בין מספר קריאת השירות, מבצע השינוי, האישור שניתן, שעת הרישום והכניסות שבאו אחריו.
בנו התראה מדורגת שמתחשבת ברגישות החשבון ובצירוף הסימנים. לא כל מכשיר חדש מוכיח השתלטות, ולא כל כניסה מאותה מדינה מוכיחה שהכול תקין. בדקו שהמערכות אכן שומרות את אירועי שינוי האימות ושאפשר להגיע מהם אל קריאת השירות הרלוונטית.
הגדירו גם מי רשאי לעצור את הגישה כאשר הבדיקה מעלה חשד ממשי. במאמר SOC בלי תגובה הוא רק מסך יפה הרחבנו על חשיבות הסמכות לפעול. כאן צריך לתרגם אותה להחלטה קונקרטית: מי יכול לחסום חשבון ששוחזר לפני רגע, ומי זמין לאשר את המשך הטיפול.
אם האיפוס אושר למתחזה, מטפלים בהשתלטות
בחשד מבוסס לשחזור בלתי מורשה, הפעילו את נוהל התגובה: הגבילו גישה בהתאם למצב, שמרו את תיעוד הקריאה ואת הלוגים במקביל לבלימה, בדקו והסירו אמצעי אימות לא מוכרים ובטלו חיבורים פעילים לפי יכולות המערכות. החלפת סיסמה לבדה עלולה להשאיר לתוקף דרכי גישה נוספות.
התיעוד של Microsoft על ביטול גישה מדגיש שגם יישומים יכולים להחזיק חיבורים פעילים משלהם, שספק הזהות אינו מבטל ישירות. לכן צריך לאמת את עצירת הגישה גם במערכות שנפגעו, ולא להסתפק בהפעלת פעולה מרכזית אחת.
בדקו מה השתנה בזמן שהחשבון היה בשליטת המתחזה: הרשאות, יישומים שאושרו, פרטי שחזור וכללי דואר. כדאי להיעזר גם במאמר על העברה אוטומטית במייל, משום שכלל שנוצר בזמן האירוע עלול להמשיך להעביר מידע גם לאחר שבעל החשבון חזר לעבוד.
תנו לנציג התמיכה סמכות לעצור
כאשר מודדים מוקד רק לפי מהירות סגירת קריאות, בדיקת זהות יסודית עלולה להיתפס כעיכוב. ההנהלה צריכה להגדיר במפורש שבקשת שחזור רגישה רשאית להיעצר לבדיקה. דרישה של בכיר ״לעשות את זה עכשיו״ צריכה להפעיל מסלול הסלמה, בלי למחוק את הבקרות.
לצד זמן הטיפול, מדדו כמה שחזורים תועדו במלואם, כמה חריגים אושרו, האם הודעות השינוי הגיעו ליעדן וכמה זמן נדרש להגיב לשחזור חשוד. אם התמיכה מופעלת בידי ספק, הגדירו איתו את סמכויות האיפוס, הדרישות לתיעוד והגישה ללוגים.
ב-010 אנחנו ממליצים לחבר את התהליך הזה לשלוש שכבות שנכללות ב מעטפת הגנת הסייבר שלנו: סקר סיכונים לזיהוי פערים בתהליכים ובהרשאות, מודעות עובדים להתחזות ולהנדסה חברתית, וניטור SIEM/SOC לזיהוי חריגות ותגובה. את הבקרות המסוימות צריך להתאים למערכות, לתפקידים ולסמכויות בארגון.
הבדיקה שכדאי לעשות השבוע
בחרו חשבון בדיקה עם הרשאות מצומצמות, ותכננו תרגיל מאושר של בקשת שחזור לאחר אובדן טלפון. בדקו את התהליך מתחילתו ועד סופו באמצעות חמש שאלות:
- איזו ראיה נדרשת כדי לאשר שהמבקש הוא בעל החשבון?
- מה קורה אם הוא מבקש לשנות מספר טלפון ולהשתמש מיד במספר החדש לאימות?
- מי מאשר חריגה, ואיזו בדיקה עצמאית הוא מבצע?
- האם השינוי מייצר תיעוד והודעה לערוץ שנקבע מראש?
- מי מזהה פעילות חשודה לאחר השחזור, ומי מוסמך לעצור אותה?
תהליך שחזור טוב מאפשר לעובד אמיתי לחזור לעבוד, ומשאיר למוקד דרך מבוססת להסביר למה דווקא לו ניתנה הגישה. אם ההסבר מסתכם בכך שהמתקשר נשמע משכנע, החשבון מוגן פחות מכפי שנדמה.
