SOCRadar concluye que la mayor parte de las más de 2.500 organizaciones relacionadas con el incidente atribuido a LiteLLM estuvieron expuestas antes de que las versiones maliciosas de LiteLLM se publicaran en PyPI, y que el punto de entrada fue una versión comprometida del escáner Trivy de Aqua Security.
Por qué importa: si la recolección de secretos comenzó por una herramienta de análisis upstream, la ventana de exposición fue mucho mayor y la acción visible en PyPI fue solo la etapa final.
Lo esencial
- SOCRadar analizó 2.188 registros por organización con marcas temporales entre el 19 y el 24 de marzo.
- Para 2.085 organizaciones (95%), la recolección de datos terminó antes de las publicaciones maliciosas de LiteLLM en PyPI.
- El vector inicial fue una build maliciosa de Trivy y la propagación se amplificó vía imágenes en Docker Hub y builds automatizados.
Trivy como punto de entrada
El informe de SOCRadar describe que la campaña siguió el patrón de otras atribuidas al grupo conocido como TeamPCP, vinculado al gusano Shai-Hulud: una build infectada de Trivy ejecutó código al descargarse y empezó a recolectar credenciales, tokens y claves API.
El malware usó secretos robados de desarrolladores para modificar paquetes accesibles y publicar versiones maliciosas en registros, lo que amplificó el alcance mediante inclusión automática en procesos de construcción.
El .pth que ejecutó código en el intérprete
SOCRadar y otros análisis explican que dos versiones envenenadas de LiteLLM publicadas el 24 de marzo incluyeron un archivo .pth que Python ejecuta al arrancar el intérprete, incluso si la librería no se importa, lo que permitió sortear protecciones como ignore-scripts.
Esas versiones permanecieron online alrededor de 40 minutos antes de que PyPI las pusiera en cuarentena; sin embargo, la actividad de recolección continuó en hosts ya infectados.
