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

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

איך אימות תמים הופך להרצת נוזקה

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

מאחורי כפתור ההעתקה מסתתרת פקודה. המשתמש אינו רואה בהכרח את כל הטקסט, משום שהוא מועתק ללוח ברקע ולעיתים מוסווה במחרוזת ארוכה. ההוראות מכוונות אותו לחלון ההרצה, ל-PowerShell, ל-Windows Terminal או למסוף של macOS. כאשר המשתמש מדביק ומפעיל את הפקודה, היא יכולה להוריד רכיבים נוספים ולהריץ קוד בזיכרון. בהמשך היא עשויה ליצור גישה קבועה ולחבר את המחשב לתשתית התוקף.

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

למה השיטה מצליחה לעקוף הגנות רגילות

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

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

הנתון שממחיש את השינוי מגיע מדוח ההגנה הדיגיטלית של מיקרוסופט ל-2025. מתוך ההתראות שטופלו בשירות Defender Experts, ClickFix הייתה שיטת הגישה הראשונית הנפוצה ביותר והופיעה ב-47 אחוז מהמקרים שנמדדו. זה אינו שיעור מכלל התקיפות בעולם. עם זאת, הוא מראה עד כמה השיטה הפכה מרכזית באירועים אמיתיים שנחקרו.

למה גם עובד קפדן עלול ליפול

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

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

מה השתנה ב-2026

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

TerminalFix: פקודה שמגיעה עד הרשת הפנימית

בסוף אוגוסט 2026 פרסמה מיקרוסופט מחקר על קמפיין TerminalFix. אתרים שנפרצו הציגו שכבת אימות מזויפת של Cloudflare והנחו את המשתמש להדביק פקודה ב-Terminal או ב-PowerShell. השרשרת שנחקרה לא הסתפקה בגנב מידע: היא השתמשה בטעינת DLL לצד קובץ חתום, הסתירה רכיבים בתוך תמונות, סרקה את סביבת Active Directory והקימה מנהרה הפוכה שאפשרה לתוקף להגיע לשירותים פנימיים דרך המחשב שנפגע.

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

ClickFix גם במחשבי Mac

הנחה נפוצה היא שהבעיה שייכת רק לחלון ההרצה של Windows. באוגוסט 2026 מיקרוסופט תיעדה קמפיין macOS שכלל יותר מ-250 דומיינים קדמיים. העמודים בדקו את מאפייני הדפדפן בצד השרת והציגו את הפיתיון בעיקר למבקרים שנראו כמו משתמשי Mac אמיתיים, בעוד שסורקים ומערכות בדיקה קיבלו עמוד תמים. המשתמשים הונחו להריץ פקודת Terminal שהובילה לגנבי מידע כמו MacSync ו-Atomic Stealer.

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

מה התוקפים מחפשים במחשב העסקי

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

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

גם כופרה נמצאת בקצה השרשרת. התרעה משותפת של CISA וה-FBI על Interlock תיארה שימוש ב-ClickFix להשגת גישה ראשונית. לכן אירוע שבו עובד "רק הדביק פקודה" דורש תגובה מלאה, גם אם המחשב נראה תקין דקות לאחר מכן.

חמשת הסימנים שכל עובד צריך להכיר

1. בדיקת אנושיות שממשיכה להוראות מערכת. CAPTCHA לגיטימי מסתיים בתוך הדפדפן. הוא אינו צריך חלון הרצה, Terminal או PowerShell.
2. אתר שמבקש להעתיק ולהדביק פקודה. אין סיבה שאתר רגיל יבקש מהמשתמש להריץ טקסט במערכת ההפעלה כדי לצפות בעמוד.
3. שימוש בקיצור מקשים כחלק מהאימות. הוראה לפתוח כלי מערכת, לעבור לסייר הקבצים או להדביק בשורת כתובת היא סימן עצירה.
4. הודעת תקלה שמייצרת לחץ. ניסוחים כמו "החיבור ייחסם", "ההורדה נכשלה" או "האימות פג" נועדו לגרום לפעולה לפני מחשבה.
5. הבטחה שהפקודה בטוחה כי היא נראית טכנית. טקסט ארוך, קידוד או מילים מוכרות כמו Cloudflare ו-Microsoft אינם הוכחה ללגיטימיות.

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

מה מנהל העסק צריך להגדיר מראש

הדרכה היא שכבה חשובה, אך אסור להשאיר את כל ההגנה על כתפי העובד. מיקרוסופט ממליצה להגביל את השימוש ב-PowerShell ובחלון ההרצה למשתמשים שאינם צריכים אותם, באמצעות AppLocker, Application Control או מדיניות קבוצתית. לפני חסימה גורפת צריך לבדוק אילו מערכות ניהול ותמיכה משתמשות בכלים האלה, כדי לא לשבור תהליך לגיטימי.

• ניהול הרשאות: להסיר הרשאות מנהל מקומיות מחשבונות עבודה רגילים ולהשתמש בחשבון נפרד לפעולות ניהול.
• הגנה התנהגותית: להפעיל הגנת ענן, ניטור נקודות קצה ויכולת בידוד מרחוק של מחשב חשוד.
• כללי צמצום משטח תקיפה: כללי ASR של Microsoft Defender נועדו לחסום התנהגויות כמו סקריפטים מוסווים והפעלה של תוכן שהורד. מתחילים במצב Audit, בודקים השפעה ורק אז עוברים לחסימה.
• סינון רשת: לחסום דומיינים מסוכנים ואתרים חדשים בעלי מוניטין נמוך, ולהפעיל הגנת רשת ודפדפן מנוהל.
• רישום וניטור: לתעד הרצת PowerShell וסקריפטים, כדי שאפשר יהיה לזהות פקודה מוסווית ולחקור מה קרה.
• ניהול זהויות: להפעיל אימות רב שלבי, מדיניות גישה מותנית ויכולת לנתק את כל ההתחברויות במקרה של גניבת אסימון.
• גיבוי והתאוששות: לשמור עותק מנותק או מוגן משינוי ולבדוק שחזור בפועל. ClickFix יכולה להיות הצעד הראשון בדרך לכופרה.

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

מה לא כדאי לעשות

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

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

תרגיל של עשר דקות לצוות

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

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

מה עושים אם הפקודה כבר הורצה

1. מנתקים את המחשב מהרשת. מוציאים כבל רשת ומכבים Wi-Fi, אך לא מתחילים למחוק קבצים או "לנקות" לבד.
2. פונים מיד לאיש המחשוב. מסרו את כתובת האתר ואת השעה. תארו במדויק מה הקלדתם ועל אילו כפתורים לחצתם. צילום מסך או היסטוריית דפדפן יכולים לעזור.
3. מבודדים ובודקים את התחנה. בודקים תהליכים, הורדות, התמדה, גישה למאגרי סיסמאות וחיבורים אל כתובות חיצוניות.
4. מחליפים סיסמאות ממחשב נקי. מתחילים בדואר ובחשבונות ניהוליים, ומנתקים את כל ההתחברויות הפעילות כדי לבטל אסימונים שנגנבו.
5. בודקים חשבונות נוספים. מחפשים כללי העברה בתיבת הדואר, כניסות חריגות, אפליקציות שאושרו ושינויים בפרטי ספקים.
6. מניחים שהמחשב עלול לשמש נקודת מעבר. בקמפיין TerminalFix שנחקר, המטרה הייתה גישה לרשת הפנימית. לכן בודקים גם מערכות שאליהן התחנה יכלה להגיע.
7. משחזרים תחנה נקייה כשנדרש. במקרה של גנב מידע או התמדה, התקנה מחדש ממקור מהימן עדיפה על תיקון חלקי.

צ'קליסט לבדיקת המוכנות

• האם כל העובדים יודעים שאתר לעולם לא אמור לבקש מהם להריץ פקודה?
• האם משתמשים רגילים עובדים ללא הרשאת מנהל מקומי?
• האם PowerShell, Terminal וחלון ההרצה מוגבלים לפי צורך תפקיד?
• האם קיימת הגנה שמזהה שרשרת התנהגות ולא רק קובץ מוכר?
• האם אפשר לבודד מחשב ולנתק התחברויות לענן במהירות?
• האם קיים נוהל קצר וברור לדיווח על אירוע חשוד?
• האם הגיבוי נבדק בשחזור אמיתי בחודשים האחרונים?

סיכום

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

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