## Desarticulada la Operación Cloud Encubierta de PCPJack El actor de amenazas conocido como **PCPJack** ha orquestado una sofisticada campaña, secuestrando servidores cloud en **Amazon Web Services (AWS)**, **Google Cloud** y **Microsoft Azure** para forjar una masiva y encubierta red de retransmisión de correo SMTP. Esta extensa infraestructura convirtió silenciosamente servidores empresariales comprometidos en EE. UU., Europa y Asia en proxies SMTP, los cuales luego fueron verificados para capacidades de retransmisión de correo y sincronizados con un consumidor aguas abajo cada cinco minutos. La firma de inteligencia de amenazas **Hunt.io** descubrió la operación, señalando que la infraestructura aún estaba completamente activa al momento del hallazgo. "Servidores empresariales comprometidos en EE. UU., Europa y Asia fueron convertidos sigilosamente en proxies SMTP, verificados para su capacidad de retransmisión de correo y sincronizados con un consumidor aguas abajo cada cinco minutos", declaró **Hunt.io**. "La infraestructura seguía funcionando cuando la encontramos".  ## Descubrimiento Accidental: Servidor C2 Abierto Expone Tácticas Los intrincados detalles de la campaña de **PCPJack** salieron a la luz debido a un error crítico de seguridad operativa. El actor de amenazas dejó dos directorios abiertos en un servidor de comando y control (C2) (213.136.80[.]73) sin ninguna autenticación. Esta omisión permitió a **Hunt.io** acceder al código fuente, binarios compilados, registros de estado de despliegue, escáneres de internet, herramientas de explotación y una configuración activa de **Sliver**. **PCPJack** surgió por primera vez en abril de 2026, identificado por **SentinelOne** como un framework de robo de credenciales dirigido específicamente a servicios cloud. Notablemente, **PCPJack** también toma medidas para eliminar artefactos asociados con **TeamPCP**, otro grupo de hacking prominente conocido por sus ataques a la cadena de suministro de software, lo que sugiere rivalidad o un intento de ofuscar su identidad. ## Herramientas del Oficio: Sliver, Chisel y Scripts Personalizados Entre los archivos descubiertos en los directorios abiertos se encontraba un kit de herramientas de despliegue de proxy SMTP integrado con **Sliver**. Este kit incluía binarios de túnel y proxy **Chisel**, compilados para varias arquitecturas de CPU de Linux como AMD64, ARM64 y x86. En las máquinas víctimas, el binario se deposita discretamente como un archivo oculto con prefijo de punto y se mantiene en "/var/tmp/.xs". También se encontraron scripts de despliegue, diseñados para cargar la configuración del cliente C2 de **Sliver** y filtrar beacons de Linux. Estos beacons son implantes que se conectan periódicamente al servidor C2 para reportarse y recibir comandos. ## Gestión Sofisticada de Proxies La operación demuestra capacidades avanzadas de gestión de proxies. "Cada beacon recibe un puerto de proxy SOCKS5 derivado de forma determinista de un hash MD5 de su UUID de **Sliver**, mapeado en el rango 10000-14999", explicó **Hunt.io**. "El mismo beacon siempre se mapea al mismo puerto en diferentes ejecuciones, eliminando la necesidad de un registro de puertos compartido".  Un componente crucial del script de despliegue es una "puerta de calidad" SMTP. Esta puerta sonda el acceso saliente a `smtp.gmail[.]com:587`. Los hosts que fallan esta verificación son omitidos, ya que "los hosts que no pueden retransmitir correo no tienen valor para esta canalización", según la compañía de ciberseguridad. Los beacons se procesan en lotes de 50, con retrasos temporizados para acomodar intervalos de registro lentos. ## Tácticas Evolucionadas y Capacidades de Diagnóstico Las iteraciones posteriores de los scripts de despliegue muestran una evolución, con la eliminación de la puerta SMTP y la lógica de lotes. Además, se presentó un script de diagnóstico, diseñado para seleccionar cinco beacons activos y encargarles comandos de shell para verificar: * Presencia de binarios de **Chisel** en rutas de depósito conocidas * Un proceso de **Chisel** está activo * Espacio en disco disponible * Alcanzabilidad del puerto 9000 en el C2 * Presencia de artefactos de persistencia, como entradas de cron o servicios de systemd  El servidor C2 también ejecuta un script de Python, `chisel_verifier.py`, como un demonio persistente en segundo plano. Este script enumera los puertos activos del túnel **Chisel** a través de `ss -tlnp` cada 60 segundos, los prueba para capacidad SMTP y elimina cualquier túnel fallido o caído del grupo activo. ## Enriquecimiento de Proxies y Motivo Desconocido Los proxies verificados se enriquecen aún más con datos de dirección IP de salida, país y Número de Sistema Autónomo (**ASN**) utilizando servicios como `api.ipify[.]org` y `ip-api[.]com`. Estas listas de proxies refinadas se sincronizan cada cinco minutos a través de **Secure Copy Protocol (SCP)** a un servidor downstream separado (38.242.204[.]245), aunque este servidor es actualmente inaccesible. El propósito final de esta extensa operación sigue sin estar claro. **Hunt.io** la describió como una campaña oportunista, declarando: "El resultado de 230 nodos es el resultado observable. Si esta progresión refleja a un solo operador iterando o a múltiples actores compartiendo la misma infraestructura no se puede determinar a partir de los archivos recuperados". Independientemente de la intención específica, las implicaciones son significativas. "La lista de proxies verificados se está sincronizando cada cinco minutos a ese servidor, y alguien la está consumiendo. Ya sea para spam, phishing o algo más, la infraestructura para entregar a escala estaba claramente funcionando".