El actor amenazante conocido como PCPJack ha secuestrado servidores en la nube asociados con Amazon Web Services (AWS), Google Cloud y Microsoft Azure para crear una red encubierta de retransmisión de correo electrónico SMTP.
«Los servidores empresariales comprometidos en EE. UU., Europa y Asia fueron convertidos silenciosamente en proxies SMTP, verificados para su capacidad de retransmisión de correo y sincronizados con un consumidor aguas abajo cada cinco minutos», dijo Hunt.io en un comunicado. «La infraestructura seguía funcionando cuando la encontramos.»
La empresa de inteligencia de amenazas afirmó haber encontrado código fuente, binarios compilados, registros de estado de despliegue, escáneres de internet, herramientas de explotación y una configuración en vivo de Sliver después de que el actor de la amenaza dejara dos directorios abiertos en un servidor de comando y control (C2) («213.136.80[.]73») sin ninguna autenticación.
PCPJack fue descubierto por primera vez por SentinelOne en abril de 2026 tras identificar un marco de robo de credenciales que apunta específicamente a servicios en la nube, mientras tomaba medidas para terminar y eliminar procesos o artefactos asociados con TeamPCP, otro grupo de hackers notorio que ha llamado la atención en los últimos meses por sus ataques a la cadena de suministro de software.
En uno de los directorios abiertos del kit de herramientas de despliegue de proxy SMTP integrado por Sliver, junto con túneles Chisel y binarios proxy para la mayoría de las arquitecturas de CPU Linux, como AMD64, ARM64 y x86. En el lado de la víctima, el binario se elimina como un archivo oculto con prefijo de puntos y persiste en «/var/tmp/.xs.»
También se encuentran en los directorios scripts de despliegue diseñados para cargar la configuración del cliente Sliver C2 y filtrar balizas Linux que hayan hecho check-in en los últimos diez minutos. Las balizas son implantes que periódicamente conectan con el servidor C2 a intervalos regulares para registrar y recuperar comandos.
«Cada baliza recibe un puerto proxy SOCKS5 derivado determinísticamente de un hash MD5 de su UUID Sliver, mapeado en el rango 10000-14999», Hunt.io señaló. «La misma baliza siempre se asigna al mismo puerto a través de las rutas, eliminando la necesidad de un registro de puerto compartido.»
El script también es capaz de ejecutar una puerta de calidad SMTP que busca acceso saliente a smtp.gmail[.]com:587. Los hosts que fallan esta comprobación se saltan con un código de salida de cero.
«Esta puerta define el propósito de la operación: los hosts que no pueden retransmitir correo electrónico no tienen valor para esta canalización», añadió la empresa de ciberseguridad. » Las balizas se procesan en lotes de 50, con una espera de 25 minutos tras la subida y 15 minutos tras los comandos de ejecución, para acomodar revisiones de balizas a intervalos lentos.»
Se ha comprobado que iteraciones posteriores de los scripts de despliegue eliminan la puerta SMTP y la lógica de lote. También está presente un script de diagnóstico que selecciona cinco balizas activas y les asigna a cada una un comando de shell que comprueba lo siguiente:
- Presencia de binarios de cincel en rutas de caída conocidas
- Un proceso de cincel está en ejecución
- Espacio en disco
- Accesibilidad del puerto 9000 en el C2, y
- Presencia de artefactos de persistencia, como la entrada cron o el servicio systemd
Además, el servidor C2 ejecuta un script en Python llamado «chisel_verifier.py» como un demonio persistente en segundo plano, que enumera los puertos activos de túnel Chisel vía ss-tlnp cada 60 segundos, prueba cada nuevo puerto para detectar capacidades SMTP y elimina túneles fallidos o perdidos del pool activo.
Los proxies verificados se enriquecen con dirección IP de salida, país y ASN mediante servicios como api.ipify[.]org e ip-api[.]com. Las listas proxy se sincronizan cada cinco minutos a través del Protocolo de Copia Segura (SCP) con un servidor descendente separado en 38.242.204[.]245. El servidor no está disponible en este momento. El objetivo final de la operación sigue sin estar claro en esta fase.
«El resultado de 230 nodos es el resultado observable. No se puede determinar si esta progresión refleja un solo operador iterando o varios actores que comparten la misma infraestructura a partir de los archivos recuperados», dijo Hunt.io, describiéndola como una campaña oportunista.
«La lista de proxy verificada se sincroniza cada cinco minutos con ese servidor, y alguien la está consumiendo. Ya fuera para spam, phishing u otra cosa, la infraestructura para entregar a gran escala estaba claramente en funcionamiento.»
Fuente: The Hacker News
