Исследователи Securonix связали кампанию Smoke#Screen как минимум с 15 уникальными файлами и тремя серверами управления, через которые жертвам тихо ставят легитимный агент удаленного доступа. По данным Dark Reading, установка ScreenConnect маскируется под апдейты Zoom и Adobe, деловые документы и даже под безобидную на вид «системную проверку». Для ИБ-команд, IT-директоров и техлидов это неприятный сигнал: на машине оказывается не условный троян с сомнительной подписью, а вполне штатный RMM-инструмент, который многие компании сами используют для поддержки и администрирования.
Публикация Dark Reading вышла 4 августа 2026 года и описывает кампанию, которая работает сразу по двум направлениям, привычным для корпоративной среды: доверие к знакомому софту и усталость пользователей от бесконечных апдейтов. В качестве приманок злоумышленники используют как минимум четыре сюжета: обновление Zoom, обновление Adobe, запрос на просмотр бизнес-документа и псевдоутилиту SystemCheck. Дальше сценарий прямолинеен: пользователь запускает файл, после чего идет тихая установка ScreenConnect, а агент начинает обращаться к одному из трех подконтрольных атакующим узлов. Причем речь идет не только о Windows: исследователи увидели и macOS-вариант с пакетом ZoomUpdateInstaller.pkg, который стучится в ту же инфраструктуру.
Сильная сторона Smoke#Screen не в одном красивом фишинговом письме, а в том, что вся цепочка живет и меняется на ходу. Securonix нашла активный staging-сервер на 207.174.0.143:8080, где лежал целый набор полезной нагрузки, от VBScript-дропперов и batch-лоадеров до .NET-исполняемых файлов и HTML-страниц. За время наблюдения исследователи восстановили пять разных kill chain и заметили важную деталь: оператор менял хэши файлов буквально между отдельными сессиями загрузки. Для защитников это означает простую вещь: классическая охота по хэшу тут быстро превращается в бюрократию ради бюрократии. Пока SOC заносит один образец в IOC-лист, злоумышленник уже выкатывает соседний файл с тем же результатом на выходе.
Самый любопытный кусок истории, и немного комичный для атакующих, связан с их собственной инфраструктурой. Исследователи получили редкий подарок: в открытом каталоге рядом с готовыми бинарниками лежали исходники на C#, включая MemoryLoader.cs и более поздний loader.cs. Это позволило буквально прочитать логику развития кампании. На ранних этапах вредоносный код действовал грубо: отключал AMSI, ковырял SmartScreen, добавлял исключения Defender, а в одном варианте вообще прописывал исключение для всего диска C:, что уже выглядит как «мы не прячемся, мы просто выключаем свет». Потом оператор, похоже, понял, что такой стиль слишком шумный, и переключился на более тихую модель: в исходнике нашли задержку на 180 секунд, явно рассчитанную на то, чтобы разорвать корреляцию событий в EDR и не светиться слишком плотной цепочкой действий.
Здесь и проявляется главный смысл кейса. Aaron Beardslee из Securonix в разговоре с Dark Reading по сути описывает не новую малварь, а новую нормальность для атак такого класса: после инсталляции защитник видит корректно подписанный сервис ConnectWise, а не экзотический имплант с кривым деревом процессов. В инфраструктуре кампании каждый слой помогает обходить свой контроль: Dropbox играет на доверии к известному файлообменнику, Cloudflare Quick Tunnel прячет источник, а подпись DigiCert на компонентах ScreenConnect снижает подозрительность бинарников. В итоге отдельные защитные меры могут выглядеть рабочими, но вся цепочка собирается так, чтобы ни один контроль не видел картину целиком. Именно поэтому злоупотребление ScreenConnect здесь опаснее обычного фишинга на логин и пароль: компрометация заканчивается не кражей учетных данных, а готовым интерактивным доступом в корпоративную среду.
Для разработчиков и бизнеса вывод очень приземленный. Если в компании нет точного реестра разрешенных RMM-инструментов, то спор о безопасности вы уже проигрываете на уровне терминов. Нужно не просто «мониторить подозрительное», а отдельно отслеживать несанкционированные установки ScreenConnect, подключения к raw IP вместо вендорских доменов, запуск msiexec.exe с тихими флагами через powershell.exe или cmd.exe, а также любые попытки трогать Defender и UAC. Полезны и старые, почти скучные меры: AppLocker или WDAC для MSI из Downloads, Temp и AppData, режим UAC с Always notify, разграничение админских прав и более жесткая политика для unmanaged/BYOD-устройств. Smoke#Screen бьет ровно туда, где корпоративная практика любит делать вид, что все под контролем: пользователь сам нажал, файл подписан, инструмент легитимный, что еще вам надо.
Следующий виток таких кампаний, похоже, будет не громче, а тише: меньше шумного отключения защиты, больше подписанного софта, больше приманок под рутину и больше аккуратной подстройки под конкретные EDR. Если установка ScreenConnect уже выглядит как обычный апдейт, то вопрос для рынка теперь не в том, как поймать «еще один троян», а в том, как отличить удаленную поддержку от вторжения, пока злоумышленник не успел стать самым вежливым администратором в вашей сети. Подробности исходного разбора собраны в материале .