Reconocimiento MCP en LiteLLM en 66 segundos: un cliente automatizado que busca honeypots

TLP:CLEAR. Autorizado para difusión pública. Capturado por la red de sensores honeypot de Kinryū Labs. Los indicadores que siguen están desactivados (defanged).

Resumen ejecutivo

• 42comandos de shell enviados a través de herramientas MCP
• 66 sdesde el primer comando hasta el último
• 7comprobaciones de honeypot en los últimos 20 segundos
• 1origen de esta actividad, del 5 al 12 de septiembre

CVE-2026-42271 es una falla de inyección de comandos en los endpoints de prueba MCP de LiteLLM (1.74.2 a 1.83.6, CVSS 8.7, en la lista KEV de CISA desde el 8 de junio de 2026), y el 6 de septiembre un cliente abusó de la superficie de herramientas MCP de LiteLLM en un señuelo LiteLLM de Kinryū Labs. Desde una dirección de VPS en Hong Kong enumeró las herramientas MCP del señuelo y luego envió 42 comandos de shell a través de ellas en 66 segundos: quién soy, estoy en un contenedor, son legibles las claves SSH de root, qué red es esta. Dedicó los últimos 20 segundos a comprobar si el host era real, con un archivo marcador, una lectura del reloj, una extracción de /dev/urandom y tres pausas cronometradas, y luego se detuvo; no llegó nada más desde ese origen hasta el 12 de septiembre. Si ejecuta LiteLLM por debajo de 1.83.7 con el puerto 4000 alcanzable, actualice; la sección de Detección incluye una regla para la forma de la petición y otra para la prueba de honeypot.

Las peticiones iban dirigidas a tools/call en /mcp. El aviso describe la falla en los endpoints /mcp-rest/test/*, que este cliente no tocó, por lo que describimos la actividad como abuso de la superficie de herramientas MCP de LiteLLM y no como ese CVE.

Valoraciones clave

Cronología

• 01:24:44 UTCPrimer contacto: HTTP POST a /mcp en TCP/4000, Mozilla/5.0, enumeración de la superficie de herramientas MCP.
• 01:25:46 UTCSegunda sonda de enumeración, mismo perfil de cliente.
• 01:27:30 UTCEl cliente cambia a curl/8.20.0 con una nueva huella de cliente HTTP y vuelve a enumerar la superficie de herramientas.
• 01:27:35 UTCPrimera inyección de comandos: herramienta bash con el comando 'id'; seguida de inmediato por read_file de /etc/hostname.
• 01:27:44 UTCLínea compuesta de reconocimiento: hostname; uname -a; listado del directorio de claves de root; cat /proc/1/cgroup.
• 01:27:55 UTCSegunda línea compuesta: pwd; whoami; /proc/1/cgroup; ip a | grep inet; ls /.
• 01:28:21 UTCGiro hacia la detección del señuelo: redirección de stderr, manejo de los envoltorios sh -c y bash -c, ls -la /etc/passwd.
• 01:28:31 UTCPruebas de rutas de error y de persistencia de estado: ruta y archivo inexistentes, touch y luego cat de /tmp/marker_uniq_93817.
• 01:28:32 UTCPruebas de reloj y entropía: date +%s, head -c 50 /dev/urandom | base64.
• 01:28:41 UTCPruebas de temporización sleep 0 / 5 / 8, y fin de la sesión. Ninguna actividad posterior desde esta dirección hasta el 12 de septiembre.

La sesión, en orden

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

El reconocimiento apunta directo a las claves de root y al límite del contenedor

El cliente se presentó con dos identidades distintas en los primeros tres minutos. Envió dos sondas de enumeración de la superficie de herramientas a partir de las 01:24:44 con un agente de usuario Mozilla/5.0. Poco menos de tres minutos después cambió a curl/8.20.0, con una huella de cliente HTTP distinta acorde, y comenzó a invocar herramientas mediante tools/call.

Primero ejecutó comprobaciones de identidad, id, hostname, luego read_file contra /etc/hostname, y después las dos líneas compuestas que se muestran arriba en la sesión.

El script enumeró dos veces el directorio de claves privadas de la cuenta root y ejecutó ip a | grep inet. Una comprobación de prueba de concepto no necesita listados del directorio de claves ni enumeración de red, así que interpretamos este reconocimiento como preparación para salir del host del proxy. Las lecturas de /proc/1/cgroup y /proc/1/cmdline determinan si la shell está dentro de un contenedor.

A las 01:28:21 el cliente deja de preguntar por el host y empieza a ponerlo a prueba

Durante veinte segundos el cliente comprobó si hablaba con un host real. Ejecutó echo hi 1>&2 para ver si stderr regresaba por su propio canal; envoltorios sh -c y bash -c para comprobar el manejo de la invocación de shell; ls y cat contra rutas deliberadamente inexistentes, para verificar la fidelidad de las rutas de error; touch seguido de un cat del mismo archivo marcador en /tmp, para ver si el sistema de archivos conservaba estado entre invocaciones; date +%s para el avance del reloj; head -c 50 /dev/urandom | base64 para la entropía; y sleep 0, sleep 5 y sleep 8 para la fidelidad de la temporización.

El último comando fue sleep 8 a las 01:28:41. No llegó nada más desde esta dirección hasta el 12 de septiembre. Se desconoce por qué se detuvo. El orden de los eventos es lo que sustenta la lectura de esto como una prueba de honeypot seguida de la decisión de detenerse, con confianza moderada.

Un operador que prueba si los endpoints de proxies LLM son honeypots antes de confiar en ellos no es algo nuevo aquí: nuestro informe sobre keyHunter describe uno cuyo verificador estaba construido para reconocerlos. No tenemos ningún indicador que vincule a ambos.

Atribución

La temporización deja una cosa clara: esto fue un script. Cuarenta y dos invocaciones en 66 segundos, disparadas en ráfagas, con 130 a 250 ms entre comandos dentro de una ráfaga y pausas de 9 a 26 segundos entre ráfagas, es utillaje que explota, busca claves y el límite del contenedor, toma la huella del host y sale. Eso encaja con el conjunto de herramientas de un operador dirigido o con un framework de red team con un prefiltro para evitar quemarse. No encaja con la explotación masiva de commodity, que repite una única carga fija y vuelve de forma reiterada; este cliente varió 37 cadenas de comandos, apareció una vez y fue el único origen de esta actividad entre el 5 y el 12 de septiembre. Un sondeo de investigación de seguridad no queda del todo excluido, porque las baterías de fidelidad son también la forma en que funciona la investigación sobre detección de honeypots, pero el origen es un rango de VPS comercial de Hong Kong, el cliente no anuncia ninguna identidad de investigación y la sesión enumeró el directorio de claves de root y leyó /etc/passwd, cosas que los sondeos serios no hacen.

No llevamos la atribución más allá. La dirección se encuentra en AS140227 (Hong Kong Communications International, 177.4.0[.]0/20), que es hosting comercial. VirusTotal muestra dos veredictos de motores como malicioso y dos como sospechoso, sin que ningún fabricante le asigne nombre, y la falla está en la lista KEV con código de prueba de concepto público, así que la capacidad no dice nada sobre quién está detrás.

Indicadores de compromiso

El único indicador de red que sigue está desactivado (defanged); las huellas y rutas se dan tal como se observaron.

Red

Indicador	Contexto
177.4.12[.]11	Único origen de esta actividad entre el 5 y el 12 de septiembre; todas las peticiones fueron a /mcp en TCP/4000; AS140227, Hong Kong

Artefactos en el host

Indicador	Contexto
/tmp/marker_uniq_<digits>	Archivo marcador escrito y luego releído por la prueba de honeypot; el sufijo fue 93817 en esta sesión, así que busque el patrón

Comportamiento

Indicador	Contexto
po11nn050000_6e4c6fcb1a9b	Huella de cliente HTTP estilo JA4H de la fase de comandos con curl/8.20.0
po11nn070000_39fa8e08ab4c	Huella de cliente HTTP estilo JA4H de la fase inicial de enumeración con Mozilla/5.0

Detección

Sigma

tools/call de MCP que transporta un comando de shell hacia un proxy LiteLLM (candidata).

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

Comprobaciones de fidelidad de honeypot lanzadas por un proceso de proxy LLM (candidata).

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

Lógica de detección

• Batería de fidelidad desde un único origen (conductual, candidata). En una ventana de 120 segundos desde un único origen, cuente los comandos distintos que coincidan con /dev/urandom, ‘date +%s’, ‘^sleep [0-9]+$’, ‘echo .* 1>&2’, ’^(sh|bash) -c ’, y un touch seguido de un cat de la misma ruta en /tmp. Tres o más categorías significan que un cliente está decidiendo si el objetivo es real; conserve la captura completa de la sesión.
• POST sin autenticar a /mcp en el puerto por defecto de LiteLLM (red, candidata). Puerto de destino 4000, método POST, ruta /mcp, sin cabecera de autorización. Combínelo con la huella de la fase curl po11nn050000_6e4c6fcb1a9b.

Remediación

• Actualice LiteLLM a 1.83.7 o posterior; la corrección añade una lista de comandos permitidos y una comprobación del rol PROXY_ADMIN en los endpoints de prueba MCP.
• Si la actualización no es inmediata, bloquee POST /mcp-rest/test/connection y POST /mcp-rest/test/tools/list en el proxy inverso, y no exponga TCP/4000 a internet.
• Parchee el bypass de la cabecera Host de Starlette CVE-2026-48710 en la misma pila. Encadenados, ambos permiten ejecución remota de código sin autenticación.
• Inventaríe cada servidor MCP que el proxy está configurado para invocar y revise sus campos command y args en busca de inyección de segundo orden.
• Rote cualquier clave de API de proveedor, valor de LITELLM_MASTER_KEY y clave virtual accesible desde el entorno del proceso del proxy o desde archivos de credenciales montados.
• Busque en los hosts /tmp/marker_uniq_ y procesos hijos del proxy que ejecuten id, whoami, uname, getent o listados del directorio de claves de la cuenta root.

Correspondencia con MITRE ATT&CK

Táctica	Técnica	Observado
Acceso inicial	T1190 Exploit Public-Facing Application	42 invocaciones de tools/call de MCP contra un proxy LLM expuesto en TCP/4000, abusando de su superficie de herramientas MCP.
Ejecución	T1059.004 Command and Scripting Interpreter: Unix Shell	Herramienta bash de MCP manejada con líneas de shell, incluidos envoltorios sh -c y bash -c.
Descubrimiento	T1082 System Information Discovery	uname -a, cat /etc/os-release, uname -r, hostname -f, ls -la /, cat /proc/1/cmdline.
Descubrimiento	T1033 System Owner/User Discovery	id, id -u, whoami, getent passwd root, cat /etc/passwd | head -3.
Acceso a credenciales	T1552.004 Unsecured Credentials: Private Keys	Dos listados del directorio de claves privadas de la cuenta root en la primera ráfaga de reconocimiento.
Evasión de defensas	T1497 Virtualization/Sandbox Evasion	La comprobación de contenedor con /proc/1/cgroup, y después la batería de siete comprobaciones en los últimos 20 segundos.
Recolección	T1005 Data from Local System	Herramienta read_file de MCP invocada contra /etc/hostname.

Referencias

• NVD: CVE-2026-42271
• Catálogo de vulnerabilidades explotadas conocidas de CISA
• Kinryū Labs: keyHunter, una operación de robo de claves de proxies LLM que filtró su propio conjunto de herramientas

Metodología y notas del analista

Este informe se apoya en 1 dirección de origen y 10 observaciones con marca de tiempo, leídas de la telemetría de sensores, contrastadas con fuentes públicas de inteligencia de amenazas y consultas de enriquecimiento, y cubre actividad del 6 de septiembre de 2026 y pivotes del 5 al 12 de septiembre. La actividad se detuvo en la fase de descubrimiento: no se intentó descargar ninguna carga útil, ni establecer persistencia, ni C2 saliente antes de que terminara la sesión.

Aún abierto:

• Qué hizo 177.4.12[.]11 antes del 6 de septiembre.
• A dónde fue el operador después de detenerse.
• ¿El sufijo del marcador 93817 está fijado en la herramienta o se genera en cada ejecución?
• ¿Coincide la batería con alguna herramienta publicada de explotación o de detección de honeypots?
• ¿Hacía falta una clave de proxy, o la petición aprovechó el bypass de la cabecera Host CVE-2026-48710?

Preguntas o correcciones: [email protected].