Разбор машины Kobold из 10-го сезона HackTheBox. Это easy-машина с интересной цепочкой уязвимостей: chaining через Docker volumes, reuse учётных данных и два пути до root. Главная изюминка — точка входа через RCE в инструменте из экосистемы ИИ. Спойлер: уязвимость в MCP-тулзе. Новый attack surface, который важно учитывать при пентестах.

Сканирование портов

Начинаем с полного сканирования портов с помощью Nmap. Обнаружено четыре открытых TCP-порта:

• OpenSSH 9.6p1 Ubuntu — свежая версия, без известных CVE.
• nginx 1.24.0 — редирект на https://kobold.htb.
• nginx 1.24.0 (SSL) — на порту 443, с заголовком «Kobold Operations Suite».
• Порт 3552 — не распознан Nmap, но содержит HTTP-сервис.

SSH недоступен без учётных данных, порт 80 редиректит на HTTPS. Основные цели — порты 443 и 3552.

Ключевая находка: SSL-сертификат на 443 порту содержит wildcard *.kobold.htb в Subject Alternative Name. Это сигнал: нужно искать сабдомены.

Исследование веб-приложений

Открываем https://kobold.htb — статичный лендинг без интерактива. Тупик.

Порт 3552: при попытке доступа по HTTPS — ошибка wrong version number. Сервис работает по HTTP. Открываем http://kobold.htb:3552.

Перед нами — Arcane v1.13.0, панель управления Docker. Форма входа с полями Username/Password. Внизу — ссылка на GitHub и версия. Без логина не пройти. Запоминаем.

Поиск сабдоменов

Wildcard в сертификате указывает на наличие сабдоменов. Используем ffuf для vhost-энумерации.

Находим один сабдомен: mcp.kobold.htb. Добавляем его в /etc/hosts.

MCPJam Inspector — точка входа

Открываем https://mcp.kobold.htb.

Перед нами — MCPJam Inspector v1.4.2, платформа для разработки MCP-серверов. Полный доступ без аутентификации: Servers, Chat, App Builder, Tools, Settings. В настройках видим подключённый Ollama и версию v1.4.2.

Model Context Protocol (MCP) — стандарт для интеграции ИИ-моделей с внешними инструментами. Такие dev-тулзы всё чаще попадают в production без защиты.

Получение доступа (Foothold)

Уязвимость: GHSA-232v-j27c-5pp6

MCPJam Inspector ≤1.4.2 уязвим к RCE. Причины:

1. Слушает на 0.0.0.0 вместо 127.0.0.1 — API доступен извне.
2. Эндпоинт /api/mcp/connect принимает serverConfig.command — произвольную команду без аутентификации и валидации.

Это задокументированный функционал, который в публичном доступе превращается в RCE за один запрос.

Эксплуатация

Запускаем listener на атакующей машине.

Отправляем payload, который выполняет reverse shell.

Получаем соединение как пользователь ben. Стабилизируем shell: теперь работают стрелки, автодополнение и интерактивные команды.

Разведка изнутри

Пользователи и группы

Пользователь alice — в группе docker, ben — нет. Зато ben состоит в группе operator. Нужно найти путь к Docker-привилегиям.

Внутренние сервисы

На порту 8080 — сервис, доступный только локально. Это Docker-контейнер с PrivateBin.

Проверяем nginx-конфиг — обнаруживаем сабдомен bin.kobold.htb, проксирующий запросы в контейнер. Добавляем в /etc/hosts.

Группа operator имеет read/write-доступ к /privatebin-data/ — это Docker volume, общий между хостом и контейнером. Мы можем писать файлы, которые будут доступны внутри контейнера.

PrivateBin LFI → Утечка учётных данных

Уязвимость: CVE-2025-64714 (GHSA-g2j9-g8r5-rg82)

PrivateBin 2.0.2 уязвим к LFI через cookie template. При включённой опции template_selection = true можно выполнить path traversal и загрузить произвольный PHP-файл из директории tpl/.

Сама по себе LFI в контейнере ограничена его файловой системой. Но у нас есть доступ к общему volume — это позволяет построить цепочку атаки.

Эксплуатация

Шаг 1: с хоста (как ben) размещаем PHP-вебшелл в /privatebin-data/data/shell.php.

Шаг 2: через браузер устанавливаем cookie: template=../../../../data/shell. Сервер загружает наш файл.

Шаг 3: выполняем команды в контейнере. Считываем конфиг PrivateBin — находим учётные данные MySQL.

В комментарии указано: база временно отключена из-за миграции. Но пароль, скорее всего, переиспользуется.

Привилегии: основной путь

Reused-пароль → Arcane Dashboard

Найденный пароль пробуем на всех сервисах. su alice и SSH не работают. Проверяем Arcane Dashboard на http://kobold.htb:3552.

Логин неизвестен. Ищем дефолтные учётные данные Arcane: в документации указано — arcane/arcane-admin. Пароль сменили, но логин остался.

Пробуем:

• Username: arcane
• Password: <LEAKED_PASSWORD>

Успешный вход. Теперь у нас полный доступ к Docker через веб-интерфейс.

Урок: при reuse паролей всегда проверяйте дефолтные логины из документации. Их часто не меняют.

Создание привилегированного контейнера

В Arcane создаём новый контейнер:

• Имя: pwned
• Образ: privatebin/nginx-fpm-alpine:2.0.2
• Volume: / → /hostfs
• Privileged mode: включён

Запускаем контейнер, открываем shell. Получаем доступ к файловой системе хоста. Читаем root-флаг.

Альтернативный путь: newgrp docker

Есть более быстрый способ — за три команды, без UI и поиска паролей.

При исследовании системы обнаруживаем, что в /etc/gshadow пользователь ben состоит в группе docker, хотя /etc/group этого не показывает.

Команда newgrp читает членство в группах из /etc/gshadow. Если запись есть — можно переключиться без пароля.

Выполняем:

newgrp docker

Теперь у нас доступ к Docker. Запускаем контейнер с монтированием корня хоста:

docker run --rm -u 0 -v /:/hostfs --entrypoint /bin/sh <image> -c "cat /hostfs/root/root.txt"

Получаем root-флаг. Быстро, но менее показательно с точки зрения обучения.

Нюансы:

• --entrypoint /bin/sh — чтобы перехватить stdin.
• -u 0 — запуск от root в контейнере.
• --rm — автоматическое удаление после завершения.

Выводы

MCP-инструменты — новый attack surface

MCPJam Inspector — не исключение. Многие MCP-сервисы по умолчанию слушают на 0.0.0.0 без аутентификации. База vulnerablemcp.info уже содержит десятки подобных уязвимостей. AppSec-инженерам нужно включать аудит MCP-конфигураций в security review.

Docker group = root

Членство в группе docker эквивалентно root. Достаточно одной команды docker run -v /:/hostfs, чтобы получить полный контроль. Это должен быть обязательный пункт при аудите Linux-систем.

LFI в контейнере ≠ тупик

Даже изолированная LFI может стать вектором атаки, если есть общий volume с правами на запись. Цепочка: размещение файла → триггер LFI → утечка конфига → reuse пароля.

Reused-пароли и дефолтные логины

Нашли пароль — пробуйте его везде. И не ограничивайтесь логинами из конфигов. Ищите дефолтные учётные данные в документации. Например, arcane для Arcane Dashboard — часто остаётся без изменений.

Перед вами разбор машины Kobold из 10-го сезона HackTheBox. Easy машина, которая оказалась интересной - тут и chaining уязвимостей через Docker volumes, и credential reuse, и два разных пути до root. Но главная изюминка: точка входа - RCE в инструменте из AI/ML-экосистемы. Спойлер: MCP тулзе. Новый attack surface, который стоит знать. Погнали)

Сканирование портов

Традиционно начинаем с полного сканирования портов:

Nmap обнаруживает четыре открытых TCP-порта:

OpenSSH 9.6p1 Ubuntu

Свежая версия, без известных CVE

nginx 1.24.0

Redirect →https://kobold.htb

nginx 1.24.0

SSL, title: “Kobold Operations Suite”

Nmap не распознал, но fingerprint содержит HTML

SSH на данном этапе бесполезен без учётных данных. Порт 80 просто редиректит на HTTPS. А вот порты 443 и 3552 - наши основные цели.

Важная находка из NSE-скриптов:SSL-сертификат на порту 443 содержитwildcard*.kobold.htbв Subject Alternative Name. Для пентестера это прямой сигнал: существуют сабдомены, которые нужно энумерить.

Добавление домена в hosts

Исследование веб-приложений

Открываемhttps://kobold.htbв браузере - перед нами статический лендинг “Kobold Operations Suite”. Никакого бэкенда, форм авторизации, интерактива. В общем тупик.

Переходим к порту 3552. Здесь важный момент -curl -k https://kobold.htb:3552возвращает ошибкуwrong version number. Это значит, что порт 3552 работает поplain HTTP, а не HTTPS. Ошибка, которую легко допустить, когда привык что всё за TLS.

Открываемhttp://kobold.htb:3552в браузере:

Arcane v1.13.0- Docker management dashboard. Login form с полями Username/Password. Внизу ссылка “View on GitHub” и версия 1.13.0. Без кредов мы сюда не попадём - запомним и идём дальше.

Поиск сабдоменов

Wildcard в SSL-сертификате кричит о сабдоменах. Используем ffuf для vhost enumeration:

Результат - один сабдомен:

Добавляем в hosts:

MCPJam Inspector - точка входа

Открываемhttps://mcp.kobold.htb:

MCPJam Inspector v1.4.2- development-платформа для MCP-серверов. Полный dashboard без какой-либо аутентификации: Servers, Chat, App Builder, Tools, Resources, Settings - всё доступно. В Settings видим подключённый Ollama и версиюv1.4.2.

Для тех, кто не следит за ИИ нарративом:Model Context Protocol- это стандарт для подключения AI-моделей к внешним инструментам. MCPJam Inspector - это dev-tool для тестирования MCP-серверов. И вот такие инструменты всё чаще оказываются exposed в production без аутентификации.

Получение доступа (Foothold)

Уязвимость: GHSA-232v-j27c-5pp6

MCPJam Inspector версий ≤1.4.2 содержит критическую уязвимость удалённого выполнения кода (RCE). Проблема в двух вещах:

1. По умолчанию Inspector слушает на0.0.0.0вместо127.0.0.1- все HTTP API доступны извне
2. Endpoint/api/mcp/connectпредназначен для подключения к MCP-серверам и принимает параметрserverConfig.command- произвольную команду для запуска. Без аутентификации. Без валидации.

По сути, это задокументированный функционал, который в контексте exposed сервиса превращается в RCE с одного HTTP-запроса.

Эксплуатация

Запускаем listener в отдельном окне терминала:

Отправляем payload:

Ловим shell:

Мы на хосте как пользовательben. Стабилизируем shell (без этого нет автокомплита, не работают стрелки, Ctrl+C убьёт соединение, а интерактивные команды вродеsuоткажутся запускаться):

Разведка изнутри

Пользователи и группы

Ключевое наблюдение:aliceв группеdocker, а ben - нет. Зато ben в группеoperator. Нам нужен путь к docker-привилегиям.

Внутренние сервисы

Docker контейнер (PrivateBin)

MCPJam Inspector (node)

Порт 8080 слушает только на localhost - он не был виден при внешнем сканировании. Проверяем:

Это Docker-контейнер. Смотрим nginx-конфиг:

Обнаружен ещё один сабдомен -bin.kobold.htb, проксирующий на PrivateBin в Docker-контейнере. Добавляем в hosts на атакующей машине и открываем в браузере:

PrivateBin 2.0.2- self-hosted pastebin с шифрованием на стороне клиента. Версия попадает в диапазон уязвимых к LFI (CVE-2025-64714, затрагивает 1.7.7 — 2.0.2). Но для эксплуатации нам нужна возможность записать PHP-файл в файловую систему контейнера. Вспоминаем, что ben состоит в группеoperator— проверяем, что она даёт:

Группаoperatorимеетread/write доступк/privatebin-data/- это Docker volume, примонтированный в контейнер PrivateBin. Директория/privatebin-data/data/- полностью writable.

Это важная находка: мы можем писать файлы в volume, которые будут видны внутри контейнера.

PrivateBin LFI → Credential Leak

Уязвимость: CVE-2025-64714 (GHSA-g2j9-g8r5-rg82)

PrivateBin с включённымtemplateselection = trueдоверяет cookietemplateдля выбора PHP-шаблона. Через path traversal можно включить произвольный PHP-файл относительно директорииtpl/. Сама по себе LFI в контейнере кажется бесполезной — мы ограничены его файловой системой. Но у нас есть writable volume, общий между хостом и контейнером. Это позволяет выстроить цепочку:

Эксплуатация

Шаг 1 - дропаем webshell с хоста (shell как ben):

Шаг 2 - LFI через template cookie (атакующая машина):

Результат:

LFI работает. Мы выполняем код внутри Docker-контейнера PrivateBin.

Шаг 3 - сливаем конфиг:

В конфиге находим секцию MySQL с реальными credentials:

Отдельно интересен комментарий в конфиге:“Temporarily disabling while we migrate to new server for loadbalancing”- база временно отключена, но пароль реальный и, как часто бывает, переиспользуется.

Privilege Escalation - Intended Path

Credential Reuse → Arcane Dashboard

Каждый найденный пароль при пентесте нужно пробоватьво всехобнаруженных сервисах. Это не опция - это обязательный чеклист:

Попыткиsu aliceи SSH не дали результата. Следующая цель — Arcane Dashboard наhttp://kobold.htb:3552. Но какой логин использовать?

При credential reuse важно не только пробовать username’ы из найденных конфигов (privatebin,alice,ben), но игуглить дефолтные учётные записидля конкретного продукта. Быстрый поиск “Arcane default credentials” приводит кдокументациииGitHub Discussions— дефолтный логин:arcane/arcane-admin.

Пароль по дефолту не подошёл — его сменили. Но username оставили стандартным. Пробуем комбинацию дефолтного username + leaked password:

• Username:arcane
• Password:

Мы внутри. Полноценный Docker management dashboard: контейнеры, образы, volumes, networks - всё под контролем.

Урок:при credential reuse всегда проверяй дефолтные учётные записи из документации продукта. Пароль могут сменить, но username часто оставляют как есть.

Создание Privileged-контейнера

Arcane позволяет создавать Docker-контейнеры через UI. Если мы создадим контейнер, который монтирует корневую файловую систему хоста - получим полный доступ как root.

Containers → Create Containerсо следующими параметрами:

Вкладка Basic:

Container Name

pwned(можем написать что угодно)

privatebin/nginx-fpm-alpine:2.0.2

Остальные параметры не трогаем на этой вкладке

Вкладка Volumes:

Source (Host)

Container Path

Или в текстовом формате:/:/hostfs

Вкладка Network & Security:

☑ Ставим галочку наPrivileged mode

ЖмёмCreate Container, запускаем, открываемShell:

Root flag получен.

Альтернативный путь - newgrp docker

Выше мы прошли полную цепочку: LFI → credential leak → Arcane → privileged container. Красиво, но долго. А теперь -бонусдля тех, кто дочитал до конца: тот же root за 3 команды, без UI, без поиска паролей, без credential reuse.

Откуда я узнал про этот путь?Когда уже был внутри Arcane, из любопытства полез в/etc/gshadowчерез shell контейнера с примонтированным хостом. И вот что бросилось в глаза:

Секунду. Ben в группе docker? Ноcat /etc/group | grep dockerпоказывал только alice. Дело в том, что gshadow — это теневой файл групповых разрешений, и он может содержать участников, которых нет в основном/etc/group. Командаnewgrpпри наличии записи в/etc/gshadowберёт список участников именно оттуда, а не из/etc/group(man newgrp). Участники, перечисленные в gshadow, могут переключиться в группу без пароля.

Теперь у нас есть прямой доступ к Docker daemon. Монтируем хостовую FS и запускаем команду чтобы прочитать флаг:

Результат тот же - root flag за 3 команды вместо 10 минут в UI. Но с точки зрения обучения, длинный путь интереснее - он учит chaining уязвимостей.

Пара нюансов при работе с Docker-образами:

• --entrypoint /bin/sh- обязателен, иначе запустится дефолтный процесс (nginx+php-fpm) и перехватит stdin
• -u 0- запуск как root в контейнере, иначе Permission denied при чтении/root/
• --rm- удаляет контейнер после выхода, чтобы не мусорить

Kill Chain

MCP Security - новый класс attack surface

MCPJam Inspector - не единичный случай. По мере роста MCP-экосистемы (серверы, инспекторы, прокси) мы видим всё больше инструментов, которые по дефолту слушают на0.0.0.0без аутентификации. Базаvulnerablemcp.infoуже содержит десятки подобных уязвимостей. Для AppSec-инженеров это сигнал: аудит MCP-конфигураций должен стать частью security review.

Docker group = root

Банально, но повторяется из лабы в лабы: членство в группеdockerэквивалентно root-доступу. Одна командаdocker run -v /:/hostfs- и файловая система хоста ваша. При аудите Linux-систем это должен быть один из первых проверяемых пунктов.

LFI в контейнере ≠ тупик

Изолированная LFI внутри контейнера кажется бесполезной - но если между хостом и контейнером есть shared volume с write-доступом, это полноценный вектор. Chain: drop file → LFI trigger → config leak → credential reuse.

Credential Reuse + дефолтные логины

Нашёл пароль? Пробуй еговезде. И не забывай проadmin/root/administrator- даже если в конфиге username былprivatebin, логин в web-приложении может быть совершенно другим. Также полезно будет поискать дефолтные юзернеймы для сервисов, как было с Arcane dasboard -arcane.

References

• GHSA-232v-j27c-5pp6- MCPJam Inspector RCE, unauthenticated
• CVE-2025-64714- PrivateBin LFI через template cookie
• Arcane Docker Management- GitHub проекта, дефолтные креды в документации
• man newgrp- gshadow приоритет над /etc/group
• man gshadow- формат теневого файла групп
• Vulnerable MCP Database- база уязвимостей в MCP-инструментах
• MITRE ATT&CK- маппинг техник использованных в kill chain

Спасибо что дочитали до конца, надеюсь было интересно. Если статья была полезна - буду рад фидбэку. Постараюсь опубликовать следующие writeup’ы по мере прохождения Season 10.