Больше 457 конечных устройств попали под атаку, в которой злоумышленники использовали Faronics Deploy не как цель, а как рабочий инструмент для захвата удалённого доступа. Для IT-команд это неприятный, но очень показательный сценарий: если сотрудник запускает легитимный подписанный установщик, дальше атакующему уже не нужно уговаривать жертву кликать ещё раз.
О схеме Faronics Deploy сообщает BleepingComputer со ссылкой на исследование Huntress. По данным MDR-компании, активность фиксировалась с 21 июля по 20 августа 2026 года. Письма маскировались под счета, налоговые документы и другие деловые файлы, а встроенные ссылки вели не сразу к вредоносу, а на промежуточный сайт, который сначала профилировал посетителя. Если страницу открывали из среды анализа, включался режим маскировки: например, пользователю показывали ошибку вместо полезной нагрузки.
Основная приманка выглядела буднично и потому опасно. Потенциальной жертве предлагали скачать и запустить легитимный, подписанный установщик Faronics Deploy, который выдавали за PDF-файл Adobe, ридер или обновление плагина. Во многих случаях файл назывался Adobe.exe. После запуска компьютер регистрировался в развёртывании Faronics, которое контролировали уже не администраторы компании, а атакующая сторона. Дальше начиналась вторая стадия: через штатную функцию удалённого деплоя злоумышленники без дополнительного участия пользователя выполняли PowerShell-скрипты на подключённой машине.
Эти скрипты тянули дополнительные компоненты с инфраструктуры операторов атаки и внешних площадок, включая GitHub. Huntress зафиксировала несколько вариантов доставки: где-то использовались curl и mshta для загрузки следующего этапа, где-то вызывался msiexec для установки полезной нагрузки с подконтрольных серверов. Финальной целью становился ConnectWise ScreenConnect — ещё один легитимный инструмент удалённого доступа. То есть схема была не про одноразовый фишинг, а про аккуратное построение устойчивого канала администрирования на чужом хосте.
Зачем злоумышленникам второй инструмент, если они уже получили контроль через Faronics? Ответ довольно приземлённый: резервирование и удобство. ScreenConnect даёт интерактивный доступ, лучше подходит для ручной работы на хосте и остаётся запасным входом, если подозрительное развёртывание в Faronics обнаружат и отключат либо если защитники удалят агент. Для SOC и внутренних ИБ-команд это важный нюанс. Проверка только на один артефакт атаки здесь не работает: даже если первичный канал закрыт, сессия может жить дальше через другое вполне легитимное ПО.
История особенно неприятна тем, что она укладывается в устойчивый тренд последних лет: атакующие всё чаще опираются не на экзотические эксплойты, а на нормальные административные и support-инструменты. Это снижает шум, упрощает обход части защитных правил и ломает привычную логику «вредонос равно подозрительный бинарник без подписи». В этой кампании ключевой трюк вообще построен на доверии к подписанному инсталлятору и к самому классу ПО, которое в корпоративной среде обычно считается допустимым. Для разработчиков и IT-директоров вывод неудобный, но очевидный: allowlist по издателю и репутации файла уже давно не равен безопасности.
Faronics, судя по данным Huntress, отреагировала достаточно быстро. Исследователи уведомили вендора 5 августа, компания подтвердила злоупотребление платформой и ввела дополнительные антиабьюз-механизмы. Кроме того, Faronics связалась с организациями, которые могли пострадать. Huntress отмечает, что с 21 августа активность заметно снизилась, а значит, контрмеры, по крайней мере на этом этапе, сработали. Это хороший сигнал для клиентов платформы, но и напоминание, что у поставщиков средств удалённого управления теперь почти такой же фронт работы, как у производителей EDR: нужно не только развивать продукт, но и постоянно отслеживать, как его пытаются превратить в оружие.
Практическая часть у этой истории важнее морали. Huntress рекомендует администраторам проверить каталог C:\ProgramData\Faronics\Logs\ на наличие файла ScriptRunner.log — в нём могут сохраниться имена удалённо выполненных скриптов и URL загрузок. Отдельный индикатор — параметр ck в конфигурационных запросах Faronics, который указывает на связанное клиентское развёртывание и может помочь найти скомпрометированные конечные точки или вредоносные аккаунты. Второй обязательный шаг — ревизия установок ScreenConnect там, где этот продукт обычно не используется. Иными словами, расследовать здесь нужно не «был ли фишинг», а «какие легитимные каналы администрирования внезапно появились на машине и кто их создал».
Для бизнеса это ещё один аргумент в пользу более жёсткого контроля над любыми средствами удалённого управления: от RMM и deployment-платформ до support-агентов. Если корпоративная среда допускает бесшовную регистрацию устройства в чужом тенанте и тихий запуск скриптов после одного неудачного клика, проблема уже не в одном письме из почты. Проблема в том, что граница между штатным администрированием и компрометацией становится всё менее заметной, а значит, защите придётся учиться различать их не по названию процесса, а по контексту действий.