La agrupación PCPJack, según los investigadores de Hunt.io, ha comprometido alrededor de 230 servidores en la nube en las plataformas Amazon Web Services, Google Cloud y Microsoft Azure, convirtiéndolos en una red encubierta de proxies SMTP para la retransmisión de correo electrónico. Se informa de que los servidores empresariales comprometidos en Estados Unidos, Europa y Asia fueron silenciosamente reconvertidos en relés SMTP, y las listas de proxies verificados se sincronizaban con un servidor externo cada cinco minutos. Las organizaciones que utilizan infraestructura en la nube basada en Linux deberían comprobar sus servidores en busca de los indicadores de compromiso descritos a continuación.
Cómo se descubrió la infraestructura
La operación se destapó después de que el atacante dejara dos directorios abiertos en el servidor de mando (213.136.80[.]73) sin ningún tipo de autenticación. En su interior, los investigadores descubrieron el código fuente, binarios compilados, registros de despliegue, escáneres, herramientas de explotación y la configuración activa del framework Sliver. Según Hunt.io, la infraestructura seguía funcionando en el momento del hallazgo.
Arquitectura técnica del ataque
Herramientas de despliegue
En los directorios expuestos se encontraba un conjunto de herramientas para el despliegue de proxies SMTP, integrado con Sliver, un framework para gestionar sistemas comprometidos. Además, se identificaron binarios de Chisel para túneles y proxys, compilados para las principales arquitecturas Linux: AMD64, ARM64 y x86. En el lado de la víctima, el binario se alojaba como un archivo oculto con un punto al inicio del nombre y se fijaba en la ruta /var/tmp/.xs.
Gestión de beacons y enrutamiento
Los scripts de despliegue descargaban la configuración del cliente Sliver C2 y filtraban los beacons en sistemas Linux que se hubieran comunicado en los últimos diez minutos. Cada beacon recibía un puerto de proxy SOCKS5, calculado de forma determinista a partir del hash MD5 de su UUID de Sliver y mapeado al rango 10000–14999. Este enfoque garantizaba que un mismo beacon recibiera siempre el mismo puerto, eliminando la necesidad de un registro centralizado de puertos.
Los beacons se procesaban en lotes de 50, con una pausa de 25 minutos tras la carga de archivos y de 15 minutos después del envío de comandos para su ejecución, compensando así los retrasos en la retroalimentación de beacons con intervalos de comunicación lentos.
Control de calidad de la retransmisión SMTP
Un «gateway de calidad» SMTP era un elemento clave de la cadena: un script comprobaba la posibilidad de establecer una conexión saliente con smtp.gmail[.]com:587. Los hosts que no superaban la comprobación se omitían. Como señalaron los investigadores, esto definía el propio objetivo de la operación: los hosts incapaces de retransmitir correo no aportaban valor a esta cadena.
Cabe destacar que, en versiones posteriores de los scripts, el gateway SMTP y la lógica de procesamiento por lotes se eliminaron, lo que podría indicar una evolución de las tácticas o una ampliación de los objetivos de la operación.
Verificación y enriquecimiento de datos
En el servidor de mando se ejecutaba un demonio en Python, chisel_verifier.py, que cada 60 segundos enumeraba los puertos de túnel activos de Chisel mediante el comando ss -tlnp, probaba cada nuevo puerto para verificar su compatibilidad con SMTP y eliminaba del conjunto los túneles inactivos o perdidos.
Los proxies verificados se enriquecían con metadatos —dirección IP de salida, país y ASN— a través de los servicios api.ipify[.]org e ip-api[.]com. Las listas finales de proxies se sincronizaban cada cinco minutos mediante el protocolo SCP con un servidor independiente (38.242.204[.]245), que en el momento de la publicación del informe no estaba accesible.
Un script de diagnóstico seleccionaba cinco beacons activos y comprobaba en cada uno de ellos:
- La presencia de binarios de Chisel en rutas conocidas
- Un proceso Chisel en ejecución
- Espacio libre en disco
- Disponibilidad del puerto 9000 en el servidor C2
- Presencia de artefactos de persistencia —entradas cron o servicios systemd—
Contexto de la amenaza y atribución
Hunt.io describió la campaña como oportunista. El resultado de 230 nodos es el saldo observable de la operación; sin embargo, los investigadores señalan que, a partir de los archivos recuperados, no es posible determinar si actúa un único operador que perfecciona sus herramientas de forma iterativa o varios actores que comparten una infraestructura común.
El objetivo final de la operación sigue sin estar claro. No obstante, como subrayaron los investigadores, la lista verificada de proxies se sincronizaba cada cinco minutos con un servidor externo y alguien la consumía: ya fuera para spam, phishing u otros fines, la infraestructura para la distribución masiva de email era plenamente funcional.
Es importante tener en cuenta: la atribución de esta actividad al grupo PCPJack se basa en los datos de una única fuente de investigación y no ha sido confirmada de forma independiente. Los proveedores de servicios en la nube no han emitido comunicados oficiales sobre este incidente.
Evaluación del impacto
Las organizaciones más expuestas al riesgo son aquellas que operan servidores Linux en entornos en la nube de AWS, Google Cloud y Azure, especialmente si el tráfico SMTP saliente no está suficientemente protegido. Los servidores comprometidos se utilizaron para retransmitir correo en nombre de dominios empresariales legítimos, lo que potencialmente socava la reputación del remitente, provoca inclusiones en listas negras y genera riesgos legales para los propietarios de la infraestructura.
Recomendaciones prácticas
- Compruebe la presencia de artefactos: busque el archivo oculto en la ruta
/var/tmp/.xsen todos los servidores Linux de la infraestructura en la nube - Revise los mecanismos de persistencia: analice las entradas de crontab y los servicios systemd en busca de tareas desconocidas
- Audite las conexiones SMTP salientes: bloquee o limite el tráfico saliente al puerto 587 en los servidores que no necesiten enviar correo
- Supervisión de las conexiones de red: compruebe en los registros de los dispositivos de red si existen conexiones a las direcciones IP
213.136.80[.]73y38.242.204[.]245 - Detección de túneles: identifique procesos Chisel y proxies SOCKS5 inusuales en el rango de puertos 10000–14999 con el comando
ss -tlnp - Reduzca la superficie de ataque: asegúrese de que los servidores no tengan directorios abiertos y de que el acceso a las interfaces de administración esté protegido mediante autenticación
La operación descubierta por Hunt.io demuestra un modelo concreto de monetización de compromisos en la nube: transformar servidores comprometidos en una infraestructura de entrega de email apta para spam o phishing a escala industrial. La acción prioritaria para los equipos de seguridad es la comprobación inmediata de los servidores Linux en la nube en busca del archivo /var/tmp/.xs, procesos no autorizados de Chisel y tráfico SMTP saliente anómalo hacia el puerto 587, así como el bloqueo de las direcciones IP indicadas a nivel de reglas de red.
