Ciberseguridad 360 | Criptojacking dirigido a la API de Docker crea una peligrosa red de bots maliciosos

Investigadores de ciberseguridad han descubierto una nueva campa�a de cryptojacking dirigida a la API de Docker Engine con el objetivo de cooptar las instancias para unirse a un Docker Swarm malicioso controlado por el actor de la amenaza.

Esto permiti� a los atacantes �utilizar las funciones de orquestaci�n de Docker Swarm con fines de comando y control (C2)�, dijeron los investigadores de Datadog Matt Muir y Andy Giron en un an�lisis.

Los ataques aprovechan Docker para el acceso inicial para desplegar un minero criptomoneda en contenedores comprometidos, mientras que tambi�n la obtenci�n y ejecuci�n de cargas �tiles adicionales que son responsables de la realizaci�n de movimiento lateral a los hosts relacionados que ejecutan Docker, Kubernetes, o SSH.

En concreto, se trata de identificar puntos finales de la API de Docker no autenticados y expuestos mediante herramientas de exploraci�n de Internet, como masscan y ZGrab.

En los puntos finales vulnerables, la API de Docker se utiliza para generar un contenedor Alpine y, a continuaci�n, recuperar un script de shell de inicializaci�n (init.sh) de un servidor remoto (�solscan[.]live�) que, a su vez, comprueba si se est� ejecutando como usuario root y si est�n instaladas herramientas como curl y wget antes de descargar el minero XMRig.

Al igual que otras campa�as de cryptojacking, hace uso del rootkit libprocesshider para ocultar al usuario el proceso malicioso del minero cuando ejecuta herramientas de enumeraci�n de procesos como top y ps.

El script de shell tambi�n est� dise�ado para obtener otros tres scripts de shell - kube.lateral.sh, spread_docker_local.sh y spread_ssh.sh - del mismo servidor para el movimiento lateral a Docker, Kubernetes y puntos finales SSH en la red.

Spread_docker_local.sh �utiliza masscan y zgrab para escanear los mismos rangos de LAN [...] en busca de nodos con los puertos 2375, 2376, 2377, 4244 y 4243 abiertos�, dijeron los investigadores. �Estos puertos est�n asociados con Docker Engine o Docker Swarm�.

�Para cualquier IP descubierta con los puertos de destino abiertos, el malware intenta generar un nuevo contenedor con el nombre alpine. Este contenedor se basa en una imagen llamada upspin, alojada en Docker Hub por el usuario nmlmweb3�.

La imagen upspin est� dise�ada para ejecutar el script init.sh antes mencionado, permitiendo as� que el malware del grupo se propague en forma de gusano a otros hosts Docker.

Adem�s, la etiqueta de imagen Docker que se utiliza para recuperar la imagen de Docker Hub se especifica en un archivo de texto alojado en el servidor C2, lo que permite a los actores de la amenaza recuperarse f�cilmente de posibles desmantelamientos simplemente cambiando el contenido del archivo para que apunte a una imagen de contenedor diferente.

El tercer script de shell, spread_ssh.sh, es capaz de comprometer servidores SSH, as� como a�adir una clave SSH y un nuevo usuario llamado ftp que permite a los actores de la amenaza conectarse remotamente a los hosts y mantener un acceso persistente.

Tambi�n busca varios archivos de credenciales relacionados con SSH, Amazon Web Services (AWS), Google Cloud y Samba en rutas de archivos codificadas en el entorno de GitHub Codespaces (es decir, el directorio �/home/codespace/�) y, si los encuentra, los carga en el servidor C2.

En la etapa final, tanto las cargas �tiles de movimiento lateral Kubernetes como SSH ejecutan otro script de shell llamado setup_mr.sh que recupera y lanza el minero de criptomoneda.

Datadog dijo que tambi�n descubri� otros tres scripts alojados en el servidor C2 -

ar.sh, una variante de init.sh que modifica las reglas iptables y borra registros y cron jobs para eludir la detecci�n
TDGINIT.sh, que descarga herramientas de escaneado y coloca un contenedor malicioso en cada host Docker identificado.
pdflushs.sh, que instala una puerta trasera persistente a�adiendo una clave SSH controlada por el actor de la amenaza al archivo /root/.ssh/authorized_keys.

TDGINIT.sh tambi�n es notable por su manipulaci�n de Docker Swarm al forzar al host a abandonar cualquier Swarm existente del que pueda formar parte y a�adirlo a un nuevo Swarm bajo el control del atacante.

�Esto permite al actor de la amenaza expandir su control sobre m�ltiples instancias de Docker de forma coordinada, convirtiendo efectivamente los sistemas comprometidos en una botnet para su posterior explotaci�n�, afirman los investigadores.

Actualmente no est� claro qui�n est� detr�s de la campa�a de ataque, aunque las t�cticas, t�cnicas y procedimientos exhibidos se superponen con los de un conocido grupo de amenazas conocido como TeamTNT.

�Esta campa�a demuestra que servicios como Docker y Kubernetes siguen siendo fruct�feros para los actores de amenazas que realizan cryptojacking a escala�, dijo Datadog.

�La campa�a se basa en que los puntos finales de la API de Docker est�n expuestos a Internet sin autenticaci�n. La capacidad del malware para propagarse r�pidamente significa que incluso si las posibilidades de acceso inicial son relativamente escasas, las recompensas son lo suficientemente altas como para mantener a los grupos de malware centrados en la nube lo suficientemente motivados como para continuar llevando a cabo estos ataques.�

El desarrollo se produce cuando Elastic Security Labs arroj� luz sobre una sofisticada campa�a de malware Linux dirigida a servidores Apache vulnerables para establecer persistencia a trav�s de GSocket y desplegar familias de malware como Kaiji y RUDEDEVIL (alias Lucifer) que facilitan la denegaci�n de servicio distribuida (DDoS) y la miner�a de criptomonedas, respectivamente.

�La campa�a REF6138 inclu�a criptominer�a, ataques DDoS y posible blanqueo de dinero a trav�s de API de juegos de azar, lo que pone de manifiesto el uso por parte de los atacantes de malware evolutivo y canales de comunicaci�n sigilosos�, afirman los investigadores Remco Sprooten y Ruben Groenewoud.

Fuente: thehackernews