Robaron claves de AWS durante siete meses y acabaron víctimas de un minero y de extorsionadores: el karma se cobra

Los especialistas de VulnCheck hallaron por casualidad toda una infraestructura criminal cuando empezaron a comprobar conexiones sospechosas a sus cebos. Primero llamaron la atención 27 direcciones IP de una misma red que explotaban la misma vulnerabilidad. Un análisis posterior mostró que no se trataba de un conjunto de servidores aleatorios, sino de un clúster organizado para el robo de credenciales en la nube.

El punto de partida fueron ataques contra CVE-2026-21859 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N — 5.8 Medium), una vulnerabilidad en Mailpit, una herramienta para probar correo electrónico. Las 27 direcciones estaban en la misma subred y usaban certificados parecidos con nombres del tipo pkNN@. Por las marcas de tiempo se pudo rastrear actividad desde noviembre de 2025 hasta abril de 2026.

Después, los especialistas cruzaron esos datos con nodos vulnerables visibles en Internet. Tres señales de red relacionadas con la configuración de SSH, características de la respuesta TCP y la huella TLS en el puerto kubelet redujeron drásticamente la búsqueda. Por separado, esas señales aparecen en miles o incluso millones de servidores, pero juntas dieron solo 21 coincidencias en todo el mundo.

Así se encontró no solo parte de las máquinas atacantes ya observadas, sino también dos nodos que los cebos de VulnCheck no habían visto antes. Uno resultó ser el nodo de control de un clúster de Kubernetes, que coordinaba la actividad pero no escaneaba objetivos. El otro probablemente era un servidor de trabajo que los cebos de VulnCheck aún no habían detectado.

Al inspeccionar la subred, los especialistas hallaron 25 aplicaciones web de una sola página idénticas, desarrolladas con Vite y React, con el título MeowProject. Todas usaban la misma clave SSH y coincidían en las señales de red con la infraestructura atacante. En el nodo de control también apareció una aplicación Cluster Monitor en el puerto 30010. Su punto de comprobación de estado público informaba de una conexión a MongoDB.

Al seguir investigando, confirmaron que el clúster usaba Cilium, la capa de red para Kubernetes. Los operadores intentaban proteger la infraestructura: el acceso al kubelet requería autenticación, la interfaz de observabilidad Hubble estaba cerrada con TLS mutuo y el servidor de la API de Kubernetes no estaba accesible desde el exterior.

Según los datos hallados, el objetivo principal de la operación era robar credenciales en la nube. En el nodo de control había un conjunto de puertos en el rango 20001–20057. Al conectarse, el manejador enviaba de forma secuencial comandos para leer archivos con credenciales de AWS, configuraciones de Git, variables de entorno y datos de los servicios de metadatos de Amazon EC2 y ECS/Fargate.

Cada paso terminaba con un marcador del tipo _*HP_DONE*<hex>. VulnCheck considera este patrón un indicador útil de compromiso. Se puede buscar en el tráfico de red y en los datos de los endpoints, ya que el sufijo hexadecimal concreto cambiaba, pero la estructura del marcador se mantenía.

La lógica de los ataques coincidía con el conjunto de vulnerabilidades explotadas. La infraestructura atacó Gravity SMTP, LiteSpeed Cache, Laravel, PHPUnit, Mailpit y routers Cisco RV320. Excepto el equipo de red de Cisco, todos esos productos son frecuentes en entornos de desarrollo, servidores en la nube y contenedores, donde suelen almacenarse claves de acceso a servicios en la nube.

La parte más irónica apareció después. En nodos de la misma subred se encontraron dos servidores relacionados con el producto Diony para la gestión de restaurantes y con el servicio al cliente Soka. No había casi rastro público de una empresa así, y en esos servidores funcionaban MongoDB y Redis sin autenticación.

Un servidor Redis almacenaba 15 hashes activos de tokens de actualización de sesiones de usuario. El otro ya había sido usado por un minero externo. Los atacantes escribieron tareas en Redis para persistir mediante un planificador de trabajos, y el proceso del minero se camufló como kworker, un nombre parecido al de procesos de servicio del núcleo de Linux.

MongoDB también había sido comprometido. En la base había una nota con una demanda de rescate de 0,0068 BTC. Cinco días después la reclamación se actualizó a 0,0074 BTC, pero por la caída del precio de bitcoin la cantidad en dólares incluso disminuyó ligeramente.

Según VulnCheck, la infraestructura atacante intentaba obtener shells inversos en los servidores comprometidos y redirigirlos al nodo de control. Los paneles de operación probablemente mostraban nuevas conexiones, credenciales robadas y el estado de toda la red. La biblioteca socket.io en el lado del cliente indicaba que los eventos llegaban en tiempo real, sin necesidad de actualizar manualmente la interfaz.

Toda la subred desapareció el 8 de junio de 2026. Los especialistas siguieron buscando certificados parecidos y coincidencias por las mismas huellas de red, pero por ahora no han hallado nuevos rastros. Según su evaluación, el caso muestra cómo la combinación de datos de cebos y de escaneos externos permite reconstruir la infraestructura de una operación criminal sin tocar a las víctimas ni conectarse a sus sistemas.