לחיצה על פישינג היא אירוע שצריך לחקור, לא רק "לתקן"

בארגונים רבים קיימת תגובה כמעט אוטומטית לאירוע פישינג:

• לחסום את השולח.
• לאפס את סיסמת המשתמש.
• למחוק את המייל.
• ולהמשיך הלאה.

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

הבעיה היא שאחרי שהמשתמש לחץ על קישור, פתח קובץ או הזין פרטי התחברות, השאלה החשובה כבר אינה רק:

האם המייל היה זדוני?

אלא:

מה קרה במערכות הארגון לאחר האינטראקציה עם המייל?

• האם נגנבו Credentials?
• האם התוקף הצליח להתחבר לחשבון?
• האם נוצר Session פעיל?
• האם נוספה שיטת MFA חדשה?
• האם הוגדר Mail Forwarding?
• האם התוקף העניק הרשאות לאפליקציית OAuth?
• האם הופעל Malware בתחנת הקצה?
• והאם נעשה שימוש בחשבון שנפרץ כדי להגיע למשתמשים, למערכות או למידע נוספים?

לכן, ברגע שקיימת אינדיקציה לכך שהמשתמש ביצע פעולה בעקבות הודעת Phishing, האירוע צריך לעבור מחשיבה של "טיפול במייל" לחשיבה של Incident Investigation.

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

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

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

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

המשמעות הארגונית ברורה:

אין להסתפק במחיקת ההודעה מתיבת המשתמש שדיווח עליה.

צריך להבין את Scope האירוע.

למשל:

• האם ההודעה הגיעה ל-3 עובדים או ל-300?
• מי מהם לחץ?
• מי פתח Attachment?
• מי הזין Credentials?
• האם ההודעה עדיין נמצאת בתיבות נוספות?
• והאם יש עובדים שלא דיווחו כלל על האירוע?

השלב הזה מאפשר לארגון לעבור מטיפול נקודתי להבנה אמיתית של היקף התקיפה.

שלב שני: חסימת השולח אינה מספיקה

חסימת Sender, Domain או URL זדוני היא חלק חשוב מה-Containment.

אבל חשוב להבין את המגבלה שלה.

התוקף אינו חייב להמשיך להשתמש באותה כתובת.

Campaign יכול להתחלף תוך דקות ל-Domain אחר, כתובת אחרת או קישור אחר.

לכן חסימת השולח צריכה להיות משולבת בבדיקת Indicators נוספים:

• Domain
• URL
• IP Address
• Hash של קבצים
• Sender Infrastructure
• דפוסי התחברות
• ואינדיקציות נוספות שהתגלו במהלך החקירה.

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

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

שלב שלישי: "להחליף את פרטי המשתמש" הוא רק תחילת הטיפול בזהות

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

אבל במערכות Cloud מודרניות, סיסמה היא רק חלק מהזהות.

תוקף שכבר הצליח לבצע Login עשוי להחזיק Session פעיל או Token שיאפשרו לו להמשיך לפעול גם לאחר החלפת הסיסמה.

לכן בתרחיש של Compromised Account יש לבחון גם:

• ביטול Sessions פעילים
• Revocation של Refresh Tokens
• בדיקת Sign-in Logs
• בדיקת MFA Methods
• בדיקת Authentication Methods חדשים
• בדיקת אפליקציות שקיבלו User Consent
• בדיקת Inbox Rules
• בדיקת Forwarding Rules
• בדיקת הרשאות או Group Memberships
• בדיקת פעולות שבוצעו מתוך החשבון

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

זו הבחנה חשובה מאוד:

Password Reset מחליף סיסמה. הוא לא בהכרח מוחק את כל מה שהתוקף עשה לפני כן.

וכאן נכנס Threat Hunting

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

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

משתמש מסוים לחץ על לינק.

מכאן מתחילים לשאול:

• מה קרה בדקות ובשעות שלאחר מכן?
• האם היה Login ממדינה חריגה?
• האם הופיע IP חדש?
• האם נוצרה גישה למערכות שהמשתמש בדרך כלל אינו משתמש בהן?
• האם התוקף ניסה לבצע Lateral Movement?
• האם נצפו פניות ל-Domains חשודים?
• האם הופעל Process חדש במחשב?
• האם קיימים Endpoint Alerts?
• האם הועתק מידע?
• האם נעשה שימוש בחשבון לשליחת Phishing נוסף?

Microsoft מציינת שבחקירת Phishing יש לקשר בין פעילות המייל לבין Entra Sign-in Logs, Audit Logs ופעילות Endpoint, ולחפש Follow-on Activity כמו Suspicious Sign-ins, OAuth Consent, Token Abuse או פעילות חריגה בתיבת הדואר ובשירותי Collaboration.

זה בדיוק ההבדל בין תגובה בסיסית לבין Threat Hunting.

תגובה בסיסית שואלת:

מה אנחנו יודעים שקרה?

Threat Hunting שואל:

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

מה מחפשים במסגרת Threat Hunting אחרי פישינג?

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

Identity Hunting

בדיקה סביב המשתמש והזהות שלו:

• Sign-in חריג
• Login ממדינה חדשה
• Impossible Travel
• Authentication חריג
• שינוי MFA
• Token Abuse
• Password Reset
• Privilege Escalation
• או גישה לשירותים חריגים

Mailbox Hunting

בדיקת תיבת הדואר:

• Inbox Rules חדשים
• Forwarding לכתובת חיצונית
• מחיקת הודעות
• שליחת הודעות חריגה
• גישה למיילים רגישים

או שימוש בתיבה להפצת פישינג נוסף.

Inbox Rules ו-Forwarding Rules הם אינדיקציות חשובות במיוחד, משום שתוקפים משתמשים בהם לעיתים כדי לשמור על Persistence או להעתיק מידע. Microsoft מציינת כללים חשודים והעברת דואר חיצונית כסימנים אפשריים לחשבון שנפרץ.

Endpoint Hunting

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

בין היתר:

Processes חדשים,

PowerShell או Script Execution,

קבצים שהורדו,

Persistence,

Registry Changes,

Scheduled Tasks,

Network Connections,

Malware,

או תקשורת ל-C2 Infrastructure.

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

Cloud ו-OAuth Hunting

תקיפות Phishing מודרניות אינן תמיד מבוססות רק על גניבת סיסמה.

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

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

יש לבדוק:

OAuth Applications,

Consent Grants,

Permissions,

Graph API Activity,

Cloud App Activity,

והאם האפליקציה קיבלה גישה ל-Mail, Files, Contacts או מידע ארגוני אחר.

Microsoft מתארת תרחישים שבהם אפליקציות OAuth זדוניות מקבלות הרשאות, קוראות הודעות ואף יוצרות Inbox Rules לצורך גישה או הוצאת מידע.

מה אם לא ניתן לבצע Threat Hunting?

כאן מגיעה ההמלצה הקיצונית יותר שמופיעה לעיתים בהנחיות Incident Response:

אם לא ניתן להוכיח שהתחנה נקייה, אפשר לשקול Reimage או Wipe.

אבל חשוב לדייק.

מחיקת תחנה אינה צריכה להיות תגובה אוטומטית לכל לחיצה על Phishing.

אם המשתמש רק נכנס לעמוד Fake Login והזין Credentials, ייתכן שהאירוע מתמקד בעיקר בזהות וב-Cloud.

לעומת זאת, אם הורד והופעל Payload, הופיעו אינדיקציות ל-Malware או שאין לארגון יכולת מספקת לבצע Endpoint Investigation, רמת אי-הוודאות עולה משמעותית.

במקרה כזה, Reimage של התחנה עשוי להיות הדרך הבטוחה להחזיר אותה למצב Trusted.

Microsoft כוללת במסגרת Remediation של Identity Compromise אפשרות לסרוק או לבצע Reimage למכשיר כאשר קיים חשד לפגיעה ב-Endpoint.

הגישה הנכונה היא לכן:

לא מוחקים תחנה משום שהיה Phishing. מוחקים או משחזרים אותה כאשר אין יכולת סבירה להוכיח שהיא נקייה או כאשר קיימת עדות ל-Endpoint Compromise.

Threat Hunting אינו תחליף ל-Incident Response

חשוב גם להפריד בין שני המושגים.

Incident Response הוא התהליך הרחב:

זיהוי,

ניתוח,

Containment,

Eradication,

Recovery,

והפקת לקחים.

Threat Hunting הוא כלי חקירתי בתוך המערך הזה.

המטרה שלו היא לזהות פעילות שלא בהכרח התגלתה באמצעות Alerts רגילים.

במילים אחרות:

Incident Response מנהל את האירוע. Threat Hunting עוזר להבין עד כמה האירוע באמת הגיע.

גישה זו משתלבת גם במודל Incident Response של NIST, המדגיש Detection & Analysis, Containment, Eradication, Recovery ופעילות לאחר האירוע.

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

גם כאן חשוב להימנע מתגובה אחידה לכל תרחיש.

יש הבדל גדול בין:

עובד שקיבל מייל ולא לחץ,

עובד שלחץ על לינק אבל לא ביצע פעולה,

עובד שהזין Credentials,

עובד שאישר MFA,

עובד שהעניק OAuth Consent,

ועובד שהוריד והפעיל קובץ.

לכל אחד מהתרחישים יש Risk Profile אחר.

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

ומה צריך לקרות אחרי שהאירוע נגמר?

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

כדאי לבדוק:

מדוע ההודעה עברה את מערכות הסינון?

האם המשתמש זיהה את הפישינג?

כמה זמן חלף עד לדיווח?

האם צוות האבטחה הצליח לזהות את כלל הנמענים?

האם קיימים Logs מספיקים?

האם ניתן היה לבצע Threat Hunting?

האם MFA עצר את התוקף?

והאם ה-Incident Response Playbook של הארגון היה ברור?

המטרה אינה רק "לסגור Ticket".

המטרה היא להשתמש באירוע כדי לשפר את המוכנות לאירוע הבא.

מאירוע פישינג לחוסן ארגוני

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

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

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

וזו בדיוק מטרת Incident Response מקצועי:

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

אלא לוודא שלא נשאר משהו שאנחנו עדיין לא רואים.

כיצד אינפוגארד מסייעת בהתמודדות עם אירועי Phishing

באינפוגארד אנו מתייחסים לאירוע Phishing כחלק מתמונה רחבה של Incident Response, Cyber Resilience וניהול סיכונים.

הטיפול יכול לכלול בחינת Scope האירוע, ניתוח הפעולות שבוצעו, Threat Hunting, בדיקת זהויות ותחנות, בחינת Indicators of Compromise, המלצות ל-Containment ו-Remediation וכן הפקת לקחים ועדכון תהליכי Incident Response.

המטרה היא לא רק להחזיר את המשתמש לעבודה.

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

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

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

המאמר נכתב בשיתוף מומחי אבטחת המידע והסייבר של Infoguard מקבוצת IDOR, ונערך על ידי ROY KISCH, חובב פרטיות, אבטחת מידע, סייבר ומנהל שיווק בקבוצת חברות עידור (Messagenet, Infoguard, Idornext).