ScreenConnect превращает заражённые клиенты в разносчиков вредоносной цепочки

В августе 2026 года специалисты Huntress обнаружили атаки, в которых ConnectWise ScreenConnect использовали для установки поддельных клиентов удалённого доступа. Заражённый клиент запускал четыре VBScript-сценария, а при подключении нового серверного ScreenConnect Host передавал ему ту же цепочку. Получался механизм, похожий на распространение червя: скомпрометированная машина сама становилась точкой доставки вредоносного кода.
Начальный доступ злоумышленники получали тремя способами. В первом случае жертву через мошенническую «техническую поддержку» убеждали запустить Quick Assist, после чего поддельный клиент ScreenConnect обращался к 45.13.237[.]190 и tele-sync.opik[.]net; на IP-адресе лежал RAR-архив с четырьмя VBS-файлами. Во втором случае фишинговое письмо доставляло установщик ScreenConnect.ClientSetup.msi. Клиент соединялся с 131.123.40[.]98 через порт 8041 и почти сразу запускал четыре сценария из временного каталога ScreenConnect. В третьем эпизоде поиск формы возврата денег Geek Squad приводил к установке ScreenConnect.Client.exe, подключавшегося к borertors92.anondns[.]net; затем wscript.exe исполнял те же файлы из папки Temp.
Первый сценарий, 1.vbs, составлял профиль компьютера. Он проверял системные ресурсы, в том числе наличие более 5 ГБ оперативной памяти, искал установленный 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. Сам файл напрямую не исполнялся. Точное содержимое этой карты осталось неизвестным: к 2 сентября 2026 года соответствующий URL Dropbox уже не работал. Затем 3.vbs дожидался %TEMP%\map.txt, выбирал связанную с Dropbox нагрузку согласно состоянию из %TEMP%\value.txt и сохранял её в %TEMP%\out.enc.
Последний сценарий, 4.vbs, после появления %TEMP%\out.enc запускал %TEMP%\runner.ps1. PowerShell расшифровывал файл, помещал результат в %APPDATA%\Microsoft\Windows\Templates\Classic\sys_cache.zip и исполнял сценарий второго этапа PyTorchFix.ps1. После завершения он останавливал все процессы wscript.exe и cscript.exe, а затем удалял промежуточный каталог. При состояниях 010 и 011 все четыре VBS-файла дополнительно копировались в C:\Users\Public\Libraries\Default\Lib\Lib1.
Нагрузка зависела от вычисленного состояния. Для 000 и 001 устанавливался пользовательский бэкдор ScreenConnect. Состояние 010 включало обход UAC, повышение привилегий и средства закрепления в системе. При 011 разворачивались туннельные утилиты и майнер XMRig. Код 011 означал, что ScreenConnect ранее не был установлен, единственным средством защиты оставался Microsoft Defender, а в Program Files отсутствовали клиенты ScreenConnect. В таком случае вредоносные компоненты отключали отправку отчётов Defender, деактивировали целостность памяти Windows и запускали добычу криптовалюты через XMRig.
Распространение начиналось, когда бэкдор обнаруживал новое подключение ScreenConnect Host. Серверная сторона получала и исполняла ту же четырёхступенчатую цепочку. Каждый ConnectionID записывался, чтобы не заражать повторно одну активную сессию. После отключения идентификатор удалялся, поэтому при следующем соединении тот же узел мог получить нагрузку заново. Такая логика позволяла атаке двигаться через доверенные сеансы удалённого управления без классического сетевого сканирования.
Для закрепления использовался пользовательский ключ Run с именем WindowsServiceHost, указывавший на WindowsServiceHost.vbs в каталоге AppData пользователя. На части пострадавших компьютеров исследователи также нашли UltraViewer и другие средства удалённого мониторинга и управления. Из-за количества компонентов, вариантов нагрузки и возможности повторного заражения Huntress SOC рекомендовал не ограничиваться удалением отдельных файлов: безопасным вариантом считалось восстановление узлов из заведомо чистого носителя либо чистая установка операционной системы.
ConnectWise выпустила предупреждение о поведении передачи файлов в сеансах ScreenConnect Remote Access Support и ScreenConnect Access. Проблема затрагивала облачные и локальные, то есть On-Premise, развёртывания. До выхода исправления компания рекомендовала отключить передачу файлов техническими специалистами:

[]Войти на страницу ScreenConnect Administration.
[]Открыть Administration > Security > Roles.
[]Выбрать роль, назначенную пользователям, и перейти к её редактированию.
[]Проверить каждую группу сеансов, для которой назначены разрешения.
[]В разделе Scoped Permissions снять разрешение TransferFiles; в старых версиях оно называется TransferFIlesInSession.
[]Сохранить роль.
[]Повторить проверку и изменение для каждой созданной роли.