יש מתקפות שנראות כמו פריצה. יש מתקפות שנראות כמו מייל חשוד. ויש מתקפות מסוכנות יותר, כי הן נראות כמו עזרה טכנית.
המשתמש רואה הודעת שגיאה. אולי בדיקת אנושיות. אולי מסמך שלא נטען. אולי חלון שטוען שהדפדפן קרס וצריך לבצע תיקון. הוא לא מוריד קובץ. הוא לא פותח קובץ מצורף חשוד. הוא רק מבצע הוראות שנראות מסודרות: ללחוץ, להעתיק, לפתוח חלון הפעלה, להדביק, ולאשר.
באותו רגע, הוא לא מתקן את המחשב. הוא מריץ פקודה בשביל התוקף.
זה בדיוק הרעיון מאחורי ClickFix, אחת מטכניקות ההנדסה החברתית שהפכו בשנים האחרונות לאיום אמיתי על ארגונים. לפי Microsoft Threat Intelligence, השיטה מנצלת את הנטייה הטבעית של משתמשים לפתור בעיות טכניות קטנות, ומובילה אותם להריץ פקודות זדוניות דרך Windows Run, Windows Terminal או PowerShell. לפי MITRE ATT&CK, מדובר בתת טכניקה של ביצוע קוד באמצעות העתקה והדבקה זדונית.
הטעות הראשונה: לחשוב שזה עוד סוג של פישינג
ClickFix מתחיל לפעמים כמו פישינג, אבל הוא לא נעצר שם. במתקפת פישינג קלאסית, התוקף מנסה לגנוב סיסמה או לגרום למשתמש לפתוח קובץ. כאן המטרה חדה יותר: לגרום למשתמש להריץ בעצמו את הפקודה שמכניסה את התוקף פנימה.
זו הסיבה שהשיטה כל כך מתסכלת מבחינת אבטחת מידע. מערכת הדואר יכולה לא לזהות קובץ זדוני, כי אין קובץ. הדפדפן יכול לא לחסום הורדה, כי המשתמש הוא זה שיוזם את הפעולה. כלי אבטחה מסורתיים יכולים לראות פעולה לגיטימית לכאורה, כי PowerShell או Windows Terminal הם כלים תקינים במערכת ההפעלה.
התוקף לא שובר את הדלת. הוא משכנע את העובד לפתוח אותה מבפנים.
במאמר שלנו על אבטחת דפדפן כתבנו שהדפדפן הפך לשטח העבודה המרכזי של הארגון. ClickFix מוכיח את זה בצורה חדה: התקיפה לא חייבת להתחיל בשרת, בענן או בעמדת קצה לא מעודכנת. לפעמים היא מתחילה בחלון דפדפן שמציג הוראות שנראות מועילות.
כך נראית מתקפת ClickFix בפועל
תרחיש נפוץ נראה כך:
- העובד מגיע לאתר שנפרץ, למודעה זדונית, לקישור ממייל, או לדף שנראה כמו שירות מוכר.
- העמוד מציג בעיה מדומה: מסמך שלא נטען, בדיקת CAPTCHA, תקלה בהצגת וידאו, או קריסה של הדפדפן.
- המשתמש מקבל הוראות שמתחזות לפתרון טכני פשוט.
- הפקודה הזדונית מועתקת ללוח העריכה או מוצגת למשתמש להעתקה.
- המשתמש מדביק את הפקודה בחלון הפעלה, במסוף או ב PowerShell.
- הפקודה מורידה רכיב נוסף, מפעילה כלי שליטה מרחוק, גונבת מידע, או פותחת ערוץ המשך לתוקף.
במחקר של Proofpoint תוארו קמפיינים שבהם ClickFix הוביל להפעלת נוזקות כמו Lumma Stealer, NetSupport, AsyncRAT ואחרות. Microsoft אף פרסמה ב 2026 וריאציה בשם CrashFix, שבה הדפדפן של הקורבן קורס בכוונה כדי ליצור תחושת דחיפות ולשכנע אותו להריץ פקודה תחת ההבטחה שהדבר ישיב את הדפדפן לפעילות תקינה. ראו את הניתוח של Microsoft על CrashFix.
זה חשוב כי התוקף כבר לא מסתפק בהודעה מפתה. הוא יוצר בעיה, ואז מוכר לקורבן את הפתרון.
למה עובדים נופלים בזה גם כשהם זהירים
הטעות הניהולית היא להאשים את המשתמש. זו תגובה נוחה, אבל היא לא מקצועית.
עובדים נופלים ב ClickFix לא מפני שהם חסרי אחריות, אלא מפני שהמתקפה בנויה על שלושה מנגנונים אנושיים חזקים:
- דחיפות: משהו לא עובד עכשיו, והמשתמש רוצה להמשיך במשימה.
- סמכות טכנית: ההוראות נראות כמו הודעת מערכת או תמיכה רשמית.
- תחושת שליטה: המשתמש מרגיש שהוא מבצע תיקון ידני, לא שהוא מותקף.
כאן בדיוק ההדרכה הרגילה נכשלת. להגיד לעובדים לא ללחוץ על קישורים חשודים כבר לא מספיק. ClickFix לא תמיד נראה כמו קישור חשוד. לפעמים הוא נראה כמו תהליך תיקון. לכן תכנית מודעות עובדים לסייבר חייבת לכלול תרחישים עדכניים של העתקת פקודות, הודעות CAPTCHA מזויפות, חלונות שגיאה מדומים, והנחיות שמבקשות לפתוח כלי מערכת.
עובד שלא יודע שעמוד אינטרנט לעולם לא אמור לבקש ממנו להריץ פקודה במחשב, נשאר חשוף. גם אם הוא כבר למד לזהות פישינג בסיסי.
הבעיה האמיתית: יותר מדי עובדים יכולים להריץ יותר מדי דברים
ClickFix מצליח כי בהרבה ארגונים אין גבול ברור בין משתמש רגיל לבין משתמש שמסוגל לבצע פעולות מסוכנות. אם כל עובד יכול לפתוח PowerShell, להריץ סקריפטים, להתקין הרחבות דפדפן, להוריד קבצי הרצה, ולעבוד ממחשב לא מנוהל, התוקף לא צריך הרשאות מנהל ביום הראשון. הוא צריך רק פעולה אחת שתיתן לו דריסת רגל.
מכאן ההגנה צריכה להתחיל בשאלה לא נעימה: למה הפעולה הזו בכלל אפשרית?
בארגון בוגר, לא כל משתמש צריך יכולת להריץ סקריפטים חופשיים. לא כל עובד צריך הרשאות התקנה. לא כל דפדפן צריך לאפשר הרחבות לא מפוקחות. לא כל מחשב אישי צריך לקבל גישה למערכות ענן רגישות.
זה מתחבר ישירות למה שכתבנו במאמר על הרשאות מנהל קבועות. הרשאות רחבות מדי הן לא נוחות תפעולית. הן חומר בעירה. ClickFix הוא הגפרור.
מה חייבים לחסום כבר עכשיו
אין פתרון קסם אחד ל ClickFix. אבל יש כמה חסימות שמקטינות משמעותית את הסיכון:
- הגבלת שימוש ב PowerShell ובכלי מסוף: משתמשים שאינם צריכים להריץ פקודות כחלק מתפקידם לא צריכים גישה חופשית להרצת סקריפטים.
- חסימת סקריפטים ממיקומים זמניים: יש לעקוב אחר הרצות מתיקיות כמו Downloads, Temp ותיקיות פרופיל משתמש.
- Application Control: להריץ רק מה שמותר, לא רק לחסום את מה שכבר ידוע כרע.
- ניהול הרחבות דפדפן: התקנת הרחבות צריכה להתבצע לפי רשימת אישור, לא לפי בחירת המשתמש.
- חסימת הורדות מסוכנות: במיוחד קבצי הרצה, סקריפטים, קבצי ארכיון חשודים וקבצים שמגיעים מאתרים לא מוכרים.
- הקשחת מכשירים לא מנוהלים: גישה למידע רגיש צריכה להיות מותנית במכשיר מנוהל, מעודכן ומוגן.
בצד הטכנולוגי, הגנה אקטיבית מכופר והגנה מתקדמת על עמדות קצה עוזרות לזהות התנהגות חריגה אחרי שהפקודה כבר רצה: יצירת תהליך חשוד, ניסיון הורדה, הפעלת כלי שליטה מרחוק, שינוי קבצים, או תנועה לא טבעית במערכת. אבל מי שמסתמך רק על זיהוי אחרי ההרצה, משחק מאוחר מדי. המטרה היא לצמצם את האפשרות להריץ מלכתחילה.
מה צריך לנטר כדי לתפוס את האירוע בזמן
ClickFix משאיר עקבות. השאלה היא האם מישהו מסתכל עליהן בזמן.
הסימנים המרכזיים שצריכים להדליק נורה אדומה:
- דפדפן שמוביל להפעלת PowerShell, Windows Terminal, CMD או כלי סקריפט אחר.
- פקודה שמכילה הורדת תוכן מהרשת והרצה מיידית.
- שימוש בקידוד או מחרוזות ארוכות שלא נראות כמו פעולה מנהלתית רגילה.
- הרצה מתיקיות זמניות או מפרופיל המשתמש.
- חיבור יוצא לכתובת לא מוכרת מיד אחרי פתיחת מסוף.
- יצירת תהליכים חריגים אחרי ביקור בדף אינטרנט או פתיחת קובץ HTML.
- התקנת כלי שליטה מרחוק ללא קריאת שירות מתועדת.
כאן נכנס הערך של SIEM/SOC. אירוע כזה לא תמיד נראה מסוכן כאשר מסתכלים על סימן אחד. דפדפן נפתח. אחר כך PowerShell. אחר כך חיבור יוצא. אחר כך תהליך חדש. כל אחד בנפרד עשוי להיראות אפור. יחד הם כבר סיפור.
ארגון בלי קורלציה רואה רעשים. ארגון עם ניטור נכון רואה שרשרת תקיפה.
הגנת דואר עדיין חשובה, אבל היא לא מספיקה
חלק מהקמפיינים מתחילים במייל, ולכן סינון דוא״ל עדיין חשוב מאוד. הוא יכול לחסום קישורים, דומיינים מתחזים, קבצי HTML חשודים, הודעות שמתחזות לעדכוני תוכנה, וניסיונות להוביל משתמשים לעמודי נחיתה זדוניים.
אבל ClickFix מלמד אותנו שאבטחת דואר אינה קו הסיום. גם אם המייל נקי יחסית, הקישור עשוי להוביל לאתר שנפרץ אחרי השליחה. גם אם אין קובץ מצורף, ההוראות עצמן מסוכנות. גם אם אין נוזקה בשלב הראשון, המשתמש עלול להריץ אותה בשלב השני.
לכן ההגנה חייבת להיות רב שכבתית: דואר, דפדפן, עמדת קצה, זהות, הרשאות, ניטור, והדרכה.
הצ׳קליסט הניהולי שלנו ל ClickFix
זה לא צ׳קליסט תאורטי. אלו שאלות שכל מנהל IT או מנהל אבטחת מידע צריך לדעת לענות עליהן:
- אילו משתמשים בארגון יכולים להריץ PowerShell או Windows Terminal?
- האם יש מדיניות שמגבילה הרצת סקריפטים לפי תפקיד?
- האם יש התרעה כאשר דפדפן מפעיל כלי מסוף?
- האם הרחבות דפדפן מנוהלות לפי רשימת אישור?
- האם המשתמשים עברו תרגול שמציג להם הודעת CAPTCHA מזויפת או תיקון מזויף?
- האם יש חסימה של הורדות והרצות מתיקיות זמניות?
- האם יש ניטור שמחבר בין דפדפן, תהליך, הורדה, חיבור רשת והתנהגות משתמש?
- האם יש תהליך תגובה שמבטל סשנים, בודק גניבת סיסמאות, ומבודד תחנה במהירות?
- האם יש גיבוי נקי וזמין במקרה שהאירוע מתפתח לכופרה?
- האם הארגון יודע להוכיח מה קרה, ולא רק לנחש?
אם רוב התשובות לא ברורות, הבעיה אינה ClickFix בלבד. הבעיה היא שהארגון לא שולט בשכבת הביצוע של המשתמשים.
איפה סקר סיכונים נכנס לתמונה
הרבה ארגונים מגלים את ClickFix רק אחרי אירוע. זו דרך יקרה ללמוד.
במקום לחכות, נכון לבצע סקר סיכונים שממפה הרשאות, תחנות קצה, מדיניות דפדפן, כלי הרצה, לוגים, תהליכי תגובה, והפער בין מה שהנהלים אומרים לבין מה שקורה בפועל. הפער הזה הוא המקום שבו ClickFix חי.
ב 010 אנחנו מסתכלים על סיכון כזה לא כעל ״בעיה של משתמשים״ אלא כעל כשל משולב: תהליך, הרשאות, מודעות, ניטור ותגובה. מי שמטפל רק באחד מהם, משאיר לתוקף נתיב חלופי.
השורה התחתונה
ClickFix מצליח כי הוא לא מבקש מהמשתמש לעשות משהו שנראה עברייני. הוא מבקש ממנו לעשות משהו שנראה מועיל.
וזו בדיוק הסכנה.
בעולם שבו העובד עובד דרך הדפדפן, מנהל קבצים בענן, מתקשר עם ספקים, מאשר כניסות ומריץ כלים מקומיים, ההגנה כבר לא יכולה להסתפק בסיסמאות, אנטי וירוס והדרכה שנתית. צריך שליטה בפועל: מה מותר להריץ, מי יכול להריץ, מאיפה, באיזה מכשיר, ובאיזה הקשר.
הפעולה המומלצת שלנו ברורה: לבדוק השבוע את היכולת של משתמש רגיל להריץ פקודות, להקשיח את מדיניות הדפדפן, להכניס את ClickFix לתרגולי מודעות, ולוודא שה SOC רואה את השרשרת המלאה מהדפדפן ועד התהליך החשוד.
כי במתקפה הזו, הקליק הוא לא הבעיה. האמון האוטומטי בפעולה שאחריו הוא הבעיה.
