В июле 2026 года Microsoft Security Research обнаружила многоэтапные фишинговые кампании против устройств Windows. Злоумышленники распространяли легитимный, подписанный цифровой подписью установщик MSP360 Remote Monitoring and Management версии MSP360 RMM v2.5.0.67. Microsoft, производитель Windows, не связала эту активность ни с одной известной киберпреступной или шпионской группой. Расчёт строился на доверии к обычному средству администрирования: его запуск выглядел куда менее подозрительно, чем установка неизвестной вредоносной программы.
Установщик маскировали под приглашения на встречи, электронные открытки с просьбой подтвердить участие, пакет установки Zoom, программы для чтения и редактирования PDF, продукты в оформлении Adobe Acrobat, выписки Управления социального обеспечения США и обновления ПО. Microsoft зафиксировала названия VIP_ECARD_INVITATION_rmm_v2.5.0.67_oid[redacted].exe, ZoomSetup_Installation_v2.5.0.67_ oid[redacted].exe, PDF Reader & Editor the Adobe Acrobatte_rmm_v2.5.0.67_ oid[redacted].exe, RSVP_INVITATION_E_CARD_rmm_v2.5.0.67_ oid[redacted].exe и _STATEMENT_rmm_v2.5.0.67_ oid[redacted].exe. Значение oid в опубликованных данных было скрыто.
Файлы размещались как на инфраструктуре самих атакующих, так и в известных облачных сервисах: Amazon S3 компании Amazon, Cloudflare R2 компании Cloudflare, Dropbox, GitLab и Supabase. Ссылка на знакомый домен могла не вызвать тревоги у пользователя и пройти через часть фильтров, доверяющих крупным платформам. При этом облачный сервис служил лишь площадкой доставки: цифровая подпись MSP360 подтверждала происхождение штатного установщика, но ничего не говорила о намерениях человека, отправившего его жертве.
После запуска пакет сохранял на компьютере несколько DLL-файлов и повторно запускал себя через механизм повышения прав Windows User Account Control, или UAC. Получив привилегированный контекст, он разворачивал MSP360 и открывал атакующим первый канал удалённого управления. Microsoft описала этот этап так: «После запуска легитимный установщик MSP360, распространявшийся под обманчивым именем файла, предоставлял удалённый доступ к затронутым устройствам и позволял субъектам угроз закрепиться на них с помощью доверенного административного программного обеспечения».
Установка сопровождалась действиями, которые удобно искать в системных журналах. Пакет перечислял установленные среды , регистрировал RMM.Agent.exe и RMM.Agent.Launcher.exe как службы Windows, а также создавал записи автозапуска в реестре Windows. Благодаря этим записям MSP360 стартовал при входе пользователя в систему. Такое сочетание служб и реестра давало постоянный доступ даже после перезагрузки компьютера.
Ещё одно заметное изменение касалось Windows Firewall. В его конфигурации появлялось разрешение на входящий UDP-трафик для RMM.Agent.exe через порт 48678. Для расследования важна вся связка признаков: исполняемый файл агента, входящее направление соединения, протокол UDP и конкретный порт. Отдельная запись может принадлежать штатной установке MSP360, поэтому её следует сопоставлять с источником установщика, временем повышения прав через UAC, созданием служб и изменениями автозапуска.
Получив управление через MSP360, атакующие запускали PowerShell и скрытно устанавливали клиент ConnectWise ScreenConnect. Так на одном устройстве возникали два независимых RMM-канала. Если защитники удаляли или блокировали MSP360, ScreenConnect сохранял удалённый доступ; сбой второго продукта, в свою очередь, не обязательно лишал операторов первого соединения. Microsoft сформулировала это так: «Сочетание MSP360 и ScreenConnect предоставляло субъекту угроз резервные каналы удалённого администрирования и позволяло передавать, запускать и контролировать дополнительные инструменты на последующих стадиях вторжения».
Через ScreenConnect злоумышленники передавали дополнительные исполняемые файлы и запускали их штатной функцией RunFile. После компрометации они могли управлять конечной точкой, собирать сведения, искать или получать учётные данные, доставлять новые инструменты и контролировать их работу. Активность при этом напоминала действия обычной ИТ-поддержки: PowerShell, RMM-агенты и удалённый запуск файлов сами по себе встречаются в корпоративных сетях каждый день. Именно контекст отличает администрирование от вторжения — неожиданный агент, установка из письма, неизвестный оператор или второй RMM-продукт на машине.
В том же июле 2026 года Microsoft наблюдала отдельную серию атак с похожей логикой. Вместо MSP360 преступники применяли Faronics Deploy Agent для первоначального доступа, а затем загружали и устанавливали ConnectWise ScreenConnect. Этот вариант снова создавал схему с несколькими RMM-продуктами. Использование MSP360, Faronics Deploy Agent и ScreenConnect в разных цепочках указывает на готовность операторов менять легитимное административное ПО, сохраняя один и тот же способ закрепления и резервирования доступа.
Microsoft описала общую тактику фразой: «Эта активность показывает, как субъекты угроз продолжают злоупотреблять легитимным программным обеспечением удалённого администрирования, чтобы сливаться с обычными ИТ-операциями, сохранять постоянный доступ и сокращать возможности обнаружения». Практическими признаками такой атаки служат запуск MSP360 RMM v2.5.0.67 из фишингового файла, создание служб RMM.Agent.exe и RMM.Agent.Launcher.exe, автозапуск через реестр, правило для входящего UDP на порту 48678, выполнение PowerShell из MSP360, последующая установка ConnectWise ScreenConnect и использование RunFile. Принадлежность кампаний конкретному оператору по состоянию на публикацию не установлена.
Изображение носит иллюстративный характер
Установщик маскировали под приглашения на встречи, электронные открытки с просьбой подтвердить участие, пакет установки Zoom, программы для чтения и редактирования PDF, продукты в оформлении Adobe Acrobat, выписки Управления социального обеспечения США и обновления ПО. Microsoft зафиксировала названия VIP_ECARD_INVITATION_rmm_v2.5.0.67_oid[redacted].exe, ZoomSetup_Installation_v2.5.0.67_ oid[redacted].exe, PDF Reader & Editor the Adobe Acrobatte_rmm_v2.5.0.67_ oid[redacted].exe, RSVP_INVITATION_E_CARD_rmm_v2.5.0.67_ oid[redacted].exe и _STATEMENT_rmm_v2.5.0.67_ oid[redacted].exe. Значение oid в опубликованных данных было скрыто.
Файлы размещались как на инфраструктуре самих атакующих, так и в известных облачных сервисах: Amazon S3 компании Amazon, Cloudflare R2 компании Cloudflare, Dropbox, GitLab и Supabase. Ссылка на знакомый домен могла не вызвать тревоги у пользователя и пройти через часть фильтров, доверяющих крупным платформам. При этом облачный сервис служил лишь площадкой доставки: цифровая подпись MSP360 подтверждала происхождение штатного установщика, но ничего не говорила о намерениях человека, отправившего его жертве.
После запуска пакет сохранял на компьютере несколько DLL-файлов и повторно запускал себя через механизм повышения прав Windows User Account Control, или UAC. Получив привилегированный контекст, он разворачивал MSP360 и открывал атакующим первый канал удалённого управления. Microsoft описала этот этап так: «После запуска легитимный установщик MSP360, распространявшийся под обманчивым именем файла, предоставлял удалённый доступ к затронутым устройствам и позволял субъектам угроз закрепиться на них с помощью доверенного административного программного обеспечения».
Установка сопровождалась действиями, которые удобно искать в системных журналах. Пакет перечислял установленные среды , регистрировал RMM.Agent.exe и RMM.Agent.Launcher.exe как службы Windows, а также создавал записи автозапуска в реестре Windows. Благодаря этим записям MSP360 стартовал при входе пользователя в систему. Такое сочетание служб и реестра давало постоянный доступ даже после перезагрузки компьютера.
Ещё одно заметное изменение касалось Windows Firewall. В его конфигурации появлялось разрешение на входящий UDP-трафик для RMM.Agent.exe через порт 48678. Для расследования важна вся связка признаков: исполняемый файл агента, входящее направление соединения, протокол UDP и конкретный порт. Отдельная запись может принадлежать штатной установке MSP360, поэтому её следует сопоставлять с источником установщика, временем повышения прав через UAC, созданием служб и изменениями автозапуска.
Получив управление через MSP360, атакующие запускали PowerShell и скрытно устанавливали клиент ConnectWise ScreenConnect. Так на одном устройстве возникали два независимых RMM-канала. Если защитники удаляли или блокировали MSP360, ScreenConnect сохранял удалённый доступ; сбой второго продукта, в свою очередь, не обязательно лишал операторов первого соединения. Microsoft сформулировала это так: «Сочетание MSP360 и ScreenConnect предоставляло субъекту угроз резервные каналы удалённого администрирования и позволяло передавать, запускать и контролировать дополнительные инструменты на последующих стадиях вторжения».
Через ScreenConnect злоумышленники передавали дополнительные исполняемые файлы и запускали их штатной функцией RunFile. После компрометации они могли управлять конечной точкой, собирать сведения, искать или получать учётные данные, доставлять новые инструменты и контролировать их работу. Активность при этом напоминала действия обычной ИТ-поддержки: PowerShell, RMM-агенты и удалённый запуск файлов сами по себе встречаются в корпоративных сетях каждый день. Именно контекст отличает администрирование от вторжения — неожиданный агент, установка из письма, неизвестный оператор или второй RMM-продукт на машине.
В том же июле 2026 года Microsoft наблюдала отдельную серию атак с похожей логикой. Вместо MSP360 преступники применяли Faronics Deploy Agent для первоначального доступа, а затем загружали и устанавливали ConnectWise ScreenConnect. Этот вариант снова создавал схему с несколькими RMM-продуктами. Использование MSP360, Faronics Deploy Agent и ScreenConnect в разных цепочках указывает на готовность операторов менять легитимное административное ПО, сохраняя один и тот же способ закрепления и резервирования доступа.
Microsoft описала общую тактику фразой: «Эта активность показывает, как субъекты угроз продолжают злоупотреблять легитимным программным обеспечением удалённого администрирования, чтобы сливаться с обычными ИТ-операциями, сохранять постоянный доступ и сокращать возможности обнаружения». Практическими признаками такой атаки служат запуск MSP360 RMM v2.5.0.67 из фишингового файла, создание служб RMM.Agent.exe и RMM.Agent.Launcher.exe, автозапуск через реестр, правило для входящего UDP на порту 48678, выполнение PowerShell из MSP360, последующая установка ConnectWise ScreenConnect и использование RunFile. Принадлежность кампаний конкретному оператору по состоянию на публикацию не установлена.
