Introducción
En marzo de 2026, 230 servidores corporativos alojados en AWS, Google Cloud y Microsoft Azure fueron convertidos silenciosamente en relés de correo electrónico clandestinos. Detrás de la operación, un actor malicioso identificado como PCPJack, cuyas herramientas revelan un conocimiento profundo de la infraestructura cloud empresarial.
Una red SMTP construida con precisión quirúrgica
No se trata de un ataque masivo y desordenado. Una vez que los atacantes lograban acceso inicial a instancias cloud expuestas —aprovechando servicios mal configurados como Docker, Kubernetes, Redis o MongoDB, o explotando vulnerabilidades conocidas en Next.js, plugins de WordPress y CentOS Web Panel— desplegaban una cadena de herramientas muy específica.
Dos componentes formaban el núcleo de la operación. Sliver, un framework de comando y control de código abierto, actuaba como canal de control remoto. Chisel, una utilidad legítima de tunneling TCP, era reutilizada para establecer túneles SOCKS5 inversos. Cada servidor comprometido se convertía así en un proxy transparente capaz de retransmitir tráfico de correo sin levantar ninguna alerta en la empresa afectada.
El sistema incorporaba además un control de calidad automatizado: un proceso interno probaba cada túnel cada 60 segundos mediante una conexión SMTP simulada. Solo los proxies operativos se conservaban, y la lista actualizada se sincronizaba cada cinco minutos hacia un servidor de destino dedicado.
La persistencia como estrategia de sigilo
Lo que diferencia a PCPJack de otros actores es su capacidad para mantenerse activo durante largos períodos en los entornos comprometidos. En sistemas con privilegios elevados se instalaban servicios systemd; en cuentas con permisos más limitados, tareas cron cumplían la misma función. Todo el mecanismo estaba diseñado para sobrevivir reinicios y limpiezas superficiales.
Las herramientas desplegadas también incluían módulos de recolección de credenciales: claves SSH, tokens de bases de datos y accesos a servicios cloud y financieros, exfiltrados hacia una infraestructura de comando cifrada. Un actor que no solo alquila su infraestructura, sino que además roba sus llaves.
Lo que esto significa para el riesgo cloud en las empresas
El aspecto que debería ocupar la agenda de CIOs y CISOs es claro: los servidores afectados pertenecían a empresas reales en Europa, Estados Unidos y Asia. Sus instancias cloud —pagadas por ellas, asociadas a su reputación de IP— fueron utilizadas con fines delictivos sin su conocimiento.
Las consecuencias operativas son concretas: reputación de IP incluida en listas negras de filtros antispam, costos cloud inflados por tráfico parásito, y posibles obligaciones legales si los servidores secuestrados participaron en campañas de phishing contra terceros.
Medidas que ya no se pueden postergar
La superficie de ataque explotada no tiene nada de misteriosa: servicios cloud mal configurados y expuestos sin controles rigurosos. Las buenas prácticas son conocidas, pero su implementación sigue siendo demasiado frecuente incompleta:
- Inventario de servicios expuestos: una API de Docker o un Redis accesible sin autenticación desde internet es una puerta abierta.
- Monitoreo de procesos inesperados: un binario de tunneling no registrado o un servicio systemd desconocido debe generar una alerta inmediata.
- Control de flujos salientes: un servidor de aplicaciones que inicia conexiones SMTP hacia el exterior es una señal de anomalía que debe investigarse.
- Revisión de la facturación cloud: picos de ancho de banda sin explicación son con frecuencia los primeros indicadores visibles de un compromiso.
PCPJack ilustra una realidad que los equipos IT empresariales deben interiorizar: sus servidores cloud tienen un valor comercial para los cibercriminales que va mucho más allá de los datos que almacenan. Retransmitir tráfico, tunelizar conexiones anónimas, ocultar el origen de un ataque: eso es lo que el mercado negro valora en su infraestructura. Prevenir siempre será menos costoso que remediar.