PCPJack es un nuevo framework de robo de credenciales dirigido a servicios cloud expuestos (Docker, Kubernetes, Redis, MongoDB, RayML, aplicaciones web vulnerables), que no solo roba de forma masiva accesos a servicios cloud, de contenedores, de desarrollo, de oficina y financieros, sino que además elimina de manera deliberada artefactos relacionados con el grupo TeamPCP, «desalojando» de hecho a los competidores de los entornos comprometidos; los propietarios de infraestructura en la nube ya deben empezar a inventariar los servicios expuestos, restringir estrictamente el acceso a los metadatos de instancias y comprobar los sistemas en busca de rastros de scripts de instalación automática y del instrumento Sliver.

Detalles técnicos de PCPJack

En el análisis publicado se describe un conjunto de herramientas completo y modular, que funciona en varias etapas y está orientado a la infraestructura cloud.

Acceso inicial y preparación del entorno

El ataque se inicia con un script bootstrap‑shell, que:

• prepara el entorno de ejecución y configura el host para descargas posteriores;
• descarga la siguiente fase de herramientas (incluidos seis scripts en Python);
• intenta infectar también la propia infraestructura del atacante (lo que apunta a rasgos de «gusano»);
• detecta y detiene procesos, y además elimina artefactos relacionados con TeamPCP;
• instala Python y habilita un mecanismo de persistencia;
• ejecuta el script orquestador en Python y luego se autodestruye, minimizando los rastros.

Los objetivos para la propagación son:

• servicios e instancias cloud abiertos y/o mal configurados;
• entornos Docker y Kubernetes;
• servicios de almacenamiento de datos Redis, MongoDB;
• la plataforma RayML y aplicaciones web vulnerables.

Orquestación y uso de Common Crawl

Una característica clave: el orquestador del gusano obtiene la lista de objetivos no de su propio escáner, sino de archivos parquet descargados directamente del conjunto de datos público de Common Crawl. Esto permite:

• escalar la campaña gracias a listas masivas ya preparadas de dominios y URL;
• trasladar parte del «trabajo de rastreo» de internet a un proyecto legítimo;
• enmascarar la lógica de selección de objetivos como trabajo habitual con datos abiertos.

Este esquema encaja bien en la técnica T1595 (Active Scanning), pero apoyándose en fuentes externas de inteligencia.

Robo de credenciales y métricas de éxito

El framework recopila de forma sistemática:

• información del sistema de la víctima;
• credenciales de servicios cloud, de contenedores, de desarrollo, de oficina y financieros;
• eventos «exitosos» específicos, incluido un campo especial «PCP replaced», enviado al servidor de mando y control (C2) y que refleja si se ha conseguido desplazar a TeamPCP de ese host.

El propio modelo de comportamiento se enmarca en las técnicas MITRE ATT&CK T1552 (Unsecured Credentials) y T1555 (Credentials from Password Stores): un recorrido sistemático por las fuentes de secretos en el cloud y en contenedores.

Script adicional check.sh y Sliver

En la infraestructura del operador se ha encontrado un script shell adicional, check.sh, que:

• determina la arquitectura de CPU y descarga el binario correspondiente de Sliver, un conocido framework multiplataforma para infraestructura de mando y control, cuyo código fuente está disponible en el repositorio de Sliver en GitHub;
• explora el Instance Metadata Service (IMDS) en nubes públicas;
• recorre los service accounts de Kubernetes;
• analiza entornos Docker en busca de configuraciones y tokens.

El objetivo es extraer credenciales y tokens relacionados con:

• Anthropic, OpenAI, Google API;
• Digital Ocean, Grafana Cloud, HashiCorp Vault;
• Discord, OnePassword y otros servicios.

Todos los secretos encontrados se envían a un servidor externo de mando y almacenamiento de los datos robados.

INDICATORS OF COMPROMISE (IOC) no se proporcionan en el informe original, por lo que la detección se basa de momento en indicadores de comportamiento y artefactos (scripts bootstrap/check.sh, interacción de red de Sliver, accesos a Common Crawl).

Contexto de la amenaza y relación con TeamPCP

Los investigadores señalan una intersección significativa entre los objetivos de PCPJack y el grupo previo TeamPCP, que explotaba activamente vulnerabilidades (incluida React2Shell) y errores de configuración en servicios cloud para construir una red distribuida de hosts destinada al robo de datos y otras acciones de post‑explotación.

Principales diferencias entre PCPJack y TeamPCP:

• ausencia de minería de criptomonedas: a diferencia de la campaña anterior, el nuevo framework elimina explícitamente las funciones de los mineros utilizados antes por TeamPCP;
• foco en el robo y la monetización de credenciales mediante fraude, spam, extorsión o reventa de accesos, y no en la minería directa;
• comportamiento anticompetitivo: eliminación explícita de procesos y artefactos de TeamPCP y recopilación de telemetría «PCP replaced», que muestra que el objetivo no es solo una infección masiva, sino el reemplazo de la infraestructura competidora.

Los investigadores suponen que la similitud de la base de código y de las tácticas podría apuntar a una posible relación con un antiguo miembro de TeamPCP, pero esto sigue siendo una valoración: no hay atribución técnica confirmada.

Evaluación del impacto y perfil de riesgo

Las organizaciones más vulnerables parecen ser aquellas que:

• operan Docker/Kubernetes/Redis/MongoDB públicamente accesibles sin políticas estrictas de autenticación y segmentación de red;
• usan Instance Metadata Service con la configuración predeterminada, sin restricciones ni capas de proxy;
• almacenan tokens sensibles (claves de API para Anthropic, OpenAI, Google API, Grafana Cloud, Digital Ocean, HashiCorp Vault, etc.) en variables de entorno, archivos de configuración de contenedores o service accounts de Kubernetes;
• tienen tokens de acceso de larga duración o sin fecha de caducidad, sin rotación.

Posibles consecuencias de un ataque exitoso:

• compromiso de la cadena de suministro y de los procesos de desarrollo: acceso a repositorios, CI/CD, secretos en Vault y gestores de contraseñas;
• compromiso de datos de clientes mediante accesos a bases de datos, paneles de monitorización y sistemas de almacenamiento;
• abuso secundario de las credenciales: envío de spam, ataques a terceros, extorsión, fraude con servicios financieros;
• riesgos reputacionales y regulatorios, si a través de las claves robadas se ataca a clientes o socios externos.

Conviene prestar especial atención a la profundidad de acceso que otorga el robo de tokens de proveedores como Anthropic u OpenAI: uso incontrolado de recursos, robo de prompts y configuraciones internas, posible abuso de los datos enviados a los modelos.

Recomendaciones prácticas de protección

1. Reducción de la superficie de ataque en cloud y contenedores

• Realizar una inventarización de todos los servicios públicamente accesibles (Docker API, Kubernetes API, Redis, MongoDB, RayML, interfaces administrativas de aplicaciones web).
• Deshabilitar el acceso anónimo y «por defecto», cerrar puertos innecesarios a nivel de firewalls cloud y security groups.
• Restringir estrictamente el acceso al Kubernetes API y al socket de Docker solo a través de canales autenticados.

2. Protección de Instance Metadata Service y de service accounts

• Restringir el acceso a IMDS (por ejemplo, solo desde servicios de confianza/sidecar‑proxy), minimizar el uso de metadatos para obtener tokens de larga duración.
• Revisar los permisos de los service accounts de Kubernetes, eliminar privilegios excesivos y aplicar el principio de mínimo privilegio.
• Configurar políticas de red en el clúster para que los contenedores no puedan acceder libremente a IMDS ni al Kubernetes API.

3. Gestión de secretos y tokens

• Sacar las claves de API (Anthropic, OpenAI, Google API, Digital Ocean, Grafana Cloud, HashiCorp Vault, OnePassword, etc.) de variables de entorno y configuraciones estáticas, y almacenarlas en gestores de secretos especializados.
• Habilitar la rotación de tokens, especialmente para claves con altos privilegios y sin límite de validez.
• Implantar monitorización de uso anómalo de claves en los proveedores (picos de peticiones, nuevas geografías, patrones de uso atípicos).

4. Detección de PCPJack y actividades relacionadas

• Buscar en logs y sistemas de archivos indicios de ejecución de scripts shell desconocidos, especialmente con el comportamiento «descarga de Python, instalación de persistencia, autodestrucción».
• Supervisar a nivel de red:
  • accesos inusuales a Common Crawl (descarga de archivos parquet con grandes listas de dominios);
  • conexiones y tráfico característicos de Sliver (patrones C2, mutual TLS, dominios de mando inusuales).
• Utilizar detectores conocidos de Sliver y reglas orientadas a MITRE (por ejemplo, para las técnicas T1105 (Ingress Tool Transfer) y T1552/T1555) en SIEM e IDS/IPS.

5. Respuesta y priorización

• Alta prioridad (plazo de días, no semanas): cierre de Docker/Kubernetes/Redis/MongoDB/IMDS expuestos, revisión de tokens y claves de los servicios enumerados, comprobación de la presencia de Sliver y de scripts shell sospechosos.
• En caso de detectar compromiso:
  • revocar y rotar de inmediato todas las claves y tokens potencialmente comprometidos;
  • recrear desde imágenes de confianza las instancias gravemente afectadas, con una nueva base de secretos;
  • realizar un análisis retrospectivo de logs para identificar acciones llevadas a cabo con las credenciales robadas.

Conclusión clave: PCPJack demuestra un cambio de enfoque desde la minería burda hacia una monetización más rentable y discreta mediante el robo de credenciales cloud y de API, por lo que en el corto plazo la prioridad para los equipos de seguridad debe ser cerrar los puntos expuestos de Docker/Kubernetes/IMDS, revisar y rotar de inmediato los tokens de servicios cloud y de IA, así como implantar monitorización de comportamiento para detectar accesos anómalos a metadatos y la ejecución de Sliver.