TeamPCP ataca la cadena de suministro de software: litellm comprometido para robar credenciales y pivotar en Kubernetes

Una nueva ola en la guerra por la cadena de suministro de software vuelve a poner en evidencia lo frágil que puede ser el ecosistema open source: el actor malicioso conocido como TeamPCP ha logrado vulnerar una popular librería de Python, litellm, y publicar versiones con código malicioso que se propagó a ambientes de desarrollo y producción. Investigadores de seguridad, entre ellos Endor Labs y JFrog, han documentado cómo las versiones 1.82.7 y 1.82.8, subidas el 24 de marzo de 2026, contenían una carga útil compleja diseñada para robar credenciales, moverse lateralmente dentro de clústeres Kubernetes y establecer una puerta trasera persistente.

El vector de la intrusión parece estar relacionado con la integración de herramientas de seguridad en los pipelines de CI/CD: el repo público de litellm muestra uso de Trivy en sus flujos, y esa dependencia operacional habría sido explotada por los atacantes para insertar la modificación maliciosa antes de que se publicaran las ruedas (wheels) en PyPI, desde donde fue descargada por proyectos y entornos de todo tipo. Las versiones comprometidas ya han sido retiradas del repositorio oficial, pero el daño potencial ya estaba en marcha.

Desde el punto de vista técnico, la campaña emplea una cadena de tres etapas que la hace especialmente peligrosa. Primero, un recolector de credenciales rastrea claves SSH, credenciales de nube, secretos de Kubernetes, carteras de criptomonedas y ficheros .env. Esa información se empaqueta y se envía cifrada a un servidor de control y comando; según los análisis, el archivo se llama "tpcp.tar.gz" y es enviado mediante una petición HTTPS a models.litellm[.]cloud. En paralelo, la carga inicial intenta escalar dentro de entornos Kubernetes: si detecta un token de servicio, usa la API del clúster para enumerar nodos y desplegar pods privilegiados que, a su vez, hacen chroot en el sistema de ficheros del host para instalar un dropper persistente como servicio de systemd. Finalmente, ese servicio persistente —registrado como ~/.config/sysmon/sysmon.py, el mismo nombre que apareció en compromisos previos relacionados con Trivy— consulta periódicamente checkmarx[.]zone/raw en busca de instrucciones o binarios adicionales. Un detalle curioso y frecuente en estas campañas es la presencia de un "kill switch": si el URL recuperado contiene youtube[.]com, el código aborta la ejecución.

Las dos versiones maliciosas usaron técnicas distintas para maximizar su alcance. En la 1.82.7, el código se incrustó en litellm/proxy/proxy_server.py y fue diseñado para ejecutarse al importar ese módulo, por lo que cualquier proceso que hiciera import de litellm.proxy.proxy_server activaba la carga sin interacción del usuario. En la siguiente iteración, 1.82.8, los atacantes fueron más agresivos: añadieron un fichero litellm_init.pth en la raíz de la rueda. Los archivos .pth son procesados automáticamente por site.py al arrancar el intérprete de Python, así que esa técnica permite ejecutar código cada vez que cualquier proceso Python se inicia en el entorno, no sólo cuando se importa litellm. Además, el .pth invoca un subproceso en segundo plano empleando subprocess.Popen, lo que facilita la ejecución desapercibida de la carga maliciosa como proceso hijo.

Ese orquestador decodificado desempaqueta el recolector de credenciales y el instalador de persistencia. El mecanismo de movimiento lateral en Kubernetes monta pods con privilegios que realizan un chroot hacia el sistema del host —una técnica conocida y descrita ampliamente en la literatura técnica (chroot)— y despliegan el servicio de systemd que actúa como puerta de entrada persistente para posteriores descargas de payloads. La estrategia de exfiltración, la persistencia por systemd y el patrón de kill switch son consistentes con otras intrusiones atribuidas a este actor.

Este episodio no es un caso aislado: TeamPCP ha demostrado un patrón de escalada que parte de comprometer herramientas en pipelines de CI/CD y termina alcanzando entornos de producción mediante artefactos supuestamente confiables. Según análisis públicos, la campaña ha afectado varios ecosistemas —GitHub Actions, Docker Hub, npm, Open VSX y ahora PyPI— ampliando su capacidad de accionar sobre una base de infraestructuras y proyectos muy diversa. Varios expertos del sector han advertido sobre el efecto dominó: una herramienta comprometida puede dar llaves para vulnerar otras, en un ciclo que se retroalimenta. Organizaciones y equipos de desarrollo se ven así obligados a reaccionar ante una amenaza que ataca en el corazón de la confianza en la cadena de suministros de software.

Los investigadores y proveedores han publicado reportes técnicos y recomendaciones que conviene leer para entender alcance y mitigación. Informes como los de Endor Labs y JFrog ofrecen detalles del comportamiento del malware y de cómo fue insertado, mientras que análisis complementarios en medios especializados resumen la cronología del ataque y las señales de compromiso.

Si administras entornos que usan Python, contenedores o pipelines automatizados, es prioritario revisar si se llegó a descargar alguna de las versiones comprometidas de litellm. Auditar instalaciones en entornos virtuales y sistemas de producción, buscar archivos sospechosos en site-packages (como litellm_init.pth), comprobar procesos Python en segundo plano y revisar si existen servicios persistentes instalados bajo ~/.config/sysmon son pasos iniciales urgentes. También hay que inspeccionar clústeres Kubernetes por pods no autorizados o con privilegios elevados, y analizar registros de red en busca de tráfico saliente hacia dominios relacionados con el operativo, en particular models.litellm[.]cloud y checkmarx[.]zone. No menos importante es auditar pipelines de CI/CD para detectar si herramientas como Trivy o KICS fueron usadas en la ventana de compromiso y, si corresponde, rotar y revocar las credenciales que puedan haberse visto expuestas.

La comunidad de seguridad ya ha reaccionado y comparte herramientas y técnicas de detección, pero los responsables de infraestructuras deben actuar con rapidez y cautela: aislar hosts comprometidos, eliminar mecanismos de persistencia identificados, reconstruir artefactos críticos desde código fuente limpio y rotar claves y credenciales son medidas que, aunque costosas, limitan la capacidad del atacante para pivotar hacia nuevos objetivos. En paralelo, es necesario replantear las políticas de confianza en artefactos externos y fortalecer las pruebas y el monitoreo en los pipelines.

La bronca pública del propio grupo, difundida en su canal de Telegram, deja claro que su intención es prolongar y ampliar la campaña; y voces del sector, como la de Gal Nagli de Wiz, han señalado la naturaleza cíclica del problema: comprometer una herramienta de seguridad puede desencadenar múltiples compromisos en cascada. Para quienes mantienen proyectos y dependencias, la lección es dolorosa pero necesaria: no asumir como inocuas las dependencias de seguridad y reforzar las barreras de protección alrededor de los procesos que generan, empaquetan y publican software.

Para profundizar en los informes técnicos y en la evolución de este incidente, recomiendo leer los análisis de Endor Labs, el reporte de JFrog y las piezas que resumen el caso en medios especializados, así como seguir las actualizaciones en los canales oficiales donde se han publicado evidencias y IOCs. La seguridad de la cadena de suministro es hoy un tema crítico y colectivo: protegerla exige tanto mejores prácticas técnicas como coordinación entre desarrolladores, mantenedores de proyectos y equipos de seguridad.