Vect y TeamPCP colaboran en campañas de ransomware

Los investigadores de Counter Threat Unit™ (CTU) han investigado dos grupos de amenazas interconectados conocidos como Vect y TeamPCP. Ambos grupos anunciaron una alianza operativa formal a finales de marzo de 2026 para combinar las capacidades de TeamPCP en la obtención de credenciales y el robo de datos con la infraestructura de despliegue de ransomware de Vect en una campaña a gran escala que incluye ataques a la cadena de suministro y la extorsión de múltiples organizaciones.

La evolución de Vect

Las actividad de ransomware como servicio (RaaS) de Vect comenzó el 31 de diciembre de 2025, cuando una cuenta que operaba bajo el nombre del grupo publicó un anuncio de reclutamiento de afiliados en Rehub, un destacado foro de ciberdelincuencia en ruso. Vect se cobró sus primeras víctimas en enero de 2026 y, un mes después, lanzó Vect 2.0. El lanzamiento de la nueva versión coincidió con una campaña de captación de afiliados. Vect afirmó en X (antes Twitter) que había reclutado a 60 afiliados, atacado a 154 organizaciones y recibido «decenas de pagos exitosos» en dos meses.

Vect ha demostrado su disposición a colaborar con otros ciberdelincuentes para ampliar sus operaciones. En marzo, el grupo anunció colaboraciones con BreachForums y TeamPCP (véase la figura 1). A pesar de declarar que cada uno de los más de 300 000 miembros de BreachForums recibiría una clave de afiliación a Vect, es probable que el número de personas que realmente lanzaran ataques de ransomware en nombre de Vect fuera considerablemente menor. TeamPCP (también conocido como PCPcat, ShellForce y DeadCatx3) parece estar formado por personas que antes formaban parte de The Com, una confederación global de ciberdelincuentes principalmente angloparlantes. Dos víctimas que aparecen en la página de filtraciones de datos de Vect fueron identificadas como víctimas de la «campaña LiteLLM/Trivy (TeamPCP)».

Figura 1: Vect anuncia su colaboración con BreachForums y TeamPCP

Evolución de TeamPCP

TeamPCP saltó a la fama por primera vez en diciembre de 2025 por su relación con la explotación masiva de la vulnerabilidad React2Shell (CVE-2025-55182), un fallo crítico (CVSS de 10,0) de ejecución remota de código previo a la autenticación en React Server Components. TeamPCP lanzó una campaña basada en un gusano que aprovechaba las API de Docker expuestas, los clústeres de Kubernetes, los paneles de control de Ray y los servidores Redis, junto con la explotación de React2Shell. La campaña afectó a organizaciones de Canadá, Serbia, Corea del Sur, los Emiratos Árabes Unidos y Estados Unidos, con víctimas en los sectores tecnológico, financiero, sanitario y gubernamental. Una característica operativa destacada durante esta fase fue el uso del puerto de salida 666 para casi toda la actividad de red.

Figura 2: ataques a cadenas de suministro de TeamPCP de marzo a mayo de 2026

El primero de estos ataques fue contra Trivy, un escáner de vulnerabilidades de código abierto creado por Aqua Security y utilizado por miles de organizaciones en todo el mundo. Según se informa, los atacantes consiguieron acceso a finales de febrero al robar credenciales de inicio de sesión de los sistemas de desarrollo de Trivy. Aqua Security descubrió e intentó mitigar esa brecha el 1 de marzo, pero la limpieza fue incompleta y permitió a los atacantes mantener el acceso de forma sigilosa. El 19 de marzo, lanzaron un ataque a gran escala: manipularon simultáneamente el programa principal del escáner de Trivy y sus herramientas de automatización asociadas en GitHub, y provocaron la publicación de una versión maliciosa del software en los canales oficiales. Las organizaciones que descargaron lo que parecía ser una actualización de seguridad legítima estaban, en realidad, instalando malware. La versión maliciosa recopilaba en silencio contraseñas, credenciales de la nube y otros datos confidenciales de los sistemas en los que se ejecutaba, para luego transmitir esos datos robados a servidores controlados por los atacantes. Seguía realizando sus funciones normales de análisis para no levantar sospechas. A continuación, los atacantes usaron esas credenciales robadas para lanzar un gusano autopropagable llamado CanisterWorm, que se extendió por docenas de paquetes de software muy utilizados. Los desarrolladores o los procesos automatizados que instalaron un paquete afectado contribuyeron sin darse cuenta a esta propagación. El equipo de Trivy identificó y eliminó los componentes maliciosos en cuestión de horas, pero un número significativo de organizaciones ya se había visto afectado. En una entrevista con Forbes, un miembro de TeamPCP confirmó que habían utilizado agentes de IA para mejorar su estrategia de ataque. Afirmaron que habían desplegado un agente de IA para manipular socialmente la cuenta de servicio de Aqua Security y conseguir acceso a GitHub; sin embargo, no dieron más detalles.

Cuatro días después del ataque a Trivy, TeamPCP utilizó las credenciales robadas durante ese ataque inicial para acceder a los repositorios de Checkmarx. Checkmarx es una de las empresas de seguridad de aplicaciones más utilizadas del mundo. El incidente afectó a dos complementos distribuidos a través del mercado OpenVSX y a dos de los flujos de trabajo de GitHub Actions de Checkmarx (herramientas automatizadas que se ejecutan dentro de los procesos de desarrollo de software). Los atacantes introdujeron commits maliciosos en las 35 etiquetas de versión de la acción de GitHub «Keeping Infrastructure as Code Secure» (KICS) de Checkmarx y contaminaron la versión 2.3.28 de la acción de GitHub «AST», inyectando una carga útil para robar credenciales que, según determinaron investigadores externos, era funcionalmente idéntica al malware utilizado contra Trivy. Los datos robados se cifraron y se filtraron a un dominio controlado por los atacantes que imitaba la infraestructura de Checkmarx. Si ese canal principal fallaba, el malware usaba las credenciales de GitHub de la víctima para crear un repositorio oculto dentro de la cuenta de GitHub de esa organización y subir allí los datos robados. El periodo de exposición fue relativamente corto: los flujos de trabajo maliciosos de GitHub Actions solo estuvieron disponibles durante menos de cuatro horas, y los complementos maliciosos de OpenVSX estuvieron activos durante unas 12 horas. Pero dada la escala a la que se utilizan estas herramientas en los entornos de desarrollo empresariales, incluso unas pocas horas bastaron para que la exposición fuera significativa. La interfaz de línea de comandos (CLI) del gestor de contraseñas de código abierto Bitwarden también se vio comprometida posteriormente como parte de la intrusión en Checkmarx, lo que aumentó drásticamente el impacto potencial, teniendo en cuenta las decenas de millones de usuarios de Bitwarden.

El 24 de marzo, TeamPCP cambió de estrategia y se centró en los tokens de publicación de PyPI que probablemente habían sido robados tras el ataque a Trivy. El grupo contaminó el proceso de integración continua y entrega/implementación continua (CI/CD) de LiteLLM, de BerriAI, para publicar versiones maliciosas (1.82.7 y 1.82.8) en PyPI. LiteLLM es una biblioteca de puerta de enlace de IA con aproximadamente 96 millones de descargas mensuales; se encarga de redirigir las solicitudes entre los distintos proveedores de LLM. Los paquetes maliciosos contenían cargas útiles para robar credenciales y lógica de movimiento lateral orientada a Kubernetes. La versión 1.82.8 incluía un mecanismo de archivos que activaba la carga útil automáticamente al iniciar el intérprete de Python, incluso sin importar explícitamente el paquete. Los paquetes estuvieron activos durante unas tres horas antes de ser puestos en cuarentena.

Siguiendo un patrón similar al del ataque a LiteLLM, TeamPCP publicó versiones maliciosas del SDK de Python de Telnyx (4.87.1 y 4.87.2) en PyPI el 27 de marzo. Estas versiones introdujeron la esteganografía de audio WAV como un nuevo mecanismo de entrega de cargas útiles, con rutas de ejecución específicas para Windows y Linux/macOS, lo que supone una evolución más de la técnica de entrega dentro de una misma campaña.

TeamPCP se asoció con grupos de extorsión ya conocidos para sacar provecho de lo que habían robado. El grupo Lapsus$ añadió Checkmarx a su sitio de filtraciones, afirmando haber obtenido código fuente, claves de API, credenciales de bases de datos y datos de empleados. El propio TeamPCP se jactó públicamente de sus planes de encadenar estas vulnerabilidades en campañas de ransomware. Esta amenaza se materializó a principios de abril, cuando una startup de IA confirmó que se encontraba entre las miles de empresas afectadas por los ataques en cadena.

Durante esta campaña, TeamPCP comprometió cuatro paquetes de herramientas de seguridad e IA muy extendidos, propagó un gusano a través de más de 48 paquetes de npm y afectó a más de 1000 entornos empresariales de software como servicio (SaaS). Se sustrajeron aproximadamente 300 GB de datos comprimidos, incluyendo unos 500 000 conjuntos de credenciales individuales. El 9 de mayo, TeamPCP continuó con los ataques a la cadena de suministro volviendo a atacar a Checkmarx y publicando una versión maliciosa del complemento AST de Checkmarx para Jenkins. Como parte de esta segunda intrusión, TeamPCP alteró el repositorio de GitHub del complemento, cambiándole el nombre y actualizando la descripción para que dijera: «Checkmarx vuelve a fallar al rotar secretos. Con cariño, TeamPCP».

Alianza entre Vect y TeamPCP

La alianza formal entre TeamPCP y Vect permite a Vect desplegar ransomware en todas las organizaciones afectadas por los ataques a la cadena de suministro de Trivy y LiteLLM. Los investigadores de CTU™ observaron que TeamPCP reclutaba negociadores poco después del ataque a Trivy, lo que sugiere que el grupo preveía pasar rápidamente a la monetización. Antes de la alianza con Vect, TeamPCP llevaba a cabo otra operación de ransomware bajo la marca CipherForce. CipherForce publicó una lista de seis víctimas en su sitio de filtraciones en febrero de 2026 y, en mayo, pasó a llamarse sitio de filtraciones de TeamPCP (véase la figura 3).

Figura 3: sitio de filtraciones de TeamPCP

En abril, Jumpsec describió un fallo crítico de implementación en el ransomware de Vect que provocaba que cualquier archivo de más de 128 KB se destruyera de forma permanente en lugar de cifrarse. Vect respondió con una publicación en X en la que negaba que existiera ningún problema; sin embargo, otros investigadores también han informado del mismo problema con el binario del ransomware Vect. TeamPCP publicó un comunicado en el que confirmaba que nunca había utilizado las herramientas de cifrado de Vect y que solo había usado su propio sistema de cifrado de CipherForce. El comunicado confirmaba que TeamPCP también estaba asociado con Lapsus$, concretamente en relación con el incidente de Checkmarx. El sitio de filtración de datos de Lapsus$ incluía a Checkmarx como víctima.

La alianza entre Vect y TeamPCP supone un cambio significativo en el panorama de las amenazas de ransomware, incluso teniendo en cuenta las deficiencias técnicas que merman su eficacia operativa. La convergencia entre el robo a gran escala de credenciales en la cadena de suministro, una operación de RaaS cada vez más madura y la movilización masiva en foros clandestinos constituye un modelo sin precedentes de despliegue industrializado de ransomware que reduce significativamente la barrera de entrada para la ciberdelincuencia. TeamPCP ha demostrado su capacidad para comprometer repetidamente herramientas de código abierto de confianza. Se ha confirmado al menos un despliegue verificado del ransomware Vect utilizando credenciales obtenidas a través de TeamPCP, lo que significa que la cadena que va desde el compromiso de la cadena de suministro hasta la ejecución del ransomware está operativa. Es fundamental que las organizaciones afectadas por Vect no den por sentado que el pago del rescate garantizará la restauración de los datos; los fallos de cifrado documentados por investigadores externos implican que pagar podría traducirse simplemente en una pérdida de datos permanente e irrecuperable.

Recomendaciones y medidas de protección

Las organizaciones que utilicen herramientas de código abierto en sus flujos de trabajo de desarrollo deben mantener un inventario actualizado para poder evaluar rápidamente el impacto potencial cuando se anuncie un ataque a la cadena de suministro y facilitar una respuesta rápida para mitigar el riesgo. Las actualizaciones de software de terceros podrían ser un vector de ataque, por lo que las organizaciones deben verificar la integridad de las actualizaciones antes de implementarlas en su entorno.

Las siguientes protecciones de Sophos están relacionadas con esta amenaza:

• Troj/PyAgent-CA
• JS/Agent-BLZZ
• JS/Steal-EAP
• Linux/Agnt-HZ