Изследователи по киберсигурност разкриха подробности за подобна на червей активност, която злоупотребява с ConnectWise ScreenConnect за разпространение на зловреден Visual Basic Script (VBScript) код към новосвързани системи.

Според Huntress са открити три несвързани инцидента, които използват различни методи за първоначален достъп — по-специално измама с техническа поддръжка чрез Quick Assist, фишинг MSI инсталатор и фалшива форма за възстановяване на суми от Geek Squad, за да активират четиристепенна VBScript верига, водеща до инсталиране на злонамерени клиенти на ScreenConnect.

Въпреки това, след като екземплярите на ScreenConnect бъдат инсталирани, компанията за киберсигурност съобщава, че е наблюдавала клиентите многократно да стартират „wscript.exe“, за да изпълняват VBScript файлове с имена 1.vbs, 2.vbs, 3.vbs и 4.vbs. Инцидентите са наблюдавани през август 2026 г.

Подробностите за трите атаки са следните:

  • Социално-инженерна атака, която убеждава потребителя да изпълни Quick Assist като част от измама с техническа поддръжка, след което се внедрява злонамерен клиент за отдалечен достъп ScreenConnect, за да се свърже с команден сървър (C2), разположен на „45.13.237[.]190“ („tele-sync.opik[.]net“). На този IP адрес се съхранява RAR архив, съдържащ четирите VBS файла.
  • MSI инсталатор („ScreenConnect.ClientSetup.msi“), най-вероятно доставен чрез фишинг атака, който внедрява ScreenConnect клиент, конфигуриран да комуникира с „131.123.40[.]98“ на порт 8041. Злонамереният ScreenConnect почти веднага стартира четирите VBScript файла от временната си директория.
  • Търсене на форма за възстановяване на суми от Geek Squad води до внедряване на злонамерен ScreenConnect клиент („ScreenConnect.Client.exe“), който след това се свързва с „borertors92.anondns[.]net“. След това сесията използва „wscript.exe“, за да изпълни четирите VBS скрипта от папката Temp.

При тези инциденти последователността на атаката е следвала четиристъпков процес, като всеки VBScript стартира следващия и му позволява да прогресира по-нататък:

  • 1.vbs — профилира хоста, проверява системните ресурси (напр. дали RAM паметта е над 5 GB), проверява дали ScreenConnect е инсталиран, изброява продуктите за сигурност, включително Cisco AMP, CrowdStrike, Huntress, Malwarebytes, SentinelOne, Sophos и Symantec Endpoint Protection, и записва резултатите от тези проверки в „%TEMP%\value.txt“ под формата на трибитова променлива на състоянието. Например стойността „000“ показва липса на съществуваща инсталация на ScreenConnect, наличие на процеси за сигурност от трети страни и липса на инсталирани клиенти на ScreenConnect в папката Program Files.
  • 2.vbs — изчаква файла „%TEMP%\value.txt“ и проверява за наличието на думата „abort“. Ако думата не съществува, той изтегля файл от Dropbox, декодира съдържанието му и го записва в „%TEMP%\map.txt“. Въпреки че съдържанието на текстовия файл не се изпълнява, точният характер на извлечения зловреден код не е ясен, тъй като Dropbox URL адресът вече не е активен към 2 септември 2026 г.
  • 3.vbs — работи подобно на 2.vbs, като изчаква „%TEMP%\map.txt“ и след това преминава към изтегляне на съответния файл от Dropbox връзката, посочена в текстовия файл, въз основа на стойностите на състоянието, зададени от 1.vbs в „%TEMP%\value.txt“, и го записва в „%TEMP%\out.enc“.
  • 4.vbs — изчаква наличието на изтегления злонамерен код „%TEMP%\out.enc“ и стартира PowerShell скрипт („%TEMP%\runner.ps1“), който декриптира съдържанието на „%TEMP%\out.enc“, записва го в „%APPDATA%\Microsoft\Windows\Templates\Classic\sys_cache.zip“ и изпълнява вторичен PowerShell скрипт („PyTorchFix.ps1“).

Открити са поне три различни вида злонамерен код въз основа на стойността на състоянието:

  • 000 и 001 водят до задна врата (backdoor) чрез ScreenConnect на потребителско ниво
  • 010 води до инструменти за ескалация на привилегии чрез заобикаляне на User Account Control (UAC) и осигуряване на персистентност
  • 011 води до инструменти за тунелиране и софтуер за копаене на криптовалута (cryptominer)

В допълнение, „%TEMP%\runner.ps1“ предприема стъпки за прекратяване на всеки процес „wscript.exe“ или „cscript.exe“ и изтрива междинната директория след изпълнението на последния етап. Скриптът 4.vbs също така записва четирите VBScript файла в „C:\Users\Public\Libraries\Default\Lib\Lib1“, ако стойността в „%TEMP%\value.txt“ е зададена на 010 или 011.

Това на свой ред задейства нов кръг от доставки на зловреден код, превръщайки компрометирания хост в механизъм за разпространение на злонамерените скриптове всеки път, когато инфектираният клиент регистрира нова връзка с Host системата.

„Това създава поведение, подобно на червей: инфекциите се разпространяват чрез нови връзки на ScreenConnect. Свързването със заразен клиент на ScreenConnect може да накара Host системата от страна на сървъра да получи и изпълни същата четиристепенна VBScript верига“, посочват от Huntress. „По-късно клиентът записва всеки ConnectionID, за да избегне повторно насочване към същата активна сесия, но премахва този идентификатор след прекъсване на връзката — което позволява последващо повторно свързване да задейства инфекцията отново.“

„Инцидентите споделят и допълнителни индикатори за компрометиране, включително WindowsServiceHost User Run Key, сочещ към WindowsServiceHost.vbs в AppData директорията на потребителя“, съобщават от Huntress, като добавят, че са наблюдавани и други инструменти за отдалечен мониторинг и управление (RMM), включително UltraViewer, на някои от засегнатите хостове.

От друга страна, клонът със стойност на състоянието „011“, което се превежда като: (1) липса на съществуваща инсталация на ScreenConnect в системата, (2) Microsoft Defender е единствената инсталирана програма за защита на крайни точки, и (3) липса на клиенти на ScreenConnect, включва злонамерен код за деактивиране на отчитането на Microsoft Defender, изключване на целостта на паметта във Windows и стартиране на XMRig криптоминьор.

„Предвид обхвата и сложността на тези вериги от атаки, SOC екипът на Huntress отправи силни препоръки засегнатите хостове да бъдат преинсталирани от проверени носители или с чиста операционна система“, заявяват от Huntress.

В отговор на констатациите ConnectWise издаде предупреждение за сигурност, заявявайки, че е идентифицирала проблем, засягащ поведението при прехвърляне на файлове в сесиите за отдалечен достъп и поддръжка на ScreenConnect. Проблемът засяга както облачните (Cloud), така и локалните (On-Premise) внедрявания.

Докато бъде инсталирана корекция за сигурност, на клиентите се препоръчва да намалят риска чрез деактивиране на възможността техниците да прехвърлят файлове:

  • Влезте в страницата за администрация на вашия екземпляр или инсталация на ScreenConnect.
  • Отидете в секцията Administration > Security > Roles.
  • Редактирайте роля, която е назначена на потребители.
  • Прегледайте всяка група сесии (session group), която има определени права.
  • За всяка група сесии в прозореца Scoped Permissions проверете дали е избрано разрешението TransferFiles (или TransferFIlesInSession за по-стари версии). Ако е избрано, премахнете избора.
  • Запазете промените в ролята.
  • Повторете процедурата за всяка дефинирана роля в екземпляра или инсталацията.