Entre el 19 y el 23 de marzo de 2026, un grupo criminal conocido como TeamPCP encadenó el compromiso de tres herramientas que millones de organizaciones usan precisamente para protegerse: los escáneres de vulnerabilidades Trivy y KICS, y la pasarela de modelos de lenguaje LiteLLM. Todo empezó con un único token de acceso personal de GitHub que no se había rotado del todo. De ahí salieron, según el análisis de Unit 42, más de mil entornos SaaS empresariales afectados.
Lo que convierte aquel episodio en noticia de julio no es el compromiso en sí, sino su desenlace. Sophos ha documentado que las credenciales robadas entonces —más de 500.000 juegos, extraídos de flujos de integración continua— están alimentando ahora los despliegues de ransomware del grupo Vect. Y hay un detalle que altera por completo el cálculo de cualquier comité de crisis: el cifrador de Vect 2.0 destruye de forma irreversible todos los archivos de más de 128 KB. Pagar el rescate no devuelve los datos, porque ni siquiera el atacante conserva lo necesario para descifrarlos.
Cinco días de marzo que siguen produciendo víctimas
La secuencia arranca en un sitio poco glamuroso: una credencial de mantenedor que sobrevivió a una rotación incompleta. Con ella, los atacantes llegaron a la automatización de compilación de Trivy y desde ahí saltaron al resto. El fallo quedó registrado como CVE-2026-33634, con una puntuación CVSS de 9.4.
A partir de ese punto, el compromiso se propagó por capas. Los atacantes reescribieron las etiquetas de versión publicadas de las acciones de GitHub de Trivy, forzaron cambios sobre las 35 etiquetas del repositorio de acción de KICS de Checkmarx y contaminaron la versión 2.3.28 de otra acción del mismo proveedor. En LiteLLM inyectaron un cargador persistente en la versión 1.82.8. Las credenciales de publicación de npm que fueron recolectando alimentaron después un gusano autopropagado que Sophos sitúa en más de 48 paquetes, y que recuentos posteriores elevan por encima de 60.
El patrón de fondo es el que conviene retener, porque se repite en cualquier ecosistema de paquetes: robar un token de publicación, enumerar los paquetes que ese token puede firmar, subir una versión menor con la carga añadida y volver a publicar. Nada de esto exige una vulnerabilidad en el código del cliente. Es la misma mecánica que vimos en el ataque contra los paquetes de Mastra en npm, solo que aquí la puerta de entrada fue el propio utillaje de seguridad.
| Fecha | Hecho documentado |
|---|---|
| 31 dic 2025 | Vect publica su primer anuncio de reclutamiento de afiliados en un foro criminal en ruso |
| Ene-feb 2026 | Primeras víctimas de Vect; un mes después aparece la versión Vect 2.0 |
| 19-23 mar 2026 | TeamPCP compromete Trivy, KICS y LiteLLM a partir de un token de GitHub mal rotado |
| 24 mar 2026 | Microsoft publica guía de detección e investigación para el compromiso de Trivy |
| Finales mar 2026 | Se anuncia la alianza operativa entre TeamPCP y Vect |
| 16 abr 2026 | Se detecta distribución de claves de afiliado en el marco del acuerdo entre Vect y BreachForums |
| Abr 2026 | Check Point documenta que Vect 2.0 destruye archivos en lugar de cifrarlos de forma recuperable |
| Jul 2026 | Sophos confirma despliegues de ransomware Vect usando credenciales procedentes de TeamPCP |
Fuentes: Unit 42 (Palo Alto Networks), Microsoft Security Response, Sophos y Check Point Research.
Por qué el atacante fue a por el escáner
Elegir una herramienta de seguridad como objetivo no es una provocación: es una decisión de eficiencia. Un escáner de vulnerabilidades ocupa una posición privilegiada dentro de la automatización de compilación. Se ejecuta con frecuencia, se ejecuta en casi todos los repositorios y —esto es lo determinante— se ejecuta con permisos amplios, porque necesita leer código, imágenes de contenedor y manifiestos de despliegue. Comprometerlo equivale a colocarse en un punto por el que pasa todo.
La condición que lo hizo posible en Trivy es conocida y perfectamente documentada en la literatura de seguridad de integración continua. Un flujo automatizado configurado para reaccionar a propuestas de cambio externas puede acabar ejecutándose con los secretos del repositorio mientras procesa código que aporta un tercero. Cuando esas dos cosas coinciden, la frontera entre «código de confianza» y «código de un desconocido» desaparece, y los secretos del repositorio quedan al alcance del proceso. No hace falta más.
El rastro que deja esta clase de compromiso es característico. La carga observada volcaba la memoria del proceso ejecutor de la automatización para extraer secretos que nunca llegan a escribirse en disco, y recolectaba claves SSH, credenciales de nube, tokens de Kubernetes y tokens de npm. Para la exfiltración, Unit 42 documenta el uso de dominios que imitaban al proveedor legítimo y, como mecanismo de reserva, la creación de un repositorio oculto dentro de la propia organización de la víctima usando el token que el flujo ya tenía a mano. Ese último detalle es el que hace que la exfiltración se confunda con actividad normal: el tráfico va a GitHub, y GitHub estaba permitido.
El archivo de credenciales invierte el orden del ataque
Aquí está la novedad que merece la atención del comité de dirección, y no solo la del equipo técnico. En el modelo clásico, un operador de ransomware compromete una organización y después averigua qué tiene delante. En este esquema el orden se da la vuelta: TeamPCP reunió primero un archivo de más de 500.000 credenciales procedentes de entornos de integración continua, y Vect selecciona después a sus víctimas de ese archivo, con criterio, sabiendo de antemano a qué está entrando.
La consecuencia operativa es incómoda. La ventana entre el compromiso y el impacto deja de medirse en días y pasa a medirse en meses. Una credencial capturada en marzo puede ser el acceso inicial de un incidente de julio, y para entonces los registros del sistema de compilación probablemente hayan caducado. Cualquier análisis retrospectivo que solo mire treinta o noventa días atrás no encontrará nada.
A esa asimetría se suma la escala. Infosecurity Magazine recoge las advertencias sobre la industrialización del modelo: al acuerdo con TeamPCP se sumó otro con el foro BreachForums, que pasa de ser un canal de distribución a funcionar como infraestructura operativa, con depósito de garantía, soporte a afiliados y reparto de claves integrados en el propio foro. El FBI publicó en julio un aviso conjunto específico sobre la actividad de TeamPCP.
Vect 2.0: el fallo que rompe el cálculo de pagar
El análisis de Check Point Research sobre el cifrador de Vect 2.0 —presente en las variantes para Windows, Linux y ESXi— destapó un error de implementación con consecuencias definitivas. Todo archivo de más de 131.072 bytes, es decir 128 KB, queda destruido de forma permanente en lugar de cifrado de forma reversible.
El motivo es sencillo de explicar sin entrar en detalle reproducible. El cifrador trocea los archivos grandes en cuatro fragmentos y genera un valor de un solo uso distinto para cada uno. Solo conserva el último junto al archivo; los tres primeros se generan, se usan y se descartan, y no quedan ni en disco, ni en el registro, ni se envían al operador. Como el algoritmo empleado exige la clave y el valor exacto de cada fragmento para revertir el cifrado, tres cuartas partes de cada archivo grande son irrecuperables. También para quien lanzó el ataque.
La lectura práctica la resume bien Help Net Security: Vect no es, en términos funcionales, ransomware; es un borrador de datos con nota de rescate. The Hacker News confirma que el comportamiento se reproduce en las tres plataformas. Para un comité de crisis esto elimina de un plumazo una de las dos ramas del árbol de decisión: la recuperación depende íntegramente de las copias de seguridad, y la negociación no aporta ninguna opción técnica real.
| Dato | Cifra | Fuente |
|---|---|---|
| Entornos SaaS empresariales afectados | Más de 1.000 | Unit 42 |
| Juegos de credenciales exfiltrados | Aproximadamente 500.000 | Sophos |
| Volumen de datos exfiltrado | Unos 300 GB comprimidos | Sophos |
| Paquetes npm alcanzados por el gusano | Más de 48 | Sophos |
| CVSS del fallo en la automatización de Trivy | 9.4 (CVE-2026-33634) | Unit 42 |
| Umbral de destrucción irreversible en Vect 2.0 | 131.072 bytes (128 KB) | Check Point Research |
Cifras publicadas por Unit 42, Sophos y Check Point Research entre marzo y julio de 2026.
Por qué los controles habituales no lo vieron
Merece la pena detenerse en por qué una organización con buenos controles pudo pasar por esto sin enterarse.
- La firma del paquete no ayuda cuando el atacante usa la credencial legítima del mantenedor: el artefacto está correctamente firmado y publicado por quien debe publicarlo.
- El inventario de componentes registra qué versión se instaló, no si esa etiqueta fue reescrita después. Varias de las etiquetas afectadas se sobrescribieron manteniendo el mismo número de versión.
- El sistema de compilación suele estar fuera del alcance de la telemetría de puesto de trabajo. Los agentes efímeros se destruyen al terminar y con ellos desaparece la evidencia.
- La exfiltración de reserva viajaba hacia dominios de proveedor legítimos y hacia la propia plataforma de código de la víctima, dos destinos que ninguna regla de salida razonable bloquea.
- Los secretos de larga duración almacenados en variables de entorno son legibles por cualquier proceso del agente. Basta con estar ahí en el momento adecuado.
Es el mismo razonamiento que aplicamos cuando analizamos el compromiso de un SIEM como puerta de entrada: las herramientas de seguridad concentran privilegio y confianza, y esa concentración es exactamente lo que las convierte en objetivo.
Detección: qué mirar y en qué ventana temporal
Lo primero, y no es un detalle menor, es ampliar la ventana de búsqueda. Si la organización usó Trivy, KICS o LiteLLM en producción o en compilación durante la primavera de 2026, el análisis retrospectivo debe llegar hasta marzo. Microsoft publicó guía específica de detección e investigación para el compromiso de Trivy que sigue siendo el punto de partida más útil.
Sobre qué buscar, estas señales son las que mejor rendimiento dan en la práctica:
- Uso de credenciales de nube o de service principal desde direcciones o regiones que no coinciden con la ubicación habitual de los agentes de compilación, especialmente si la credencial se emitió antes de abril de 2026.
- Creación de repositorios en la organización de código que ningún desarrollador reconoce. En esta campaña se ha documentado el uso de un repositorio oculto de nombre fijo dentro de la organización de la víctima.
- Presencia del cargador persistente asociado a la versión comprometida de LiteLLM en imágenes de contenedor construidas en la ventana afectada.
- Resolución DNS hacia dominios que imitan a proveedores de seguridad conocidos desde agentes de compilación, un destino que no tiene ninguna justificación funcional.
- Lectura de memoria del proceso ejecutor de la automatización por parte de procesos hijo, un comportamiento que no forma parte de ningún flujo legítimo de compilación.
En un entorno con Microsoft Defender, una consulta de partida sobre la telemetría de dispositivos para acotar el punto tres sería de este estilo, adaptando el nombre de los agentes al parque propio:
DeviceFileEvents | where DeviceName has_any ("runner", "build", "ci-") | where FileName endswith ".pth" or FileName has "litellm_init" | where Timestamp between (datetime(2026-03-01) .. now()) | project Timestamp, DeviceName, FolderPath, FileName, InitiatingProcessFileName, InitiatingProcessAccountName | order by Timestamp asc
Conviene tratar el resultado como hipótesis, no como veredicto: el objetivo es acotar qué agentes construyeron imágenes en la ventana afectada para pasarlos a análisis manual. Este tipo de barrido retrospectivo sobre hipótesis concretas es el trabajo propio de un ejercicio de búsqueda proactiva de amenazas, y rara vez sale bien si se improvisa en mitad de un incidente.
Defensa: qué cambiar en la práctica
Las medidas que de verdad reducen la exposición a este patrón no son genéricas, y ninguna es especialmente cara:
- Fijar las acciones y dependencias externas por identificador de confirmación inmutable, no por etiqueta de versión. Una etiqueta se puede reescribir; un identificador de confirmación, no. Esta sola medida habría neutralizado la mayor parte de la propagación.
- Sustituir los secretos de larga duración en la automatización por credenciales efímeras emitidas por federación de identidad. Un token que expira en una hora tiene un valor marginal en un archivo de credenciales robadas.
- Separar los flujos automatizados que procesan aportaciones externas de aquellos que tienen acceso a secretos. Son dos funciones distintas y no deberían compartir contexto de ejecución.
- Aplicar egreso restringido en los agentes de compilación, con lista de destinos permitidos. Un agente que solo necesita hablar con tres registros no debería poder resolver un dominio arbitrario.
- Verificar que las copias de seguridad son inmutables y que la restauración se ha probado de verdad sobre volúmenes grandes. Frente a un cifrador que destruye lo que supera los 128 KB, la copia de seguridad no es un plan alternativo: es el único plan.
- Incluir a los proveedores de utillaje de seguridad en el inventario de terceros críticos. Con frecuencia quedan fuera del proceso formal de gestión del riesgo de terceros precisamente por ser proveedores de seguridad.
Y una consideración de gobierno que suele resolverse tarde: rotar 500.000 credenciales no es un ejercicio realista para nadie, pero identificar cuáles de las propias estuvieron expuestas en la ventana de marzo sí lo es, si existe un inventario decente de secretos. Quien no tenga ese inventario descubrirá que el trabajo de contención empieza por construirlo.
Lo que esto significa en clave NIS2 y DORA
Para las entidades incluidas en el ámbito de NIS2, este caso encaja de lleno en las obligaciones de seguridad de la cadena de suministro del artículo 21, que exige considerar las vulnerabilidades específicas de cada proveedor directo y la calidad de sus prácticas de desarrollo. Un proveedor de herramientas de seguridad integrado en la automatización de compilación es, a estos efectos, un proveedor directo con acceso privilegiado.
En el ámbito financiero, DORA plantea la misma cuestión con más aristas, porque el registro de información de acuerdos con terceros proveedores de servicios TIC obliga a documentar dependencias que muchas organizaciones nunca habían tratado como contractuales. Un escáner de código abierto embebido en la automatización de compilación no aparece en ningún contrato, pero es una dependencia funcional real con acceso a secretos de producción.
Sobre notificación, el elemento a valorar no es el compromiso del proveedor en marzo, sino el momento en que se determina que credenciales propias estuvieron expuestas y pudieron usarse. Esa determinación es la que activa los plazos, y por eso conviene que la respuesta a incidentes y el equipo de cumplimiento trabajen sobre el mismo cronograma desde el primer día.
Lo que deja este caso
Hay una tentación comprensible de leer esto como un problema de código abierto, y no lo es. El mismo patrón funciona con software propietario en cuanto una credencial de publicación cae en malas manos. Lo que cambia el panorama es otra cosa: que ahora existe un mercado que convierte de forma industrial el acceso robado en cadena de suministro en despliegues de ransomware, con reparto de funciones entre quien roba y quien extorsiona.
La segunda lectura es más incómoda. Durante años, el argumento para invertir en utillaje de seguridad en la automatización de compilación fue que reducía el riesgo. Sigue siendo cierto, pero ya no es gratis: ese utillaje es ahora superficie de ataque privilegiada y hay que tratarlo como tal, con las mismas exigencias de fijación de versiones, credenciales efímeras y vigilancia que aplicamos a cualquier componente con acceso a producción.
Y la tercera es la que más deprisa hay que interiorizar. Con Vect sobre la mesa, la pregunta «¿pagamos?» ya no tiene respuesta técnica útil. La única variable que queda bajo control es si las copias de seguridad aguantan una restauración completa. Conviene comprobarlo antes de necesitarlo, no durante. Si la organización no tiene claridad sobre su exposición en la ventana de marzo de 2026, un SOC gestionado con capacidad de análisis retrospectivo es el camino más corto para averiguarlo, y las lecciones acumuladas de la cadena de suministro digital apuntan todas en la misma dirección.
Este artículo incluye consultas de detección y medidas de fortificación con fines defensivos. Valídalas en un entorno de pruebas antes de aplicarlas en producción y adáptalas a tu propia arquitectura: los nombres de agentes, las rutas y las ventanas temporales varían en cada organización.