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

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

ב-2 בספטמבר 2026 פרסמה Microsoft Security Research מחקר על קמפיין פעיל בדיוק בתבנית הזאת. התוקפים השתמשו ב-Teams ובכלי סיוע מרחוק כדי להפוך אינטראקציה שהמשתמש אישר לגישה מתמשכת לרשת. זו תזכורת מעשית לעסקים: תמיכה מרחוק חייבת להיות תהליך מזוהה ומנוהל, לא רק תוכנה שמותקנת על המחשב.

מה קרה בקמפיין החדש

לפי המחקר של מיקרוסופט, המגע הראשוני הגיע מחשבון חיצוני ב-Teams שהתחזה לצוות IT או Helpdesk. הפיתיון השתנה בין הודעת עדכון אבטחה, תיקון מסנן דואר, אימות חשבון או איום שהחשבון יושבת. העובד התבקש לאשר בקשת שליטה במהלך שיתוף מסך או לפתוח את Quick Assist ולהקריא את קוד החיבור.

מיד לאחר קבלת השליטה, התוקף הפעיל PowerShell, הוריד חבילת MSI משירות אחסון בענן והתקין אותה ללא חלון גלוי. החבילה הכינה סביבת Node.js ניידת וקוד JavaScript מוצפן שסיפק לתוקף ערוץ קבוע לקבלת פקודות. השימוש בכלים לגיטימיים כמו Teams, Windows Installer, PowerShell ו-Node.js עזר לפעילות להיראות דומה לעבודת IT רגילה.

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

למה כלי לגיטימי מסוכן בידיים הלא נכונות

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

החתימה הדיגיטלית של התוכנה אינה הוכחה שהשימוש בה תקין. במרץ 2026 תיעדה מיקרוסופט קמפיינים שהפיצו קבצים חתומים שהתחזו ל-Teams, Zoom ו-Adobe Reader. לאחר ההפעלה הותקנו כלי RMM שסיפקו התמדה ותנועה ברשת. בחלק מהמקרים הותקנו כמה כלי שליטה במקביל, כדי שגם אם ערוץ אחד ייחסם יישאר לתוקף ערוץ נוסף.

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

שלוש דרכי כניסה נפוצות

התחזות לתמיכה בתוך כלי העבודה

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

הורדה שמתחזה לעדכון

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

שימוש לרעה בכלי שכבר מותקן

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

מה התוקף יכול לעשות אחרי החיבור

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

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

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

כלל האימות שעוצר את ההתחזות

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

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

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

איך מנהלים כלי תמיכה מרחוק נכון

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

1. בוחרים כלי מאושר אחד. מתעדים את שמו, היצרן, שרת הניהול והספק שמורשה להשתמש בו.
2. מסירים כלים ישנים. תוכנה של ספק קודם או כלי ניסוי שנשכח אינם "גיבוי", אלא ערוץ לא מנוהל.
3. דורשים MFA לכל חשבון טכנאי. סיסמה לבדה אינה מספיקה למערכת שמסוגלת לשלוט בעשרות מחשבים.
4. מפרידים בין טכנאים. לכל איש תמיכה חשבון אישי. אין חשבון משותף שאין דרך לדעת מי השתמש בו.
5. מגבילים הרשאות. תמיכה בתחנת משתמש אינה אמורה להעניק אוטומטית גישה לבקר דומיין או לכל השרתים.
6. קובעים חלונות וגישה. חיבור בלתי מאויש ניתן רק למחשבים שצריכים אותו, ובתנאים מתועדים.

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

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

מה צריך לנטר

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

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

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

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

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

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

1. מבודדים את התחנה. חוסמים את היכולת של התוקף להמשיך לפעול או לעבור למחשבים נוספים.
2. מבטלים סשנים וזהויות. מאפסים סיסמאות רלוונטיות ומנתקים התחברויות ענן פעילות ממכשיר נקי.
3. מחפשים התמדה. בודקים שירותים, משימות מתוזמנות, תוכנות RMM, רכיבי Startup וכלי שליטה נוספים.
4. בודקים את טווח האירוע. מסתכלים ביומנים על PowerShell, MSI, WinRM, שינויים בחשבונות וגישה לשרתים.
5. משחזרים בביטחון. אם הותקן רכיב זדוני או שאין ודאות לגבי הניקיון, בונים את התחנה מחדש ממקור מהימן.

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

צ'קליסט לבעל העסק

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

סיכום

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

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