APWG ספרה 971,181 מתקפות פישינג רק ברבעון הראשון של 2026 — עלייה של 13.8% לעומת הרבעון הקודם. ובינואר 2026, Google שיבשה מה שכינתה אחת מרשתות ה־proxy הביתיות הגדולות בעולם לאחר שמצאה שבמהלך שבוע אחד יותר מ־550 קבוצות איום ניתבו דרכה תעבורה. מסתבר שפרוקסי נמצאים בשני הצדדים של מאבק הפישינג.
זה בדיוק המתח שרוב המאמרים על "פרוקסי ופישינג" מתעלמים ממנו. הם או אומרים לכם שפרוקסי הם מגן (תקנו את מוצר הפרוקסי שלנו, ותישארו בטוחים) או מזהירים שפרוקסי הם נשק של תוקפים (תפחדו). בפועל, המציאות מורכבת ומעניינת הרבה יותר.
תוקפים משתמשים בתשתיות פרוקסי כדי להסתיר את המקור שלהם, להחליף כתובות IP שנראות אמינות, ולגנוב סשנים מאומתים — אפילו אחרי MFA. מגינים משתמשים בפרוקסי כדי לבדוק קישורים חשודים בבטחה, לראות איך דפי פישינג נראים במדינות שונות, ולסנן תעבורה זדונית לפני שהיא מגיעה לאתרים שלהם. המדריך הזה סוקר את שני הצדדים, ואז מראה תהליך עבודה קונקרטי שאפשר ליישם בפועל. בלי סיסמאות ריקות, בלי פתרונות קסם.
- רמת קושי: בינונית
- זמן נדרש: כ־25 דקות לקריאה ולתכנון; היישום משתנה לפי השלב
- מה תצטרכו: הבנה בסיסית של תשתית האינטרנט בארגון, גישה להגדרות ה־DNS של הדומיין שלכם, דפדפן Chrome (לשלבים עם Thunderbit), ובאופן אופציונלי גם חשבון אצל ספק פרוקסי
מהו פישינג ולמה העסק שלכם צריך להקדיש לזה תשומת לב?
פישינג הוא מתקפת הונאה. פושעים משתמשים במיילים, הודעות טקסט, דפי התחברות מזויפים, קודי QR או אתרים מתחזים כדי לגרום לאנשים למסור פרטי גישה, לאשר כניסה, להתקין תוכנה זדונית או להעביר כסף.
כבר לא מדובר רק ב"מייל גרוע". פישינג מודרני כולל דפים שמתארחים בענן, זרימות כניסה מזויפות של Microsoft 365, קודי QR וגניבת טוקנים של סשן.
לעסקים, ההשלכות מאוד מוחשיות. דו״ח 2025 של IBM על עלות פרצת נתונים מציב את עלות הפריצה הממוצעת הגלובלית על 4.4 מיליון דולר. דו״ח פשעי האינטרנט 2025 של ה־FBI מציין כי IC3 קיבל בערך 453,000 תלונות על הונאות מבוססות־סייבר, עם נזקים מדווחים של יותר מ־17.7 מיליארד דולר, כאשר הונאת דוא״ל עסקי (BEC) אחראית ליותר מ־3 מיליארד דולר מתוכם.
גניבת אישורים, הונאות העברה בנקאית, פגיעה בשרשרת אספקה, קנסות רגולטוריים — פישינג נוגע בכל אלה.
בהמשך נבחן איך פרוקסי משתלבים גם בצד ההתקפי וגם בצד ההגנתי, ואיך נראית באמת הגנה שכבתית וכנה.
האופי הכפול של פרוקסי: גם מגן וגם נשק
פרוקסי הוא מתווך בין המכשיר שלכם לאינטרנט. במקום שאתר יראה את כתובת ה־IP האמיתית שלכם, הוא רואה את הכתובת של הפרוקסי. אפשר לחשוב על זה כמו שירות העברת דואר: הנמען מקבל את המכתב מכתובת ההעברה, לא מהבית שלכם.
אותה תכונה יוצרת את בעיית השימוש הכפול. צוותי אבטחה משתמשים בפרוקסי כדי לחקור איומים בלי לחשוף כתובת IP ארגונית או תחנת עבודה של אנליסט. תוקפים משתמשים באותה טכנולוגיה בדיוק כדי לגרום לתעבורה זדונית להיראות כאילו היא מגיעה ממשתמשים רגילים, ממדינות שונות או מרשתות ביתיות מהימנות. הניתוח של Barracuda מאפריל 2026 מסביר זאת בפשטות: כתובות IP ביתיות נראות אותנטיות כי הן קשורות לחיבורי אינטרנט אמיתיים של בית או עסק קטן, ולכן מערכות הונאה נוטות פחות לסמן אותן.
רוב המאמרים המתחרים מכסים רק צד אחד. התוצאה היא תמונה חלקית — וגם הגנות חלקיות.
איך תוקפים משתמשים בפרוקסי נגדכם
שלושה וקטורי תקיפה עיקריים חשובים במיוחד למגיני ארגונים: אנונימיות והחלפת IP, ניצול לרעה של פרוקסי ביתי, והתחמקות מפלטפורמות מהימנות.
הסבר על פישינג AiTM (Adversary-in-the-Middle)
AiTM הוא סוג המתקפה שמפרק את ההנחה ש"MFA מגן עלינו" (ספוילר: MFA מסורתי לא שורד את זה).
במתקפת AiTM, התוקף מציב reverse proxy בין הקורבן לבין דף התחברות לגיטימי — למשל Microsoft 365. המשתמש רואה מה שנראה כמו תהליך כניסה אמיתי. הוא מזין פרטי גישה, משלים MFA, וספק הזהות האמיתי מנפיק cookie של סשן. אבל מאחר שכל התעבורה עוברת דרך הפרוקסי של התוקף, התוקף לוכד את ה־cookie הזה. עכשיו הוא יכול לשחזר אותו ולהיכנס לחשבון — בלי סיסמה ובלי בקשת MFA.
הניתוח של Microsoft על Tycoon2FA, אחד מערכות הפישינג AiTM המובילות, מראה שמפעילים יכולים להתחזות לדפי ההתחברות של Microsoft 365, Outlook, SharePoint, OneDrive ו־Google. הערכה מייצרת קובצי PDF וקודי QR, מנהלת שרשראות הפניה, ועוקבת אחרי שימוש ב־MFA ולכידת cookies של סשן. התשתית שלה משתמשת בתתי־דומיינים קצרי חיים ובתשתית שמאוחסנת ב־Cloudflare כדי להקשות על רשימות חסימה.
שום דבר מזה אינו תיאורטי. ערכות AiTM מנוצלות כיום בקנה מידה רחב, וזו הסיבה מספר אחת לכך ש"יש לנו MFA" הוא לא תשובה מלאה לפישינג.
ניצול לרעה של פרוקסי ביתי והחלפת IP
רשתות פרוקסי ביתיות מנתבות את תעבורת התוקף דרך כתובות IP אמיתיות של בתים, כך שבקשות פישינג נראות לגיטימיות יותר ועוקפות זיהוי הונאה מבוסס IP. ספקים רבים לא בודקים בקפדנות איך ה־IP שלהם משמש, וכך נוצר שוק אפור.
הדוגמה המוחשית ביותר: בינואר 2026, Google Threat Intelligence Group שיבשה את רשת הפרוקסי הביתית IPIDEA והקטינה את מאגר המכשירים הזמין שלה במיליונים. GTIG זיהתה יותר מ־550 קבוצות איום שונות שהשתמשו בנקודות יציאה של IPIDEA בתוך פרק זמן של שבעה ימים. החקירה מצאה חפיפה עם botnets, ניצול לרעה של גישה ל־SaaS, מתקפות password spray ושחקני ריגול גלובליים. פריסות רבות של SDK לפרוקסי לא כללו הסכמה ברורה של המשתמשים.
ההתראה של ה־FBI על פרוקסי ביתיים מ־2026 מונה שימושים פליליים כמו פישינג, התחברות עם אישורים גנובים, מתקפות brute force, השתלטות על חשבונות, ספאם והסוואת C2.
אירוח על גבי פלטפורמות מהימנות והתחמקות מערכות פישינג
טקטיקת התחמקות נוספת: אירוח דפי פישינג על פלטפורמות מהימנות — SharePoint, Google Docs, Azure Blob Storage — כדי לרכב על המוניטין של הדומיין. הניתוח של Microsoft על איומים ב־Azure Blob Storage מראה שתוקפים משתמשים בו כדי לארח דפי כניסה מזויפים של Microsoft, מה שמקשה על קורבנות לזהות אותם כזדוניים רק לפי תעודות.
גם ערכות פישינג כוללות לוגיקות התחמקות. הניתוח של Cofense לערכות פישינג מתעד סינון לפי גאולוקיישן, סינון לפי user-agent ושפה, CAPTCHA, זיהוי כלי מפתחים והפניות לדפים לגיטימיים. אם המבקר לא מתאים לפרופיל הקורבן המיועד — מדינה שגויה, דפדפן שגוי, או נראֶה כמו סורק אבטחה — הדף יציג עמוד תמים או שגיאת 404.
סריקה מ־IP ארגוני בודד או מ־datacenter בענן תפספס את הדפים האלה. הערכה עצמה בנויה להסתתר מכם.
איך מגינים משתמשים בפרוקסי כדי להילחם בחזרה
בצד ההגנתי, לפרוקסי יש ארבעה תפקידים מעשיים:
-
סריקת URL ודומיין בצורה אנונימית. ניתוב קישורים חשודים דרך פרוקסי מבוקר כך שהיעד יראה את כתובת ה־IP של הפרוקסי, ולא את המחשב של העובד או את הרשת הארגונית. זה מצמצם חשיפה ישירה ויוצר תהליך חקירה שחוזר על עצמו.
-
איסוף מודיעין איומים. שימוש בפרוקסי מתחלף כדי לסרוק תשתיות פישינג, רשימות דומיינים, פידיים ציבוריים של איומים או מקורות לדומיינים שנרשמו לאחרונה — בלי להיחסם אחרי מספר קטן של בקשות. (תמיד בכפוף לחוק ולתנאי השימוש.)
-
זיהוי פישינג מבוזר גאוגרפית. שימוש בפרוקסי בכמה אזורים כדי לראות אם URL חשוד מתנהג אחרת מארה״ב, אירופה, APAC או שוק יעד אחר. כך אפשר לתפוס ערכות שמפעילות geofencing או סינון לפי user-agent — אותן טכניקות התחמקות שתוארו למעלה.
-
פריסת reverse proxy / WAF. reverse proxy יושב מול הדומיינים שלכם. הוא לא מונע מעובדים ללחוץ על קישורי פישינג יוצאים, אבל הוא מגן על נכסי האינטרנט שלכם מפני תעבורת בוטים, credential stuffing, מטענים זדוניים ותבניות תעבורה מנצלות.
למה MFA לבדו נכשל מול פישינג מבוסס פרוקסי
ראיתי את הדיון הזה חוזר על עצמו בעשרות פורומים של IT: "יש לנו MFA, אז אנחנו מכוסים." למנהלי המערכות שכבר התמודדו עם אירוע AiTM יש גישה שונה מאוד.
המנגנון פשוט יחסית. הקורבן משלים MFA על מה שנראה כמו זרימת התחברות אמיתית. ספק הזהות האמיתי מנפיק טוקן של סשן. התוקף לוכד את הטוקן הזה דרך ה־reverse proxy שלו.
האימות הצליח — אבל עכשיו התוקף שולט בסשן. איפוס סיסמה לבדו אולי לא יספיק אם סשנים פעילים ושינויים ב־MFA שבוצעו על ידי התוקף עדיין קיימים. Microsoft מציינת במפורש שארגונים שנפגעו צריכים לבטל session cookies ולהחזיר לאחור שינויים ב־MFA שבוצעו על ידי התוקף, מעבר לטיפול הרגיל.
קודי SMS, אפליקציות OTP, אישורי push — כולם יכולים להיגנב בפישינג אם המשתמש משלים אותם בתוך זרימה שבשליטת התוקף. ה־MFA עשה את העבודה שלו. הבעיה היא שהתוקף צפה בכל רגע.
מה באמת עוצר פישינג AiTM
FIDO2 / Passkeys. FIDO Alliance מסבירה ש־passkeys הן עמידות לפישינג כברירת מחדל: אין סיסמאות לגנוב, ואין נתוני כניסה שאפשר לעשות בהם שימוש חוזר. זוג המפתחות הקריפטוגרפי קשור למקור של הדומיין הלגיטימי, כך שהפרוקסי של התוקף פשוט לא יכול לשחזר את האתגר. CISA מאשרת ש־FIDO ו־PKI הן שיטות ה־MFA הלא־קנייניות הנפוצות היחידות שמונעות גניבת אישורים דרך פישינג.
אימות מבוסס תעודות. מתאים לארגונים, מורכב יותר להטמעה, אבל גם הוא עמיד מאוד לפישינג כי הוא נשען על תעודות מכשיר ולא על קודים שהמשתמש מזין.
מדיניות Conditional Access. בסביבות Microsoft, Conditional Access יכולה לדרוש מכשירים תואמים, מיקומים מהימנים, בדיקות מבוססות סיכון, או רמת אימות עמידה לפישינג — וכך להקטין את הערך של טוקן סשן גנוב, גם אם התוקף השיג אותו.
כל אלה משלימים פרוקסי, לא מחליפים אותם. המטרה היא שכבות.
אפשרויות פרקטיות ל־SMB עם תקציב מוגבל
ההתנגדות הברורה: "Intune, MDM, מפתחות חומרה — זה תקציב של אנטרפרייז." הוגן. הנה המסלול החסכוני:
- Passkeys מבוססי דפדפן. רוב הדפדפנים המודרניים תומכים ב־passkeys באופן מובנה. אין צורך ברכישת חומרה. התחילו עם חשבונות ניהול, כספים ומשאבי אנוש.
- הטמעת DMARC בחינם. רשומות SPF, DKIM ו־DMARC אפשר לפרסם ללא עלות. ל־Google Workspace ול־Microsoft 365 יש מדריכי הגדרה מובנים.
- רישום דומיינים הגנתיים. רשמו שגיאות כתיב נפוצות ודומיינים דומים מאוד למותג שלכם. רוב הרשמים גובים 10–15 דולר לשנה לדומיין. הגדירו לכל אחד מדיניות DMARC מסוג reject.
- הדרכה ממוקדת. התמקדו במודעות עובדים במיוחד בניסיונות AiTM: דפי כניסה מזויפים ל־Microsoft 365, שיתופי מסמכים מזויפים, קודי QR, הונאות קוד מכשיר, ותהליכי "שכר/ספק דחופים".
תחשבו על זה כעל "מתחילים כאן, משדרגים אחר כך". גם אימוץ חלקי מפחית את הסיכון באופן משמעותי.
איזה סוג פרוקסי הכי טוב כדי להימנע מפישינג?
סוגי פרוקסי שונים משרתים מטרות אנטי־פישינג שונות, ובחירה לא נכונה מבזבזת כסף או יוצרת אזורי עיוורון.
| סוג פרוקסי | השימוש האנטי-פישינג הטוב ביותר | יתרונות | חסרונות | רמת עלות |
|---|---|---|---|---|
| Datacenter | סריקת URL בהיקף גדול, ניטור דומיינים | מהיר, זול, נפח גבוה | ניתן לזיהוי בקלות על ידי ערכות פישינג מתוחכמות | נמוכה |
| Residential | זיהוי פישינג ממוקד־אזורית, בדיקה מנקודת מבט של משתמש | נראה כמו תעבורת משתמש אמיתית, עוקף חסימות גיאוגרפיות | איטי יותר, יקר יותר, ויש חששות אתיים משמעותיים לגבי מקור | גבוהה |
| Rotating | איסוף מודיעין איומים, ניטור מתמשך | מונע חסימת IP במהלך סשנים ארוכים של סריקה | הגדרה מורכבת יותר, השהיה משתנה | בינונית |
| Reverse Proxy / WAF | הגנה על הנכסים האינטרנטיים שלכם | מסנן איומים נכנסים, זיהוי בוטים, הגנה מפני DDoS | לא מסייע בזיהוי פישינג יוצא | בינונית |
הערה על מקורות אתיים. המקרה של Google/IPIDEA וגם ההתראה של ה־FBI מבהירים שרשתות פרוקסי ביתיות יכולות להיבנות ממכשירים שנפגעו, SDKs מטעהים, תנאי VPN מוסתרים או תוכנה זדונית. לפני שקונים תעבורת פרוקסי ביתית, דרשו מהספק שקיפות מלאה לגבי הסכמת משתמשים, מנגנוני opt-out, יכולת ביקורת וטיפול בניצול לרעה. ספקים שזוהו בעבר במחקר אבטחה (כמו PacketStream, או 911 Proxy שכבר אינו פעיל) צריכים להיבחן בזהירות רבה במיוחד.
עבור רוב העסקים הקטנים והבינוניים, התחילו עם פרוקסי Datacenter לסריקה בהיקף גדול ועם reverse proxy/WAF לדומיינים שלכם. הוסיפו פרוקסי Residential רק אם אתם צריכים בדיקות ממוקדות־אזורית ויכולים לבדוק את הספק לעומק.
שלב אחר שלב: איך להימנע מפישינג בעזרת פרוקסי (תהליך עבודה מעשי)
רוב המאמרים נעצרים בתיאוריה. כל שלב כאן כולל המלצת כלי ורמת פירוט שאפשר להעביר לצוות ה־IT או לבצע לבד.
שלב 1: מעקב אחרי דומיינים דומים שנרשמו לאחרונה
תוקפים רושמים דומיינים שנראים כמו שלכם לפני שהם מתחילים קמפיינים: thunderb1t.com, thunderbit-login.com, thunderbit-support.net.
איתור מוקדם שלהם הוא אחת הפעולות ההגנתיות בעלות הערך הגבוה ביותר.
איך עושים את זה:
- בנו רשימת מעקב של מונחי המותג, שמות המוצרים, שמות המנהלים ומילים שקשורות להתחברות (למשל "login", "portal", "invoice", "payment").
- שאבו מדי יום את נתוני Certificate Transparency (CT) באמצעות crt.sh, שמאפשר לחפש תעודות לפי דומיין או שם ארגון. יומני CT מחויבים לכלול תעודות שהונפקו עם אמון ציבורי, כך שתעודות חדשות לדומיינים מתחזים יופיעו שם.
- סמנו דומיינים עם מרחק עריכה קטן מהמותג שלכם, סיומות דומיין חשודות (.xyz, .top, .click), או מילות מפתח של כניסה/תשלום.
- רנדרו את הדפים המסומנים דרך פרוקסי או sandbox — לעולם לא דרך דפדפן של עובד.
איך Thunderbit נכנס לתמונה: ה־API של Thunderbit לחילוץ בכמות יכולה לעבד עד 100 כתובות URL חשודות בכל משימה, תוך שימוש ב־renderMode: "full" כדי לרנדר דפי פישינג עם הרבה JavaScript. אתם מגדירים JSON Schema לנתונים שתרצו לקבל חזרה — כותרת הדף, האם קיימת טופס התחברות, דומיין של פעולת הטופס, מנפיק ה־SSL, שרשרת ההפניות, וה־URL הסופי. המקבילה ב־CLI משתלבת היטב בניטור מבוסס cron:
thunderbit batch extract --file suspicious-urls.txt --schema phishing-signals.json --render-mode full
למשתמשים לא טכניים, גם תוסף Chrome של Thunderbit יכול לשמש לסריקה מהירה ובחינה של דפים חשודים בכמה קליקים — שימושי כשצריך רק לעבור בעין על כמה כתובות URL ולא להפעיל תהליך מתוזמן.
תוצאה צפויה: דוח יומי או שבועי של דומיינים דומים חדשים שנרשמו, עם מטא־דאטה מובנה שמוכן לטיפול.
נסו את Thunderbit לבדיקת כתובות URL חשודות
שלב 2: נתבו קישורים חשודים דרך פרוקסי Datacenter
לפני שמישהו בארגון לוחץ על קישור חשוד, נתחו אותו דרך נתיב מבוקר. כתובת ה־IP של הפרוקסי תיחשף, לא המכשיר של העובד ולא הרשת הארגונית.
איך עושים את זה:
- לבדיקות מהירות, השתמשו ב־urlscan.io (sandbox וובי שמאפשר לבחור מדינת סריקה) או ב־VirusTotal (סורק כתובות URL מול עשרות מוצרי אנטי־וירוס ורשימות חסימה).
- לסקריפטים פנימיים או ניתוח בנפח גבוה, נתבו בקשות דרך פרוקסי Datacenter:
curl -x http://proxy.example.com:8080 -I "https://suspicious.example"
- עבור דפי פישינג חיים, השתמשו ב־VM חד־פעמי או ב־browser sandbox. כבו הזנת פרטי גישה. תעדו את שרשרת ההפניות, כותרת הדף, היעד הסופי, שליחת הטפסים, סקריפטים וצילומי מסך.
- לעולם אל תשלחו אישורים אמיתיים של הארגון. וגם סריקות ציבוריות דורשות זהירות — חלק מהשירותים חושפים כתובות URL שהוגשו אליהם אלא אם מגדירים אותן כפרטיות או לא־רשומות.
תוצאה צפויה: הערכה בטוחה של היעד, ההתנהגות והסימנים של הקישור — בלי חשיפה ארגונית.
שלב 3: השתמשו בפרוקסי מבוזרים גאוגרפית כדי לתפוס קמפיינים ממוקדים
חלק מערכות הפישינג מציגות תוכן זדוני רק למבקרים ממדינה או שפה מסוימת. Cofense מתעדת שסינון גאוגרפי נפוץ מאוד: מבקרים מהאזור ה"לא נכון" רואים עמוד תמים או 404, בעוד קהל היעד מקבל את טופס איסוף האישורים.
איך עושים את זה:
- בדקו קישורים חשודים מהאזורים שבהם העובדים, הלקוחות וצוותי הכספים שלכם באמת פועלים. אם החברה שלכם מבוססת בארה״ב ויש לה משרד בבריטניה, בדקו משני האזורים.
- השוו כתובות URL סופיות, צילומי מסך, כותרות דפים, טפסים וקודי תגובת HTTP לפי אזור.
- החליפו user-agent והגדרות שפה כשאתם חוקרים קודי QR או הונאות שמכוונות למובייל — יש ערכות שמסננות גם לפיהם.
- הסלימו כתובות URL שמציגות תוכן תמים במקום אחד אבל טפסי התחברות במקום אחר. זה סימן חזק לפישינג.
תוצאה צפויה: זיהוי קמפיינים ממוקדים גאוגרפית, שהיו נעלמים מסריקה ממיקום יחיד.
שלב 4: פרסו Reverse Proxy או WAF עבור הדומיינים שלכם
עכשיו עוברים מזיהוי תעבורה יוצאת להגנה על תעבורה נכנסת. Reverse proxy ו־WAF יושבים מול נכסי האינטרנט שלכם ובודקים את התעבורה הנכנסת לפני שהיא מגיעה לשרתים.
איך עושים את זה:
- כוונו את ה־DNS של הדומיין שלכם לספק reverse proxy. Cloudflare היא האפשרות הנגישה ביותר ל־SMB — DNS, CDN, WAF וכללי אבטחה נמצאים בממשק אחד. עבור אפליקציות שמתארחות ב־AWS, AWS WAF עובד היטב אם אתם כבר משתמשים ב־CloudFront, ב־ALB או ב־API Gateway.
- הפעילו כללי WAF מנוהלים. הם חוסמים כתובות IP זדוניות ידועות, מסננים תעבורת בוטים ומזהים דפוסי credential stuffing.
- הפעילו מגבלות קצב עבור התחברות, איפוס סיסמה וטפסי יצירת קשר.
- הוסיפו כללי bot או challenge לנקודות קצה בסיכון גבוה.
- עקבו אחר אירועי WAF מדי שבוע — אל תגדירו ושכחו.
תוצאה צפויה: תעבורה זדונית נכנסת מסוננת לפני שהיא מגיעה לשרתים שלכם. ניסיונות credential stuffing על דפי ההתחברות שלכם נחסמים או מקבלים challenge.
שלב 5: אוטומציה ותזמון של ניטור מתמשך
פישינג הוא לא ביקורת חד־פעמית. דומיינים חדשים, ערכות חדשות ותשתיות חדשות מופיעים מדי יום — לכן הניטור חייב לעבוד בקצב קבוע:
- מדי יום: סריקת CT לדומיינים דומים ותור דומיינים חשודים.
- מדי יום או לפי שעה (למותגים בסיכון גבוה): בדיקות sandbox ל־URL עבור דומיינים שהתגלו לאחרונה.
- מדי שבוע: סקירת דוחות DMARC מצטברים ודפוסי התחזות.
- מדי שבוע: סקירת אירועי WAF עבור credential stuffing וקפיצות בבוטים.
- מדי חודש: בדיקת ההתקדמות בהטמעת MFA עמיד לפישינג.
- מדי רבעון: בדיקת תהליכי כספים ומשאבי אנוש מול תרחישי AiTM ו־BEC ריאליסטיים.
איך Thunderbit משתלב: תהליכי scraping מתוזמנים ו־CLI/API של Thunderbit יכולים לתמוך בניטור חוזר עבור צוותי תפעול לא טכניים. השימוש הכי טוב הוא לא "Thunderbit מונע פישינג לבד" — אלא "Thunderbit עוזר לצוותי תפעול לאסוף אותות מובנים מדפים חשודים וממקורות ניטור דומיינים בלי לפתח scraper מותאם מאפס". אפשר להזרים את התוצאות ל־Google Sheets או Airtable לצורך נראות צוותית, או ל־Slack דרך אינטגרציה פשוטה.
תוצאה צפויה: לולאת ניטור רציפה שמאתרת איומים חדשים בתוך שעות, לא שבועות.
מה פרוקסי לא יכולים לתפוס: אבטחת אימייל עם DMARC, SPF ו־DKIM
ספקי פרוקסי לא תמיד יגידו לכם את זה: פרוקסי הם רק שכבת הגנה אחת, אבל פישינג שמגיע במייל ולא עובר בכלל דרך שכבת פרוקסי דורש הגנה נפרדת.
הרבה מתקפות פישינג מגיעות מכתובות דוא״ל מתחזות. פרוקסי לא יירט אותן.
הגדרת SPF עם Hard Fail
SPF (Sender Policy Framework) הוא רשומת DNS שמפרטת אילו כתובות IP מורשות לשלוח מייל בשם הדומיין שלכם. הגדירו -all (hard fail) ולא ~all (soft fail) כדי לדחות מיד שולחים לא מורשים.
טעות נפוצה: לשכוח לכלול את כל שירותי השליחה הלגיטימיים — ה־CRM, פלטפורמת השיווק, ספק המיילים הטרנזקציונליים, וה־helpdesk. עברו על כל מקורות השליחה לפני פרסום הרשומה.
הטמעת חתימת DKIM
DKIM (DomainKeys Identified Mail) מוסיף חתימה קריפטוגרפית למיילים היוצאים. הנמען בודק שההודעה לא שונתה בדרך. גם ל־Google Workspace וגם ל־Microsoft 365 יש מדריכי הגדרה מובנים של DKIM. זה לוקח בערך 15 דקות.
אכיפת DMARC עד דחייה
DMARC (Domain-based Message Authentication, Reporting & Conformance) אומר לשרתי הקבלה מה לעשות כשבדיקות SPF או DKIM נכשלות. הצעד הקריטי שרוב הארגונים מדלגים עליו: לעבור מ־p=none (ניטור בלבד) ל־p=reject (חסימת הודעות כושלות) אחרי שמוודאים שזרימות המייל הלגיטימיות תקינות.
הרבה ארגונים משאירים את DMARC על p=none לנצח — נראות בלי הגנה. זה כמו להתקין מצלמת אבטחה אבל אף פעם לא לנעול את הדלת.
רישום הגנתי של דומיינים דומים
רשמו מראש שגיאות כתיב נפוצות ודומיינים דומים מאוד למותג שלכם. הגדירו עליהם מדיניות DMARC מסוג reject כדי שלא יוכלו לשמש למייל מתחזה. בעלות של 10–15 דולר לשנה לדומיין, זו אחת הפעולות הזולות והמשפיעות ביותר — ורוב העסקים הקטנים בכלל לא חושבים עליה.
חיבור כל החלקים: הגנה שכבתית נגד פישינג
אין כלי אחד שעוצר פישינג. השילוב הוא מה שמחזיק את ההגנה. צ'ק־ליסט מעשי:
יוצא (חקירת איומים):
- סריקת URL מבוססת פרוקסי לקישורים חשודים
- ניטור דומיינים דרך יומני CT ו־batch extraction
- בדיקות מבוזרות גאוגרפית לקמפיינים ממוקדי־אזור
נכנס (הגנה על הנכסים שלכם):
- Reverse proxy / WAF עבור דומייני האינטרנט שלכם
- DMARC/SPF/DKIM לאימות מיילים
- רישום הגנתי של דומיינים דומים
אימות (הגנה על חשבונות):
- FIDO2 / passkeys ל־MFA עמיד לפישינג
- מדיניות Conditional Access (מכשירים תואמים, בדיקות מבוססות סיכון)
- תהליכים לניטור ולביטול של טוקני סשן
אנשים (קו ההגנה האחרון):
- הדרכה שמתמקדת במיוחד בניסיונות AiTM, בקודי QR ובתרחישי BEC
- תרבות דיווח ברורה — להפוך דיווח על הודעות חשודות לפשוט ולא מעניש
- בדיקות קבועות של תהליכי כספים ומשאבי אנוש מול תרחישי פישינג ריאליסטיים
הגישה הזו מתיישבת עם עקרון ההגנה בשכבות של NIST Cybersecurity Framework: כמה שכבות בלתי תלויות, כך שכשל בשכבה אחת לא אומר פגיעה כוללת.
לצוותים שצריכים לחקור כתובות URL חשודות, לאסוף נתוני איומים או לנטר דומיינים בקנה מידה גדול, ה־AI web scraper של Thunderbit יכול להאיץ את התהליך — תוסף Chrome למשתמשים לא טכניים, ו־API/CLI לצוותים טכניים. זה לא מוצר אבטחה בפני עצמו, אבל הוא בהחלט ראוי למקום בארגז הכלים של אנליסטים. אפשר ללמוד עוד על web scraping בלי קוד או לחקור גישות של AI web scraping בבלוג שלנו.
השתמשו ב־AI web scraping לניטור איומים Get Started Free
שאלות נפוצות
איך תוקפים משתמשים בפרוקסי במתקפות פישינג?
תוקפים משתמשים בפרוקסי Residential ו־Rotating כדי להסתיר את ה־IP האמיתי שלהם, להחליף כתובות מהימנות, לעקוף זיהוי הונאה מבוסס IP, ולפרוס reverse proxy מסוג AiTM שמיירט סשנים מאומתים — גם אחרי שהקורבן השלים MFA. השיבוש של IPIDEA בינואר 2026 הראה יותר מ־550 קבוצות איום שהשתמשו ברשת פרוקסי ביתית אחת.
איך reverse proxy מונע פישינג ופריצה לאתר?
reverse proxy יושב מול שרתי האינטרנט שלכם ובודק תעבורה נכנסת לפני שהיא מגיעה לתשתית. הוא חוסם כתובות IP זדוניות ידועות, מסנן תעבורת בוטים, מגביל קצב ניסיונות התחברות ומזהה credential stuffing או פעילות שקשורה לפישינג. עם זאת, הוא לא מגן על עובדים שלוחצים על קישורי פישינג יוצאים.
האם פרוקסי יכולים למנוע פישינג לחלוטין?
לא. פרוקסי הם שכבת הגנה קריטית אחת, אבל פישינג שמגיע במייל דורש DMARC/SPF/DKIM, וחטיפת סשן באמצעות AiTM דורשת MFA עמיד לפישינג כמו FIDO2/passkeys. הגנה שכבתית שמשלבת פרוקסי, אימות מייל, אישורים עמידים לפישינג והדרכת עובדים היא חיונית.
מהו פישינג AiTM ולמה MFA לא עוצר אותו?
פישינג AiTM (Adversary-in-the-Middle) משתמש ב־reverse proxy בין הקורבן לבין דף ההתחברות האמיתי, ולוכד את טוקן הסשן אחרי סיום ה־MFA. MFA מסורתי לא עוצר את זה כי התוקף גונב את הסשן המאומת, לא את הסיסמה. FIDO2/passkeys עמידים למתקפה הזו כי האתגר הקריפטוגרפי קשור לדומיין הלגיטימי ולא ניתן לשחזר אותו דרך הפרוקסי של התוקף.
איזה סוג פרוקסי הכי מתאים לזיהוי פישינג?
פרוקסי Datacenter הכי מתאימים לסריקת URL בהיקף גדול (מהיר וזול). פרוקסי Residential הכי מתאימים לבדיקה ממוקדת גאוגרפית (מציאותיים יותר אבל יקרים יותר — צריך לבדוק היטב את הספק מבחינת מקורות אתיים). Reverse proxy/WAF הם הטובים ביותר להגנה על האתרים שלכם. הגישה החזקה ביותר משלבת כמה סוגים בהתאם למה שמנסים לזהות או להגן עליו.
נסו את Thunderbit לניטור איומים ול־AI scraping Get Started Free
לקריאה נוספת
