האימות עבר. התוקף כבר בפנים

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

MFA לא מת. הוא פשוט כבר לא קו ההגנה האחרון

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

מיקרוסופט עצמה כותבת על המעבר לאימות עמיד לפישינג, ומסבירה ששיטות מסורתיות כמו SMS, קודים חד פעמיים בדוא״ל והודעות push נעשות פחות יעילות מול תוקפים שמשתמשים בהנדסה חברתית, תקיפות Man in the Middle ועייפות משתמשים. לכן, ארגון שמסתפק ב״יש MFA״ מתעלם מהשאלה החשובה יותר: איזה MFA, באיזה הקשר, מאיזה מכשיר, ולאיזו פעולה. להעמקה, ראו את המסמך של Microsoft על אימות עמיד לפישינג.

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

מהי גניבת סשן ולמה היא כל כך מסוכנת

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

MITRE מתארת את הטכניקה Steal Web Session Cookie כדרך שבה יריב יכול לגנוב עוגיות סשן ולהשתמש בהן כדי לגשת לשירותים כמשתמש מאומת, בלי להזדקק לפרטי התחברות מחדש. כלומר, תוקף שמצליח להעתיק את הסשן לא תמיד נראה כמו תוקף. הוא עשוי להיראות כמו אותו עובד, עם אותו דפדפן, אותה תיבת דואר ואותה סביבת ענן. ראו את תיאור הטכניקה אצל MITRE ATT&CK.

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

כך זה נראה באירוע אמיתי

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

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

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

למה החלפת סיסמה לא תמיד מספיקה

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

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

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

גישה מותנית היא לא כפתור. היא משילות

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

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

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

הדפדפן הוא סביבת העבודה. לכן הוא גם שדה התקיפה

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

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

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

אימות חזק בלי ניהול זהויות הוא חצי עבודה

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

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

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

הצ׳קליסט שלנו לעצירת גניבת סשן

• עברו לאימות עמיד לפישינג בחשבונות רגישים: מנהלים, כספים, IT, הנהלה, משתמשים עם גישה רחבה וספקים צריכים לקבל עדיפות. Passkeys או מפתחות אבטחה עדיפים על קודים שניתן לשכנע עובד למסור.
• הגבילו סשנים לפי מכשיר: גישה למידע רגיש צריכה להתאפשר ממכשירים מנוהלים, מעודכנים ומוצפנים. מכשיר לא מוכר לא אמור לקבל אותו אמון כמו מחשב ארגוני.
• הקשיחו גישה מותנית: הגדירו תנאים לפי סיכון משתמש, מיקום, סוג אפליקציה, רגישות מידע, עמידת מכשיר במדיניות ותדירות התחברות מחדש.
• בטלו סשנים בחשד לאירוע: החלפת סיסמה בלבד אינה תגובה מספקת. צריך לבטל סשנים, לבדוק טוקנים, כללי דואר, אפליקציות מורשות ופעילות קבצים.
• נטרו פעולות שנראות לגיטימיות אבל אינן רגילות: יצירת כלל העברת דואר, הורדת נפח גדול של קבצים, כניסה ממדינה חריגה, הוספת אפליקציה, שינוי MFA או התחברות ראשונה ממכשיר חדש.
• חברו לוגים למרכז ניטור: דואר, זהויות, עמדות קצה, דפדפן, VPN, SaaS וגיבוי חייבים לדבר יחד. בלי קורלציה אין זיהוי מוקדם.
• בדקו חשיפות מחוץ לארגון: פרטי התחברות, עוגיות, טוקנים ומידע אישי שנמכרים ברשת האפלה יכולים להיות סימן מקדים. כאן שירות מודיעין סייבר נותן ערך לפני שהאירוע מתפרץ.
• תנו לעובדים תרחישים אמיתיים: הדרכה כללית על פישינג כבר לא מספיקה. צריך לתרגל התחזות לספק, שיתוף קובץ, עמוד כניסה מזויף, בקשת MFA חשודה ושיחת תמיכה מתחזה.

איפה סינון דואר נכנס לתמונה

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

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

איך אנחנו מסתכלים על הסיכון הזה

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

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

השורה התחתונה

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

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

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