Hack The Box: как MCP Inspector превращает AI-инструменты в новую точку атаки

История с машиной Kobold из Hack The Box Season 10 показывает важную вещь: новые риски вокруг AI появляются не только в самих моделях, но и в инструментах, которыми их обслуживают разработчики. В этом разборе стартовая точка атаки находится в MCP Inspector — dev-утилите для AI-серверов. Дальше цепочка развивается по знакомому для инфраструктурной безопасности сценарию: выполнение кода, чтение локальных файлов внутри контейнера, повторное использование учётных данных и повышение привилегий через Docker, вплоть до полного захвата системы.

Kobold позиционируется как Easy-машина, но её ценность не в сложности эксплуатации, а в реалистичности связки уязвимостей. Автор показывает, как сервис для отладки и инспекции MCP-компонентов может внезапно стать внешним периметром. Для команд, которые собирают AI-стек из серверов, коннекторов и вспомогательных инструментов, это неприятное напоминание: всё, что подключено к модели и имеет доступ к локальной среде, автоматически становится частью поверхности атаки.

И именно такие элементы часто защищены слабее всего, потому что считаются внутренними, временными или «только для разработчиков». Первый этап цепочки — RCE через MCP Inspector. Сам по себе этот шаг уже меняет картину угроз: злоумышленнику не нужно ломать основное приложение, если рядом есть менее защищённый инструмент с расширенными возможностями.

После получения выполнения кода внутри контейнера атакующий переходит к LFI, то есть к чтению локальных файлов. На практике это один из самых продуктивных этапов любой атаки на контейнеризированные сервисы: конфиги, переменные окружения, журналы, ключи, служебные токены и артефакты сборки часто лежат в предсказуемых местах. Даже если сами секреты не выданы напрямую, утечка структуры каталогов, имён сервисов или внутренних адресов уже помогает ускорить дальнейшее продвижение.

Следующий важный момент — повторное использование учётных данных. В AI-проектах это особенно частая проблема: команды быстро поднимают экспериментальные сервисы, копируют .env-файлы, дублируют пароли между контейнерами и оставляют одинаковые учётные данные для разных ролей.

В разборе именно reuse секретов помогает перейти от локального доступа к более чувствительным компонентам системы, а затем использовать ошибки в Docker-конфигурации для повышения привилегий. В материале показаны два независимых пути до полного контроля над машиной, и это подчёркивает главную мысль: если у атакующего уже есть код внутри контейнера, то сокет Docker, лишние capability, небезопасные монтирования и слишком широкий доступ к ресурсам хоста быстро превращают контейнер из барьера в удобную промежуточную точку. Отдельно полезно, что автор маппит атаку на MITRE ATT&CK.

Такой разбор превращает пошаговое взятие машины в прикладной материал для защитников: видно не только последовательность действий, но и классы техник — начальное исполнение, discovery, collection, credential access, lateral movement и privilege escalation. Это помогает blue team и DevSecOps соотнести лабораторный сценарий с реальными журналами, алертами и мерами детекта. Главный тезис выходит далеко за рамки одной машины: MCP-экосистема, включая инспекторы, прокси, коннекторы и локальные мосты к файлам, сети и секретам, становится новой поверхностью атаки именно потому, что живёт на стыке сразу нескольких доверенных зон.

Что это значит на практике? Командам, которые строят AI-сервисы, уже недостаточно защищать только API модели и пользовательский интерфейс. Нужно выносить dev-инструменты из публичного доступа, включать аутентификацию даже для «внутренних» утилит, запрещать повторное использование секретов, урезать права контейнеров, проверять Docker-настройки и логировать действия вокруг MCP-компонентов так же внимательно, как вокруг основных сервисов в продакшене.

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