El 28 de abril de 2026, Check Point Research publicó un análisis técnico del cifrado de VECT 2.0 (CPR-2026-0428). La conclusión es clara: el cifrado de VECT se puede descifrar de una forma concreta. En cualquier archivo de más de 128 KB, el proceso que debería generar una clave de cifrado única para cada fragmento del archivo reutiliza, en cambio, un único valor, y solo se guarda ese valor final. Las tres cuartas partes de cada archivo de gran tamaño quedan cifradas de forma permanente. La víctima no puede recuperarlas. VECT tampoco puede recuperarlas.
Pagar el rescate no permite recuperar los archivos de gran tamaño. La clave de descifrado es auténtica. La pérdida de datos se produce incluso antes de que la clave sea relevante.
Esa conclusión es importante por sí misma. Además, es consecuencia de un problema más estructural al que se le ha prestado mucha menos atención.
Cómo se seleccionan los objetivos
La mayoría de las operaciones de ransomware siguen la misma secuencia a la hora de elegir sus objetivos. Un grupo identifica una organización, se hace con acceso —ya sea creándolo o comprándolo— y, a continuación, lleva a cabo el ataque. La selección del objetivo tiene lugar antes de que exista dicho acceso. Tu exposición a un grupo de ransomware concreto depende de si ese grupo ha decidido atacar a organizaciones como la tuya.
VECT no funciona así. Tampoco lo hace su socio en la cadena de suministro, TeamPCP.
El informe FLASH-20260702-01 del IC3 del FBI, publicado el 2 de julio de 2026, documenta una campaña basada en la amplitud de alcance más que en la selección de objetivos. Entre febrero y marzo de 2026, el grupo TeamPCP manipuló cuatro paquetes de software de código abierto de uso generalizado en los que las organizaciones confían para el desarrollo y los análisis de seguridad:
- Trivy, una herramienta utilizada para analizar contenedores en busca de vulnerabilidades de seguridad: TeamPCP aprovechó una vulnerabilidad (CVE-2026-33634) para sobrescribir 76 de las 77 versiones del flujo de trabajo automatizado de Trivy con una copia maliciosa, utilizando unas credenciales de desarrollador robadas que tenían acceso de escritura al repositorio de código.
- Checkmarx KICS, una herramienta que analiza el código de la infraestructura en busca de errores de configuración: TeamPCP también sobrescribió 35 versiones. Además, utilizaron las propias credenciales de automatización de cada organización víctima para crear un repositorio oculto llamado
docs-tpcpdentro de la cuenta de GitHub de la víctima. - LiteLLM v1.82.8, una biblioteca de software con aproximadamente 95 millones de descargas mensuales: TeamPCP añadió un archivo llamado
litellm_init.ptha la instalación. Los archivos con la extensión.pthPython lee y ejecuta automáticamente las extensiones cada vez que se inicia, independientemente del software que estés ejecutando en ese momento. Esto permitió a TeamPCP ejecución persistente de código en cualquier equipo en el que se hubiera instalado el paquete. - Versiones 4.87.1 y 4.87.2 del SDK de Python de Telnyx: un troyano de acceso remoto de tres fases, es decir, un software que, de forma silenciosa, permite a los atacantes tomar el control del equipo infectado.
TeamPCP es el mismo grupo responsable del worm de cadena de suministro Shai-Hulud, que utiliza paquetes comprometidos para propagarse automáticamente a través de entornos de desarrollo y procesos de CI/CD. La campaña llevada a cabo entre febrero y marzo de 2026 contra Trivy y LiteLLM utilizó el mismo mecanismo subyacente: paquete de confianza, ejecución automática y sustracción de credenciales. Shai-Hulud, parte 2, aborda la campaña de mayo de 2026 contra TanStack, en la que el worm más allá y generó certificados de firma criptográfica válidos para superar los controles de verificación de paquetes.
El resultado: más de 500 000 credenciales robadas de más de 10 000 pipelines de CI/CD (integración y despliegue continuos), los sistemas automatizados que crean, prueban y despliegan software. Tokens de AWS, Azure y GCP. Secretos de Kubernetes. Credenciales de registros de contenedores. Tokens de acceso a GitHub y GitLab.
TeamPCP no seleccionó objetivos, sino paquetes. En marzo de 2026, ya existía el archivo de credenciales. VECT lo revisó y seleccionó a las víctimas del ransomware del inventario.
La selección del objetivo se produjo después del acceso, no antes.
«Juntos, estamos preparados para lanzar un ransomware contra todas las empresas afectadas por estos ataques, y no nos detendremos ahí».
«Encadenaremos estas brechas de seguridad para lanzar campañas de ransomware posteriores con efectos devastadores».
Qué cambia esto en cuanto a la exposición al ransomware
El ejercicio convencional de planificación frente al ransomware plantea la siguiente pregunta: «¿Qué tendría que hacer un atacante para acceder a nuestro entorno?». Esa pregunta da por sentado que el atacante aún no lo ha decidido. El modelo TeamPCP sugiere que esa pregunta podría haber sido respondida ya, hace meses, mediante la instalación rutinaria de un paquete en un proceso de desarrollo del que tu equipo se ha olvidado desde entonces.
La unidad Counter Threat Unit de Sophos ha confirmado al menos un caso de implementación de VECT en el que se utilizaron credenciales procedentes de TeamPCP. El FBI advierte de que las credenciales robadas «se utilizarán con fines maliciosos mucho tiempo después de la intrusión inicial». Tu exposición a VECT no depende de si el grupo tiene como objetivo tu sector, sino de si tus cloud se encuentran en ese archivo.
Por qué no aparece en tus registros
Esta es la brecha n.º 3: el movimiento no es visible.
En litellm_init.pth El archivo de persistencia se ejecuta automáticamente cada vez que se inicia Python en el entorno afectado. El gestor de paquetes de software registra una instalación. El proceso de CI/CD registra la ejecución de un flujo de trabajo atribuido a una cuenta de servicio conocida. El cloud registra una llamada a la API autenticada desde una identidad reconocida. Tres registros de auditoría, tres incidencias del Centro de Operaciones de Seguridad (SOC) y una filtración.
No hay ningún registro que muestre por sí solo el recorrido desde el paquete comprometido hasta cloud de producción. Para reconstruirlo, es necesario correlacionar la marca de tiempo de la instalación, la ejecución del flujo de trabajo y la llamada a la API saliente con una lista de versiones de paquetes afectadas que la mayoría de las organizaciones no mantienen y que la mayoría de los sistemas de monitorización de seguridad no comprueban automáticamente. El mismo problema de registros fragmentados se produjo en el incidente de la cadena de suministro de Anodot/Snowflake en abril de 2026, en el que los tokens robados a un proveedor de integración SaaS se reutilizaron en múltiples entornos de clientes, y cada sistema validaba su propia parte de la actividad sin que ninguno los conectara entre sí. El caso de VECT/TeamPCP sigue el mismo patrón, pero a través de la capa de CI/CD en lugar de la capa de integración SaaS.
El vector KICS de Checkmarx añade otra capa. TeamPCP utilizó las propias credenciales de automatización de la víctima para crear docs-tpcp dentro de la organización de GitHub de la víctima. El evento de creación del repositorio aparece en el registro de auditoría de GitHub atribuido a la cuenta de servicio de la víctima. Todo parecía estar bien. Eso es el «Gap 1».
La brecha de competencias dentro de la operación
El análisis realizado por Check Point del código de VECT 2.0 reveló claros indicios de un desarrollo amateur: código destinado a eludir la seguridad que está escrito pero que en realidad nunca se ejecuta, una capa de ofuscación que se desactiva por sí misma, parámetros de configuración que parecen flexibles pero que, en realidad, están codificados de forma fija, y texto decorativo defectuoso en el programa. La falla de cifrado que hace que VECT destruya de forma permanente los archivos de sus víctimas sigue el mismo patrón. El malware obra de aficionados.
Sin embargo, la infraestructura que lo rodea sí lo es. El programa de afiliados de VECT incluye cuentas de depósito en garantía de Monero (una criptomoneda centrada en la privacidad), integración con BreachForums, comisiones por niveles y negociadores especializados que se encargan de las negociaciones de los rescates. El modelo de afiliación masiva de BreachForums, formalizado el 16 de abril de 2026, permite a los operadores acceder a esta infraestructura sin necesidad de crear la suya propia. El archivo de credenciales de TeamPCP sustituye a las habilidades técnicas de explotación: no se necesita una vulnerabilidad en las defensas del objetivo si ya se dispone de sus cloud .
Esto es importante para la planificación de la defensa. Un software de seguridad para dispositivos finales que funcione correctamente identificará el malware. La vía de distribución a través de las cadenas de suministro de software y los procesos automatizados no lo activará. La detección no falla. Es incompleta.
Qué hay que comprobar ahora
Si tu entorno ejecutó alguno de estos paquetes antes de abril de 2026, considera que tus cloud de Pipeline están comprometidas hasta que puedas confirmar lo contrario:
- LiteLLM, concretamente la versión 1.82.8. Busca también
litellm_init.pthen los directorios de instalación de Python de cualquier equipo en el que se ejecutara LiteLLM durante febrero y marzo de 2026. - Acción de GitHub «Trivy», cualquier versión fijada en las etiquetas 0.76.x o 0.77.x durante ese periodo.
- Acción de GitHub de Checkmarx KICS, cualquiera de las 35 etiquetas afectadas.
- SDK de Python de Telnyx 4.87.1 o 4.87.2.
Busca en la lista de repositorios de tu organización de GitHub: docs-tpcp. Su presencia indica que TeamPCP utilizó tus propias credenciales de automatización para crearlo. Renueva cloud (cuentas de servicio de AWS, Azure y GCP, tokens de registro de contenedores y tokens de acceso a GitHub y GitLab) emitidas antes de abril de 2026 en los entornos afectados. Revisa los registros de AWS CloudTrail, Azure Monitor y GCP Cloud para detectar llamadas a la API realizadas desde cuentas de servicio de pipelines a entornos de producción entre febrero y abril de 2026, prestando especial atención a aquellas llamadas anteriores a las implementaciones conocidas.
El capítulo «La brecha 3» de Mind Your Attack Gaps aborda el caso prácticocloud , en el que el mismo problema de registros fragmentados se repite en una cadena de ataque diferente. En Vectra AI, modelamos el movimiento entre entornos a través de identidades, cloud y el SaaS sin depender de la correlación entre tres sistemas de auditoría independientes. La campaña TeamPCP/VECT es un claro ejemplo de por qué la visibilidad de un solo entorno no cubre este tipo de ataques.
El archivo de credenciales existe. Si tu pipeline ejecutó los paquetes afectados antes de abril de 2026, la pregunta que debes plantearte ahora no es si podrías ser objeto de un ataque, sino si tus tokens ya se encuentran allí.