Когда я впервые расследовал инцидент, где атакующие использовали легитимный ConnectWise ScreenConnect для lateral movement по сети из 800 эндпоинтов, первый вопрос от руководства был: «Почему антивирус это пропустил?» Ответ до обидного прост - RMM-агент не вредонос. Он подписан доверенным сертификатом, работает с SYSTEM-привилегиями и генерирует трафик, который firewall считает родным. Антивирус его «пропустил» ровно потому, что для антивируса это свой. Именно поэтому харденинг RMM систем - не пункт в бэклоге «на потом», а критический контроль, без которого ваша сеть - проходной двор для любого, кто получит доступ к управляющему агенту.
Ниже - конкретные шаги по сегментации сети RMM, настройке least privilege для управляющих агентов, написанию detection-правил и харденингу конфигураций. С реальными конфигами, Sigma-правилами и KQL-запросами, которые можно внедрить в тот же день.
Почему RMM-агенты стали главным вектором атак
Безопасность RMM агентов долго оставалась слепым пятном Blue Team. Все силы шли на EDR, SIEM-корреляции и патч-менеджмент, а RMM-платформы воспринимались как внутренний инструмент - мол, что с ним может случиться? Атакующие это заметили раньше защитников.По данным Huntress 2025 Cyber Threat Report, количество инцидентов со злоупотреблением RMM-инструментами заметно выросло в 2024 году. Значительная доля подозрительной активности через Atera связана с развёртыванием ransomware. Согласно Red Canary Threat Detection Report 2025, RMM стали предпочтительным payload у финансово мотивированных атакующих и ransomware-аффилиатов: NetSupport Manager поднялся с 7-го на 4-е место в рейтинге угроз.
Почему атакующие выбирают именно RMM:
- Агент работает с привилегиями SYSTEM/root - ему нужны максимальные права для патчинга, установки ПО, изменения конфигураций. Компрометация агента = компрометация хоста. Без промежуточных шагов.
- Коммуникация идёт через инфраструктуру вендора - домены ConnectWise, Atera, NinjaRMM. Это трафик, который proxy и firewall пропускают без вопросов, потому что он и правда легитимный.
- RMM-агент автоматически переподключается при разрыве связи, переживает перезагрузки, работает как сервис. Идеальный backdoor - и писать ничего не надо, persistence уже встроен.
- Подписанные бинарники RMM-вендоров не вызывают срабатываний сигнатурных движков. По MITRE ATT&CK это
Ссылка скрыта от гостей, тактика Command and Control).
Кейс
Ссылка скрыта от гостей
: когда одна уязвимость открывает тысячи сетей
Показательный пример - CVE-2024-1709 в ConnectWise ScreenConnect версий 23.9.7 и ниже. Authentication Bypass Using an Alternate Path or Channel (CWE-288) - атакующий получает прямой доступ к критическим системам вообще без аутентификации.Вектор CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H - максимальная оценка 10.0 (CRITICAL). Разберём: сетевой доступ (AV:N), низкая сложность (AC:L), не нужны привилегии (PR:N), не нужно действие пользователя (UI:N), выход за границы scope (S:C), максимальное воздействие на конфиденциальность, целостность и доступность. По данным SentinelOne, в течение нескольких дней после раскрытия уязвимость массово использовалась для развёртывания ransomware.
Согласно CISA Advisory AA25-163A, эксплуатация уязвимостей в SimpleHelp RMM привела к нарушениям работы сервисов, затронувшим провайдера биллингового ПО и его нижестоящих клиентов. Одна дыра в RMM - и по цепочке летит целый supply chain.
Инвентаризация: найдите все RMM в своей сети
Прежде чем говорить о защите ITSM инфраструктуры и харденинге, нужно ответить на базовый вопрос: какие RMM-инструменты реально крутятся в вашей среде? Лично у меня в практике - в средней организации от 500 эндпоинтов обнаруживается 2–4 «теневых» RMM помимо официально утверждённого. Кто-то из IT-поддержки поставил AnyDesk «для удобства», подрядчик оставил TeamViewer, а на паре хостов из прошлого проекта тихо живёт устаревшее решение.По данным Red Canary, в 2025 году зафиксировано злоупотребление: NetSupport Manager, ScreenConnect, AnyDesk, TeamViewer, Atera, ITarian (Comodo), PDQ, SimpleHelp, RustDesk. Атакующие осознанно выбирают тот RMM, который уже разрешён в целевой среде - так детектирование усложняется на порядок.
Практический шаг: сканирование среды
Для обнаружения неавторизованных RMM используйте EDR-телеметрию. KQL-запрос для Microsoft Sentinel, который ищет процессы известных RMM-инструментов:
Код:
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName in~(
"ScreenConnect.ClientService.exe",
"AnyDesk.exe",
"TeamViewer.exe",
"aaborern.exe", // Atera agent
"ninjarmmagent.exe",
"rustdesk.exe",
"client32.exe", // NetSupport Manager
"SimpleHelp.exe",
"PDQInventoryConsole.exe"
)
| summarize
FirstSeen = min(Timestamp),
LastSeen = max(Timestamp),
HostCount = dcount(DeviceName),
Hosts = make_set(DeviceName, 50)
by FileName
| sort by HostCount descСегментация сети RMM: изолируйте плоскость управления
Сегментация сети RMM - один из самых эффективных и при этом недооценённых контролей. В большинстве сетей, которые я аудировал, RMM-сервер сидел в том же VLAN, что и рабочие станции пользователей. Это значит: компрометация одного хоста даёт атакующему прямой сетевой доступ к management console. Красота, правда?Целевая архитектура
Выделите отдельный управляющий сегмент (Management VLAN) со следующими правилами:| Направление | Источник | Назначение | Порт | Действие |
|---|---|---|---|---|
| Агент к серверу | Workstation VLAN | Management VLAN | 443/TCP (TLS) | Разрешить |
| Консоль администратора | Admin Jump Host | Management VLAN | 8040/TCP (web console) | Разрешить |
| Прямой доступ | Workstation VLAN | Management VLAN | Все прочие | Запретить |
| Исходящий от сервера | Management VLAN | Internet | vendor-domains (allowlist) | Разрешить |
| Между сегментами | Management VLAN | Production VLAN | Все | Запретить |
Пример правила iptables для RMM-сервера в Linux-сегменте:
Bash:
# Разрешить входящие подключения от агентов только по 443
iptables -A INPUT -s 10.10.0.0/16 -p tcp --dport 443 -j ACCEPT
# Разрешить доступ к web-консоли только с jump host
iptables -A INPUT -s 10.20.1.5/32 -p tcp --dport 8040 -j ACCEPT
# Всё остальное - в дропы
iptables -A INPUT -j DROP
# Разрешить исходящий только к вендорским доменам (через ipset)
ipset create rmm_vendor_ips hash:ip
ipset add rmm_vendor_ips 52.x.x.x # пример - актуальные IP уточнять у вендора
iptables -A OUTPUT -m set --match-set rmm_vendor_ips dst -p tcp --dport 443 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 443 -j DROPLeast privilege для управляющих агентов: RBAC и PAM
Самая частая ошибка, которую я встречаю при аудите, - все техники поддержки имеют одинаковый уровень доступа в RMM-консоли: полный. L1, L2, админ - все как один с God Mode. По данным Deepwatch, принцип least privilege должен распространяться на гранулярный контроль над скриптами, remote shell и файловыми операциями в рамках RMM-платформы.Настройка RBAC в RMM-платформе
Создайте минимум три роли:| Роль | Remote View | Remote Shell | Script Execution | File Transfer | Agent Deploy/Remove | Manage Users |
|---|---|---|---|---|---|---|
| L1 Support | Да | Нет | Нет | Нет | Нет | Нет |
| L2 Engineer | Да | Ограничен (read-only) | Предутверждённые скрипты | Нет | Нет | Нет |
| RMM Admin | Да | Да | Да | Да | Да | Да |
Роль RMM Admin - не более 2–3 учётных записей. MFA обязателен, привязка к PAM-решению обязательна.
Интеграция с PAM
При использовании CyberArk или BeyondTrust настройте just-in-time (JIT) доступ к административным учёткам RMM:- Администратор запрашивает доступ через PAM-портал с указанием причины.
- PAM выдаёт временные credentials с TTL 2–4 часа.
- Сессия записывается (session recording).
- По истечении TTL пароль автоматически ротируется.
Пример политики GPO для ограничения установки RMM-агентов на хостах:
Код:
# Блокировка запуска неутверждённых RMM через AppLocker
# Адаптируйте под вашу среду
New-AppLockerPolicy -RuleType Publisher -Action Deny `
-FileInformation "AnyDesk.exe" `
-User "Everyone" | Set-AppLockerPolicy -Merge
New-AppLockerPolicy -RuleType Publisher -Action Deny `
-FileInformation "TeamViewer.exe" `
-User "Everyone" | Set-AppLockerPolicy -MergeМониторинг RMM активности: Sigma-правила и KQL-запросы
Детектирование злоупотреблений RMM - головная боль Blue Team. Атакующий использует тот же бинарник и тот же трафик, что и легитимный администратор. Детектировать нужно не инструмент, а аномальное поведение. Разница тонкая, но принципиальная.Базовая линия: что считать нормой
Прежде чем писать правила, определите baseline (Huntress рекомендует то же самое):- Какие RMM утверждены в среде?
- Какие пользователи обычно инициируют сессии?
- В какое время суток происходят подключения?
- С каких IP-адресов подключаются администраторы?
Sigma-правило: обнаружение неавторизованного RMM
YAML:
title: Unauthorized RMM Tool Execution
id: 7c3b2a1f-5d6e-4a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: >
Detects execution of RMM tools that are not approved
in the corporate environment. Adapt the exclusion list
to your approved RMM toolset.
references:
- https://attack.mitre.org/techniques/T1219/002
logsource:
category: process_creation
product: windows
detection:
selection_rmm:
Image|endswith:
- '\AnyDesk.exe'
- '\TeamViewer.exe'
- '\client32.exe' # NetSupport Manager
- '\rustdesk.exe'
- '\SimpleHelp.exe'
- '\Supremo.exe'
- '\RemotePC.exe'
# filter_approved:
# Uncomment and populate with your sanctioned RMM binaries, e.g.:
# Image|endswith:
# - '\ScreenConnect.ClientService.exe'
condition: selection_rmm # Add 'and not filter_approved' once filter is populated
falsepositives:
- Legitimate use by IT staff with unapproved tools
- Vendor support sessions
level: high
tags:
- attack.command_and_control
- attack.t1219
- attack.t1219.002Sigma-правило: аномальное время RMM-сессии
YAML:
title: RMM Session Outside Business Hours
id: 8d4c3b2e-6f7a-5b9c-0d1e-2f3a4b5c6d7e
status: experimental
description: >
Detects RMM agent network connections initiated outside
normal business hours (before 07:00 or after 20:00 local time).
logsource:
category: network_connection
product: windows
detection:
selection:
Image|endswith:
- '\ScreenConnect.ClientService.exe'
- '\ninjarmmagent.exe'
- '\aaborern.exe'
Initiated: 'true'
# NOTE: Sigma не поддерживает нативную фильтрацию по времени суток.
# Реализуйте time-based фильтр на уровне SIEM-бэкенда:
# KQL: | where hourofday(TimeGenerated) < 7 or hourofday(TimeGenerated) > 20
# SPL: | where date_hour<7 OR date_hour>20
condition: selection
level: medium
tags:
- attack.command_and_control
- attack.t1219.002KQL-запрос для Microsoft Sentinel: поиск Shadow RMM
Код:
// Обнаружение установки нового RMM-сервиса
DeviceEvents
| where Timestamp > ago(7d)
| where ActionType == "ServiceInstalled"
| where FileName in~(
"AnyDesk.exe", "TeamViewer_Service.exe",
"client32.exe", "rustdesk.exe",
"SimpleService.exe"
)
| project Timestamp, DeviceName, FileName,
FolderPath, InitiatingProcessAccountName
| join kind=leftanti (
// Таблица утверждённых RMM - замените на вашу watchlist
_GetWatchlist('ApprovedRMM')
| project FileName = SearchKey
) on FileNameSplunk-запрос: массовое подключение RMM к новым хостам
Код:
index=sysmon EventCode=3
(Image="*\\ScreenConnect.ClientService.exe"
OR Image="*\\ninjarmmagent.exe")
| stats dc(DestinationIp) as unique_destinations
values(DestinationIp) as dest_ips
by SourceHostname, Image, _time span=1h
| where unique_destinations > 10
| sort - unique_destinationsХарденинг конфигурации RMM-платформ
Безопасность удалённого управления начинается с конфигурации самих платформ. Ниже - чеклист харденинга, собранный по моему опыту работы с ConnectWise, NinjaRMM, Datto и Atera.Аутентификация и доступ
MFA обязателен для всех учётных записей консоли. Предпочтительно FIDO2/аппаратные токены - SMS-ки атакующие перехватывают через SIM-swap, и это не теория. Согласно
Ссылка скрыта от гостей
, атакующие целенаправленно охотятся за скомпрометированными учётными данными RMM через фишинг и покупку на даркнет-площадках.Ограничение по IP - доступ к web-консоли только с IP-адресов корпоративной сети или VPN. В ConnectWise ScreenConnect это настраивается через
web.config:
XML:
<!-- Пример ограничения доступа к консоли по IP -->
<security>
<ipFilter allowUnlisted="false">
<add ipAddress="10.20.1.0" subnetMask="255.255.255.0" allowed="true" />
<add ipAddress="198.51.100.5" allowed="true" />
</ipFilter>
</security>Отключите remote shell для ролей, которым он не нужен. В NinjaRMM это настраивается на уровне политики устройства. Если L1-инженеру не нужен shell - значит, у L1-инженера нет shell. Точка.
Обновления и supply chain
Включите автообновление RMM-платформы или установите жёсткий SLA на применение патчей - не более 48 часов для критических. Вспомните CVE-2024-1709: задержка с обновлением ConnectWise ScreenConnect означала полный Authentication Bypass с CVSS 10.0. Кто затянул с патчем - тот получил ransomware.Проверяйте цифровые подписи обновлений. TLS 1.2/1.3 для всех коммуникаций - тут без компромиссов.
Отключение ненужных функций
На каждой RMM-платформе отключите то, что не используется:| Функция | Риск если включена | Рекомендация |
|---|---|---|
| File Transfer | Эксфильтрация данных | Отключить для L1-L2, аудитировать для Admin |
| Remote Shell | Выполнение произвольных команд | Только для RMM Admin через PAM |
| Unattended Access (без подтверждения пользователя) | Скрытый доступ атакующего | Ограничить по расписанию и IP |
| Agent auto-enrollment | Развёртывание rogue-агентов | Требовать одобрения от Admin |
| API access | Автоматизация атак | Ротация ключей каждые 90 дней, IP-фильтрация |
Принцип простой: если функция включена «на всякий случай» - она включена для атакующего тоже.
Контроль доступа ITSM: защита сервис-деска как вектора атаки
Отдельная история - злоупотребление ITSM-платформами (ServiceNow, Jira Service Management, Freshservice) для социальной инженерии. Атакующий звонит в сервис-деск, представляется сотрудником и просит «поставить TeamViewer для удалённой работы». По данным Huntress, такие help-desk themed phishing-кампании стали одним из основных векторов первоначального доступа. Сервис-деск - это не просто тикетная система, это ещё один периметр.Контроль доступа ITSM должен включать:
- Верификацию запросов на установку любого ПО для удалённого доступа через второй канал - звонок руководителю, подтверждение в корпоративном мессенджере. Да, это неудобно. Да, это необходимо.
- Workflow-автоматизацию: запрос на установку RMM-агента в ITSM должен требовать approval от Security Team.
- Логирование всех операций - каждая установка агента через ITSM-тикет фиксируется с привязкой к конкретному инженеру и тикету.
Реагирование на компрометацию RMM: пошаговый план
Когда detection-правило сработало и подозрение на злоупотребление RMM подтверждается - счёт идёт на минуты. Вот план, который я использую.Первые 15 минут: containment
- Изолируйте хост через EDR (network isolation). Не выдёргивайте кабель - нужно сохранить volatile memory.
- Отзовите все активные сессии в RMM-консоли для скомпрометированного агента.
- Заблокируйте учётную запись технического специалиста, если подозревается credential theft.
15–60 минут: оценка масштаба
- Проверьте логи RMM-платформы: какие команды выполнялись в скомпрометированной сессии? Многие RMM ведут собственные логи активности - копайте там.
- Проверьте, не установлен ли вторичный RMM. Атакующие часто разворачивают второй инструмент как backup-канал. Red Canary отмечает, что два RMM одновременно - уже обычная практика среди атакующих.
- Оцените lateral movement: запустите KQL/Splunk-запрос по сетевым подключениям с хоста за последние 24 часа.
1–4 часа: eradication
- Удалите нелегитимного агента. Учтите - атакующий мог отключить стандартную деинсталляцию. В этом случае: остановите сервис, удалите файлы и реестровые записи вручную.
Код:
# Принудительное удаление rogue RMM (AnyDesk)
Stop-Service -Name "AnyDesk" -Force -ErrorAction SilentlyContinue
Stop-Process -Name "AnyDesk" -Force -ErrorAction SilentlyContinue
Remove-Item -Path "C:\ProgramData\AnyDesk" -Recurse -Force
Remove-Item -Path "$env:APPDATA\AnyDesk" -Recurse -Force
# Удалите сервис
sc.exe delete "AnyDesk"- Ротируйте все credentials, которые могли быть доступны со скомпрометированного хоста: сервисные учётные записи, API-ключи RMM, пароли локальных администраторов. Всё, до чего мог дотянуться SYSTEM на этом хосте - считайте скомпрометированным.
Сводный чеклист харденинга RMM систем
| Категория | Мера | Приоритет |
|---|---|---|
| Инвентаризация | Создать реестр всех RMM в среде, внедрить allowlist/blocklist | Критический |
| Сегментация | Выделить Management VLAN, ограничить firewall-правилами | Критический |
| Аутентификация | MFA (FIDO2) для консоли, ограничение по IP, таймаут сессий 15 мин | Критический |
| Least privilege | RBAC с тремя ролями минимум, интеграция с PAM для admin-доступа | Высокий |
| Патч-менеджмент | SLA 48 часов на критические обновления RMM-платформы | Критический |
| Мониторинг | Sigma-правила для shadow RMM, baseline-аналитика по времени и пользователям | Высокий |
| SIEM-интеграция | Экспорт логов RMM в Sentinel/Splunk, корреляция с EDR-телеметрией | Высокий |
| Харденинг конфигурации | Отключить неиспользуемые функции, TLS 1.2+, ротация API-ключей | Высокий |
| ITSM-контроль | Workflow с approvals на установку агентов, верификация запросов | Средний |
| IR-готовность | Документированный runbook для RMM-компрометации, проверка в табличных учениях | Средний |
Заключение
Харденинг управляющих агентов - не проект с датой завершения. Это постоянная работа на стыке IT-операций, ИБ-команды и сервис-деска. Главный сдвиг в мышлении, который я стараюсь донести: присутствие утверждённого инструмента не равно безопасности. Когда Atera, ScreenConnect или NinjaRMM появляется в логах - это не повод расслабиться, а сигнал проверить: кто именно, откуда и зачем инициировал сессию.Начните с инвентаризации (KQL-запрос из раздела выше - копируйте и запускайте прямо сейчас). Внедрите сегментацию и базовые Sigma-правила, потом наращивайте зрелость через PAM-интеграцию и behavioral analytics. Атакующие продолжат использовать ваши легитимные инструменты против вас. Ваша задача - сделать так, чтобы каждое такое злоупотребление обнаруживалось за минуты, а не за месяцы.
Запустите тот KQL и посмотрите, сколько «теневых» RMM живёт в вашей сети. Готов поспорить - сюрпризы будут.
Последнее редактирование модератором:
