Dentro de TeamPCP: cómo Google desbarató una campaña contra la cadena de suministro desde el chat central de los atacantes

Google vigiló a TeamPCP desde el interior del grupo cibercriminal mientras este comprometía software de código abierto, obtenía credenciales de desarrolladores y se expandía a más de mil empresas. El acceso permitió a los equipos defensivos revocar material de autenticación robado, advertir a las víctimas y obtener código funcional para un exploit de día cero asistido por IA.

La operación también puso al descubierto un ecosistema criminal fragmentado. TeamPCP se asoció con ShinyHunters para monetizar su acceso, pero el grupo terminó apropiándose de las credenciales robadas, reteniendo los pagos y filtrando los mensajes internos de TeamPCP.

Posteriormente, las autoridades australianas detuvieron y acusaron a dos ciudadanos del país, Ruben Ian Thomson y Louis Michael Gaebler. Las autoridades los describieron como participantes principales de TeamPCP, pero la atribución sigue siendo una acusación y no se han revelado los cargos concretos.

Los paquetes comprometidos se convirtieron en puertas de entrada para la siguiente víctima

TeamPCP parece haber aparecido públicamente a finales de 2025. Su campaña siguió un modelo de cadena de suministro en cascada, en el que cada intrusión exitosa generaba nuevas oportunidades de compromiso.

Los atacantes obtenían primero el control de un proyecto de código abierto o de un proveedor de software. Después insertaban malware para robar credenciales en el software afectado, dejando expuestos nombres de usuario, contraseñas y tokens de acceso pertenecientes a desarrolladores y usuarios posteriores.

TeamPCP podía utilizar ese material de autenticación para acceder a otro proyecto, entorno cloud o empresa tecnológica. El malware introducido a través del software recién comprometido permitía recopilar otra tanda de credenciales, lo que hacía posible que el ciclo continuara.

Según la investigación de Google, la campaña afectó a cientos de paquetes de código abierto y permitió vulnerar a más de mil empresas. Entre los productos y organizaciones afectados por la operación se encontraban:

• Trivy, un escáner de seguridad de código abierto;
• LiteLLM, una herramienta de API utilizada por aplicaciones de IA;
• la empresa de seguridad de aplicaciones web Checkmarx;
• TanStack, una biblioteca para aplicaciones web;
• Mistral AI y su plataforma de IA empresarial;
• GitHub;
• Mercor, una empresa de contratación basada en datos;
• dispositivos de empleados de OpenAI;
• dispositivos de empleados de la Comisión Europea.

No se han identificado otras víctimas. Tampoco se han revelado los paquetes concretos, los números de las versiones maliciosas ni las versiones de software afectadas, lo que impide a las organizaciones basarse en una lista definitiva de exposición por versión.

TeamPCP complementó estas intrusiones con Mini Shai-Hulud, un gusano autorreplicante diseñado para automatizar la expansión por los entornos de desarrollo. Su nombre aparentemente hacía referencia a Shai-Hulud, otro gusano asociado con una técnica similar contra la cadena de suministro en septiembre de 2025. No se ha establecido ninguna conexión entre TeamPCP, los sospechosos detenidos y aquella campaña anterior.

Una identidad encubierta entró en el círculo interno de CanisterWorm

Un analista de Mandiant contactó con TeamPCP utilizando una identidad online inventada. Tras ganarse la confianza de una persona invitada a la organización, el analista obtuvo acceso en marzo a CanisterWorm, un chat central con aproximadamente 12 participantes.

Austin Larsen, de Google Threat Intelligence Group, que tiene previsto hablar sobre la investigación en una conferencia de SentinelOne LABScon, no era el agente encubierto.

El analista evitó participar en ataques, ayudar en intrusiones o animar a los miembros de TeamPCP. En su lugar, la identidad se comunicaba únicamente cuando era necesario para conservar el acceso y observaba discretamente la infraestructura del grupo, sus conversaciones, los datos robados y sus planes futuros.

Esa posición permitió acceder a un servidor que almacenaba credenciales sustraídas a las víctimas. La información incluía contraseñas, nombres de usuario y tokens de acceso capturados mediante los compromisos de software del grupo, así como material que aparentemente se estaba preparando para una extorsión.

Google se enfrentaba a un problema de contención: ponerse en contacto individualmente con cada propietario de una credencial habría dado a los atacantes más tiempo para utilizar el acceso robado. En su lugar, los investigadores contactaron con los proveedores capaces de invalidar grandes cantidades de credenciales, entre ellos Amazon Web Services y Microsoft.

GTIG envió cientos de avisos a proveedores y organizaciones afectadas. Muchos destinatarios actuaron de inmediato, lo que permitió revocar credenciales y tokens antes de que pudieran facilitar nuevas intrusiones.

Esta estrategia centrada en los proveedores abordó una característica definitoria de los incidentes contra la cadena de suministro. Un solo token de desarrollador robado puede afectar a repositorios, lanzamientos de paquetes, sistemas de compilación y recursos cloud pertenecientes a varias organizaciones. Por tanto, revocarlo en la capa de servicio puede cerrar varias vías de ataque a la vez.

La IA ayudó a crear un bypass funcional de la autenticación de dos factores

La vigilancia interna dejó al descubierto a otro miembro de TeamPCP que estaba desarrollando un exploit de día cero contra un producto de inicio de sesión ampliamente utilizado. El atacante empleaba una herramienta de IA para ayudar a crear código capaz de eludir el control de autenticación de dos factores del producto.

Google obtuvo el exploit y lo probó. Aunque los investigadores tuvieron que realizar varias modificaciones, el código terminó funcionando, lo que demostró un intento de explotación asistido por IA contra una vulnerabilidad desconocida hasta entonces durante una operación criminal activa.

Se notificó al desarrollador afectado y se corrigió la vulnerabilidad. Google describió el episodio en un estudio de caso publicado en mayo, pero no identificó a TeamPCP ni reveló que sus investigadores habían recuperado el código de las comunicaciones del grupo.

El nombre del producto, el proveedor, el identificador de la vulnerabilidad y la versión corregida siguen sin conocerse. En consecuencia, no existe un CVE público que las organizaciones puedan utilizar para hacer un seguimiento de la exposición, y no se ha divulgado información que permita establecer si la vulnerabilidad aparece en el catálogo de vulnerabilidades explotadas conocidas de CISA.

Estas omisiones limitan la verificación independiente y la corrección dirigida. Los administradores no pueden determinar a partir de la información disponible si utilizan la tecnología de inicio de sesión afectada o si una versión concreta instalada contiene el código corregido.

No obstante, el incidente ilustra un uso concreto de la IA en el desarrollo ofensivo. La herramienta no eliminó la necesidad de realizar modificaciones humanas, pero contribuyó a crear código destinado a neutralizar una protección de autenticación crítica.

ShinyHunters utilizó contra TeamPCP el acceso que le había robado

Aunque supuestamente disponía de credenciales asociadas a más de medio millón de usuarios, TeamPCP tuvo dificultades para convertir el acceso en ingresos. Larsen calculó que el grupo solo obtuvo decenas de miles de dólares mediante extorsiones, muy por debajo de los millones conseguidos por organizaciones criminales con más experiencia.

Por ello, TeamPCP ofreció a otros grupos acceso a su colección de credenciales a cambio de una parte de los pagos de extorsión resultantes. Uno de sus socios fue ShinyHunters, una prolífica operación de robo de datos y extorsión.

Alrededor de abril, varias semanas después de iniciar la colaboración, ShinyHunters empezó a utilizar las credenciales de TeamPCP por su cuenta y no entregó la parte acordada de los ingresos. También envió a Larsen una copia completa de los mensajes almacenados en el servidor de TeamPCP, aparentemente sin saber que Google ya tenía acceso a través de la identidad de Mandiant.

ShinyHunters se burló públicamente de TeamPCP en X. TeamPCP reaccionó restringiendo las membresías, trasladando la información robada a otro servidor y expulsando a ShinyHunters y a varios participantes más de CanisterWorm.

La identidad encubierta de Google también fue expulsada. Los responsables de TeamPCP ordenaron a los miembros restantes que dejaran de compartir información con ShinyHunters.

La disputa no puso fin a la investigación de Google. En su lugar, obligó a la operación a pasar de la observación directa al análisis de la infraestructura, los registros archivados de foros y la atribución digital.

Los registros de foros antiguos vincularon un alias con Ruben Ian Thomson

Los datos filtrados de una cuenta de BreachForums asociaron una de las identidades más activas de CanisterWorm con la dirección de Gmail [email protected].

Google buscó en archivos antiguos de foros e identificó una disputa de 2019 relacionada con el seudónimo «sheepstealing» y un vendedor de claves pirateadas de Microsoft Office. Durante la disputa, el usuario solicitó un reembolso a una cuenta de PayPal vinculada a [email protected].

Los investigadores encontraron otro vínculo después de que TeamPCP trasladara su repositorio de credenciales. La información obtenida a través de un socio de confianza mostró que el nuevo servidor se estaba respaldando en una cuenta de Google Drive asociada a [email protected].

Google entregó la información identificativa al FBI. Larsen afirmó que un agente respondió en cuestión de minutos. Aproximadamente un mes después, las autoridades estadounidenses completaron el proceso judicial necesario para obtener de Google los datos de la cuenta de Thomson.

Posteriormente, la policía australiana detuvo a Thomson en una vivienda de las afueras. Louis Michael Gaebler fue detenido en la misma investigación. Ambos tenían poco más de 20 años, y la Australian Federal Police los describió como participantes principales de TeamPCP.

La AFP no los identificó en su comunicado público debido a las normas australianas de privacidad. Ninguno de los dos hizo declaraciones y no se hicieron públicos los cargos concretos. El periodista e investigador de ciberseguridad Brian Krebs también podría haber identificado a Thomson de forma independiente antes de las detenciones.

Los equipos defensivos deben tratar las credenciales de desarrolladores como una exposición que afecta a todo el incidente

Las organizaciones potencialmente afectadas por TeamPCP no pueden depender de una lista completa de paquetes o versiones. Por tanto, la labor defensiva debe centrarse en las credenciales, la integridad de las versiones y los sistemas utilizados para compilar y publicar software.

Las contraseñas, claves de API, tokens de repositorios y credenciales cloud expuestos en los equipos de desarrolladores deben rotarse de inmediato. La revocación es preferible a cambiar únicamente las contraseñas, ya que los tokens de larga duración pueden seguir funcionando de forma independiente de la contraseña del usuario.

Los equipos de seguridad también deberían revisar:

• los repositorios de código fuente en busca de commits, mantenedores o artefactos de lanzamiento no autorizados;
• las plataformas CI/CD para detectar flujos de trabajo modificados y accesos desconocidos a secretos;
• los registros de paquetes en busca de versiones creadas fuera de los procedimientos habituales de publicación;
• los endpoints de los desarrolladores para detectar robo de credenciales y actividad de Mini Shai-Hulud;
• los entornos de AWS y Microsoft para identificar sesiones creadas con credenciales expuestas;
• el almacenamiento cloud para detectar copias de seguridad sospechosas o la sincronización de información robada.

Las cuentas de desarrolladores comprometidas deben deshabilitarse hasta revisar su actividad, los factores de autenticación y los tokens asociados. Las organizaciones que utilicen Trivy, LiteLLM, TanStack y otras tecnologías mencionadas deben verificar la procedencia de los paquetes, pero la ausencia de versiones reveladas significa que su mera presencia no demuestra que se hayan visto comprometidas.

Las acciones de Google formaron parte de un cambio más amplio hacia la interrupción directa a través de su Cyber Disruption Unit. En lugar de limitarse a publicar inteligencia, la empresa utilizó su acceso para invalidar recursos de los atacantes, avisar a los proveedores, proteger a las víctimas, asegurar un parche para una vulnerabilidad de día cero y apoyar la atribución por parte de las fuerzas del orden.

La investigación encubierta sobre TeamPCP muestra hasta qué punto puede propagarse una sola identidad de desarrollador robada por los sistemas modernos de distribución de software. En esta campaña, los paquetes de confianza no eran simplemente objetivos. Eran el mecanismo para llegar a la siguiente organización.