Huntress фиксирует рост злоупотребления RMM-инструментами - заметная доля инцидентов связана с легитимным софтом для удалённого администрирования в руках атакующих. Red Canary подтверждает: NetSupport Manager серьёзно поднялся в их годовом рейтинге угроз, а ScreenConnect, Atera и SimpleHelp всё чаще оказываются финальным payload в фишинговых кампаниях. Проблема в том, что большинство SOC-команд ловят RMM-агент уже после установки на эндпоинте. А инфраструктура, откуда агент скачивается и куда отстукивает - слепое пятно. Ниже разбираем, как находить серверы управления нелегитимных RMM через IoT-поисковики, какие артефакты выдают атакующего и как превратить находки в actionable IOC.
Злоупотребление RMM инструментами: бизнес-логика атаки и место в kill chain
Злоупотребление RMM-инструментами - не хитрый приём APT-группировок. По данным Huntress, основной объём приходится на low-skill атакующих, которым нужны три вещи: быстрое развёртывание, устойчивый доступ и минимальная детектируемость. RMM даёт всё из коробки: подписанный сертификатом вендора бинарник, трафик через легитимные домены, процесс в белом списке EDR.Red Canary формулирует проблему прямо: даже когда SOC обнаруживает несанкционированный RMM, организация может тянуть с блокировкой - "а вдруг это shadow IT". Пока команда думает, атакующий уже работает hands-on-keyboard.
В терминах MITRE ATT&CK злоупотребление RMM покрывает несколько тактик:
- T1219 (Remote Access Tools, Command and Control) - RMM-агент как канал управления
- T1133 (External Remote Services) - доступ через легитимный удалённый сервис (тактики: Initial Access, Persistence)
- T1078 (Valid Accounts) - атакующий использует trial или free аккаунт вендора как валидную учётную запись (тактики: Defense Evasion, Persistence, Privilege Escalation, Initial Access)
Полная цепочка атаки выглядит так: фишинговая страница или SEO-poisoning -> жертва скачивает MSI-установщик RMM -> установка агента (initial access + persistence через Windows-службу) -> hands-on-keyboard через RMM-консоль -> credential theft, lateral movement -> установка второго RMM (redundant persistence) -> exfiltration или ransomware. Huntress фиксирует случаи, когда LLM-сгенерированные инфостилеры парсили историю браузера в поисках QuickBooks и Coinbase - чёткий индикатор финансовой мотивации.
OSINT-разведка инфраструктуры атакующих через IoT-поисковики
Проактивная охота на угрозы через IoT-поисковики переворачивает логику атакующего. Злоумышленник использует Shodan для разведки целей (T1596.005 - Scan Databases, Reconnaissance) - а defender использует те же инструменты для обнаружения его серверов. Фокус - self-hosted RMM-серверы, которые атакующие разворачивают на VPS (T1583.003 - Virtual Private Server, Resource Development) для полного контроля.
Три платформы работают в связке:
- Shodan - широкое покрытие по баннерам, HTTP-заголовкам, favicon-хешам и SSL-сертификатам. Интервал переиндексации - от часов до дней в зависимости от порта и региона
- Censys - глубже по TLS-сертификатам, поддерживает метки вроде
labels: "open-dir"илиlabels: "remote-access", обновляется чаще для популярных портов - Netlas - удобен для поиска по хешам HTTP body и нестандартным заголовкам, хорошо индексирует высокие порты
Fingerprinting C2 инфраструктуры: HTTP-артефакты и TLS-сертификаты
Каждый self-hosted RMM оставляет характерные HTTP-отпечатки: тайтл страницы логина, набор response headers, тело ответа. Блог Netlas демонстрирует подход на примере SectopRAT: комбинацияhttp.headers.server (значение Microsoft-HTTPAPI/2.0), http.status_code (значение 404) и http.headers.access_control_allow_methods (полный набор методов OPTIONS, HEAD, GET, PUT, POST, DELETE, PATCH) - три поля вместе дают уникальную сигнатуру, по которой вылавливается целый кластер C2-серверов.Для RMM логика та же: каждый продукт при self-hosted деплое отдаёт характерную комбинацию заголовков и контента. Задача - снять эти данные с известного IOC и построить поисковый запрос.
TLS-сертификаты - второй сильный маркер. Атакующие, разворачивающие self-hosted RMM на дешёвом VPS, часто используют самоподписанные сертификаты или Let's Encrypt на свежезарегистрированном домене. Легитимный корпоративный деплой привязан к домену компании с давно действующим сертификатом. В Shodan и Censys сертификаты доступны для поиска по полям
ssl.cert.subject.cn, ssl.cert.issuer.cn, дате выпуска ssl.cert.not_before. Свежий self-signed сертификат на IP из AS дешёвого хостера - уже повод копнуть глубже.Favicon hash и JARM fingerprint
Веб-панели RMM используют специфичные favicon. Shodan вычисляет MurmurHash3 от base64-encoded представления favicon (черезbase64.encodebytes, с line breaks) и хранит его в поле http.favicon.hash. При самостоятельном расчёте хеша - используйте тот же алгоритм, иначе хеши не сойдутся. Один запрос по хешу показывает все хосты с идентичной иконкой в интернете. Если хеш принадлежит панели конкретного RMM - дальше фильтруем: какие инстансы корпоративные, а какие подозрительные.JARM - TLS-fingerprint сервера: инструмент отправляет 10 различных TLS Client Hello и хеширует комбинацию полученных Server Hello, формируя уникальный отпечаток TLS-стека. Одинаковая серверная конфигурация (ОС + TLS-библиотека + версия) даёт одинаковый JARM. Блог Netlas показывает применение на примере Cobalt Strike: дефолтная конфигурация имеет известный JARM-fingerprint, и поиск по нему выявляет серверы, чьи операторы не потрудились изменить TLS-стек.
Но есть нюанс. JARM работает против дефолтных конфигураций. Атакующий, изменивший TLS-параметры (через malleable profile в случае Cobalt Strike или через nginx reverse proxy для RMM), получит другой fingerprint. Против массовых кампаний - отлично. Против подготовленного противника - бесполезно.
Практические запросы для Shodan, Censys и Netlas
[Применимо: внешняя разведка, threat intelligence. Не требует доступа к внутренней сети]
Netlas поиск угроз: универсальный pipeline для любого RMM
Red Canary перечисляет десятки злоупотребляемых RMM: NetSupport Manager, Atera, Splashtop, SimpleHelp, PDQ, Action1, HeartbeatRM, ITarian. Huntress отдельно отмечает HeartbeatRM как менее известный инструмент, который тем не менее активно злоупотребляется через invitation-themed lures. Каждый ищется по аналогичной методологии.Алгоритм для нового RMM-продукта:
- Получить IOC (IP сервера) из TI-фида, инцидента или Abuse.ch SSL Blacklist
- Запросить IP в Shodan (
shodan host <IP>) - зафиксировать: HTTP-тайтл, заголовок Server, статус-код, набор Allow/Access-Control заголовков, данные TLS-сертификата - Выделить уникальную комбинацию артефактов (минимум 2–3 поля, чтобы не утонуть в false positives)
- Построить поисковый запрос с этой комбинацией
- Выполнить запрос - получить список IP
- Отфильтровать: исключить AS вендора, корпоративные AS, IP с валидными корпоративными сертификатами
- Обогатить: VirusTotal (репутация), AbuseIPDB (confidence score), WHOIS (возраст домена, registrar)
Атрибуция инфраструктуры злоумышленников: отделяем легитимное от вредоносного
Найти все self-hosted RMM-серверы - полдела. Дальше надо вычленить нелегитимные. Вот чеклист маркеров подозрительности, выработанный при анализе реальных инцидентов.
| Признак | Легитимный деплой | Атакующий деплой |
|---|---|---|
| Хостинг | Корпоративный AS, dedicated сервер | VPS: DigitalOcean, Vultr, Hetzner, OVH |
| TLS-сертификат | Валидный CA, корпоративный домен в CN | Self-signed или LE на свежем домене |
| Порт | Стандартный (443, вендорский дефолт) | Нестандартный высокий порт |
| Домен | Зарегистрирован давно, корпоративный whois | Свежий (< 30 дней), privacy-protected |
| Reverse DNS | Настроен, соответствует организации | Дефолтный hostname VPS-провайдера |
| Геолокация | Совпадает с регионом компании | Нехарактерный регион |
Huntress отмечает, что большинство наблюдаемых кампаний - mass-scale, с минимальной подготовкой: trial-аккаунты, дефолтные конфигурации, одноразовые VPS. Для таких кампаний чеклист даёт высокую точность. Против подготовленного противника с купленным доменом и настроенным сертификатом - потребуется дополнительный контекст из TI-фидов.
Поиск индикаторов компрометации: от находки до детекта
Результаты hunting-запросов - ещё не IOC. Вот workflow, который превращает находки в детектирующую логику:- Scheduled hunting - еженедельный запуск запросов через API Shodan/Censys. Результаты складываются в MISP, TheHive или, на крайний случай, в spreadsheet с полями: IP, порт, RMM-тип, дата обнаружения, confidence
- Обогащение - автоматическая проверка через VirusTotal API и AbuseIPDB
Python:
# Обогащение через AbuseIPDB - пример для демонстрации концепции
import requests
ip = "203.0.113.42" # IP из результатов hunting-запроса
headers = {"Key": "YOUR_ABUSEIPDB_KEY", "Accept": "application/json"}
resp = requests.get(
f"https://api.abuseipdb.com/api/v2/check?ipAddress={ip}",
headers=headers
)
score = resp.json()["data"]["abuseConfidenceScore"]
# score > 75 → рекомендуется блокировка
# Бесплатный тир: 1000 запросов/день- Кросс-проверка - сопоставление с TI-фидами: MISP CIRCL OSINT, Abuse.ch SSL Blacklist. Совпадение повышает confidence
- Загрузка в SIEM - для Elastic 8.x+: threat intelligence indicator matching через filebeat/logstash. Для MaxPatrol SIEM: табличные списки с IP-индикаторами и правило корреляции на событие network connection. Для Kaspersky KUMA: аналогичный подход через табличные списки. Принцип универсален - конкретная реализация зависит от вашего стека
- Алерт и реагирование - при срабатывании: проверить наличие RMM-агента на хосте-источнике -> если установлен несанкционированный RMM -> изолировать эндпоинт, начать расследование
Ограничения метода: когда Shodan IOC атрибуция не работает
Cloud-hosted RMM. Если атакующий использует облачный SaaS-вариант (ScreenConnect Cloud, Atera Cloud) - сервер управления сидит в инфраструктуре вендора и не виден как отдельный хост в Shodan. Тут нужна эндпоинтная детекция: allowlist/blocklist RMM-бинарников, мониторинг установки служб, поведенческий анализ.Trial-аккаунты. Huntress пишет прямо: любое ПО для развёртывания с trial-доступом или "free tier is being actively abused or is likely to be abused in the near future""Бесплатный период становится легко обмануть или станет легко обмануть в ближайшем будущем". Trial на инфраструктуре вендора - не наш hunting-кейс.
Короткоживущие серверы. VPS, который поднимается на час для доставки MSI и тут же гасится, может не попасть в индекс. Shodan и Censys не сканируют в реальном времени - интервал переиндексации от часов до дней.
CDN и reverse proxy. Сервер за Cloudflare или аналогичным CDN - реальный IP не виден через IoT-поисковики.
False positives. Легитимные MSP-провайдеры разворачивают self-hosted RMM для обслуживания клиентов. Без дополнительного TI-контекста отличить их от атакующего сложно. Чеклист маркеров помогает, но 100% accuracy не даёт.
Метод наиболее эффективен против массовых кампаний low-skill атакующих с дефолтными конфигурациями на одноразовых VPS - а это, по данным Huntress, подавляющее большинство наблюдаемых злоупотреблений.
За пару лет регулярного мониторинга IoT-поисковиков для threat hunting главный вывод оказался не про запросы. Запросы из этой статьи пишутся за минуты и запускаются по расписанию. Проблема в другом: многие SOC-команды, начинающие hunting по внешней инфраструктуре, не имеют актуального инвентаря разрешённых RMM. Red Canary говорит об этом открыто - первый и самый важный шаг: robust allowlist/blocklist policy для RMM-приложений. Пока такой политики нет, hunting через Shodan - латание дыр при отсутствии стен. Профилирование окружения (Red Canary упоминает бесплатный Surveyor для EDR-сканирования) должно идти параллельно с внешним hunting, не вместо него. Тренд RMM-абьюза не замедлится: пока вендоры раздают trial и free tier, атакующие будут это эксплуатировать. Единственное, что масштабируется на стороне защиты - автоматизация: scheduled-запросы через API, авто-обогащение, авто-загрузка IOC в SIEM. Кто не построил этот pipeline - работает в режиме "бежать, чтобы стоять на месте". Если у вас другой стек детекции - на форуме codeby.net обсуждаем, как адаптировать эти правила под конкретные SIEM и EDR.
Последнее редактирование модератором:
