Un nuevo análisis ha revelado que el actor de amenazas rastreado como TeamPCP no empezó sus operaciones a finales de 2025, como sugieren algunos reportes. De hecho, la actividad atribuida al mismo “ecosistema operativo” se remonta al menos a 2020, cuando el grupo ya comprometía infraestructuras accesibles desde Internet. Esta continuidad ayuda a entender por qué su enfoque pasó, con el tiempo, de ataques directos a objetivos concretos a incursiones más amplias en la cadena de suministro del software.
La investigación señala vínculos basados en coincidencias técnicas: solapamiento de dominios, rutas de despliegue de malware, técnicas de preparación (staging), infraestructura de soporte y patrones de operación. En otras palabras, no se trata de una única “historia” desconectada, sino de un hilo conductor que une campañas anteriores con el perfil que luego se asoció públicamente con TeamPCP.
De la infraestructura pública a los ataques Redis
Uno de los hallazgos centrales del informe es que los ataques Redis TeamPCP forman parte de una trayectoria más larga. La investigación sostiene que existe una evolución desde campañas previas documentadas por terceros, incluyendo una detallada en abril de 2020, en la que se atacaban servidores Redis expuestos para desplegar malware.
Según el análisis, el comportamiento observado en campañas posteriores confirma que el actor siguió apuntando a servicios accesibles y desplegó cargas útiles orientadas a monetización y control. En la práctica, esto se traduce en intentos de acceso oportunistas: cuando un servicio (por ejemplo, Redis) está disponible públicamente sin la protección adecuada, se vuelve un objetivo directo para la intrusión automatizada.
Campañas de 2025: ShadowRay 2.0 y TA-NATALSTATUS
Durante la segunda mitad de 2025 se observaron al menos dos campañas relevantes dentro de este mismo marco de actividad.
ShadowRay 2.0 (IronErn): infraestructura de IA en modo botnet
La campaña ShadowRay 2.0, también identificada como IronErn, incluyó el secuestro de infraestructura relacionada con IA para integrarla en una botnet de propagación. El objetivo operativo no se limitaba a un impacto aislado: buscaba que el acceso y el despliegue se integraran en un mecanismo con capacidad de avance posterior.
TA-NATALSTATUS: servidores Redis expuestos y mineros
La otra campaña, TA-NATALSTATUS, se enfocó en servidores Redis expuestos. En este caso, la finalidad descrita en el análisis fue entregar mineros de criptomonedas como parte del impacto. Este tipo de actividad encaja con el patrón de criminalidad orientada a la obtención de recursos: cuando un atacante controla entornos accesibles, puede monetizar el uso de CPU/GPU mediante minería.
Vínculos previos: credenciales y explotación en React
Antes de que el grupo recibiera la etiqueta pública de TeamPCP, los indicios emergieron por su relación con la explotación de fallas en React Server Components (RSC) y Next.js. Este comportamiento facilitó la extracción de credenciales y otros datos sensibles desde entornos comprometidos.
En el seguimiento, esta fase fue conocida como Operation PCPcat. El punto importante aquí es que, aunque el “tema” pudiera variar entre componentes de software y tecnologías específicas, el patrón se mantiene: el actor busca una forma de acceso aprovechando debilidades en aplicaciones web y frameworks ampliamente utilizados.
Flare y el enfoque en entornos cloud
Más adelante, en el mismo año, otra línea de análisis destacó una campaña grande orientada a entornos cloud nativos. En lugar de limitarse a un único tipo de víctima, el objetivo fue preparar infraestructura maliciosa distribuida a escala, para después comprometer servidores y ejecutar acciones como:
- exfiltración de datos
- despliegue de ransomware
- extorsión
- minería de criptomonedas
Este enfoque muestra una transición: de intrusiones centradas en servicios concretos hacia una estrategia con componentes de infraestructura listos para posteriores operaciones. En términos prácticos, quien controla la fase de preparación gana ventaja para escalar impactos.
Puente operativo: GitHub, GitLab y la conexión entre campañas
El análisis también subraya un elemento operativo clave: el solapamiento entre identidades en GitHub y GitLab. En concreto, se describen coincidencias observadas durante ShadowRay 2.0 y el despliegue posterior asociado a TeamPCP.
La vinculación se refuerza al correlacionar registros de autenticación en GitLab, infraestructura de comando y control, actividad de reverse shell y técnicas de preparación del malware. De esta manera, el informe sostiene que existe un “puente” directo entre campañas, lo que sugiere continuidad de operadores, reutilización de recursos o una coordinación estrecha.
El salto hacia la cadena de suministro
Con el tiempo, el actor amplió su estrategia hacia compromisos de cadena de suministro. Aquí la idea es aprovechar que el software moderno está interconectado: en lugar de atacar solo a usuarios finales o servidores individuales, el atacante busca infectar sistemas de desarrollo en masa.
El análisis describe el envenenamiento de bibliotecas de código abierto mediante una combinación de GitHub Actions y abuso de robo de tokens. Esto permite que la manipulación se propague a través de procesos legítimos de automatización, afectando a equipos que dependen de dependencias y flujos de trabajo ya establecidos.
Así, la evolución hacia ataques en cascada de la cadena de suministro se interpreta como un paso “natural” dentro del patrón: reutilizar métodos ya probados, pero aplicarlos a un entorno más amplio y con mayor capacidad de propagación.
Actualizaciones del arsenal: scripts para Kubernetes
Además de los cambios en objetivos, el informe señala ajustes continuos del arsenal malicioso. Se menciona un script en Python llamado kube.py, diseñado específicamente para actuar tras el acceso a entornos Kubernetes.
De acuerdo con el análisis, versiones anteriores del script se centraban en propagación y persistencia. Sin embargo, variantes observadas hasta marzo de 2026 incorporaron funcionalidades con comportamiento destructivo.
Funcionalidad tipo “wiper” y acciones según la zona horaria
El código descrito evalúa si el sistema víctima está configurado con la zona horaria de Irán. Si coincide, dispara un DaemonSet que borra nodos del clúster utilizando un componente con un nombre asociado a “Kamikaze”.
Para nodos ubicados fuera de Irán dentro de Kubernetes, el informe indica que se despliega un backdoor llamado CanisterWorm. En sistemas no-Kubernetes configurados para esa región, el malware ejecuta una rutina tipo “poison_pill()” para eliminar el sistema de archivos completo.
¿Rebranding o un mismo operador? Lo que sí y lo que no se puede afirmar
El informe no concluye con certeza absoluta sobre si los cambios obedecen a un rebranding directo, un conjunto compartido de operadores o una colaboración estrecha entre actores con historiales relacionados. No obstante, sí enfatiza el punto más relevante desde la perspectiva defensiva: los datos sugieren que TeamPCP representa la continuidad de un ecosistema operativo, más que la aparición de un actor totalmente nuevo a finales de 2025.
En conjunto, los hallazgos conectan campañas centradas en React, Docker, Redis y Ray, además del uso de técnicas automatizadas que permiten explotación escalable y con capacidad de propagación.
Qué significa para la defensa
Si los ataques Redis TeamPCP forman parte de una cadena que empieza en 2020, entonces la implicación para organizaciones es clara: los riesgos no se limitan a “vulnerabilidades puntuales” ni a un periodo concreto. El actor vuelve una y otra vez a tecnologías accesibles y populares, y además evoluciona hacia vectores con impacto sistémico como la cadena de suministro.
Para reducir la exposición, conviene reforzar medidas básicas que suelen frenar este tipo de intrusiones: gestionar correctamente servicios expuestos, limitar superficie de ataque, revisar entornos cloud y Kubernetes, y endurecer los procesos de CI/CD para evitar que tokens o automatizaciones se conviertan en una vía de propagación.
Mientras tanto, monitorear señales de actividad y correlacionar eventos de autenticación, despliegues y comportamientos anómalos puede ayudar a identificar continuidad operativa, especialmente cuando un atacante reutiliza infraestructura y patrones.
Conclusión
La investigación presentada consolida una historia más larga: TeamPCP se asocia con operaciones que incluyen ataques a servicios expuestos como Redis desde al menos 2020, con campañas posteriores que abarcan minería, intrusiones en entornos web y una transición hacia compromisos de cadena de suministro. Lo más preocupante no es un solo golpe, sino la idea de continuidad: el actor perfecciona técnicas, amplía objetivos y actualiza su arsenal para seguir encontrando oportunidades.
Fuente: https://thehackernews.com/2026/08/teampcp-linked-to-redis-attacks-dating.html
