El actor de amenazas PCPJack secuestró servidores de AWS, Google Cloud y Azure para crear una red de relevo de correos SMTP. Mediante el uso de herramientas como Sliver y Chisel, convirtieron servidores empresariales en proxies para enviar correos a gran escala. Aunque el objetivo final es incierto, se sospecha que la infraestructura fue diseñada para campañas de spam o phishing.



El actor de amenazas 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.

"Servidores empresariales comprometidos en EE. UU., Europa y Asia fueron convertidos silenciosamente en proxies SMTP, verificados para la capacidad de retransmisión de correo y sincronizados con un consumidor final cada cinco minutos", afirmó Hunt.io en un comunicado. "La infraestructura todavía estaba funcionando cuando la encontramos".

La empresa de inteligencia de amenazas señaló que encontró código fuente, binarios compilados, registros de estado de despliegue, escáneres de internet, herramientas de explotación y una configuración de Sliver en vivo después de que el actor de amenazas detrás de la operación 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, después de identificar un marco de robo de credenciales que se dirige específicamente a los servicios en la nube, mientras tomaba medidas para terminar y eliminar procesos o artefactos asociados con TeamPCP, otro grupo de hacking 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 se encontraba el kit de despliegue de proxy SMTP integrado con Sliver, junto con binarios de proxy y tunelización Chisel para la mayoría de las arquitecturas de CPU de Linux, como AMD64, ARM64 y x86. En el lado de la víctima, el binario se deposita como un archivo oculto con prefijo de punto y se mantiene en "/var/tmp/.xs."

También se encontraron en los directorios scripts de despliegue diseñados para cargar la configuración del cliente Sliver C2 y filtrar los beacons de Linux que se han reportado en los últimos diez minutos. Los beacons son implantes que llaman periódicamente al servidor C2 a intervalos regulares para reportarse y recuperar comandos. "Cada beacon recibe un puerto proxy SOCKS5 derivado determinísticamente de un hash MD5 de su UUID de Sliver, mapeado en el rango 10000-14999", señaló Hunt.io. "El mismo beacon siempre se mapea al mismo puerto en cada ejecución, eliminando la necesidad de un registro de puertos compartido".

El script también es capaz de ejecutar una puerta de calidad SMTP que sondea el acceso saliente a smtp.gmail[.]com:587. Los hosts que fallan esta comprobación son omitidos 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 este flujo", añadió la empresa de ciberseguridad. "Los beacons se procesan en lotes de 50, con una espera de 25 minutos después de las cargas y 15 minutos después de los comandos de ejecución, para adaptarse a los reportes de beacons de intervalo lento".

Iteraciones posteriores

Se ha descubierto que las iteraciones posteriores de los scripts de despliegue eliminan la puerta SMTP y la lógica de lotes. También hay un script de diagnóstico que selecciona cinco beacons activos y les asigna a cada uno un comando de shell que verifica lo siguiente:

• * Presencia de binarios de Chisel en rutas de depósito conocidas
• * Si un proceso Chisel se está ejecutando
• * Espacio en disco
• * Accesibilidad del puerto 9000 en el C2
• * Presencia de artefactos de persistencia, como la entrada de cron o el servicio systemd

Además, el servidor C2 ejecuta un script de Python llamado "chisel_verifier.py" como un demonio de fondo persistente, que enumera los puertos de túnel Chisel activos a través de ss -tlnp cada 60 segundos, prueba cada puerto nuevo para la capacidad de SMTP y elimina los túneles fallidos o caídos del grupo activo.

Los proxies verificados se enriquecen con la dirección IP de salida, el país y el ASN a través de servicios como api.ipify[.]org e ip-api[.]com. Las listas de proxies se sincronizan entonces cada cinco minutos a través del Protocolo de Copia Segura (SCP) a un servidor downstream separado en 38.242.204[.]245. El servidor no es accesible actualmente. El objetivo final de la operación sigue siendo incierto en esta etapa.

"El resultado de 230 nodos es el resultado observable. No se puede determinar a partir de los archivos recuperados si esta progresión refleja a un solo operador iterando o a múltiples actores compartiendo la misma infraestructura", dijo Hunt.io, describiéndola como una campaña oportunista.

"La lista de proxies verificados se está sincronizando cada cinco minutos con ese servidor, y alguien la está consumiendo. Ya sea para spam, phishing o cualquier otra cosa, la infraestructura para entregar a escala estaba claramente funcionando".

Fuente:
THN