LiteLLM en PyPI atacado por TeamPCP: análisis en profundidad de la campaña de malware para el robo de credenciales.

Home » Python » LiteLLM en PyPI atacado por TeamPCP: análisis en profundidad de la campaña de malware para el robo de credenciales.

Durante unas horas el 24 de marzo de 2026, un paquete de Python enormemente popular se convirtió silenciosamente en un poderoso ladrón de credenciales. Dos versiones envenenadas de LiteLLM, una biblioteca ampliamente utilizada como Interfaz unificada para grandes modelos de lenguaje (LLM), fueron subidos a PyPI, exponiendo brevemente a un gran número de sistemas a un sofisticado ataque a la cadena de suministro.

Las versiones maliciosas, 1.82.7 y 1.82.8, empaquetó una carga útil de varias etapas capaz de extraer secretos de máquinas de desarrolladores, ejecutores de CI/CD, infraestructura en la nube y clústeres de Kubernetes, para luego exfiltrarlos a servidores controlados por el atacante. La campaña ha sido vinculado al grupo de amenazas TeamPCP, que lleva meses atacando Trivy, las herramientas de Checkmarx, las imágenes de Docker, ataques a la cadena de suministro de npm y ahora el ecosistema PyPI.

¿Qué es LiteLLM y por qué era un objetivo tan prioritario?

LiteLLM es un Biblioteca Python de código abierto y servidor proxy que actúa como una especie de adaptador universal para las API de LLM. Permite que las aplicaciones se comuniquen con más de cien modelos diferentes, de proveedores como OpenAI, Anthropic, Google, AWS Bedrock, Vertex AI y otros, a través de una única API al estilo de OpenAI.

Debido a ese rol, el proyecto se ha integrado profundamente en todo el ecosistema de IA. Los informes de varios proveedores de seguridad indican que LiteLLM ve aproximadamente Entre 3 y 3.4 millones de descargas diarias., con algunos datos de telemetría que sugieren que está presente en aproximadamente 36% de los entornos de nube monitorizadosPara los atacantes, comprometer un paquete con esa huella digital representa una oportunidad única para acceder a un enorme flujo de datos confidenciales y credenciales con un solo movimiento.

Por diseño, LiteLLM a menudo se sitúa directamente entre aplicaciones y múltiples proveedores de servicios de IAEsta posición implica el manejo rutinario de claves API, variables de entorno, archivos de configuración y otros secretos necesarios para acceder a los puntos finales externos de LLM. Una puerta trasera en dicha dependencia puede interceptar y extraer silenciosamente esos valores sin necesidad de vulnerar directamente las plataformas de origen.

El incidente también subraya lo interconectado que está el desarrollo moderno: estaciones de trabajo locales, pipelines de CI/CD, clústeres de Kubernetes y cuentas en la nube están todos vinculados a través de secretos compartidos y automatización. Un solo dependencia comprometida en ese gráfico Esto puede acabar exponiendo las credenciales en múltiples capas de la infraestructura de una organización, amplificando el impacto mucho más allá de un único servidor.

Cómo se introdujeron las versiones maliciosas de LiteLLM

Las liberaciones envenenadas LiteLLM 1.82.7 y 1.82.8 fueron enviados a PyPI en la mañana del 24 de marzo de 2026, alrededor de 08: 30 UTC. Permanecieron disponibles durante casi dos horas antes de ser puestos en cuarentena por el equipo de seguridad de PyPI y bloqueados por defensas de terceros, y se informó de su eliminación alrededor de 11: 25 UTC.

Lo que hace que este caso sea notable es que el La puerta trasera no apareció en el código fuente de GitHub correspondiente.Endor Labs y otros investigadores descubrieron que la lógica maliciosa se inyectó en el archivo wheel compilado y distribuido en PyPI, no en el repositorio público, lo que sugiere que la vulneración se produjo durante o después del proceso de compilación/publicación, en lugar de a través de una confirmación de código visible.

Específicamente, los analistas observaron que el archivo litellm/proxy/proxy_server.py contenía una carga útil codificada en base64 incrustada que era ausente del mismo archivo en la confirmación de GitHubSe insertaron alrededor de una docena de líneas entre bloques de código que de otro modo serían legítimos (por ejemplo, cerca de la definición de REALTIME_REQUEST_SCOPE_TEMPLATE y showwarning función). Esas líneas adicionales decodificaban y ejecutaban silenciosamente un script oculto cada vez que se importaba el módulo.

En la versión 1.82.8, los atacantes fueron un paso más allá al dejar caer un .pth archivo llamado litellm_init.pth en el entorno de Python. Porque Python procesa todo .pth archivos al iniciar el intérprete, esto aseguró que la carga útil se ejecutara en cada invocación de Python, incluso si LiteLLM nunca fue importado por la aplicación.

Esta escalada hizo 1.82.8 significativamente más peligrosoCualquier script de Python, ejecutor de pruebas, herramienta de compilación o automatización ejecutada en un entorno con el paquete comprometido instalado activaría silenciosamente la lógica de robo de credenciales en segundo plano.

Conexión con la campaña más amplia de TeamPCP.

La vulnerabilidad LiteLLM no se produjo de forma aislada. Las investigaciones realizadas por Sonatype, Wiz, Endor Labs y otros la vinculan a un Campaña en curso sobre la cadena de suministro llevada a cabo por TeamPCP., un grupo que acaparó la atención a finales de 2025 y que desde entonces ha puesto en el punto de mira a una serie de proyectos de código abierto y ecosistemas de desarrolladores.

A principios de marzo, los mismos actores fueron vinculados a la puerta trasera de Trivia de Aqua Security Escáner de vulnerabilidades y acciones de GitHub relacionadas, así como variantes maliciosas de herramientas Checkmarx, incluyendo KICS, GitHub Actions y extensiones de OpenVSX. La campaña también ha afectado a paquetes npm, imágenes de Docker Hub y entornos Kubernetes, reutilizando con frecuencia infraestructura, esquemas de cifrado y artefactos de persistencia.

Al rastrear el incidente de LiteLLM, los mantenedores revelaron que un token de publicación de PyPI Almacenado como una variable de entorno en el repositorio de GitHub de LiteLLM fue exfiltrado a través del flujo de trabajo comprometido de Trivy. Ese token fue luego utilizado indebidamente para publicar las versiones contaminadas de PyPI, lo que permite a los atacantes eludir las protecciones de doble factor en las cuentas de usuario e inyectar código malicioso sin alterar el código fuente público.

Los investigadores también señalan confirmaciones y flujos de trabajo sospechosos creados alrededor del 23 de marzo en repositorios relacionados con LiteLLM, incluyendo una rama de corta duración y un flujo de trabajo de GitHub Actions que contiene una clave pública RSA familiar vista en otras cargas útiles de TeamPCP. La telemetría de las ejecuciones de flujos de trabajo sugiere que se pudo haber accedido a secretos disponibles para esos ejecutores de CI y haberlos exfiltrado.

En todos los incidentes, el grupo ha mostrado un patrón constante: robar credenciales en un entorno y luego pasar al siguiente ecosistemaEn este caso, una configuración incorrecta en GitHub Actions de Trivy permitió el robo de un token privilegiado; ese token condujo a lanzamientos maliciosos de Trivy e imágenes Docker; estos, a su vez, permitieron la vulneración de las herramientas de Checkmarx y, en última instancia, del paquete LiteLLM de PyPI.

Cómo funciona el malware LiteLLM

Los análisis de varios proveedores describen la puerta trasera LiteLLM como una Carga útil de Python multietapa ofuscada en base64 Diseñado para ser sigiloso, flexible y resistente. La lógica se organiza en aproximadamente tres capas, cada una de las cuales gestiona una fase diferente del ataque.

En la primera capa, el código inyectado en proxy_server.py o el litellm_init.pth presentar decodifica y lanza un orquestador ocultoEn lugar de utilizar funciones fácilmente señalizables como exec()El script se apoya en llamadas a subprocesos y en la funcionalidad de la biblioteca estándar para ejecutar la carga útil decodificada y capturar su salida, lo que ayuda a que se integre en el comportamiento normal de la aplicación.

Una vez en funcionamiento, este orquestador recoge la salida de la siguiente etapa, cifra los datos recopilados con AES-256-CBC y luego cifra la clave de sesión AES en sí misma utilizando una clave pública RSA codificada integrada en el código. El blob cifrado y la clave se empaquetan en un archivo llamado tpcp.tar.gzHaciéndose eco de otras operaciones del TeamPCP, y se prepararon para la exfiltración.

La segunda capa es responsable de Reconocimiento agresivo del sistema y obtención de credencialesEnumera los nombres de host, la información de usuario y de red, y las variables de entorno, y luego escanea una larga lista de rutas y archivos de configuración en busca de material confidencial. Los objetivos incluyen:

• Claves SSH y archivos de configuración (cliente y servidor)
• Credenciales en la nube para AWS, GCP y Azure, incluidos los tokens derivados de metadatos.
• Archivos kubeconfig de Kubernetestokens de cuenta de servicio y secretos de clúster
• Archivos de entorno como .env variantes que se utilizan a menudo para almacenar claves API
• Configuración de CI/CDsecretos y tokens de acceso
• Terraform, Helm y otros artefactos de IaC o de despliegue
• Cadenas de conexión de base de datos y archivos de configuración
• claves privadas TLS/SSL y material de autenticación
• Carteras de criptomonedas y datos relacionados

En algunos entornos, el ladrón no se detiene en la recolección. Intenta utilizar activamente las credenciales descubiertas, por ejemplo, consultando las API de los proveedores de la nube, extrayendo secretos de Kubernetes o explorando los recursos accesibles, lo que aumenta la probabilidad de movimiento lateral y posterior vulneración de la seguridad.

La tercera capa proporciona persistencia y control remoto. Escribe un script de Python en el disco (comúnmente observado como sysmon.pyy lo registra como un servicio de larga duración, a menudo disfrazado de algo inofensivo como un "Servicio de telemetría del sistema". Este servicio se comunica periódicamente con la infraestructura del atacante, normalmente cada 50 minutos, para obtener comandos o cargas útiles adicionales.

Los investigadores observan un comportamiento peculiar aquí: cuando ciertos proveedores de seguridad intentaron obtener la carga útil del punto final de comando y control, el servidor respondió con un enlace a una versión remasterizada de la canción "Bad Apple!!", aparentemente como una táctica de distracción contra el análisis automatizadoSin embargo, en los sistemas infectados, el mismo mecanismo puede ofrecer silenciosamente nuevas funcionalidades con el tiempo.

Canales de exfiltración e infraestructura del atacante

En todos los incidentes de LiteLLM, los analistas observaron comunicación con al menos dos dominios principales controlados por el atacante: modeloslitellmcloud además checkmarxzoneEstos elementos se corresponden con la infraestructura utilizada en actividades anteriores de TeamPCP y cumplen funciones específicas.

El archivo cifrado tpcp.tar.gz es típicamente subido a models.litellmcloud, lo que permite a los operadores recuperar credenciales robadas de miles de entornos posteriores. En algunas variantes, diferentes subrutas de checkmarxzone (por ejemplo, checkmarxzone/raw or .../vsx) se utilizan para entregar scripts de persistencia o etapas adicionales.

En los sistemas comprometidos, los defensores han informado de una serie de problemas recurrentes. indicadores de compromiso (IoC) Asociado al malware LiteLLM:

• Presencia del archivo tpcp.tar.gz en directorios temporales o de trabajo
• Archivos temporales como /tmp/pglog además /tmp/.pg_state
• Rutas de configuración y scripts de Python relacionadas con sysmon.py y un archivo de servicio correspondiente (a menudo ubicado en los directorios de configuración del usuario o de systemd).
• Inesperado litellm_init.pth archivos en paquetes de sitio de Python para la versión 1.82.8
• Tráfico saliente o búsquedas DNS que apuntan a modeloslitellmcloud or checkmarxzone

Se rastreó lógica maliciosa en archivos que incluían: proxy_server.py (LiteLLM 1.82.7 y 1.82.8) y litellm_init.pth (1.82.8). Los proveedores de seguridad han catalogado hashes y otros indicadores de compromiso (IoC) y continúan actualizando sus avisos a medida que surgen detalles forenses adicionales.

Impacto en entornos de IA, nube y CI/CD

Debido a que LiteLLM se utiliza mucho en Aplicaciones y servicios impulsados ​​por IAEl impacto práctico de esta vulnerabilidad va más allá de los simples consumidores de paquetes. Es probable que los entornos en la nube donde LiteLLM actúa como puerta de enlace a los proveedores de LLM tengan secretos ubicados en el mismo espacio de ejecución o configuración.

Wiz y otros observadores estiman que LiteLLM aparece en aproximadamente un tercio de los entornos nubosos observadoslo que subraya el alcance potencial. Algunas fuentes citadas por BleepingComputer sugieren que el número de filtraciones de datos podría ascender a cientos de miles, aunque aún está pendiente la confirmación independiente de las cifras exactas.

Cabe destacar que el malware enfatiza Comportamiento compatible con KubernetesEn muchos análisis, la carga útil intenta desplegar pods privilegiados en todos los nodos de un clúster y luego usar esos pods para acceder a secretos y objetos de configuración. En operaciones de TeamPCP separadas pero relacionadas, los investigadores han visto clústeres de Kubernetes atacados con scripts que borran nodos cuando el entorno parece estar ubicado en Irán, mientras instalan puertas traseras (como el llamado CanisterWorm) en otros lugares.

El enfoque en las herramientas de CI/CD es igualmente claro. Al comprometer Trivy GitHub Actions, las extensiones Checkmarx VS Code y GitHub Actions, y ahora LiteLLM, los atacantes obtienen puntos de entrada donde La automatización ya cuenta con amplios privilegios. sobre repositorios, artefactos de compilación y credenciales de despliegue. Este enfoque convierte herramientas que de otro modo estarían orientadas a la seguridad en puntos de acceso para una mayor vulnerabilidad.

Funcionarios del FBI e investigadores de la industria han advertido que con grandes volúmenes de credenciales robadas en manoEs razonable esperar más notificaciones de violaciones de seguridad, intrusiones secundarias e intentos de extorsión en las semanas y meses posteriores a la divulgación inicial de LiteLLM.

Pasos de detección, contención y remediación

Para las organizaciones que puedan haber descargado o ejecutado versiones de LiteLLM 1.82.7 ó 1.82.8 En lo que respecta a PyPI, las directrices de los proveedores de seguridad y de los mantenedores de PyPI son directas: tratar los sistemas afectados como comprometidosLa simple desinstalación del paquete no elimina los mecanismos de persistencia ni deshace ningún robo de credenciales que ya se haya producido.

Las medidas inmediatas recomendadas incluyen:

• Identificar cualquier instalación de LiteLLM 1.82.7 o 1.82.8 en máquinas de desarrolladores, ejecutores de CI/CD, contenedores y entornos de producción.
• Elimine las versiones maliciosas y fijar LiteLLM a una versión que se sabe que funciona correctamente (siendo la 1.82.6 la versión más citada como la última versión limpia en el momento de redactar este informe).
• Rotar todas las credenciales Accesible desde los entornos afectados: claves SSH, claves y tokens del proveedor de la nube, secretos de Kubernetes, secretos de CI/CD, credenciales de la base de datos, claves TLS y cualquier cartera o secreto relacionado con pagos.
• Búsqueda de artefactos de persistencia, como sysmon.py, definiciones de servicio systemd sospechosas y archivos inusuales en ~/.config o directorios temporales como /tmp/pglog además /tmp/.pg_state.
• Inspeccionar clústeres de Kubernetes para pods privilegiados inesperados, especialmente en espacios de nombres como kube-systemy para cuentas de servicio o vinculaciones de roles inusuales.
• Supervisar las conexiones salientes y consultas DNS para dominios atacantes conocidos como models.litellmcloud además checkmarxzone.

En entornos donde la puerta trasera podría haberse ejecutado durante un período significativo, muchos expertos sugieren que una Reconstrucción completa desde una base confiable Puede ser la opción más segura, especialmente para infraestructuras críticas. Dada la naturaleza del malware, no se puede descartar una manipulación sutil o la inclusión de cargas útiles adicionales simplemente eliminando el paquete LiteLLM.

También se está animando a las organizaciones a adoptar medidas más sólidas. Gestión de dependencias y defensas de la cadena de suministro: fijar las versiones a versiones específicas y verificadas, habilitar herramientas que bloqueen o marquen paquetes maliciosos conocidos en el momento de la ingesta e incorporar análisis de comportamiento automatizados que puedan detectar actividad inesperada en la red o el sistema de archivos durante las compilaciones y las pruebas.

Lo que el caso LiteLLM revela sobre las cadenas de suministro de software de IA

El incidente de LiteLLM pone de relieve una tendencia más amplia que se ha ido gestando en los últimos años: Los componentes de alto apalancamiento en las pilas de IA y la nube se están convirtiendo en objetivos primordiales. para los atacantes de la cadena de suministro. En lugar de atacar directamente las aplicaciones de los usuarios finales, los ciberdelincuentes buscan cada vez más puntos en la cadena de herramientas donde comprometer una sola biblioteca o complemento les permita acceder a muchas organizaciones posteriores.

Paquetes como LiteLLM se sitúan efectivamente en un punto de estrangulamiento para secretosEstos componentes gestionan las llamadas a proveedores de IA, interactúan con sistemas de CI/CD y automatización de infraestructura, y a menudo se ejecutan con permisos elevados. A medida que más empresas se apresuran a integrar capacidades LLM mediante herramientas de código abierto, el valor de dichos componentes —y el incentivo para acceder a ellos de forma no autorizada— no hace más que aumentar.

Al mismo tiempo, el ataque ilustra los desafíos que supone proteger los procesos de compilación y publicación. En este caso, los atacantes supuestamente aprovecharon una configuración incorrecta del flujo de trabajo de Trivy para robar un token y luego lo utilizaron para publicar paquetes infectados en PyPI, todo ello sin dañar el código fuente público. Las etiquetas de versión y los pasos de compilación se convirtieron en parte de la superficie de ataque., aprovechando el hecho de que muchos pipelines se basan en etiquetas en lugar de confirmaciones fijas y pueden confiar implícitamente en artefactos provenientes de mantenedores conocidos.

Proveedores como Sonatype, Wiz y Endor Labs destacan la importancia de medidas de seguridad automatizadas y en tiempo real que pueden detectar comportamientos anómalos, como destinos de red nunca antes vistos o exfiltración cifrada, incluso cuando los metadatos del paquete y el historial del repositorio parecen legítimos. Los cortafuegos de repositorio, los escáneres basados ​​en inteligencia de amenazas y el análisis contextual de dependencias se consideran cada vez más capas necesarias, no extras opcionales.

Para los mantenedores y las organizaciones por igual, el compromiso de LiteLLM es un recordatorio de que Gestión de secretos, fortalecimiento de CI/CD y rotación de credenciales son fundamentales para la seguridad de la cadena de suministro. La rotación incompleta o no atómica de credenciales en incidentes anteriores dejó vulnerabilidades que TeamPCP pudo reutilizar semanas después, lo que demuestra cómo un solo error en la respuesta a incidentes puede tener repercusiones en todos los ecosistemas.

La campaña que arrasó con LiteLLM comenzó con lo que parecía un problema de flujo de trabajo limitado y desde entonces se ha extendido a GitHub Actions, Docker Hub, El incidente de Shai-Hulud en npmOpenVSX y PyPI. Con puertas traseras ocultas en herramientas y conectores de IA ampliamente confiables, y credenciales robadas que fluyen a la infraestructura del atacante, este episodio subraya la rapidez con la que la cadena de suministro de software puede convertirse en una superficie de ataque atractiva y altamente efectiva.