INICIO > BLOG

Ransomware

Ransomware ESXiArgs (Equipo de respuesta a incidentes de Dolbuck)

Adrián Ramírez Correa 10 de febrero de 2023 0 Comments

Ransomware ESXiArgs

El pasado fin de semana se dispararon todas las alarmas cuando por la mañana cientos de servidores ESXi verisón 6.5 y 6.7 se vieron afectados por este ransomware.

Al acceder a su interfaz web por el puerto 443 se encontraba mensajes como el siguiente:

Ransomware ESXiArgs

La sorpresa era mayúscula cuando los usuarios se quejaban que ya no estaban disponibles los servicios y el administrador de sistemas accedía a su ESXi y se encontraba con este mensaje.

Supongo que cualquier administrador experto, sabe que detrás de este mensaje no puede haber nada bueno. En nuestra oficina de Dolbuck empezaron a llegar los primeros llamados de auxilio sobre las 10:00 de la mañana del pasado viernes 3 de febrero de 2023.

Automáticamente se aplicó un protocolo de emergencia, ya que nuestro servicio de hosting y VPS utiliza un gran número de servidores montados en VMWare ESXi.

Como es sabido, la actualización de los parches de los ESXi, no es tan simple como darle a un botón, por lo que muchos ESXi están en Internet sin parchear y aceptando todas las conexiones del mundo mundial.

El fatídico viernes 3 de febrero

Una vez pasada la tormenta, y pensar que habrán otras… se salda con más de 3000 servidores ESXi cifrados, muchas horas de administradores invertidas y un fin de semana negro para muchos.

En Dolbuck nos pareció interesante escribir sobre este viernes negro, ya que hemos podido colaborar y ayudar a algunas empresas a recuperar sus servidores cifrados. Y nuestro equipo de respuesta a incidentes, siempre tiene el deber de aprender de cada incidente. Sobre todo, cuando toca la tecnología que nosotros mismos utilizamos para nuestros servicios.

Vector de ataque

En lo que respecta a nosotros, los primeros que comunicaron algo, aunque desde mi punto de vista, tarde, fue la gente de OVH, que vio como su centralita se vio desbordada desde primera horas de la mañana de cientos de administradores con sus sistemas en ESXi cifrados pidiendo ayuda.

Algo que desde mi punto de vista es inútil, ya que cuando se contratan los servicios de VPS de OVH, su soporte llega hasta el hardware, todo lo que montes por encima, es siempre asunto del cliente. Por lo que ellos solo podrán decirte que reinstales el ESXi por una nueva versión no vulnerable “aparentemente” la ESXi 7.03 y vuelques las copias de seguridad que deberías de tener.

Al parecer los vectores de ataque explotados fueron las siguientes CVE.

CVE-2021-21974 afecta a los siguientes sistemas:

Versiones de ESXi 7.x anteriores a ESXi70U1c-17325551

Versiones de ESXi 6.7.x anteriores a ESXi670-202102401-SG

Versiones de ESXi 6.5.x anteriores a ESXi650-202102101-SG

Está claro que es un ataque dirigido a ESXi con versiones anteriores a la 7.03 ya que a partir de esta versión el servicio de OpenSLP que escucha por defecto en el puerto 427 está deshabilitado.

Si buscamos en CENSYS veremos más de 2400 servidores ESXi que fueron comprometidos el pasado fin de semana(si, algunos administradores tuvieron un viernes tranquilo y se fueron a sus casas tranquilos, para el lunes tener un lunes negro).

Ransomware ESXiArgs

Búsqueda en censys de máquinas afectadas que nos devolvió más de 2400 servidores cifrados

El mismo día 6, el propio VMWare anunció y confirmó que se estaba explotando dicha vulnerabilidad, indicando lo siguiente:

«VMware no ha encontrado evidencia que sugiera que se esté utilizando una vulnerabilidad desconocida (día 0) para propagar el ransomware utilizado en estos ataques recientes»,

«La mayoría de los informes indican que el fin del soporte general (EOGS) y/o los productos significativamente desactualizados están siendo atacados con vulnerabilidades conocidas que se abordaron y divulgaron previamente en los avisos de seguridad de VMware (VMSA).

El ransomware se hizo conocido por la extensión con la que cifra que es “.args”

Los atacantes usan el malware para encriptar las siguientes extensiones:

Ransomware ESXiArgs

En la máquina víctima se despliega un script llamado “encrypt.sh” que es el encargado de buscar estos archivos.

Para cada archivo que se encuentra, la secuencia de comandos comprueba el tamaño del archivo y, si el archivo tiene menos de 128 MB, cifra todo el archivo en incrementos de 1 MB.

En la primera oleada, se descubrió que por la forma de cifrar, quedan varios bloques de datos que no se cifraban al mejor estilo de los primeros ransomware que solo cifraban la cabecera del fichero para no perder tiempo cifrando todo el archivo. Esta primera versión, hacia lo mismo cifrando bloques de 4,49 GB, por lo que era posible recuperar datos de los discos duros cifrados.

Hay un script creado por CISA, disponible en este enlace: https://github.com/cisagov/ESXiArgs-Recover/blob/main/recover.sh

Que puede ayudar a víctimas de la primera ola de ataques, pero se detectó una segunda, en donde dicho script ya no funciona. Al parecer el proceso de encriptación cambió.

El experto en ransomware Michael Gillespie comentó que este cambio hace que el cifrador alterne entre cifrar 1 MB de datos y omitir 1 MB de datos.

Todos los archivos de más de 128 MB ahora tendrán el 50 % de sus datos cifrados, lo que probablemente los haga irrecuperables.

Este cambio también evita que las herramientas de recuperación anteriores recuperen máquinas con éxito, ya que los archivos planos tendrán demasiados datos cifrados para poder utilizarlos.

Esta segunda ola de ataques también realizó un cambio menor en la nota de rescate al no incluir direcciones de bitcoin en la nota de rescate, como se muestra a continuación.

Ransomware ESXiArgs

Como vemos, los malos se van mejorando a si mismos.

En ambas versiones sigue creando estos archivos.

En los servidores ESXi comprometidos se vio que se pone una nota de rescate llamadas «ransom.html» y «How to Restore Your Files.html».

Michael Gillespie de ID Ransomware analizó una copia del  cifrador ESXiArgs  y comentó que, desafortunadamente, es un cifrador seguro sin errores criptográficos que no permitirían el descifrado.

Detalle más técnico del Ransomware ARGS

Cuando se cifra un servidor ESXI estos son los archivos se almacenan en la carpeta /tmp:

encrypt: el ejecutable ELF del cifrador.

encrypt.sh : un script de shell que actúa como la lógica del ataque y realiza varias tareas antes de ejecutar el cifrador, como se describe a continuación.

public.pem : una clave RSA pública utilizada para cifrar la clave que cifra un archivo.

motd : la nota de rescate en forma de texto que se copiará en /etc/motd para que se muestre al iniciar sesión. El archivo original del servidor se copiará en /etc/motd1.

index.html : la nota de rescate en formato HTML que reemplazará la página de inicio de VMware ESXi. El archivo original del servidor se copiará en index1.html en la misma carpeta.

«El public.pem que espera es una clave RSA pública (se supone que es RSA-2048 viendo los archivos encriptados, pero el código técnicamente acepta cualquier PEM válido)», publicó Gillespie en el tema de soporte del foro .

«Para que el archivo se cifre, genera 32 bytes usando el CPRNG  RAND_pseudo_bytes seguro de OpenSSL , y esta clave luego se usa para cifrar el archivo usando Sosemanuk, un cifrado de flujo seguro. La clave del archivo se cifra con RSA (OpenSSL’s  RSA_public_encrypt ) y se agrega a el final del archivo».

«El uso del algoritmo Sosemanuk es único y, por lo general, solo se usa en ransomware derivado del código fuente de Babuk (variante ESXi). Este puede ser el caso, pero lo modificaron para usar RSA en lugar de la implementación Curve25519 de Babuk».

Este análisis indica que es probable que ESXiArgs se base en el código fuente filtrado de Babuk, que ya fue utilizado por otras campañas de ransomware de ESXi, como  CheersCrypt y el cifrador PrideLocker  del grupo Quantum/Dagon .

Si bien la nota de rescate para ESXiArgs y Cheerscrypt es muy similar, el método de encriptación es diferente, por lo que no queda claro si se trata de una nueva variante o simplemente de un código base compartido de Babuk.

El cifrador se ejecuta mediante un archivo de script de shell que lo inicia con varios argumentos de línea de comandos, incluido el archivo de clave RSA pública, el archivo para cifrar, los fragmentos de datos que no se cifrarán, el tamaño de un bloque de cifrado y el archivo. tamaño.

usage: encrypt <public_key> <file_to_encrypt> [<enc_step>] [<enc_size>] [<file_size>]

       enc_step   –   number of MB to skip while encryption

       enc_size   –   number of MB in encryption block

       file_size  –   file size in bytes (for sparse files)

Este cifrador se inicia utilizando el script de shell encrypt.sh que actúa como la lógica detrás del ataque, que describiremos brevemente a continuación.

Cuando se inicie, el script ejecutará el siguiente comando para modificar los archivos de configuración de la máquina virtual ESXi (.vmx) de modo que las cadenas ‘ .vmdk’  y ‘ .vswp’  se cambien a ‘ 1.vmdk’  y ‘ 1.vswp ‘.

Modificación de archivos VMX

Modificación de archivos VMX

Luego, la secuencia de comandos finaliza todas las máquinas virtuales en ejecución al forzar la terminación (kill -9) de todos los procesos que contienen la cadena ‘ vmx ‘.

El script luego usará el esxcli storage filesystem list | grep «/vmfs/volumes/» | awk -F’  ‘ ‘{print $2} para obtener una lista de volúmenes ESXi.

El script buscará en estos volúmenes archivos que coincidan con las siguientes extensiones:

.vmdk

.vmx

.vmxf

.vmsd

.vmsn

.vswp

.vmss

.nvram

.vmem

Para cada archivo encontrado, la secuencia de comandos creará un archivo [file_name].args en la misma carpeta, que contiene el paso de tamaño calculado (que se muestra a continuación), ‘1’ y el tamaño del archivo.

Por ejemplo, server.vmx tendrá un archivo server.vmx.args asociado.

La secuencia de comandos utilizará el ejecutable ‘cifrar’ para cifrar los archivos en función de los parámetros calculados, como se muestra en la siguiente captura de pantalla.

Ransomware ESXiArgs

Después del cifrado, la secuencia de comandos reemplazará el archivo ESXi index.html y el archivo motd del servidor con las notas de rescate, como se describe anteriormente.

Finalmente, la secuencia de comandos realiza una limpieza eliminando registros, eliminando una puerta trasera de Python instalada en  /store/packages/vmtools.py  y eliminando varias líneas de los siguientes archivos:

/var/spool/cron/crontabs/root

/bin/hostd-probe.sh

/etc/vmware/rhttpproxy/endpoints.conf

/etc/rc.local.d/local.sh

Ransomware ESXiArgs

El archivo /store/packages/vmtools.py es la misma puerta trasera de Python personalizada para el servidor VMware ESXi descubierta por Juniper en diciembre de 2022, lo que permite a los actores de amenazas acceder de forma remota al dispositivo.

Lo que preocupa:

Recientemente en el foro de https://www.bleepingcomputer.com/forums/t/782193/esxi-ransomware-help-and-support-topic-esxiargs-args-extension/

Hay personas que indican que lo siguiente:

Same issue at same (10:30) connection lost and ESXI hacked. no SSH open, there is password combination. also 5 invalid login attempt rule exist.

I’m face to face with this problem and no solution.

Otros dicen que fueron atacados tienen el servicio SLP desactivado, lo que genera, cierto nerviosismo entre los que tienen un servidor ESXi.

La recomendación de Dolbuck

Desde el equipo de respuesta a incidentes de Dolbuck realizamos las siguientes recomendaciones.

  1. Siempre que se pueda poner un firewall delante del ESXi es lo más recomendable cerrar todos los accesos.
  2. Tener backups de todas las máquinas.
  3. Deshabilitar el SLP (427).
  4. Activar el firewall del propio ESXi con reglas de filtrado.
  5. Monitorizar actividades anómalas.
Logos Footer

Contacto

Dirección: Calle Nobel Nº3,3-5
Mairena del Aljarafe 41927, Sevilla

Teléfono: 900 52 52 45
Móvil: 607 739 265

Email: [email protected]

Últimos Artículos

Biometría y ciberseguridad

Biometría y ciberseguridad

11 de abril de 2024
Construyendo una defensa sólida: La importancia del factor humano en la ciberseguridad

Construyendo una defensa sólida: La importancia del

20 de marzo de 2024
Webinar Plan Director de Seguridad en la empresa

Webinar Plan Director de Seguridad en la

14 de febrero de 2024

Copyright © Dolbuck | Todos los derechos reservados.