Разведка LiteLLM MCP за 66 секунд: скриптовый клиент, проверяющий хост на honeypot

TLP:CLEAR. Разрешено к публичному распространению. Зафиксировано сенсорной сетью honeypot-ловушек Kinryū Labs. Индикаторы ниже приведены в обезвреженном виде.

Краткая сводка

• 42shell-команды, проведённые через MCP-инструменты
• 66 сот первой команды до последней
• 7проверок на honeypot за последние 20 секунд
• 1источник этой активности с 5 по 12 сентября

CVE-2026-42271 представляет собой уязвимость внедрения команд в тестовых MCP-эндпоинтах LiteLLM (версии с 1.74.2 по 1.83.6, CVSS 8.7, в каталоге CISA KEV с 8 июня 2026 года). 6 сентября один клиент злоупотребил поверхностью MCP-инструментов LiteLLM на ловушке Kinryū Labs, имитирующей LiteLLM. С адреса VPS в Гонконге он перечислил MCP-инструменты ловушки, а затем провёл через них 42 shell-команды за 66 секунд: кто я, нахожусь ли я в контейнере, читаются ли SSH-ключи root, что это за сеть. Последние 20 секунд он потратил на проверку того, реален ли хост: файл-маркер, чтение часов, выборка из /dev/urandom и три хронометрированных вызова sleep, после чего остановился; до 12 сентября больше ничего от него не поступало. Если вы используете LiteLLM ниже 1.83.7 с доступным портом 4000, обновитесь; в разделе «Обнаружение» приведены правило на форму запроса и правило на проверку honeypot.

Запросы шли на tools/call по пути /mcp. В бюллетене уязвимость описана применительно к эндпоинтам /mcp-rest/test/*, которых этот клиент не касался, поэтому мы описываем активность как злоупотребление поверхностью MCP-инструментов LiteLLM, а не как эксплуатацию данной CVE.

Ключевые выводы

Хронология

• 01:24:44 UTCПервый контакт: HTTP POST на /mcp, TCP/4000, Mozilla/5.0, перечисление поверхности MCP-инструментов.
• 01:25:46 UTCВторой зондирующий запрос на перечисление, тот же профиль клиента.
• 01:27:30 UTCКлиент переключается на curl/8.20.0 с новым отпечатком HTTP-клиента и заново перечисляет поверхность инструментов.
• 01:27:35 UTCПервое внедрение команды: инструмент bash с командой 'id'; сразу следом read_file для /etc/hostname.
• 01:27:44 UTCСоставная разведывательная однострочная команда: hostname; uname -a; перечисление каталога ключей root; cat /proc/1/cgroup.
• 01:27:55 UTCВторая составная: pwd; whoami; /proc/1/cgroup; ip a | grep inet; ls /.
• 01:28:21 UTCПереход к обнаружению ловушки: перенаправление stderr, обработка обёрток sh -c и bash -c, ls -la /etc/passwd.
• 01:28:31 UTCПроверки путей обработки ошибок и сохранения состояния: несуществующий путь и файл, touch с последующим cat для /tmp/marker_uniq_93817.
• 01:28:32 UTCПроверки часов и энтропии: date +%s, head -c 50 /dev/urandom | base64.
• 01:28:41 UTCПроверки таймингов sleep 0 / 5 / 8, затем сессия завершается. До 12 сентября активности с этого адреса больше не было.

Сессия по порядку

01:27:35  id
01:27:44  hostname; uname -a | cut -c1-120; ls -la [root key directory] 2>&1 | head -5; cat /proc/1/cgroup 2>/dev/null | head -3
01:27:55  pwd; whoami; cat /proc/1/cgroup | head -2; ip a | grep inet | head -3; ls / | head -15
01:28:21  echo hi 1>&2
01:28:32  date +%s
01:28:32  head -c 50 /dev/urandom | base64
01:28:41  sleep 8

Разведка сразу идёт за ключами root и границей контейнера

За первые три минуты клиент предъявил две разные личности. С 01:24:44 он отправил два зондирующих запроса на перечисление поверхности инструментов под user agent Mozilla/5.0. Чуть менее чем через три минуты он сменил его на curl/8.20.0, с соответственно изменившимся отпечатком HTTP-клиента, и начал вызывать инструменты через tools/call.

Сначала он выполнил проверки идентичности, id, hostname, затем read_file для /etc/hostname, затем две составные однострочные команды, показанные в сессии выше.

Скрипт дважды перечислил каталог приватных ключей учётной записи root и выполнил ip a | grep inet. Проверке концепции не нужны ни перечисление каталога ключей, ни разведка сети, поэтому мы трактуем эту разведку как подготовку к перемещению за пределы хоста прокси. Чтение /proc/1/cgroup и /proc/1/cmdline устанавливает, находится ли shell внутри контейнера.

В 01:28:21 клиент перестаёт спрашивать о хосте и начинает его проверять

Двадцать секунд клиент проверял, разговаривает ли он с реальным хостом. Он выполнил echo hi 1>&2, чтобы увидеть, возвращается ли stderr по собственному каналу; обёртки sh -c и bash -c, чтобы проверить обработку вызовов shell; ls и cat для заведомо несуществующих путей, чтобы оценить достоверность путей обработки ошибок; touch с последующим cat того же файла-маркера в /tmp, чтобы понять, сохраняет ли файловая система состояние между вызовами; date +%s для хода часов; head -c 50 /dev/urandom | base64 для энтропии; и sleep 0, sleep 5 и sleep 8 для достоверности таймингов.

Последней командой была sleep 8 в 01:28:41. До 12 сентября с этого адреса больше ничего не приходило. Почему он остановился, неизвестно. Именно порядок событий позволяет трактовать это как проверку на honeypot с последующим решением прекратить работу, со средней уверенностью.

Оператор, который проверяет эндпоинты LLM-прокси на honeypot, прежде чем им доверять, здесь не новость: наш отчёт по keyHunter описывает оператора, чей верификатор был построен именно для их распознавания. Индикаторов, связывающих эти два случая, у нас нет.

Атрибуция

Тайминги закрывают один вопрос: это был скрипт. Сорок два вызова за 66 секунд, отправленных сериями, с интервалом 130–250 мс между командами внутри серии и паузами 9–26 секунд между сериями, выглядят как инструментарий, который эксплуатирует уязвимость, ищет ключи и границу контейнера, снимает отпечаток хоста и выходит. Это соответствует набору инструментов целевого оператора или red-team-фреймворку с предварительным фильтром для избежания «сгорания». Это не соответствует массовой эксплуатации товарного уровня, которая воспроизводит одну фиксированную полезную нагрузку и возвращается многократно; данный клиент варьировал 37 командных строк, обратился однократно и был единственным источником этой активности в период с 5 по 12 сентября. Исследовательский сканирующий проект полностью не исключён, поскольку батареи проверок достоверности служат в том числе и методом исследований по обнаружению honeypot, однако источник находится в коммерческом диапазоне VPS в Гонконге, клиент не заявляет исследовательскую принадлежность, а в ходе сессии был перечислен каталог ключей root и прочитан /etc/passwd, чего добросовестные исследования не делают.

Дальше в атрибуции мы не идём. Адрес относится к AS140227 (Hong Kong Communications International, 177.4.0[.]0/20), это коммерческий хостинг. VirusTotal показывает два вердикта «вредоносный» и два «подозрительный» без указания имён со стороны вендоров, а уязвимость числится в KEV и имеет публичный код проверки концепции, поэтому возможности ничего не говорят о том, кто это.

Индикаторы компрометации

Единственный сетевой индикатор ниже приведён в обезвреженном виде; отпечатки и пути даны так, как наблюдались.

Сеть

Индикатор	Контекст
177.4.12[.]11	Единственный источник этой активности с 5 по 12 сентября; все запросы шли на /mcp, TCP/4000; AS140227, Гонконг

Артефакты на хосте

Индикатор	Контекст
/tmp/marker_uniq_<digits>	Файл-маркер, записанный и затем прочитанный в ходе проверки на honeypot; в этой сессии суффикс был 93817, поэтому ищите по шаблону

Поведенческие

Индикатор	Контекст
po11nn050000_6e4c6fcb1a9b	Отпечаток HTTP-клиента в стиле JA4H для фазы команд с curl/8.20.0
po11nn070000_39fa8e08ab4c	Отпечаток HTTP-клиента в стиле JA4H для начальной фазы перечисления с Mozilla/5.0

Обнаружение

Sigma

MCP tools/call с shell-командой к прокси LiteLLM (кандидат).

title: MCP tools/call Carrying A Shell Command To A LiteLLM Proxy
id: 5b0f6c1e-2f0a-4d0e-9a53-6b1d0f7a42c1
status: experimental
description: POST to a LiteLLM MCP endpoint whose JSON body invokes a tool with a command argument. Needs request-body logging at the reverse proxy; the body field name is a placeholder for whatever your proxy calls it. Any hit on LiteLLM below 1.83.7 should be treated as exploitation.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-42271
logsource:
  category: webserver
detection:
  selection_request:
    cs-method: POST
    cs-uri-stem:
      - /mcp
      - /mcp-rest/test/connection
      - /mcp-rest/test/tools/list
  selection_call:
    request_body|contains: '"method": "tools/call"'
  selection_command:
    request_body|re: '"(command|args)"\s*:'
  condition: all of selection_*
falsepositives:
  - An MCP shell tool you expose on purpose to trusted clients
level: high

Проверки достоверности на honeypot, порождённые процессом LLM-прокси (кандидат).

title: Honeypot Fidelity Checks Spawned By An LLM Proxy Process
id: 0c9a7e52-8d1b-4a38-b0f4-3e5f2a9d7c10
status: experimental
description: A proxy process spawning the checks a client uses to decide whether the host is emulated. Seen immediately before the client abandoned the session. Works from ordinary process telemetry on the proxy host.
logsource:
  product: linux
  category: process_creation
detection:
  selection_parent:
    ParentImage|endswith:
      - /python
      - /python3
      - /litellm
  selection_checks:
    CommandLine|contains:
      - /dev/urandom
      - date +%s
      - /proc/1/cgroup
      - marker_uniq_
  condition: selection_parent and selection_checks
falsepositives:
  - Container entrypoint or health-check scripts that read /proc/1/cgroup
level: high

Логика обнаружения

• Батарея проверок достоверности с одного источника (поведенческое, кандидат). В пределах 120 секунд от одного источника подсчитайте различные команды, совпадающие с /dev/urandom, ‘date +%s’, ‘^sleep [0-9]+$’, ‘echo .* 1>&2’, ’^(sh|bash) -c ’, а также touch с последующим cat того же пути в /tmp. Три и более категории означают, что клиент решает, реальна ли цель; сохраните полную запись сессии.
• Неаутентифицированный POST на /mcp по порту LiteLLM по умолчанию (сетевое, кандидат). Порт назначения 4000, метод POST, путь /mcp, отсутствует заголовок авторизации. Сопоставьте это с отпечатком фазы curl po11nn050000_6e4c6fcb1a9b.

Меры по устранению

• Обновите LiteLLM до 1.83.7 или новее; исправление добавляет список разрешённых команд и проверку роли PROXY_ADMIN на тестовых MCP-эндпоинтах.
• Если обновление невозможно немедленно, заблокируйте POST /mcp-rest/test/connection и POST /mcp-rest/test/tools/list на обратном прокси и не выставляйте TCP/4000 в интернет.
• Устраните обход по заголовку Host в Starlette (CVE-2026-48710) в том же стеке. В связке эти две уязвимости дают неаутентифицированное удалённое выполнение кода.
• Проведите инвентаризацию всех MCP-серверов, к которым настроено обращение прокси, и проверьте их command и args на предмет внедрения второго порядка.
• Смените все API-ключи провайдеров, значения LITELLM_MASTER_KEY и виртуальные ключи, доступные из окружения процесса прокси или из смонтированных файлов с учётными данными.
• Проверьте хосты на наличие /tmp/marker_uniq_ и на дочерние процессы прокси, выполняющие id, whoami, uname, getent или перечисление каталога ключей учётной записи root.

Сопоставление с MITRE ATT&CK

Тактика	Техника	Наблюдалось
Первоначальный доступ	T1190 Exploit Public-Facing Application	42 вызова MCP tools/call к открытому LLM-прокси на TCP/4000 со злоупотреблением его поверхностью MCP-инструментов.
Выполнение	T1059.004 Command and Scripting Interpreter: Unix Shell	Инструмент MCP bash, управляемый shell-однострочниками, включая обёртки sh -c и bash -c.
Разведка	T1082 System Information Discovery	uname -a, cat /etc/os-release, uname -r, hostname -f, ls -la /, cat /proc/1/cmdline.
Разведка	T1033 System Owner/User Discovery	id, id -u, whoami, getent passwd root, cat /etc/passwd | head -3.
Доступ к учётным данным	T1552.004 Unsecured Credentials: Private Keys	Два перечисления каталога приватных ключей учётной записи root в первой серии разведки.
Обход защиты	T1497 Virtualization/Sandbox Evasion	Проверка контейнера через /proc/1/cgroup, затем батарея из семи проверок за последние 20 секунд.
Сбор	T1005 Data from Local System	Инструмент MCP read_file, вызванный для /etc/hostname.

Ссылки

• NVD: CVE-2026-42271
• Каталог известных эксплуатируемых уязвимостей CISA
• Kinryū Labs: keyHunter, операция по сбору ключей LLM-прокси, которая выдала собственный инструментарий

Методология и заметки аналитика

Этот отчёт опирается на 1 адрес-источник и 10 хронометрированных наблюдений, считанных из телеметрии сенсоров, сверенных с публичными фидами threat intelligence и запросами обогащения, и охватывает активность 6 сентября 2026 года и связанные обращения с 5 по 12 сентября. Активность прекратилась на этапе разведки: до завершения сессии не было попыток загрузить полезную нагрузку, закрепиться или установить исходящий канал C2.

Остаётся неясным:

• Что делал 177.4.12[.]11 до 6 сентября.
• Куда оператор ушёл после остановки.
• Зафиксирован ли суффикс маркера 93817 в самом инструменте или генерируется при каждом запуске?
• Совпадает ли эта батарея проверок с каким-либо опубликованным эксплойтом или инструментом обнаружения honeypot?
• Требовался ли ключ прокси, или запрос прошёл через обход по заголовку Host (CVE-2026-48710)?

Вопросы или исправления: contact@kinryu.sh.