Un atacante conocido como PCPJack se apoderó de los servidores en la nube asociados con Amazon Web Services (AWS), Google Cloud y Microsoft Azure y creó una red secreta de retransmisión de correo electrónico SMTP.
«Los servidores empresariales comprometidos en EE.UU., Europa y Asia se convirtieron de forma encubierta a servidores proxy SMTP, se verificó la funcionalidad de retransmisión de correo electrónico y se sincronizaron con los consumidores intermedios cada cinco minutos», dijo Hunt.io en un comunicado. «La infraestructura todavía estaba operativa cuando la descubrimos».
La firma de inteligencia de amenazas anunció que los atacantes detrás de la operación dejaron dos directorios abiertos en un servidor de comando y control (C2) (‘213.136.80(.)73’) sin autenticación, y luego descubrieron el código fuente, archivos binarios compilados, registros de estado de implementación, escáneres de Internet, herramientas de explotación y configuraciones de Sliver en vivo.
PCPJack fue descubierto por primera vez por SentinelOne en abril de 2026 después de que identificó un marco de robo de credenciales dirigido específicamente a servicios en la nube mientras tomaba medidas para terminar y eliminar procesos y artefactos asociados con TeamPCP, otro notorio grupo de piratería que ha llamado la atención por ataques a la cadena de suministro de software en los últimos meses.
Está organizado en uno de los directorios abiertos del kit de herramientas de implementación de proxy SMTP integrado con Sliver, junto con el túnel Chisel y los archivos binarios de proxy 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 coloca como un archivo oculto con un prefijo de punto y se guarda en «/var/tmp/.xs».
Este directorio también contiene un script de implementación diseñado para cargar la configuración del cliente Sliver C2 y filtrar las balizas de Linux que se han registrado en los últimos 10 minutos. Una baliza es un implante que llama periódicamente a un servidor C2 a intervalos regulares para registrar y recuperar comandos.
«Cada baliza recibe un puerto proxy SOCKS5 que se deriva de manera determinista del hash MD5 del UUID Sliver y se asigna a un rango de 10000 a 14999», dijo Hunt.io. «La misma baliza siempre se asigna al mismo puerto entre ejecuciones, lo que elimina la necesidad de un registro de puerto compartido».
Este script también puede ejecutar una puerta de calidad SMTP que examina el acceso saliente a smtp.gmail(.)com:587. Los hosts que no pasan esta verificación se omiten con el código de salida 0.
«Esta puerta define el propósito de la operación. Un host que no puede transmitir correo electrónico no tiene ningún valor para este canal», añadió la firma de ciberseguridad. «Las balizas se procesan en lotes de 50 y esperan 25 minutos después de la carga y 15 minutos después de la ejecución del comando para adaptarse a los registros lentos de las balizas».
Resulta que las iteraciones posteriores del script de implementación eliminan la puerta SMTP y la lógica por lotes. También hay un script de diagnóstico que selecciona las cinco balizas activas y ejecuta un comando de shell en cada una que verifica lo siguiente:
Los archivos binarios de Chisel están presentes en una ruta de entrega conocida. Se está ejecutando un proceso de Chisel. Espacio en disco. Se puede acceder al puerto 9000 en C2 y hay artefactos de persistencia como entradas cron y servicios systemd.
Además, el servidor C2 ejecuta un script de Python llamado «chisel_verifier.py» como demonio en segundo plano persistente. Enumera los puertos activos del túnel Chisel a través de ss -tlnp cada 60 segundos, prueba la funcionalidad SMTP de cada nuevo puerto y elimina los túneles fallidos o descartados del grupo activo.
Los servidores proxy verificados se enriquecen con direcciones IP de salida, países y ASN a través de servicios como api.ipify(.)org e ip-api(.)com. Luego, la lista de proxy se sincroniza cada 5 minutos a través del Protocolo de copia segura (SCP) con otro servidor descendente en 38.242.204(.)245. Actualmente el servidor es inaccesible. En este momento, el objetivo final de la operación sigue sin estar claro.
«El resultado de 230 nodos es un resultado observable. Si esta progresión refleja una iteración de un solo operador o múltiples actores que comparten la misma infraestructura no se puede determinar a partir de los archivos recuperados», dijo Hunt.io, describiendo esto como una campaña oportunista.
«La lista de proxy verificada se sincronizaba con ese servidor cada cinco minutos y alguien la estaba usando. Ya sea para spam, phishing u otros fines, la infraestructura estaba claramente en funcionamiento para su distribución a escala».
Source link
