ניתוח הודעת פישינג: מההודעה ועד התשתית

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

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

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

• Gmail: תפריט ⋮ של ההודעה, ואז „הצג מקור”;
• Outlook: תפריט … של ההודעה, ואז האפשרות שמציגה את פרטי ההודעה או את המקור שלה;
• Apple Mail: תפריט „תצוגה”, ואז „הודעה” והצגת כל הכותרות;
• Thunderbird: קיצור המקשים Ctrl+U (או Cmd+U ב-Mac), שפותח את מקור ההודעה.

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

שורות Received: החותמות של הדואר

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

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

Received: from mx1.provider.example (mx1.provider.example [192.0.2.10])
        by mailbox.provider.example; Tue, 15 Sep 2026 09:14:05 +0200
Received: from vps-4411.host.example (vps-4411.host.example [203.0.113.45])
        by mx1.provider.example with ESMTPS; Tue, 15 Sep 2026 09:14:03 +0200
Received: from mail.mybank.example (unknown [10.0.0.7])
        by vps-4411.host.example; Tue, 15 Sep 2026 07:13:58 +0000
Authentication-Results: mx1.provider.example;
        spf=pass smtp.mailfrom=parcel-mail.example; dkim=none;
        dmarc=fail header.from=mybank.example
Return-Path: <bounce@parcel-mail.example>
From: "My Bank" <security@mybank.example>
Reply-To: mybank.support@freemail.example
Subject: Your account will be suspended within 24 hours

כל שורת Received נקראת כמו משפט קצר: „התקבל מ(from) מחשב פלוני, על ידי (by) שרת פלוני, בתאריך פלוני”. מיד אחרי from מופיע השם שהמחשב הכריז עליו כשהציג את עצמו, בלי שום בדיקה. בסוגריים מופיע מה שהשרת המקבל ראה בפועל: כתובת ה-IP של המחשב שעמד מולו, בסוגריים מרובעים.

קוראים מלמטה למעלה… אבל סומכים מלמעלה למטה

כיוון שכל שרת מוסיף את השורה שלו מעל הקודמות, הסיפור נקרא מלמטה למעלה: השורה התחתונה מספרת על היציאה, והעליונה על ההגעה לתיבה שלנו. בדוגמה, ההודעה יוצאת ממחשב שקורא לעצמו „mail.mybank.example”, עוברת דרך vps-4411.host.example, ואז נכנסת לשירות הדואר שלנו.

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

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

ומה עם השורה התחתונה? היא טוענת שההודעה הגיעה מ-„mail.mybank.example”, מהכתובת 10.0.0.7, כתובת פרטית שלא קיימת באינטרנט. מי שכתב אותה הוא vps-4411 עצמו: זה עקבות שווא, שהונחו בכוונה.

מה אמין, ומה אפשר לזייף

בדוגמה, Authentication-Results מספר הרבה. spf=pass אומר שהשרת אכן היה רשאי לשלוח… בשם parcel-mail.example, הדומיין של המעטפה, ולא בשם הבנק. dmarc=fail אומר שהכתובת המוצגת mybank.example לא תואמת שום דבר שנבדק: ה-„מאת” מזויף. אז למה ההודעה הגיעה בכל זאת? זה בדיוק הנושא של המדריך דוא״ל יכול לשקר… גם כשהבדיקות אומרות „OK”.

מה-IP אל המפעיל: של מי הכתובת הזו?

כתובת IP היא כתובת הדואר של מחשב באינטרנט. כמו כתובות דואר, הן מחולקות בגושים גדולים. חמישה רשמים אזוריים אחראים לכך: RIPE NCC (אירופה והמזרח התיכון), ARIN (צפון אמריקה), APNIC (אסיה והאוקיינוס השקט), LACNIC (אמריקה הלטינית) ו-AFRINIC (אפריקה). הם מקצים את הגושים למפעילים, שמשכירים אותם ללקוחות שלהם.

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

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

$ whois 203.0.113.45
inetnum:        203.0.113.0 - 203.0.113.255
netname:        HOST-EXAMPLE-VPS
org-name:       Host Example SAS
country:        FR
abuse-mailbox:  abuse@host.example
origin:         AS64500

שלושה פרטים חשובים: מי (שם הארגון), איפה (המדינה, שימושי כדי לדעת אילו חוקים חלים) ובעיקר כתובת ה-abuse, התיבה הרשמית שמקבלת דיווחים על שימוש לרעה. השם ההפוך של ה-IP, כאן vps-4411.host.example, נותן לעיתים קרובות עוד רמז: „vps” מעיד על שרת וירטואלי שכור.

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

הולכים בעקבות הרמזים האחרים: השולח, הקישור, ה-DNS

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

הרמז של השולח

מסתכלים על הדומיינים שמופיעים ב-From‏, Return-Path ו-Reply-To:

• שירות דואר חינמי (כמו Gmail או Outlook.com): הגורם הוא ספק השירות, שיכול לסגור את החשבון. זה שימושי במיוחד עבור Reply-To, התיבה שאליה נוחתות התשובות של הקורבנות;
• דומיין שנוצר במיוחד: מחפשים את רשם הדומיינים שלו, החברה שמכרה אותו, בעזרת חיפוש RDAP או WHOIS על הדומיין, למשל ב-lookup.icann.org. שם רואים גם את תאריך היצירה: דומיין „בנקאי” שנולד לפני שלושה ימים הוא סימן רע מאוד;
• הדומיין האמיתי של מותג שהתחזו אליו: המותג לא אשם, הוא לא שלח את ההודעה. אפשר להודיע לו אם יש לו כתובת לדיווח על פישינג.

הרמז של הקישור

הקישור שבהודעה מוביל לדף המלכודת, שחייב להיות מאוחסן איפשהו. לא לוחצים: מעתיקים את הכתובת (לחיצה ימנית, „העתק קישור”). השם שחשוב הוא הדומיין, ממש לפני ה-„/” הראשון שאחרי https://; כל מה שמשמאלו נבחר בחופשיות על ידי הנוכל. קישורים עוברים לעיתים קרובות כמה הפניות: Baitback עוקב אחריהן בשבילנו ומציג את השרשרת המלאה. על קישורים שמוסתרים בתוך תמונה, ראו את המדריך קווישינג: כשהפישינג מסתתר מאחורי קוד QR.

הרמז של ה-DNS

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

$ dig +short A  secure-login.example    # IP of the website (sometimes a CDN)
$ dig +short MX secure-login.example    # servers that receive its email
$ dig +short NS secure-login.example    # who runs its DNS

השאלה הראשונה נותנת את ה-IP של האתר (לפעמים זה CDN), השנייה את השרתים שמקבלים את הדואר שלו, והשלישית את מי שמנהל את ה-DNS שלו. אחר כך ה-IP של האתר עובר את אותו תהליך כמו IP השליחה: WHOIS‏, ASN, מפעיל, כתובת abuse. ודומיין בלי שום שרת דואר שטוען שהוא כותב לנו שווה בדיקה: ראו רשומת MX ב־DNS: סימן לאמינות?

למה תמיד יש כמה ספקים

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

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

IP הוא לא אשם

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

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

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

דומיין או שרת: השלט והבניין

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

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

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

המקרה של CDN

אם ה-WHOIS של ה-IP של האתר מחזיר שם כמו Cloudflare‏, Akamai או Fastly, זה כמעט אף פעם לא ספק האחסון: זו הקבלה. ה-CDN מקבל דיווחים, יכול להציג למבקרים דף אזהרה, ומעביר את התלונה לספק האחסון האמיתי, שאת כתובתו הוא מכיר. ל-Cloudflare, למשל, יש טופס ייעודי ב-abuse.cloudflare.com. מדווחים גם לרשם הדומיין, שה-CDN לא מסתיר.

המקרה של שרת פרוץ

כתובת כמו https://cohen-bakery.example/wp-content/uploads/x/login.php מסגירה לעיתים קרובות אתר פרוץ. הדומיין קיים כבר שנים ושייך לעסק אמיתי; דף המלכודת הוחדר לפינה נסתרת. כאן, לבקש את השעיית הדומיין יהיה לא הוגן וגם לא יעיל: מודיעים לספק האחסון, ולבעל האתר אם מוצאים דרך ליצור איתו קשר, עם הכתובת המדויקת של הדף. אותו היגיון עבור הודעה שנשלחה מתיבה אמיתית שנפרצה: מודיעים לספק, שיכול לחסום את החשבון ולהחזיר אותו לבעליו.

למי פונים בכל מצב

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

בונים את שרשרת הדיווח

לדווח על הכול בבת אחת, לכולם, לא עובד טוב. עדיף להתקדם לפי סדר, מהדחוף ביותר ועד לטווח הארוך:

1. לעצור את הנזק: דף המלכודת (ספק האחסון או ה-CDN) ורשימות החסימה של הדפדפנים. כל שעה חשובה: קמפיין גורם לרוב הקורבנות שלו בשעות הראשונות.
2. לנתק את השם: רשם הדומיין, כדי שהקישורים שכבר נשלחו יהיו חסרי תועלת.
3. לנתק את השליחה: ספק האחסון של IP השליחה, והספק של תיבת ה-Reply-To.
4. להשאיר תיעוד: הפלטפורמות הרשמיות, בשביל החקירות.

דיווח טוב הוא קצר וניתן לאימות. הוא כולל:

• את הכותרות המלאות של ההודעה, לא רק צילום מסך;
• את הפריט המדויק שנוגע לנמען הזה: ה-IP לספק האחסון, הדומיין לרשם, הכתובת המדויקת של הדף לספק האחסון של האתר;
• את התאריך והשעה, עם אזור הזמן;
• קישורים מנוטרלים, שנכתבו למשל hxxps://secure-login[.]example, כדי שאף אחד לא ילחץ בטעות.

זו בדיוק העבודה ש-Baitback עושה: מדביקים את מקור ההודעה, והכלי קורא את שורות ה-Received, מוצא את שרת השליחה, את ספק האחסון שלו ואת כתובת הדיווח, בודק SPF‏, DKIM ו-DMARC, עוקב אחרי הקישורים וההפניות שלהם, ומכין הודעות דיווח מוכנות לשליחה. החקירה של המדריך הזה, בכמה שניות.