למה דליפת סיסמה היא אירוע סייבר, לא תקלה תפעולית
דליפה של זהויות היא לא רק “עוד משתמש שצריך להחליף לו סיסמה”. היא יכולה להיות התחלה של שרשרת. באותו DBIR מופיע נתון שמנהל צריך לקרוא פעמיים: בניתוח שהצליב לוגים של נוזקות גונבות מידע עם קורבנות כופרה, 54% מהקורבנות הופיעו עם דומיין ארגוני בתוך מאגרי ה infostealer, ו 40% מהלוגים שנבדקו הכילו כתובות דוא״ל ארגוניות כחלק מה credentials שנגנבו.
זו גם הסיבה שאנחנו ב 010 מתייחסים למודיעין סייבר כאל שכבת הגנה, לא כאל “Nice to have”. ניטור מוקדם של חשיפות ברשת האפלה נותן לכם יתרון זמן. וזמן הוא המטבע היחיד שקובע באירוע אמיתי.
איך זה נראה בשטח: מסלול קצר מפרטי התחברות גנובים לפריצה מלאה
- הדבקה שקטה בעמדת קצה באמצעות קובץ “תמים”, תוסף דפדפן, התקנה פיראטית או קמפיין פישינג.
- איסוף זהויות הדפדפן שומר סיסמאות, טוקנים, עוגיות, ולעיתים גם גישה לשירותי ענן.
- מכירה בשוק עברייני סייבר מתמחים מוכרים “גישה ראשונית” למתווכים, במקום לבזבז זמן על חדירה בעצמם.
- ניסיונות התחברות אוטומטיים password spraying או credential stuffing על שירותי דוא״ל, VPN, פורטלים ומערכות SaaS.
- העמקה חוקים במייל, הפניית הודעות, הרשאות OAuth חשודות, גניבת מידע, תנועה רוחבית.
- מכה עסקית הונאת תשלומים, דלף מידע, או כופרה שמגיעה רק בסוף, כשהתוקף כבר “מכיר את הבית”.
המיתוס המסוכן: “יש לנו MFA אז אנחנו מוגנים”
MFA הוא בסיס, אבל הוא לא קסם. למה? כי התוקפים משחקים על שלושה אזורים אפורים, והם עושים את זה מהר יותר משנה לשנה. Microsoft מתארים ב Microsoft Digital Defense Report 2025 איך פישינג מונע בינה מלאכותית נעשה יעיל פי שלושה מקמפיינים מסורתיים, ואיך יש תעשייה של מתווכי גישה שמוכרים כניסה לאלפי ארגונים.
- עייפות אישורים והנדסה חברתית מתקפות שמנסות לגרום למשתמש לאשר בקשה “רק כדי שזה יפסיק”.
- גניבת טוקנים ועוגיות נוזקות גונבות מידע לא תמיד צריכות את הסיסמה אם הן מצליחות להשיג session תקף.
- אימות ישן ושירותים נשכחים נקודת כניסה אחת שלא דורשת MFA מספיקה כדי לעקוף את כל מה שעשיתם נכון במקום אחר.
המסר שלנו ב 010 חד: MFA צריך להיות עמיד לפישינג, מוגן במדיניות, ונמדד בפועל. לא רק “מסומן בוי” בהגדרות. אם אתם רוצים לגשת לזה פרקטית, התחילו מהשכבה של אימות דו שלבי והרחיבו לאכיפה על חשבונות אדמין וספקים.
מה עושים היום בבוקר: תוכנית פעולה אמיתית נגד דלף זהויות
1. תבנו רדאר לדליפות
אם אתם לא מקבלים התרעה כשאימייל ארגוני מופיע במאגרי credentials, אתם עיוורים. כאן נכנס שירות מודיעין הסייבר של 010: איתור מוקדם של חשיפות, מיפוי מי דלף, והכוונה לפעולות סגירה.
2. תעדיפו זהויות מפתח
מנהלים, כספים, IT, ספקים חיצוניים, ותיבות שירות. להם יש “מפתח מאסטר” בפועל. התחילו מהם: אימות עמיד לפישינג, עיקרון הרשאות מינימליות, ביטול גישות שלא חייבות להיות קיימות, והפרדה בין חשבון יומיומי לחשבון ניהולי.
3. תחסמו credential stuffing לפני שהוא פוגע
OWASP מגדירים credential stuffing כהזרקה אוטומטית של זוגות משתמש וסיסמה שנגנבו כדי להשתלט על חשבונות. זה לא “האקר גאון”, זו תעשייה של אוטומציה. ראו את ההגדרה הרשמית ב OWASP והבינו למה הגנה חייבת לכלול גם שכבות אפליקטיביות: rate limiting, זיהוי בוטים, נעילה חכמה, והתראות.
4. תבטלו אימות ישן ופתחים מיותרים
כל שירות שמאפשר התחברות בלי MFA הוא יעד. כל פורטל שנשאר פתוח לאינטרנט “כי צריך”, הוא פתח למכירה בשוק. כאן נכנסים גם תהליכי ניהול עדכונים ועדכוני אבטחה וסקר תקופתי של שטח התקיפה.
5. תוודאו שיש לכם נראות אמיתית
דליפה הופכת לאירוע רק אם אין גילוי. לכן נדרש איסוף לוגים וניתוח מתמשך. אם אתם רוצים להבין איך עושים את זה נכון, קראו את המדריך שלנו על שלוש רמות של איסוף לוגים. ובפועל, זה בדיוק מה שעושה שירות SIEM ו SOC של 010: איסוף, קורלציה, אנליסטים, ותגובה.
6. תבנו שכבה נגד הונאות דוא״ל
גם כשזה מתחיל בזהות, זה הרבה פעמים נגמר במייל. תוקף שנכנס לתיבה יכול לבנות אמון, לחפש חשבוניות, לשנות פרטי תשלום, ולהוסיף חוקים שמסתירים התראות. כאן סינון דוא״ל והדרכת עובדים הופכים לשכבת בלימה, לא לעלון מודעות.
7. תעצרו דלף מידע גם אחרי שהחשבון נפרץ
הגנה מודרנית מניחה שיהיו כשלונות. לכן צריך גם למנוע יציאה של מידע רגיש. זה תפקידן של מערכות מניעת דלף מידע: סיווג, חוקים, חסימות ושקיפות. תוקף יכול להיכנס, אבל לא תמיד הוא חייב לצאת עם “הסחורה”.
8. והקצה האחרון: תוודאו שיש לכם חבל הצלה
כשזה בכל זאת מסתבך, אין תחליף לגיבוי בדוק וליכולת התאוששות. זו לא כותרת יפה, זו הנדסה תפעולית. אם אתם עדיין רואים בגיבוי “פרויקט IT”, אתם מפספסים את התפקיד שלו בניהול סיכונים עסקי. התחילו ב גיבוי והמשכיות עסקית והקפידו לבדוק שחזור מלא, לא רק קובץ בודד.
שעה ראשונה אחרי גילוי דלף זהויות: מה לא מדלגים עליו
- ביטול sessions וניתוק התחברויות קיימות, כולל טוקנים מתמשכים, לפני שמחליפים סיסמה.
- איפוס סיסמה חכם לחשבונות שנחשפו, ובדיקה אם קיימת מחזוריות סיסמאות בין מערכות.
- בדיקת תיבת דוא״ל חוקים, forwarding, הרשאות delegate, ושינויים בחשבוניות או פרטי תשלום.
- בדיקת OAuth האם הותקנה אפליקציה עם הרשאות רחבות בלי הצדקה.
- ציד לוגים ממוקד התחברויות ממדינות לא צפויות, כניסות בשעות חריגות, או ניסיונות כושלים בהיקף גבוה.
- סגירת סודות מוטמעים מפתחות API, סיסמאות בקבצי קונפיג, וסקריפטים. CISA מדגישים ש credentials מוטמעים קשה לגלות ועלולים לאפשר גישה ארוכת טווח אם נחשפו.
שאלון אמת קצר: האם אתם מוכנים לדלף זהויות?
- האם אתם יודעים מי המשתמשים המועדפים לתקיפה בארגון, והאם הם מוגנים במדיניות חזקה?
- האם אתם מקבלים התרעה כשמופיע אימייל ארגוני במאגר דלוף?
- האם אתם יכולים לבטל session פעיל ולהכריח התחברות מחדש בתוך דקות?
- האם אתם מנטרים חריגות התחברות, במיוחד לחשבונות אדמין וספקים?
- האם יש לכם נראות רציפה בלוגים, או שאתם מגלים רק בדיעבד?
אם עניתם “לא” על יותר משאלה אחת, זה לא סוף העולם. אבל זה כן סימן שאתם צריכים להחליף גישה. המסגרת המקצועית נקראת Zero Trust, והיא מתחילה בזהות, לא ברשת. לקריאה עמוקה יותר, עברו למאמר שלנו על Zero Trust.
הצעד החכם ביותר: להפוך מודיעין ותגובה לשגרה
התקפות זהות לא מחכות לישיבת הנהלה. הן קורות בלילה, בסוף שבוע, בדיוק כשאף אחד לא מסתכל. לכן אנחנו ב 010 בונים מעטפת שמחברת בין מודיעין, זהויות, נראות ותגובה: מודיעין רשת אפלה, הקשחת אימות, ניטור לוגים עם צוות אנושי, וסגירת נתיבי דלף מידע.
רוצים להתחיל בלי הצגות? התחילו משני דברים: סריקת חשיפות זהויות, וחיבור לוגים שמאפשר גילוי מהיר. משם כבר בונים חוסן אמיתי.
מקורות חיצוניים מומלצים
- Verizon DBIR 2025
- DBIR 2025 תקציר נתונים
- CISA על סיכוני credentials ודגשים לפעולה
- Microsoft Digital Defense Report 2025
- NIST SP 800 207 Zero Trust Architecture
לקריאה משלימה בבלוג שלנו: איך לזהות ולחסום ניסיונות פישינג מתוחכמים, האמת על אבטחת Microsoft 365 בשנת 2025