Los investigadores de ciberseguridad han descubierto una nueva campaña de criptojacking 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 amenazas.
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. dicho en un análisis.
Los ataques aprovechan Docker para obtener acceso inicial para implementar un minero de criptomonedas en contenedores comprometidos, al mismo tiempo que obtienen y ejecutan cargas útiles adicionales que son responsables de realizar el movimiento lateral a hosts relacionados que ejecutan Docker, Kubernetes o SSH.
Específicamente, esto implica identificar puntos finales de Docker API 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 shell de inicialización (init.sh) desde un servidor remoto («solscan[.]live») que, a su vez, verifica si se está ejecutando como usuario root y si las herramientas como curl y wget están 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 recuperar otros tres scripts de shell (kube.lateral.sh, spread_docker_local.sh y spread_ssh.sh) del mismo servidor para el 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 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.
Es más, la etiqueta de imagen de 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 amenazas recuperarse fácilmente de posibles eliminaciones simplemente cambiando el contenido del archivo para que apunte a otro diferente. imagen del 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 de amenazas conectarse de forma remota 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 encontrados, los sube al servidor C2.
En la etapa final, 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 un actor de amenazas 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 al actor de amenazas expandir su control sobre múltiples instancias de Docker de manera coordinada, convirtiendo efectivamente los sistemas comprometidos en una botnet para una mayor explotación», dijeron 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 mostrados 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 criptojacking 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 para «Continuar realizando estos ataques».
El desarrollo se produce cuando Elastic Security Labs arroja luz sobre 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 la denegación de servicio distribuido (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 de azar, destacando el uso por parte de los atacantes de malware en evolución y canales de comunicación sigilosos», investigadores Remco Sprooten y Ruben Groenewoud dicho.