LiteLLM MCP 侦察只用 66 秒：一个脚本化客户端在检测蜜罐

TLP:CLEAR。已批准公开发布。由 Kinryū Labs 蜜罐传感器网络捕获。下文指标均已做失活处理。

执行摘要

• 42条经 MCP 工具下发的 shell 命令
• 66 秒从第一条命令到最后一条
• 7项蜜罐检查集中在最后 20 秒
• 1个来源，9 月 5 日至 12 日期间

CVE-2026-42271 是 LiteLLM MCP 测试端点中的命令注入缺陷（影响 1.74.2 至 1.83.6，CVSS 8.7，自 2026 年 6 月 8 日起列入 CISA KEV）。9 月 6 日，一个客户端在 Kinryū Labs 的 LiteLLM 诱饵主机上滥用了 LiteLLM 的 MCP 工具面。它从一个香港 VPS 地址列举诱饵主机的 MCP 工具，随后在 66 秒内经由这些工具下发 42 条 shell 命令：我是谁、我是否在容器里、root 的 SSH 密钥是否可读、这是什么网络。最后 20 秒它在检查这台主机是否真实，手段包括一个标记文件、一次时钟读取、一次从 /dev/urandom 取数据以及三次计时 sleep，然后停止；截至 9 月 12 日，该来源再无后续动作。如果你运行的 LiteLLM 低于 1.83.7 且 4000 端口可达，请升级；检测章节提供了一条针对请求形态的规则和一条针对蜜罐检测行为的规则。

这些请求发往 /mcp 的 tools/call。公告描述的缺陷位于 /mcp-rest/test/* 端点，而该客户端并未触碰这些端点，因此我们将此次活动描述为对 LiteLLM MCP 工具面的滥用，而非该 CVE 的利用。

关键研判

时间线

• 01:24:44 UTC首次接触：向 TCP/4000 上的 /mcp 发起 HTTP POST，Mozilla/5.0，MCP 工具面枚举。
• 01:25:46 UTC第二次枚举探测，客户端画像相同。
• 01:27:30 UTC客户端切换为 curl/8.20.0，HTTP 客户端指纹随之更换，并重新枚举工具面。
• 01:27:35 UTC首次命令注入：以 bash 工具执行命令 'id'；紧接着对 /etc/hostname 调用 read_file。
• 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，随后会话结束。截至 9 月 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 起以 Mozilla/5.0 用户代理发出两次工具面枚举探测。不到三分钟后，它切换为 curl/8.20.0，HTTP 客户端指纹也相应改变，并开始通过 tools/call 调用工具。

它先做身份检查，id、hostname，然后对 /etc/hostname 调用 read_file，随后是上文会话中那两条组合式单行命令。

脚本两次列出 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，检验错误路径的保真度；对 /tmp 下同一个标记文件先 touch 后 cat，看文件系统是否在多次调用之间保持状态；用 date +%s 检查时钟推进；用 head -c 50 /dev/urandom | base64 检查熵；用 sleep 0、sleep 5 和 sleep 8 检查计时保真度。

最后一条命令是 01:28:41 的 sleep 8。截至 9 月 12 日，该地址再无任何请求到达。停止的原因不明。支撑”先做蜜罐检测、再决定收手”这一解读的是事件的先后顺序，信心为中等。

在信任 LLM 代理端点之前先检测其是否为蜜罐的操作者，在这里并非首次出现：我们的 keyHunter 报告描述过一个验证器被专门构建为识别蜜罐的操作者。我们没有任何将两者关联起来的指标。

归因

计时特征可以定下一件事：这是一个脚本。66 秒内 42 次调用，以突发方式发出，突发内命令间隔 130 至 250 毫秒，突发之间停顿 9 至 26 秒，这是一套完成利用、寻找密钥和容器边界、对主机做指纹识别然后退出的工具。这符合定向操作者的工具包，或是带有”避免暴露”前置过滤的红队框架。它不符合大规模商品化利用的特征，后者重放一份固定载荷并反复回访；而该客户端变换了 37 条命令字符串，只访问一次，且是 9 月 5 日至 12 日期间此类活动的唯一来源。安全研究性质的扫描调查未被完全排除，因为保真度测试组合也正是蜜罐检测研究的做法，但该来源位于商业性质的香港 VPS 网段，客户端未表明任何研究身份，且会话中列出了 root 的密钥目录并读取了 /etc/passwd，正规的研究调查不会这样做。

归因到此为止。该地址位于 AS140227（Hong Kong Communications International，177.4.0[.]0/20），属于商业托管。VirusTotal 显示两个引擎判定为恶意、两个判定为可疑，无厂商命名，且该缺陷已列入 KEV 并有公开的概念验证代码，因此能力本身无法说明是谁。

失陷指标

下方唯一的网络指标已做失活处理；指纹和路径按观测原样给出。

网络

指标	上下文
177.4.12[.]11	9 月 5 日至 12 日期间此类活动的唯一来源；所有请求均发往 TCP/4000 上的 /mcp；AS140227，香港

主机痕迹

指标	上下文
/tmp/marker_uniq_<digits>	蜜罐检测中先写入再读回的标记文件；本次会话的后缀为 93817，因此应按该模式排查

行为

指标	上下文
po11nn050000_6e4c6fcb1a9b	curl/8.20.0 命令阶段的 JA4H 式 HTTP 客户端指纹
po11nn070000_39fa8e08ab4c	初始 Mozilla/5.0 枚举阶段的 JA4H 式 HTTP 客户端指纹

检测

Sigma

向 LiteLLM 代理发起的、携带 shell 命令的 MCP tools/call（候选规则）。

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

由 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 ’ 以及对同一 /tmp 路径先 touch 后 cat 的不同命令数量。命中三类或以上说明客户端正在判断目标是否真实；请保留完整的会话捕获。
• 向 LiteLLM 默认端口 /mcp 发起的免认证 POST（网络类，候选）。目标端口 4000，方法 POST，路径 /mcp，无授权头。将其与 curl 阶段指纹 po11nn050000_6e4c6fcb1a9b 配合使用。

处置建议

• 将 LiteLLM 升级至 1.83.7 或更高版本；修复补丁为 MCP 测试端点加入了命令白名单和 PROXY_ADMIN 角色校验。
• 若无法立即升级，在反向代理上拦截 POST /mcp-rest/test/connection 和 POST /mcp-rest/test/tools/list，并且不要将 TCP/4000 暴露到互联网。
• 在同一技术栈上修补 Starlette Host 头绕过漏洞 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	针对 TCP/4000 上暴露的 LLM 代理发起 42 次 MCP tools/call 调用，滥用其 MCP 工具面。
执行	T1059.004 Command and Scripting Interpreter: Unix Shell	用 shell 单行命令驱动 MCP bash 工具，包含 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	对 /etc/hostname 调用 MCP read_file 工具。

参考资料

• NVD：CVE-2026-42271
• CISA 已知被利用漏洞目录
• Kinryū Labs：keyHunter，一次泄露了自身工具包的 LLM 代理密钥行动

方法论与分析员说明

本报告基于 1 个来源地址和 10 次带时间戳的观测，取自传感器遥测数据，并与公开威胁情报源和富化查询进行核对，覆盖 2026 年 9 月 6 日的活动以及 9 月 5 日至 12 日的关联追溯。此次活动止步于发现阶段：会话结束前未尝试载荷下载、持久化或外联 C2。

仍未解答：

• 177.4.12[.]11 在 9 月 6 日之前做过什么。
• 操作者停手之后去了哪里。
• 标记文件后缀 93817 是工具中写死的，还是每次运行生成的？
• 这套检查组合是否与任何已公开的利用工具或蜜罐检测工具吻合？
• 此次请求是否需要 proxy key，还是借助了 Host 头绕过漏洞 CVE-2026-48710？

问题或更正请联系：contact@kinryu.sh。