Los ataques cibernéticos dirigidos a contenedores y servicios Docker no se limitan a la intrusión de IS y el robo de datos. También se pueden ejecutar para extraer monedas virtuales. Aunque a primera vista las consecuencias parecen menos graves, resultan muy molestas. ¿La razón? Al explotar los recursos utilizados para los entornos Docker de destino, ayudan a ralentizarlos o incluso impedir que funcionen correctamente. Este es el caso del último tipo de campaña maliciosa. descubrimiento por investigadores de seguridad de Cado Security. Fue descubierto después de una operación rutinaria de la infraestructura de honeypot del proveedor y despliega dos contenedores en una instancia vulnerable, concretamente un minero XMRig, así como la aplicación 9hits, utilizada aquí como carga útil, para intercambiar el tráfico redirigido a su sitio por créditos a través de un Sesión de Chrome sin interfaz gráfica.
Actualmente no está claro el método exacto utilizado para distribuir el malware a los hosts Docker vulnerables, pero Cado Security sospecha que implica el uso de motores de búsqueda como Shodan para buscar objetivos potenciales. Una vez encontrado, los servidores de los piratas informáticos implementan dos contenedores maliciosos a través de la API de Docker y recuperan imágenes listas para usar de la biblioteca Docker Hub para el software 9Hits y XMRig. "Este es un vector de ataque común para campañas dirigidas a Docker, donde en lugar de obtener una imagen adaptada a sus necesidades, obtienen una imagen genérica de Docker Hub que casi siempre será accesible y la aprovechan según sus necesidades", explican los investigadores de seguridad.
Controlar la visualización de ventanas emergentes y la duración del caché de datos
La infección se activa mediante un comando que ejecuta el script nh.sh en la instancia de 9hits a la que el atacante agregó su token de sesión. “Esto permite que la aplicación 9hits se autentique con sus servidores y obtenga una lista de sitios para visitar. Una vez que la aplicación visita el sitio, el propietario del token de sesión recibe crédito en la plataforma 9hits”, dice Cado Security. “Parece que 9hits diseñó el sistema de token de sesión para que funcione en contextos que no son de confianza. No hay forma de utilizar el token para nada más que ejecutar la aplicación para generar créditos para el propietario del token, ya que la API y los tokens de autenticación son un sistema independiente. Esto permite utilizar la aplicación en campañas fraudulentas sin riesgo de comprometer la cuenta del atacante. La operación también se basa en el hecho de que 9hits se basa en una sesión de Chrome sin una interfaz gráfica configurada para autorizar la visita de sitios para adultos o sitios que muestran ventanas emergentes, controlar la duración del almacenamiento en caché de los datos, pero también impedir visitar sitios relacionados con criptomonedas.
En el otro contenedor implementado por el atacante que incorpora XMRig, se ejecuta un comando bash que incluye la opción -0 para especificar el recurso de minería a usar. "La mayoría de las implementaciones de XMRig utilizan un grupo público y le informan la dirección de la billetera del propietario, que se puede combinar frecuentemente con los datos públicos del grupo para ver cuántos sistemas están extrayendo esa dirección, así como las ganancias del propietario", informa Cado Security “Sin embargo, en este caso, parece que el grupo de minería es privado, lo que nos impide encontrar estadísticas sobre la campaña. Synology utiliza el dominio dscloud para DNS dinámico, donde el servidor Synology mantiene el dominio actualizado con el actual del atacante. IP. Al realizar una búsqueda de esta dirección al momento de escribir este artículo, podemos ver que se resuelve en 27.[.]36.82.56, la misma IP que infectó el honeypot en primer lugar”.
Consecuencias que deben tomarse en serio
"El principal impacto de esta campaña en los hosts comprometidos es el agotamiento de los recursos, ya que el minero XMRig utilizará toda la potencia de CPU disponible, mientras que 9hits utilizará una gran cantidad de ancho de banda, memoria y la poca CPU que queda", advierte Cado Security. “Como resultado, las cargas de trabajo legítimas en servidores infectados no pueden funcionar como se esperaba. Además, la campaña podría actualizarse para dejar un shell remoto en el sistema, lo que podría provocar una infracción más grave. Esto se observó anteriormente con mexals/diicot, un actor rumano que mantuvo el acceso a servidores comprometidos utilizando una clave SSH maliciosa además de ejecutar XMRig”.
Otras noticias que te pueden interesar