Kaseya VSA и REvil: когда ваш RMM становится вектором атаки на клиентов

2 июля, в пятницу перед Independence Day в США, REvil провела то, что уже называют крупнейшей ransomware-атакой через цепочку поставок. Вектор - Kaseya VSA, платформа удалённого мониторинга и управления, которую используют MSP-провайдеры по всему миру. Итог к выходным: по разным оценкам от нескольких сотен до более тысячи компаний зашифрованы - не потому что их атаковали напрямую, а потому что атаковали их MSP.

Мы уже говорили про supply-chain как вектор - после Codecov, SolarWinds, Colonial Pipeline. Kaseya - это следующая итерация той же логики, но с прямым ransomware-эффектом у конечных клиентов.

Как это работало технически

Kaseya VSA - это on-premise или SaaS-платформа для управления клиентскими инфраструктурами. MSP ставит агент VSA на машины клиентов, через него деплоит патчи, скрипты, конфигурации. Агент работает с высокими привилегиями - иначе он не мог бы делать своё дело.

Атака использовала уязвимости в on-premise VSA-серверах (CVE-2021-30116 и смежные - обход аутентификации и произвольная загрузка файлов). Kaseya об этих уязвимостях знала - патч был в разработке при содействии DIVD. REvil атаковали до того, как патч вышел.

Схема атаки выглядела так:

1. Атакующие получают RCE на on-premise VSA-сервере MSP через уязвимость в веб-интерфейсе.
2. Через скомпрометированный VSA-сервер создают вредоносный «апдейт» - процедуру, которая деплоится на все управляемые машины клиентов автоматически.
3. Агент VSA на клиентских машинах запускает payload с привилегиями SYSTEM. Шифрование начинается.

Ключевой момент: клиентские машины не были атакованы напрямую. Атакующие вошли через инструмент, которому клиент уже дал полный доступ. Проверять подлинность команд от «своего» RMM-агента у большинства клиентов просто не предусмотрено.

Для SaaS-версии Kaseya VSA атака не сработала - Kaseya успела отключить SaaS-инфраструктуру превентивно. Пострадали только on-premise установки.

Что это означает для модели «инструмент = доверие»

После Codecov мы разбирали проблему в контексте CI/CD: внешний скрипт с доступом к окружению - это риск. Kaseya переводит ту же проблему в плоскость production-инфраструктуры. RMM-агент - это не скрипт в пайплайне, это постоянный привилегированный процесс на каждой машине, который по определению умеет выполнять произвольный код.

Интересное наблюдение из разбора атаки: часть систем была защищена антивирусами, которые детектировали payload. Но агент VSA, чтобы корректно работать, часто добавляется в исключения антивируса MSP-провайдером. Таким образом payload, запущенный от имени VSA-агента, шёл мимо AV-проверки. Это не баг в антивирусе - это логика операционной модели MSP, которая в данном случае сработала против защиты.

Что мы делаем со своим стеком

Мы используем несколько RMM-инструментов в работе - не только Kaseya. После того как в пятницу вечером пришли первые сообщения об атаке, начали проходить по собственному стеку и клиентским инфраструктурам. Не в панике - методично.

Первое - инвентаризация агентов с привилегированным доступом. На каждой управляемой машине: какие агенты стоят, какие права у них есть, с какими серверами они соединяются. Это должен быть живой список, а не то, что кто-то помнит. Оказалось, что в нескольких местах стояли агенты от инструментов, от которых мы уже отказались - просто никто их не снёс.

Второе - сегментация управляющего канала. RMM-агент должен соединяться только с известным адресом управляющего сервера, и только через этот канал - не принимать команды из других источников, не открывать широкого доступа внутри сети клиента. На практике это означает: жёсткие firewall-правила для трафика агентов, ограничение lateral movement даже в случае компрометации агента на одной машине.

Третье - мониторинг поведения агентов. Запуск нового процесса с SYSTEM-правами от имени RMM-агента - это нормально в штатной работе. Но запуск cmd.exe /c powershell -encoded ... в нерабочее время или массово на всём флоте - это уже аномалия. Это можно детектировать, если логировать и анализировать process creation events.

Четвёртое - изоляция MSP-доступа. Это самый неудобный разговор с клиентами: агент с полным доступом к машине - это удобно для нас и риск для них. Мы сейчас прорабатываем политику: минимальные необходимые права для каждого типа задач, разделение административного и мониторингового доступа, явная авторизация на деплой изменений в production-среде.

Где сейчас

Kaseya выпустила патч 11 июля - через девять дней после атаки. VSA on-premise пришлось держать отключённым всё это время. Это тоже часть картины: vendor patch cycle и реальные атаки не синхронизированы, и в окне между «уязвимость найдена» и «патч вышел» нужно уметь снижать риск операционными мерами.

У нас работа по аудиту собственного RMM-стека и выработке политики изоляции агентов продолжается - это не задача на неделю. Если коротко: удалённое управление инфраструктурой клиентов требует такой же строгости в части аудита безопасности, как и периметр самого клиента. Инструмент с привилегиями - это часть поверхности атаки, а не исключение из неё.