В начале июля исследователи из китайской компании QiAnXin, а точнее её подразделения XLab, обнаружили ботнет, написанный на Go. Назвали его NadMesh — прямо по строке «n4d mesh controller», найденной в исходном коде вредоноса. Отчёт вышел в пятницу, и в нём описана довольно нетипичная для ботнетов охота: не за роутерами и не за камерами, а за облачными сервисами, которые компании разворачивают для работы с искусственным интеллектом.
Через Shodan-харвестер NadMesh ищет открытые инсталляции ComfyUI, Ollama, n8n, Open WebUI, Langflow и Gradio. Это не экзотика — такие панели массово поднимают энтузиасты и небольшие команды, часто без авторизации, потому что «ну кто будет ломать мой локальный сервер генерации картинок». Ломают, как выясняется, довольно активно.
XLab поставила собственные сенсоры и получила независимую картину: количество уникальных IP-адресов, с которых распространяется NadMesh, было почти нулевым до конца июня, а в первую неделю июля подскочило примерно до 139 в сутки. Это уже похоже на настоящую кампанию, а не на тестовый запуск.
Любопытнее всего то, что показывает собственная панель оператора ботнета, попавшая в руки исследователей 10 июля. Цифры там расходятся между собой настолько, что это скорее похоже на плохо склеенную аналитику, чем на достоверную статистику. Панель заявляет 3811 уникальных AWS-ключей и счётчик развёртываний в 17700, но при этом «воронка» за последние 24 часа показывает 95700 — цифра, которая просто не бьётся с числом деплоев. На одном тайле активных ботов указано 16, на другом — 12. Единственное, что совпадает — число похищенных учётных данных, оно указано дважды и одинаково. В последних 100 записях внутреннего фида значится 47 случаев кражи credentials и 41 инвентаризация моделей, среди которых помечены тегом «:cloud» DeepSeek, GLM и Kimi.
Отдельно панель хвастается 12100 «эксплуатируемыми» MCP-сервисами и 21 уязвимостью MCP. Но когда XLab посмотрела те самые 100 записей интел-фида, ни одной MCP-уязвимости там не оказалось. То есть оператор либо приукрашивает статистику для собственного отчёта, либо панель управления просто работает криво.
Что бот утаскивает домой — список довольно неприятный: ключи из переменных окружения облачных провайдеров, токены сервис-аккаунтов Kubernetes, содержимое
История с эксплуатацией AI-сервисов не началась с NadMesh. Ещё в апреле The Hacker News писал о другом операторе, который через Censys нашёл открытые ComfyUI-инсталляции и использовал их для майнинга на GPU — Monero и Conflux, а заодно поднимал прокси-ноды Hysteria для перепродажи трафика. Тогда эта кампания была узкой, заточенной именно под ComfyUI. Censys в своей финальной оценке 27 мая прямо предупреждала, что открытые MCP-инструменты для выполнения команд рано или поздно станут частью какой-нибудь ботнет-инфраструктуры или инструментом злоупотребления. NadMesh появился ровно через семь недель после этого прогноза — только цель у него уже не GPU-мощности, а облачные учётные данные и привилегии в Kubernetes. Сеть заброшена шире, добыча ценнее, а сама логика атаки эволюционировала от кражи вычислительных ресурсов к краже доступа.
Через Shodan-харвестер NadMesh ищет открытые инсталляции ComfyUI, Ollama, n8n, Open WebUI, Langflow и Gradio. Это не экзотика — такие панели массово поднимают энтузиасты и небольшие команды, часто без авторизации, потому что «ну кто будет ломать мой локальный сервер генерации картинок». Ломают, как выясняется, довольно активно.
XLab поставила собственные сенсоры и получила независимую картину: количество уникальных IP-адресов, с которых распространяется NadMesh, было почти нулевым до конца июня, а в первую неделю июля подскочило примерно до 139 в сутки. Это уже похоже на настоящую кампанию, а не на тестовый запуск.
Любопытнее всего то, что показывает собственная панель оператора ботнета, попавшая в руки исследователей 10 июля. Цифры там расходятся между собой настолько, что это скорее похоже на плохо склеенную аналитику, чем на достоверную статистику. Панель заявляет 3811 уникальных AWS-ключей и счётчик развёртываний в 17700, но при этом «воронка» за последние 24 часа показывает 95700 — цифра, которая просто не бьётся с числом деплоев. На одном тайле активных ботов указано 16, на другом — 12. Единственное, что совпадает — число похищенных учётных данных, оно указано дважды и одинаково. В последних 100 записях внутреннего фида значится 47 случаев кражи credentials и 41 инвентаризация моделей, среди которых помечены тегом «:cloud» DeepSeek, GLM и Kimi.
Отдельно панель хвастается 12100 «эксплуатируемыми» MCP-сервисами и 21 уязвимостью MCP. Но когда XLab посмотрела те самые 100 записей интел-фида, ни одной MCP-уязвимости там не оказалось. То есть оператор либо приукрашивает статистику для собственного отчёта, либо панель управления просто работает криво.
Что бот утаскивает домой — список довольно неприятный: ключи из переменных окружения облачных провайдеров, токены сервис-аккаунтов Kubernetes, содержимое
~/.aws/config, файлов .env, ~/.docker/config.json, доступ к моделям и, что важнее всего, возможность вызывать инструменты по протоколу MCP (Model Context Protocol). Контроллер задаёт чёткий приоритет атаки: сначала MCP, затем Kubernetes, потом Docker API, и только в конце Redis. Вектор через MCP реализован через JSON-RPC вызов tools/call к методу execute_command» — и, что важно отметить отдельно, никакого CVE тут нет. Это не уязвимость в привычном смысле, а особенность самого протокола.
Дело в том, что изначальная спецификация MCP вообще выносила аутентификацию за пределы ядра протокола. В марте 2025 года добавили флоу авторизации, но сделали его опциональным — то есть разработчик сервиса может его просто не включить. Censys фиксировала рост открытых MCP-сервисов: 28 апреля — 12520 штук на 8758 IP-адресах, а уже 6 мая — больше 21000. Из них около 90 сервисов открыто рекламировали инструмент для выполнения команд, а 39 из них назывались буквально execute_command. То есть уязвимость была видна невооружённым глазом задолго до появления NadMesh.
При этом реальный трафик атак, зафиксированный сенсорами XLab, рисует другую картину, чем панель оператора. Основная масса попыток эксплуатации всё ещё приходится на старую добрую инфраструктуру:
[]docker_containers_api_rce — 30,31%
[]jenkins_scripttext_rce — 22,28%
[]слабые пароли Telnet — 10,36%
[]Redis — 8,29%
[]CVE-2022-22947 (Spring Cloud Gateway) — 6,48%
[]CVE-2017-12611 (Struts Freemarker) — 4,15%
[]mcp_cmd_execute — 0,78%
Получается интересный разрыв: сама добыча (украденные ключи, модели, MCP-доступ) действительно новая и заточена под AI-инфраструктуру, но основной объём попыток взлома всё ещё бьёт по старым добрым дырам — открытым Docker-сокетам и консолям Jenkins. Диаграмма показывает попытки атаки, а не заявленные оператором успехи, и это разные вещи.
Сам ботнет устроен как самообучающийся сканер. Продуктивные подсети пересканируются каждые 5 минут. IP-адреса, помеченные как опасные за последние 24 часа, проверяются заново каждые 15 минут уже как отдельные /32-адреса, причём AI-порты идут первыми в очереди. Раз в 7 дней происходит полная зачистка всего, что было помечено опасным. Если у бота заканчивается очередь целей — он просто генерирует случайную подсеть /24 и продолжает работу. Есть и защитный механизм: 10 неудачных попыток развёртывания на одной цели — и она автоматически заносится в чёрный список как подозреваемый honeypot. XLab трактует это как прямое доказательство того, что автор ботнета заранее закладывался на мониторинг со стороны исследователей.
Инфраструктура сборки тоже выдаёт зрелость проекта. Одновременно работают пять версий билда, 11 ботов сидят на версии 33.8-GO-TITAN, а отстающие всё ещё используют версию 30.0. Есть canary-эндпоинт, который выкатывает новые сборки на часть флота: он отдал 5448 ответов и 84024 null-ответа. При этом внутренняя система подсчёта успеха в панели явно исключает из зачёта харвест Ollama и AWS — то есть собственная же статистика оператора не учитывает реально украденные активы. Зачем так сделано — неясно, возможно, просто недоделанная метрика, возможно, сознательное занижение для внешних отчётов перед заказчиками ботнета.
Персистентность у NadMesh тройная: удаление одного механизма закрепления оставляет ещё два рабочих. Каждая сборка проходит через обфускатор Garble, упаковывается UPX с флагом -9 и получает случайный паддинг. В итоге хеши агентов не совпадают между собой вообще никогда — опубликованный образец хеша ловит буквально одну-единственную сборку из пяти.
Для защиты в первую очередь стоит закрыть порты, которые сканер проверяет в первую очередь: 8188 (ComfyUI), 11434 (Ollama), 7860 (Gradio), 5678 (n8n). Дальше идут вещи, которые не лечатся патчем, только конфигурацией: открытый Docker API на 2375 порту, консоль скриптов Jenkins, неаутентифицированный Redis, слабые пароли Telnet и SSH. А вот реальные патчи нужны для CVE-2026-39987 — предаутентификационного RCE в блокнотах Marimo до версии 0.23.0, который CISA внесла в KEV в апреле и который начали эксплуатировать буквально в течение нескольких часов после публикации. Ещё один — CVE-2026-41176, позволяющий неаутентифицированному вызывающему переключить флаг rc.NoAuth на RC-серверах rclone версий с 1.45.0 по 1.73.5, запущенных без HTTP-авторизации. Риск тут прямой: конфиги rclone часто содержат готовые облачные учётные данные.
Стоит проверить систему на подозрительные файлы и пути: неопознанные ключи в ~/.ssh/authorized_keys, а также /dev/shm/.a, /var/tmp/.a, /tmp/.a, /etc/cron.d/.sys_monitor и /etc/cron.d/.s. Если компрометация подтвердилась, порядок действий такой: сначала изолировать хост, затем отозвать (именно отозвать, а не просто повернуть) все доступные с него учётные данные — AWS-ключи, токены кластера, содержимое .env, логины реестров контейнеров. Важный момент: механизмы персистентности нужно удалить раньше выпуска новых ключей, иначе новые credentials окажутся скомпрометированы точно так же, как старые. И уже после этого стоит проверить, где именно старые учётные данные использовались, пока были действительны.
Индикаторы компрометации, зафиксированные XLab: управляющий сервер по адресу 209.99.186[.]235, домен cdnorigin[.]net и хеш образца SHA1 31c69b3e12936abca770d430066f379ec1d997ec`. История с эксплуатацией AI-сервисов не началась с NadMesh. Ещё в апреле The Hacker News писал о другом операторе, который через Censys нашёл открытые ComfyUI-инсталляции и использовал их для майнинга на GPU — Monero и Conflux, а заодно поднимал прокси-ноды Hysteria для перепродажи трафика. Тогда эта кампания была узкой, заточенной именно под ComfyUI. Censys в своей финальной оценке 27 мая прямо предупреждала, что открытые MCP-инструменты для выполнения команд рано или поздно станут частью какой-нибудь ботнет-инфраструктуры или инструментом злоупотребления. NadMesh появился ровно через семь недель после этого прогноза — только цель у него уже не GPU-мощности, а облачные учётные данные и привилегии в Kubernetes. Сеть заброшена шире, добыча ценнее, а сама логика атаки эволюционировала от кражи вычислительных ресурсов к краже доступа.
