TeamPCP, de los ataques a Redis al compromiso de la cadena de suministro

Una actividad delictiva que se remonta al menos a 2020

Un análisis de Oligo Security, publicado el 7 de agosto de 2026, vincula a TeamPCP con actividades de ciberdelincuencia iniciadas al menos en 2020. Por tanto, el grupo llevaría años operativo antes de las campañas más recientes contra la cadena de suministro de software.

La relación se desprende de la coincidencia de dominios, infraestructuras de backend, rutas de distribución del malware, técnicas de staging y procedimientos operativos. Sin embargo, Oligo no determina si se trata de un cambio de marca directo, de un mismo grupo de operadores o de una colaboración entre actores previamente relacionados.

Las primeras actividades habrían tenido como objetivo sistemas accesibles desde Internet basados en Redis, Ray, Docker y React. En abril de 2020, Trend Micro ya había documentado una campaña contra servidores Redis expuestos, utilizados para distribuir malware y mineros de criptomonedas.

ShadowRay 2.0 y TA-NATALSTATUS

Durante la segunda mitad de 2025 se observaron dos campañas atribuibles al mismo ecosistema operativo.

La primera, ShadowRay 2.0, también conocida como IronErn, atacó infraestructuras de inteligencia artificial y las convirtió en una botnet capaz de propagarse de forma autónoma. La segunda, denominada TA-NATALSTATUS, tuvo como objetivo servidores Redis expuestos para instalar software de minería.

La correlación entre las identidades de GitHub y GitLab asociadas con IronErn y la infraestructura atribuida posteriormente a TeamPCP refuerza esta conexión. Oligo comparó registros de autenticación de GitLab, actividad de reverse shell, servidores de command and control y fases de staging del malware.

Además, el actor habría explotado vulnerabilidades conocidas en React, Docker, Redis y Ray, combinando automatización y técnicas wormable para acelerar la propagación.

De la explotación de servidores a la cadena de suministro

Las primeras informaciones públicas sobre el actor aparecieron hacia finales del año pasado, en relación con la Operation PCPcat. En esa campaña se habrían explotado vulnerabilidades en React Server Components y Next.js para sustraer credenciales y datos sensibles.

A principios de año, Flare describió una campaña a gran escala contra entornos cloud-native. Los objetivos incluían crear infraestructuras para proxy y escaneo, comprometer servidores, exfiltrar datos, desplegar ransomware, realizar extorsiones y minar criptomonedas.

Posteriormente, TeamPCP habría trasladado estas mismas capacidades a la cadena de suministro de software mediante:

• el compromiso de los sistemas de los desarrolladores;
• el envenenamiento de bibliotecas open source ampliamente utilizadas;
• el abuso de GitHub Actions;
• el robo y uso fraudulento de tokens;
• la explotación de infraestructuras cloud legítimas.

Esta evolución incrementa el riesgo para las organizaciones que dependen de pipelines automatizados y paquetes de terceros.

kube.py y el comportamiento destructivo en Kubernetes

Entre las herramientas observadas figura el script de Python kube.py, utilizado tras comprometer entornos Kubernetes. Las primeras versiones se centraban principalmente en la propagación y la persistencia.

Sin embargo, las variantes detectadas todavía en marzo de 2026 incorporan funciones similares a las de un wiper. El comportamiento depende de la zona horaria configurada en el sistema:

• en los clústeres de Kubernetes iraníes, crea un DaemonSet que borra todos los nodos mediante el wiper Kamikaze;
• en los nodos de Kubernetes fuera de Irán, despliega la backdoor CanisterWorm;
• en los sistemas iraníes que no utilizan Kubernetes, ejecuta poison_pill(), diseñada para borrar todo el sistema de archivos.

Por tanto, el impacto potencial incluye el robo de credenciales y datos, la minería, el ransomware, las backdoors y la destrucción completa de la infraestructura.

Qué deben comprobar las organizaciones

No se han publicado parches específicos, versiones corregidas, indicadores de compromiso ni reglas YARA. Por ello, las organizaciones deberían centrar las comprobaciones en las superficies señaladas por el análisis:

• servidores Redis, Ray y Docker expuestos directamente a Internet;
• clústeres de Kubernetes y actividad anómala de DaemonSets;
• pipelines de GitHub Actions y GitLab;
• tokens utilizables por sistemas automatizados;
• instalación o modificación inesperada de paquetes open source;
• conexiones con infraestructuras de command and control;
• procesos de reverse shell y scripts como kube.py;
• eliminación anómala de nodos, sistemas de archivos o recursos cloud.

No se conocen las versiones exactas de los productos vulnerables ni los procedimientos específicos de remediation. Por tanto, son necesarias un inventario de activos, la reducción de la exposición a Internet, la rotación de tokens y la supervisión de los pipelines de desarrollo.