Поддельные клиенты ScreenConnect распространяют VBScript-цепочку
Исследователи Huntress обнаружили три инцидента августа 2026 года, в которых злоумышленники устанавливали поддельные клиенты ConnectWise ScreenConnect и запускали цепочку из четырёх VBScript-файлов. После компрометации клиент мог передавать ту же цепочку на новые подключённые хосты, создавая червеобразный механизм распространения внутри удалённых сеансов.
Три пути к установке вредоносного клиента
В одном случае жертву убедили запустить Quick Assist в рамках мошеннической схемы технической поддержки. Затем на устройство был развёрнут несанкционированный клиент ScreenConnect, связывавшийся с управляющим сервером. На этом сервере находился RAR-архив с четырьмя VBS-файлами.
Во втором эпизоде использовался установщик ScreenConnect.ClientSetup.msi, предположительно доставленный фишинговым письмом. Он запускал клиент, настроенный на соединение с внешним сервером по порту 8041, после чего из временного каталога почти сразу исполнялись четыре скрипта.
Третий сценарий начинался с фальшивой формы возврата средств от имени Geek Squad. На компьютер попадал файл ScreenConnect.Client.exe; после подключения он вызывал wscript.exe для запуска VBS-файлов из каталога Temp. Huntress также видела на части затронутых хостов другие инструменты удалённого управления, включая UltraViewer.
Как устроена четырёхэтапная цепочка
Первый скрипт, 1.vbs, профилирует систему: проверяет объём оперативной памяти, наличие ScreenConnect и процессы защитных продуктов. Среди проверяемых решений указаны Cisco AMP, CrowdStrike, Huntress, Malwarebytes, SentinelOne, Sophos и Symantec Endpoint Protection. Результат записывается в %TEMP%\value.txt как трёхбитное значение состояния.
Скрипт 2.vbs ожидает этот файл и, если в нём нет слова abort, загружает данные из Dropbox, декодирует их и сохраняет в %TEMP%\map.txt. Затем 3.vbs выбирает ссылку из этого файла по значению состояния и скачивает содержимое в %TEMP%\out.enc. На 2 сентября ссылка Dropbox уже была недоступна, поэтому точный состав промежуточной загрузки не установлен.
Четвёртый этап запускает PowerShell-скрипт runner.ps1, который расшифровывает out.enc, сохраняет данные в архив sys_cache.zip в профиле пользователя и исполняет PyTorchFix.ps1. Для состояний 000 и 001 исследователи обнаружили пользовательский бэкдор ScreenConnect, для 010 — средства обхода UAC и закрепления, для 011 — утилиты туннелирования и майнер XMRig. В последней ветке также отключаются отчётность Microsoft Defender и проверка целостности памяти Windows.
Почему заражение распространяется дальше
При состояниях 010 и 011 скрипт 4.vbs копирует четыре VBS-файла в общедоступный каталог. Когда скомпрометированный клиент ScreenConnect видит новое подключение Host, серверная система может получить и выполнить ту же цепочку. Клиент сохраняет идентификатор соединения, чтобы не атаковать текущую сессию повторно, но удаляет его после отключения: повторное подключение способно снова запустить заражение.
Скрипт runner.ps1 завершает процессы wscript.exe и cscript.exe и удаляет каталог подготовки после финального этапа. Huntress также отметила признак закрепления: ключ автозапуска WindowsServiceHost, указывающий на WindowsServiceHost.vbs в AppData пользователя.
Меры для администраторов
ConnectWise сообщила о проблеме, затрагивающей передачу файлов в сеансах ScreenConnect Remote Access Support и Access как в облачных, так и в локальных развёртываниях. До выхода исправления компания рекомендует в разделе Administration > Security > Roles снять разрешение TransferFiles, а для устаревших версий — TransferFilesInSession, во всех назначенных ролях и группах сеансов.
Для организаций практический вывод состоит в немедленной проверке ролей и журналов подключений ScreenConnect, а также в поиске указанных VBS- и PowerShell-файлов. Huntress рекомендует для затронутых хостов восстановление из заведомо доверенного образа или чистую установку операционной системы.