Por Canuto  

La campaña de TeamPCP no solo ha comprometido más de 1.000 paquetes de software de código abierto en pocos meses. También ha dejado al desnudo una falla más profunda: la dependencia casi automática de bibliotecas, repositorios y agentes de IA que muchas organizaciones incorporan a producción sin verificar su legitimidad.

***

  • TeamPCP ha inyectado código malicioso en más de 1.000 paquetes de software en menos de cuatro meses.
  • Los ataques se apoyan en fallas conocidas del modelo de confianza del código abierto, la automatización CI/CD y el uso creciente de IA.
  • Investigadores sostienen que el grupo busca más caos y notoriedad que ganancias directas, aunque ya ha reclamado miles de víctimas y extorsiones.

 

La ofensiva de TeamPCP contra el ecosistema de código abierto está redefiniendo el debate sobre la seguridad del software moderno. En menos de cuatro meses, el actor de amenazas ha comprometido e inyectado código malicioso en más de 1.000 paquetes, una escala que ha encendido alarmas en toda la industria.

El problema no se limita a la cantidad de paquetes alterados. El fondo del asunto es que TeamPCP ha demostrado, una y otra vez, que muchas organizaciones no verifican si el código que incorporan a sus sistemas es legítimo.

Ese punto resulta especialmente grave en un momento en que el desarrollo depende de cadenas complejas de librerías, repositorios y automatizaciones. En la práctica, una sola dependencia contaminada puede viajar aguas abajo hacia múltiples empresas y entornos de producción.

La historia comenzó a ganar visibilidad desde febrero, con incidentes como el caso de Trivy, y desde entonces la campaña se ha mantenido activa. La combinación de despliegues automáticos, confianza implícita y presión por actualizar rápido ha creado un escenario ideal para este tipo de sabotaje.

Según reportó CyberScoop, varios investigadores coinciden en que TeamPCP no inventó una técnica totalmente nueva. Lo que sí hizo fue explotar con velocidad, persistencia y volumen un conjunto de debilidades defensivas que la industria conoce desde hace años.

La velocidad del desarrollo se convirtió en una superficie de ataque

La obsesión del sector por acelerar ciclos de desarrollo y distribución de software aparece en el centro del problema. Hoy muchas empresas automatizan la instalación, prueba y publicación de código mediante pipelines de CI/CD que operan con intervención humana mínima.

Esa arquitectura permite escalar desarrollo, pero también amplifica los riesgos cuando un paquete malicioso entra en la cadena. Si un ejecutor automatizado consume una versión contaminada, el problema puede propagarse de inmediato a sistemas internos y clientes aguas abajo.

Feross Aboukhadijeh, fundador y CEO de Socket, dijo a CyberScoop que antes los desarrolladores ya hacían un trabajo insuficiente al revisar la seguridad de sus dependencias de código abierto. Ahora, con la IA, en algunos casos ni siquiera hay humanos aplicando verificaciones sensatas.

Su advertencia fue directa: hay agentes instalando paquetes que no han sido verificados. Cuando un atacante logra entrar en ese flujo, el impacto se vuelve mayor porque disminuyen los controles y equilibrios que podrían contener el daño.

Kimberly Goody, gerente senior del Google Threat Intelligence Group, resumió el fenómeno con otra idea clave. A su juicio, lo más llamativo no es la metodología de fondo, sino la velocidad y escala con la que TeamPCP está explotando la confianza depositada en terceros.

La situación también expone un dilema operativo. La industria ha enseñado por años que conviene instalar la última versión disponible para corregir vulnerabilidades y recibir mejoras, pero ese reflejo hoy puede convertirse en una puerta de entrada para malware.

Un modelo de confianza roto en el corazón del código abierto

El núcleo de estos ataques es una verdad incómoda para el software abierto: su modelo de confianza lleva tiempo bajo cuestionamiento. Investigadores y mantenedores saben desde hace años que el sistema es vulnerable al sabotaje, aunque el problema nunca se resolvió de forma estructural.

Los paquetes de software suelen atravesar monitoreo intensivo antes de llegar a producción. Sin embargo, la debilidad que TeamPCP ha puesto en primer plano no está solo en el paquete final, sino más arriba, en quienes publican ese software al mercado.

Nathaniel Quist, gerente de inteligencia de amenazas en la nube de Palo Alto Networks, sostuvo que la responsabilidad empieza por asegurar credenciales y evitar que el publicador del paquete se convierta en el punto inicial de un evento de cadena de suministro. Para él, toda esa zona debe permanecer bajo monitoreo y control estricto.

El efecto reputacional de esta campaña ha sido enorme porque destruye una premisa operativa básica del ecosistema. Durante años, registros abiertos como npm o PyPI fueron vistos como bienes públicos imperfectos, pero en general confiables y rara vez tratados como vectores primarios de intrusión.

Aboukhadijeh planteó que instalar software abierto con rapidez se ha convertido en una de las acciones más peligrosas para una organización en este momento. Incluso afirmó que existe aproximadamente una probabilidad de una en diez de que cualquier paquete instalado pueda detonar un ataque activo.

Ese cálculo ilustra el nivel de ansiedad que atraviesa hoy a investigadores y equipos de defensa. El problema ya no es únicamente corregir vulnerabilidades conocidas, sino discernir si la actualización que promete proteger también puede comprometer el entorno.

Quiénes están detrás y qué buscan

TeamPCP emergió a finales de 2025 y desde entonces ha capturado la atención de múltiples equipos de inteligencia de amenazas. Google atribuye la actividad a un operador central y rastreó conexiones de direcciones IP residenciales y móviles hacia Sudáfrica durante al menos parte de los ataques.

La empresa no identificó públicamente a esa persona ni confirmó conocer su identidad real. Goody dijo que no creen estar frente a un grupo central establecido, al menos por ahora, y que gran parte de la campaña parece haber sido ejecutada por un individuo.

Palo Alto Networks afirmó que el gestor central utiliza el seudónimo “ResoluteXBF” en múltiples plataformas. La firma también sigue a otros dos miembros centrales, identificados como “diencracked” y “Shinigami”.

Si la operación recae sobre todo en una sola persona, las fuerzas del orden tendrían una oportunidad poco común de generar impacto duradero con un único arresto. Aun así, los investigadores aclaran que TeamPCP sí ha colaborado con otros cibercriminales en distintos momentos.

De acuerdo con Goody, muchas de esas alianzas fueron breves y terminaron en disputas públicas o no prosperaron de forma relevante. Pese a ello, la campaña ha sido vinculada con grupos de extorsión, foros de la dark web y afiliados como Lapsus$, ShinyHunters, Vect, DragonForce, BreachForums y HasanBroker.

Entre las señales de monetización, TeamPCP publicó unos 4.000 repositorios de código privado en un foro de la dark web con un precio de USD $95.000. Sin embargo, tanto Google como Palo Alto consideran que la motivación central va más allá del dinero y apunta con claridad a la notoriedad y al caos.

Víctimas, alcance e impacto real de la campaña

TeamPCP ha sido particularmente ruidoso en su forma de operar. El grupo ha inyectado malware en software de código abierto con el fin de robar credenciales para entornos de Kubernetes, Amazon Web Services, Microsoft Azure, Google Cloud y otros servicios conectados.

La lista de víctimas reclamadas es amplia e incluye a Checkmarx, Bitwarden, LiteLLM, Telnyx, Mercor AI, PyTorch Lightning, AntV, SAP, GitHub, TanStack, UiPath, MistralAI, Microsoft DurableTask, Red Hat y Nx Console. Ese repertorio muestra que los ataques no se concentran en un solo nicho.

Quist indicó que la colección completa de paquetes comprometidos o envenenados por TeamPCP representa cerca de 500 millones de descargas semanales combinadas. Esa cifra sugiere un potencial de exposición descendente extraordinario dentro del ecosistema de desarrollo.

No obstante, el mismo investigador matizó el alcance práctico del daño. Explicó que muchos puntos finales infectados con esos paquetes no están expuestos a Internet, por lo que no necesariamente quedan en una posición explotable.

Su conclusión fue que probablemente no habrá un número extremadamente grande de víctimas efectivamente comprometidas. Sí existirán muchas personas y empresas con paquetes potencialmente vulnerables en su entorno, aunque no todas estarán expuestas a un ataque directo.

Aunque la campaña no ha generado pagos tan altos como otros esquemas criminales, el impacto reputacional ha sido desproporcionado. TeamPCP ha afirmado públicamente tener más de 10.000 víctimas y alrededor de USD $90.000 en extorsiones, según Quist.

Goody resumió esa contradicción de forma simple. Puede que no estén haciendo mucho dinero, dijo, pero sí están causando un impacto enorme y campañas muy disruptivas.

Cómo opera TeamPCP dentro de la cadena de suministro

La expansión de TeamPCP se ha apoyado en el secuestro de repositorios y herramientas de desarrollo en npm, PyPI, GitHub y otros servicios externalizados. Desde allí, el grupo inserta código malicioso en dependencias que luego son consumidas por proyectos legítimos.

Amitai Cohen, jefe del equipo de inteligencia sobre vectores de ataque en Wiz, explicó en SleuthCon que las laptops de desarrolladores y otros puntos finales usados para instalar, construir y publicar software suelen contener claves y acceso al código fuente. Eso las vuelve objetivos muy valiosos para atacantes de cadena de suministro.

Uno de los blancos preferidos de TeamPCP son los ejecutores de CI, es decir, sistemas automatizados encargados de construir, probar y publicar código. Cuando esos ejecutores son comprometidos, el malware puede quedar incrustado en repositorios que otros desarrolladores descargan sin sospechar.

El riesgo crece porque algunos artefactos, incluidas bibliotecas de Python, registros de npm y GitHub Actions, son descargados casi de inmediato por miles o millones de desarrolladores. Muchos entornos están configurados para consumir siempre la última versión disponible.

Cohen sostuvo que la propia industria de seguridad ayudó a instalar esa práctica. La lógica era razonable, porque actualizar rápido protege frente a vulnerabilidades conocidas y permite aprovechar nuevas funciones, pero ese mismo hábito es el que TeamPCP está explotando.

Al comprometer un flujo de trabajo de CI/CD, el grupo obtiene acceso a todos los usuarios aguas abajo que descargan ese código infectado de forma automática. En otras palabras, un solo “paciente cero” puede abrir la puerta a una expansión masiva por dependencias encadenadas.

Ritmo diario, evolución táctica y fatiga defensiva

Los investigadores describen una operación de alto ritmo que apenas da respiro. Según Wiz, TeamPCP infecta nuevos paquetes casi a diario, valida compromisos y captura datos sensibles dentro de las primeras 24 horas.

Ben Read, director de inteligencia estratégica en Wiz, señaló que algunos paquetes comprometidos permanecieron activos durante casi 13 horas. A la vez, también destacó que la comunidad de seguridad ha mejorado su capacidad de respuesta y ya retira algunos repositorios contaminados en apenas 15 minutos.

El grupo además ha ido refinando sus tácticas. Sus cargas útiles se han extendido en JavaScript y Python, mientras su alcance pasó de archivos locales a interfaces de programación de aplicaciones de Kubernetes y kits de desarrollo de software empaquetados.

Más recientemente, TeamPCP ha estado robando credenciales mediante protocolos personalizados. Esa evolución sugiere que no se trata de una campaña estática, sino de un adversario que ajusta herramientas y vectores conforme aprende del entorno defensivo.

Sus ambiciones también se expandieron hacia la replicación indirecta. TeamPCP fue vinculado con Mini Shai-Hulud, una pieza de malware autorreplicante que infectó cientos de paquetes de software en registros de código abierto durante oleadas sucesivas el mes pasado.

Un afiliado del grupo publicó el código fuente completo de ese malware en GitHub y animó a otros criminales a reutilizarlo en campañas propias. Read interpretó ese comportamiento como una prueba de que TeamPCP busca volumen por encima de sigilo, discriminación de objetivos o maximización de retorno.

La presión sobre los defensores ya es visible incluso en sus testimonios públicos. Cohen admitió que seguir esta ola de ataques se ha vuelto demasiado difícil y agotador para quienes trabajan en este espacio, hasta el punto de describir la situación como insostenible.

Las fallas defensivas que siguen alimentando el problema

Más allá de la intrusión inicial, la campaña también ha revelado lo difícil que resulta para muchas organizaciones revocar secretos comprometidos. Wiz afirmó que varias víctimas sufrieron infecciones recurrentes, en algunos casos hasta tres veces dentro de un mes, por no rotar correctamente sus secretos.

Ese patrón muestra que la respuesta posterior al incidente es tan importante como la prevención. Si las credenciales robadas siguen vigentes, el atacante puede regresar incluso después de que un paquete malicioso haya sido retirado del registro.

En el fondo, las organizaciones están lidiando con un compromiso operativo complejo. Deben actualizar software con rapidez para corregir vulnerabilidades, pero hacerlo demasiado rápido puede exponerlas a registros ilegítimos o versiones envenenadas.

TeamPCP ya ha comprometido escáneres de seguridad, gestores de contraseñas, herramientas de automatización, software de visualización de datos e infraestructura de CI/CD. La amplitud de esas categorías demuestra que ningún componente aparentemente auxiliar debe considerarse exento de riesgo.

Además del acceso inicial, el grupo ha extraído un volumen importante de credenciales y otros datos sensibles. Ese botín puede usarse para ataques posteriores, para venta clandestina o simplemente para reforzar la reputación de sus operadores en circuitos criminales.

La mayor lección que deja este caso es que la confianza implícita ya no basta en la cadena de suministro de software. Para una industria que también sustenta servicios financieros, plataformas de IA, exchanges, custodios y herramientas corporativas críticas, ese hallazgo tiene implicaciones que van mucho más allá del mundo del desarrollo.

El mensaje final de los investigadores es claro. No se puede seguir despertando cada mañana con un paquete de uso masivo comprometido y actuar como si nada hubiera pasado, porque la economía digital moderna depende precisamente de esos bloques de software reutilizado.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA.

 


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados