Banda de ransomware está cifrando servidores VMware ESXi con un script de Python

Los operadores de una banda de ransomware desconocida están utilizando un script de Python para cifrar las máquinas virtuales alojadas en los servidores VMware ESXi.

Investigadores de Sophos afirmaron que el ransomware se está utilizando para comprometer y cifrar las máquinas virtuales alojadas en un hipervisor ESXi en operaciones que, están tardando menos de tres horas en completarse desde la infracción inicial hasta el cifrado.

“Este es uno de los ataques de ransomware más rápidos que Sophos haya investigado, y pareció apuntar con precisión a la plataforma ESXi”.

Andrew Brandt, investigador principal de Sophos, en un comunicado de prensa que acompaña a su informe detallado.

Brandt señaló que es raro ver el lenguaje de programación Python utilizado para ataques de ransomware. Pero su uso tiene sentido, explicó, dado que Python viene preinstalado en sistemas basados ​​en Linux como ESXi. Y, por lo tanto, hace posibles los ataques basados ​​en Python en estos sistemas.

Atacar a ESXi es una obviedad

Si bien la elección de Python para el ransomware es bastante distintiva, apuntar a los servidores ESXi es todo lo contrario. A los atacantes les encanta ESXi de VMware (anteriormente conocido como ESX), que es un hipervisor completo que se instala fácilmente en los servidores y los divide en varias máquinas virtuales.

Si bien eso facilita que varias máquinas virtuales compartan el mismo almacenamiento de disco duro, configura los sistemas para que sean puntos únicos para los ataques. Esto porque los atacantes pueden cifrar los discos duros virtuales centralizados que se utilizan para almacenar datos de entre las máquinas virtuales. En otras palabras, un ataque bloquea varias máquinas virtuales.

Así es como Alien Labs de AT&T Cybersecurity lo explicó en julio, poco después de que los actores de amenazas del ransomware REvil presentaran una variante de Linux que también apuntaba a VMware ESXi. Asimismo, apuntaba a dispositivos de almacenamiento conectados a la red (NAS).

Más tarde ese mes, HelloKitty se unió a la creciente lista de peces gordos del ransomware que persiguen al jugoso objetivo. DarkSide también ha apuntado a los servidores ESXi. En junio, un análisis de la versión Linux del ransomware de DarkSide, fue calificado como uno de los ransomwares más activos en el trimestre anterior.

En resumen, todos en el mundo del ransomware anhelan atacar ESXi: es como ganar el premio mayor en las tragamonedas.

Los servidores ESXi representan un objetivo atractivo para los actores de amenazas de ransomware porque pueden atacar múltiples máquinas (VM) virtuales a la vez. es importante recalcar que cada una de las VM podría estar ejecutando aplicaciones o servicios críticos para el negocio. Los ataques a los hipervisores pueden ser rápidos y altamente disruptivos.

Cronología de un ataque detectado

Sophos estaba investigando un ataque de ransomware cuando se encontró con el nuevo script ultrarrápido de Python. El ataque comenzó en la madrugada, a las 12:30 am, un domingo por la mañana, cuando los operadores de ransomware irrumpieron en una cuenta de TeamViewer. Esta cuenta pertenecía a un usuario que tenía acceso de administrador pero que no tenía habilitada la autenticación multifactor (MFA). A continuación, te mostramos la línea de tiempo de lo que sucedió:

12:40 a.m.

Diez minutos después, los atacantes buscaban objetivos de red, utilizando la herramienta Advanced IP Scanner para el reconocimiento. Los investigadores de Sophos creen que el servidor ESXi de la red era vulnerable porque tenía una shell activa que un equipo de informática usaba para comandos y actualizaciones. Según el informe de Sophos, los servidores ESXi tienen un servicio SSH incorporado llamado ESXi Shell que los administradores pueden habilitar. Sin embargo, generalmente está deshabilitado de manera predeterminada.

El personal de informática de esta organización estaba acostumbrado a usar ESXi Shell para administrar el servidor y había habilitado y deshabilitado la shell varias veces en el mes anterior al ataque, según el informe de Brandt. Sin embargo, la última vez que habilitaron la shell, no pudieron deshabilitarla después. Los delincuentes se aprovecharon de esta situación fortuita cuando descubrieron que la shell estaba activa.

2:00 a.m.

Los atacantes descargaron un cliente SSH llamado Bitvise y lo utilizaron para iniciar sesión en un servidor VMware ESXi que identificaron mediante Advanced IP Scanner.

3:30 a.m.

Tres horas después de que los atacantes escanearon la red, utilizaron las credenciales de administrador robadas para iniciar sesión en ESXi Shell. Luego copiaron un archivo llamado “fcker.py” al almacén de datos de ESXi. El almacén de datos alberga las imágenes de disco virtual utilizadas por las máquinas virtuales que se ejecutan en el hipervisor.

El script de Python utiliza las funciones de comando vim-cmd de ESXi Shell para producir una lista de los nombres de todas las máquinas virtuales instaladas en el servidor, luego las apaga todas. Solo después de que todas las máquinas virtuales estén apagadas, la secuencia de comandos comienza a cifrar los volúmenes del almacén de datos.

Luego, el script de Python se inmiscuye, seleccionando máquinas virtuales una tras otra. Una por una, los atacantes ejecutaron el script de Python, pasando la ruta a los volúmenes de disco del almacén de datos como un argumento para el script. Cada volumen individual contenía el disco virtual y los archivos de configuración de VM para varias máquinas virtuales.

El fragmento de ransomware utiliza una única instrucción para cada archivo que cifra, invocando la herramienta de código abierto OpenSSL para cifrar los archivos con este comando:

openssl rsautil -encrypt -inkey pubkey.txt -pubin -out [nombre de archivo] .txt

Los investigadores de Sophos lograron obtener una copia del script de Python. Esto a pesar de que los atacantes aparentemente lo sobrescribieron con otros datos antes de eliminar el archivo. 

Finalmente, los atacantes eliminaron los archivos que contenían las listas de directorios, los nombres de las VMs y a él mismo al sobrescribir esos archivos antes de eliminarlos.

Esta pequeña “Python” tiene colmillos afilados

Con un peso de solo 6 KB, es algo diminuto que puede hacer mucho daño.

El script contiene variables que el atacante puede configurar con múltiples claves de cifrado, direcciones de correo electrónico y donde puede personalizar el sufijo de archivo que se agrega a los archivos cifrados. Específicamente, el script de Python incrusta, como variables, el sufijo de archivo que agrega a los archivos cifrados (ext) y las direcciones de correo electrónico (mail, mail2) que se utilizarán para contactar al atacante para el pago del rescate.

También incorpora el texto de la nota de rescate que se muestra a continuación.

Claves de cifrado

Mientras recorrían el código, los investigadores de Sophos notaron varias claves de cifrado codificadas, así como una rutina para generar aún más pares de claves de cifrado. Eso les pareció extraño

Según el investigador, normalmente, un atacante solo necesitaría incrustar la ‘clave pública’ que el atacante generó en su propia máquina y se usaría para cifrar archivos en la (s) computadora (s) de destino. Pero este ransomware parece crear una clave única cada vez que se ejecuta.

Resultó que los atacantes ejecutaron el script una vez para cada almacén de datos ESXi que querían cifrar. Cada vez que se ejecutaba, el script generaba un par de claves únicas para utilizar en el cifrado de archivos. En el caso que investigó Sophos, los atacantes apuntaron a tres almacenes de datos, cada vez con ejecuciones individuales del script. Por lo tanto, el script creó tres pares de claves únicos, uno para cada almacén de datos.

Sin embargo, esas claves no iban a ninguna parte, dado que el script no tenía la capacidad de transmitirlas a ninguna parte. Pero los atacantes obviamente no querían dejarlas donde las víctimas pudieran usarlas para descifrar sus archivos bloqueados sin pagar un centavo en rescate. Por lo tanto, el script escribió una copia de la clave secreta, luego la cifró, usando la clave incrustada. Es decir, clave pública codificada.

El script ejecuta una rutina que enumera todos los archivos en la ruta que se proporciona al mismo script durante la ejecución. Para cada archivo, el script genera un código aleatorio único de 32 bytes que llama aeskey y luego cifra el archivo usando aeskey en la ruta /tmp. Posteriormente, antepone el valor aeskey al archivo cifrado y agrega un nuevo sufijo de archivo al nombre, además sobrescribe el contenido del archivo original con la palabra fuck. Finalmente elimina el archivo original y mueve la versión cifrada de /tmp a la ubicación del almacén de datos donde se almacenó el archivo original.

Falta de protección de terminales en los servidores ESXi

Si bien las variantes de malware de Linux que se pueden usar para atacar sistemas como ESXi siguen siendo “relativamente poco comunes”, la protección de terminales en este tipo de servidores es aún más rara.

A continuación, te mostramos algunos consejos para fortalecer ESXi u otros hipervisores, incluidas las mejores prácticas de seguridad estándar, como:

• Evitar la reutilización de contraseñas
• Usar contraseñas complejas, difíciles de descifrar por fuerza bruta debido a la que tienen longitud adecuada.
• Habilitar el uso de MFA siempre que sea posible y aplicarlo para cuentas con permisos elevados, como las de los administradores de dominio.
• Desactivar la Shell cuando no se esté en utilizando

En el caso de ESXi, el uso de ESXi Shell es algo que puede activarse o desactivarse. Esto puede hacerse desde una consola física en la propia máquina o mediante las herramientas de administración normales proporcionadas por VMware. Los administradores solo deben permitir que la Shell esté activa durante el uso por parte del personal y deben deshabilitarlo tan pronto como se complete el mantenimiento (como la instalación de parches).

VMware también ha publicado una lista de las mejores prácticas para los administradores de sus hipervisores ESXi. Esta lista muestra cómo protegerlos y limitar la superficie de ataque en el propio hipervisor.