← Blog

PCPJack: el gusano que convierte servidores en la nube en una red oculta de spam

Un gusano de robo de credenciales ha secuestrado más de 230 servidores en AWS, Google Cloud y Azure para montar una red clandestina de relay SMTP. Te contamos cómo entra, cómo saber si tu servidor es uno de sus nodos y cómo blindarte.

Un vecino que limpia la casa antes de okuparla

Cada cierto tiempo aparece una campaña que merece que pares y mires tus servidores. Esta semana le toca a PCPJack, un gusano descubierto por los investigadores de SentinelOne que tiene un detalle casi cómico: antes de instalarse en una máquina comprometida, expulsa al inquilino anterior. Busca y elimina las infecciones de otro grupo (TeamPCP) y se queda él la casa.

Lo que hace después no tiene ninguna gracia: roba credenciales y convierte el servidor en un nodo más de una red oculta de relay SMTP. Es decir, tu servidor mandando correo para otros —spam, phishing— con tu IP y tu reputación. Ya van más de 230 servidores secuestrados entre AWS, Google Cloud y Azure.

En una frase

PCPJack busca servicios mal expuestos, entra, roba todas las credenciales que encuentra (de la nube, de contenedores, de herramientas de desarrollo), intenta propagarse a más máquinas como un gusano y, de paso, monta sobre el servidor un proxy de correo que sincroniza con su red cada pocos minutos para repartir el envío.

No necesita un 0-day exótico: vive de lo que dejamos abierto.

Cómo entra

Aquí está la lección de verdad. PCPJack no fuerza nada sofisticado; aprovecha servicios expuestos a internet que no deberían estarlo:

  • Docker con la API expuesta sin autenticación.
  • Kubernetes con el API server o el kubelet accesibles.
  • Redis sin contraseña.
  • MongoDB abierto.
  • Plataformas de ML (RayML) y aplicaciones web vulnerables.

¿Te suena la lista? Es exactamente la colección de "lo dejé abierto un momento para probar" que acaba quedándose abierta para siempre. Una vez dentro, recolecta credenciales de servicios cloud, contenedores, herramientas de desarrollo e incluso financieras, y las exfiltra a infraestructura del atacante.

Por qué el relay SMTP es tan dañino

Que usen tu servidor para enviar correo no es "solo molesto":

  1. Tu IP acaba en listas negras. El día que necesites que tu propio correo legítimo llegue, irá directo a spam. Recuperar reputación de IP es lento y tedioso.
  2. Consume tus recursos y tu factura. Ancho de banda y cómputo que pagas tú para que otro haga campañas.
  3. Te puede meter en problemas legales. El spam y el phishing salen, a ojos de todo el mundo, desde tu servidor.
  4. Si te roban las credenciales cloud, el relay es lo de menos. Con tus llaves de AWS/GCP/Azure pueden levantar más máquinas, escalar el gasto y moverse lateralmente.

Cómo saber si tu servidor está afectado

Sin alarmismo, pero con método. Revisa:

1. ¿Estás emitiendo correo que no deberías?

# Conexiones salientes al puerto 25 (SMTP) desde tu servidor
sudo ss -tnp | grep ':25'

# Cola de correo inusualmente llena (si tienes Postfix)
mailq | tail -n 1

Un servidor que no es un servidor de correo no tiene por qué estar abriendo conexiones salientes al puerto 25 a destinos raros. Si las ves, mala señal.

2. ¿Tienes servicios abiertos que no recuerdas?

# Qué está escuchando y en qué interfaz
sudo ss -tlnp

# ¿La API de Docker está expuesta?
sudo ss -tlnp | grep -E ':2375|:2376'

El 2375 (Docker sin TLS) abierto a 0.0.0.0 es una puerta de entrada de manual. Redis en 6379 y Mongo en 27017 accesibles desde fuera, igual.

3. Procesos y cron sospechosos

# Procesos consumiendo CPU que no reconoces
top -b -n1 | head -n 20

# Tareas programadas inyectadas (vector clásico de persistencia)
for u in $(cut -f1 -d: /etc/passwd); do crontab -l -u "$u" 2>/dev/null; done

Qué hacer hoy para blindarte

La defensa contra PCPJack es, casi punto por punto, higiene básica de servidor. Lo que aplicamos nosotros:

Cierra lo que no tiene que estar abierto

  • Docker: nunca expongas la API (2375/2376) a internet. Usa el socket Unix local y, si necesitas acceso remoto, túnel SSH o TLS con certificados de cliente.
  • Redis / MongoDB: bind solo a 127.0.0.1 si son locales, contraseña obligatoria, y firewall delante. Nunca en 0.0.0.0 sin auth.
  • Kubernetes: API server no público, RBAC bien acotado, kubelet protegido.

Bloquea el puerto 25 saliente si no envías correo

Si el servidor no manda correo legítimo, corta la salida al puerto 25. Es la mitigación más directa contra que se convierta en relay:

# Bloquear SMTP saliente (ajusta a tu firewall)
sudo iptables -A OUTPUT -p tcp --dport 25 -j REJECT

Muchos proveedores cloud ya bloquean el 25 saliente por defecto justo por esto. Si el tuyo no, hazlo tú.

Rota credenciales y revisa accesos

Si encuentras cualquier indicio, asume compromiso: rota las claves cloud (AWS/GCP/Azure), las de la base de datos y las de SSH, y revisa los logs de acceso y la facturación del proveedor por si hay máquinas o gasto que no reconoces.

Pon un firewall delante de todo

La regla de oro: un servicio solo escucha hacia donde tiene que escuchar. Si una base de datos o una API de orquestación es accesible desde internet sin necesitarlo, es cuestión de tiempo que alguien —o algún gusano— la encuentre.

La lección de fondo

PCPJack no es un genio del mal: es un recolector paciente de descuidos. Cada uno de sus 230 nodos fue, en algún momento, un servicio que alguien dejó expuesto "un momentito". La diferencia entre estar en esa lista o no estar casi nunca es un exploit sofisticado; es un puerto cerrado, una contraseña puesta y un firewall que hace su trabajo.

En Atenea Systems esto es parte de la revisión rutinaria de los servidores que gestionamos: qué escucha, hacia dónde, con qué autenticación y con qué firewall delante. Si no sabes con seguridad qué tienes expuesto en tus máquinas, ese es exactamente el primer sitio donde mirar. Y si quieres que lo revisemos contigo, escríbenos.

Referencias

¿Hablamos de tu caso?

Cuéntanos qué necesitas y te respondemos en menos de 24 horas con una propuesta clara.

Pedir presupuesto