בסוף אוגוסט הוציא מרכז התפעול של חברת Huntress שלוש התראות קריטיות משלושה ארגונים שאין ביניהם שום קשר, וכולן נראו אותו דבר. על כל אחת מהמכונות הותקן לקוח ScreenConnect שאיש לא ביקש, ומיד אחריו הוא הריץ ארבע פעמים את wscript.exe, מנוע הסקריפטים המובנה של ווינדוס, כדי להפעיל ארבעה קבצים בשמות 1.vbs, 2.vbs, 3.vbs ו-4.vbs. אותם שמות, אותו סדר, בשלושה מקומות שלא אמורים לדעת זה על קיומו של זה.

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

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

למה דווקא ScreenConnect

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

וזו גם לא הפעם הראשונה שהמוצר הזה עומד במרכז. BleepingComputer מזכירה ש-CVE-2024-1709 נוצלה ב-2024 גם בידי קבוצות כופרה וגם בידי Kimsuky הצפון קוריאנית, שב-2025 ConnectWise עצמה נפרצה דרך חולשה במוצר (CVE-2025-3935), ושמאז פברואר 2024 נכנסו שלוש חולשות של ScreenConnect לקטלוג הניצול הפעיל של CISA. אותו דיווח מוסיף ש-Shadowserver סופר כמעט 6,000 מופעים של ScreenConnect חשופים לאינטרנט, אם כי אין דרך לדעת כמה מהם מלכודות דבש וכמה כבר טופלו.

שלוש כניסות שונות, אותם ארבעה קבצים

שלושת האירועים התחילו בהנדסה חברתית, כל אחד בדרך אחרת. ב-20 באוגוסט שוכנע משתמש להפעיל את Quick Assist, כלי התמיכה מרחוק המובנה בווינדוס, בתרחיש המוכר של "תמיכה טכנית" שמודיעה לקורבן שהמחשב שלו נפרץ ומדריכה אותו למסור קוד גישה. מיד אחר כך הותקן לקוח ScreenConnect שדיבר עם שרת שליטה ובקרה (C2, השרת שממנו התוקף שולח פקודות) בכתובת 45.13.237[.]190, שלפי VirusTotal הייתה קשורה במהלך אוגוסט לדומיין tele-sync.opik[.]net. משם נמשך קובץ שנראה כמו EXE ובפועל היה ארכיון RAR עם ארבעת קבצי ה-VBS.

באירוע שני מאותו יום הגיע הקורבן, ככל הנראה דרך פישינג, להרצת ScreenConnect.ClientSetup.msi מתוך תיקיית ההורדות של Edge. הלקוח שהותקן דרכו פנה ל-131.123.40[.]98 בפורט 8041 והריץ את ארבעת הסקריפטים כמעט מיד, מתוך תיקיית העבודה הזמנית של ScreenConnect. על אותה מכונה נמצאה גם UltraViewer, עוד כלי שליטה מרחוק שמוכר משימוש של נוכלים. באירוע השלישי, ב-24 באוגוסט, חיפש הקורבן טופס החזר כספי של Geek Squad ושוכנע להוריד ScreenConnect.Client.exe שפנה חזרה ל-borertors92.anondns[.]net.

בשני האירועים הראשונים נמצא גם מפתח Run ברישום של המשתמש בשם WindowsServiceHost, שמצביע לקובץ WindowsServiceHost.vbs בתיקיית ה-AppData. זהו מנגנון שימור אחיזה פשוט: הקובץ ירוץ שוב בכל כניסה של המשתמש למערכת. בשני מקרים מתוך השלושה עצר ה-SOC של Huntress את השרשרת לפני שהתקדמה, ובאחד מהם Windows Defender כבר זיהה והסגיר את 4.vbs בעצמו.

הסקריפט הראשון לא תוקף, הוא ממיין

1.vbs לא מתקין דבר. הוא בונה משתנה מצב באורך שלושה ביטים שמתאר את המכונה שעליה הוא רץ, וכותב אותו לקובץ %TEMP%\value.txt. הביט הראשון נקבע לפי קיומה של התקנת ScreenConnect קודמת, ואם נמצאת כזאת הסקריפט כותב לקובץ את המילה abort והשרשרת נעצרת. את הביט השני קובעת רשימת מוצרי אבטחה: הסקריפט מחפש services ותהליכים של Huntress, Cisco AMP, CrowdStrike, SentinelOne, Sophos, Malwarebytes ואחרים, ואם אחד מהם קיים הביט נשאר 0. אם Windows Defender הוא ההגנה היחידה על המכונה, הביט נדלק ל-1. הביט השלישי בודק אם אין לקוח ScreenConnect בתיקיית Program Files.

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

מהמפה למטען

השלב הבא הוא בעצם רשימת קניות. 2.vbs ממתין שקובץ value.txt יופיע, בודק שאין בו את המילה abort, ומוריד קובץ מ-Dropbox עם User-Agent קבוע שנועד לגרום לבקשה להיראות כמו הורדה של גולש רגיל. את התוכן הוא מפענח מ-base64 ומריץ עליו XOR עם בית יחיד בערך 90, וכותב את התוצאה ל-%TEMP%\map.txt. הקובץ הזה לא מורץ בשום שלב. הוא קטלוג: כל שורה בו מצמידה לצירוף ביטים אחד כתובת הורדה, ואחרי תו מפריד גם מפתח AES. (החוקרים מציינים שבקוד של 3.vbs נשארה הערה שמסבירה בדיוק את מבנה השורה הזאת, ולהערכתם היא שריד מהמודל שכתב את הסקריפט.)

3.vbs קורא את value.txt שוב, מאתר ב-map.txt את השורה שמתאימה למצב שנקבע בשלב הראשון, ומוריד את הקובץ שמצוין בה. הצירופים 000 ו-001 מובילים לדלת אחורית של ScreenConnect ברמת המשתמש, 010 מוביל לכלים להסלמת הרשאות ולשימור אחיזה, ו-011 מוביל לכלי מנהור ולכורה מטבעות קריפטו. אצל Huntress מדובר בקבצים user.enc, acc.enc ו-combo.enc בהתאמה.

את השרשרת סוגר 4.vbs. הוא שולף את מפתח ה-AES מתוך השורה ב-map.txt, מוחק את שני קבצי העבודה, ובונה בתוך עצמו סקריפט PowerShell שנכתב ל-%TEMP%\runner.ps1 ומורץ עם עקיפה של מדיניות ההרצה. הסקריפט מפענח את המטען ב-AES-CBC כששישה עשר הבתים הראשונים של הקובץ המוצפן משמשים כווקטור האתחול, כותב את התוצאה לקובץ sys_cache.zip בתוך פרופיל המשתמש, ומפעיל סקריפט PowerShell שני בשם PyTorchFix.ps1. אחר כך הוא הורג כל תהליך wscript.exe או cscript.exe שרץ, ומוחק את תיקיית ההכנה מאחוריו.

בגרסת ה-010 שהחוקרים הצליחו לחלץ, PyTorchFix.ps1 בונה קובץ הרצה מקוד C# משובץ, חוטף את מטפל הפרוטוקול ms-settings ומשתמש ב-ComputerDefaults.exe המובנה של ווינדוס כדי לעקוף את בקרת חשבון המשתמש (UAC). מה שרץ אחר כך בהרשאות גבוהות מנסה לנטרל את AMSI, הממשק שדרכו ווינדוס מעביר סקריפטים לסריקה לפני הרצה, מוסיף את כל C:\Users כנתיב חריג ב-Defender, מבטל שינה וכיבוי מסך, ומתקין לקוח ScreenConnect נוסף בזיהוי 7a4d7d66502d4260. את רישום ההסרה שלו הוא מוחק, ולשירות שלו הוא מצמיד הרשאות מגבילות כדי שלא יופיע ברשימת ה-services.

הענף השלישי, 011, שמור למכונה שאין עליה ScreenConnect ושהגנתה היחידה היא Defender. שם החבילה מכבה דיווחים והתראות של Defender ואת מנגנון שלמות הקוד המוגן בווירטואליזציה (HVCI), מתקינה את כלי המנהור wstunnel בשם Themes.exe שפונה ל-homehub.opik[.]net בפורט 443, ומריצה כורה XMRig בשם SearchIndex.exe. נמצא בה גם הדרייבר WinRing0, שיש בו חולשה ידועה, בשם svcdrv64.sys.

הלקוח שמדביק את מי שמתחבר אליו

עד כאן זו שרשרת הדבקה מסודרת, אבל לא כזאת שלא ראינו. מה שהפך את הדוח לסיפור הוא מה ש-4.vbs עושה כשהמצב שנקבע הוא 010 או 011: הוא מעתיק את ארבעת קבצי ה-VBS לנתיב C:\Users\Public\Libraries\Default\Lib\Lib1 ומשאיר אותם שם.

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

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

זו גם הנקודה שבה ConnectWise נכנסה לתמונה. לפי העדכון ש-Huntress הוסיפה לדוח, החברה פרסמה ב-3 בספטמבר הודעת אבטחה על תקלה שזיהתה ב"התנהגות העברת הקבצים" בסשנים של ScreenConnect Remote Access Support ו-Access, בענן ובהתקנות מקומיות כאחת, והבטיחה CVE ותיקון רשמי בתוך שבוע. עד כתיבת שורות אלה עוד אין ב-NVD חולשה מתועדת של ScreenConnect מהתקופה הזאת, ובינתיים ההמלצה הזמנית של ConnectWise היא לבטל לטכנאים את הרשאת TransferFiles בכל אחד מהתפקידים המוגדרים במערכת.

מה זה אומר בפועל

אם אתם מריצים התקנת ScreenConnect מקומית, הדבר הראשון לבדוק הוא יומני הביקורת של השרת: לפי Huntress, כל רישום RunFiles או RanFiles שמריץ סקריפטים מתוך Process: Guest צריך להדליק נורה אדומה, גם אם השמות כבר השתנו מ-1.vbs עד 4.vbs למשהו אחר. כיבוי הרשאת העברת הקבצים לטכנאים הוא הצעד הבא, לפחות עד שיצא תיקון רשמי. ולגבי מכונה שכבר עברה את השרשרת הזאת, ההמלצה של ה-SOC של Huntress חד משמעית: לא לנקות אותה, אלא להתקין עליה מחדש מערכת הפעלה ממקור נקי.