Los investigadores de ciberseguridad han descubierto una nueva campaña de criptojacking dirigida a la API de Docker Engine con el objetivo de cooptar instancias para que se unan 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)”, según los investigadores de Datadog Matt Muir y Andy Giron. dicho en un análisis.
Los ataques aprovechan Docker para obtener acceso inicial para implementar un minero de criptomonedas en contenedores comprometidos, mientras obtienen y ejecutan cargas útiles adicionales responsables de realizar movimientos laterales a hosts asociados que ejecutan Docker, Kubernetes o SSH.
Específicamente, esto implica identificar puntos finales de la API de Docker expuestos y no autenticados utilizando herramientas de escaneo de Internet, como Masscan y ZGrab.
En puntos finales vulnerables, la API de Docker se utiliza para generar un contenedor Alpine y luego recuperar un script de inicio de shell (init.sh) desde un servidor remoto (“solscan[.]live”) que, a su vez, comprueba si se está ejecutando como root y tiene herramientas como curl y wget instaladas antes de descargar el minero XMRig.
Al igual que otras campañas de criptojacking, utiliza el rootkit libprocesshider para ocultar el proceso minero malicioso al usuario cuando ejecuta herramientas de enumeración de procesos como top y ps.
El script de shell también está diseñado para capturar otros tres scripts de shell (kube.lateral.sh, spread_docker_local.sh y spread_ssh.sh) del mismo servidor para su movimiento lateral a los puntos finales Docker, Kubernetes y SSH en la red.
Spread_docker_local.sh “usa masscan y zgrab para escanear los mismos rangos de LAN […] para 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 dirección IP descubierta con los puertos de destino abiertos, el malware intenta generar un nuevo contenedor con el nombre alpin. 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 mencionado anteriormente, lo que permite que el malware del grupo se propague como un gusano a otros hosts Docker.
Además, la etiqueta de imagen de Docker utilizada 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 amenazas recuperarse fácilmente de una posible eliminación simplemente modificando el contenido del archivo para que apunte a otra imagen en el contenedor. .
El tercer script de shell, spread_ssh.sh, es capaz de comprometer servidores SSH, además de agregar una clave SSH y un nuevo usuario llamado ftp que permite a los actores maliciosos 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 dentro del entorno de GitHub Codespaces (es decir, el directorio “/home/codespace/”) y, si los encuentra, los carga. al servidor C2.
En el último paso, las cargas útiles de movimiento lateral de Kubernetes y SSH ejecutan otro script de shell llamado setup_mr.sh que recupera e inicia el minero de criptomonedas.
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 de iptables y borra registros y trabajos cron para evadir la detección.
- TDGINIT.sh, que descarga herramientas de escaneo y coloca un contenedor malicioso en cada host Docker identificado.
- pdflushs.sh, que instala una puerta trasera persistente agregando una clave SSH controlada por el actor de la amenaza al archivo /root/.ssh/authorized_keys
TDGINIT.sh también se destaca por su manipulación de Docker Swarm al obligar al host a abandonar cualquier Swarm existente del que pueda formar parte y agregarlo a un nuevo Swarm bajo el control del atacante.
“Esto permite a los actores maliciosos extender su control sobre múltiples instancias de Docker de manera coordinada, transformando así los sistemas comprometidos en una botnet para su posterior explotación”, dijeron los investigadores.
No está claro quién está detrás de la campaña de ataque, aunque las tácticas, técnicas y procedimientos presentados 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 útiles para los malos actores que llevan a cabo criptojacking a escala”, dijo Datadog.
“La campaña se basa en exponer los puntos finales de la API de Docker a Internet sin autenticación. La capacidad del malware para propagarse rápidamente significa que, si bien las posibilidades de acceso inicial son relativamente escasas, las recompensas son lo suficientemente altas como para mantener motivados a los grupos de malware centrados en la nube para continuar llevando a cabo estos ataques”.
Este desarrollo se produce cuando Elastic Security Labs destaca una sofisticada campaña de malware para Linux dirigida a servidores Apache vulnerables para establecer persistencia a través de GSocket e implementar familias de malware como Kaiji y RUDEDEVIL (también conocido como Lucifer) que facilitan el servicio distribuido de denegación (DDoS) y las criptomonedas. minería, respectivamente.
“La campaña REF6138 involucró criptominería, ataques DDoS y posible lavado de dinero a través de API de juegos, destacando el uso por parte de los atacantes de malware escalable y canales de comunicación sigilosos”, los investigadores Remco Sprooten y Ruben Groenewoud. dicho.