ESXiArgs: acciones de respuesta y recuperación
ESXiArgs es un ransomware desplegado en servidores del hipervisor VMWare ESXi (versiones v.6.x anteriores a v.6.7 y potencialmente v.7.x) desde el 3 de febrero de 2023. Se han identificado varias vulnerabilidades como posibles puntos de intrusión y, aunque todas ellas han sido parcheadas hasta la fecha, sigue siendo una amenaza a tener en cuenta. El país más afectado por esta campaña es Francia. De hecho, el CISO del cloud francés, OVH Cloud, fue uno de los primeros en reportar la existencia de la campaña. A día de hoy, según Censys, aún pueden encontrarse centenares de servidores infectados.
Cabe señalar que todas las vulnerabilidades son bastante antiguas, descubiertas alrededor de 2021, algunas de ellas con el código de explotación disponible públicamente desde entonces.
Características
El malware ESXiArgs exhibe una serie de atributos y comportamientos distintivos que lo distinguen en el panorama de la ciberseguridad.
Motivación
La motivación detrás del desarrollo y despliegue de ESXiArgs, un ransomware para hipervisores VMWare ESXi, reside en la obtención de beneficios económicos a través de la extorsión. La elección de servidores VMWare ESXi como objetivo revela un enfoque estratégico, ya que estos servidores son fundamentales en entornos de virtualización, lo que potencialmente amplifica el impacto del ataque en las organizaciones afectadas.
Infección y propagación
El vector de ataque no está completamente confirmado, ya que parece que se han utilizado una amplia gama de vulnerabilidades durante la campaña. En todas las vulnerabilidades explotadas, la mayoría de ellas afectan al servicio OpenSLP, una implementación del Protocolo de Ubicación de Servicios, que escucha en el puerto 427 y se utiliza para permitir que los sistemas descubran servicios en una red local sin necesidad de estar preconfigurados. Las siguientes vulnerabilidades sospechosas son consideradas por VMware como las que posiblemente se utilizaron en las campañas:
- CVE-2022-31699 (heap overflow).
- CVE-2021-21995 (heap overflow).
- CVE-2021-21974 (heap overflow).
- CVE-2020-3992 (use-after-free).
- CVE-2019-5544 (heap overwrite).
Queda cierto grado de incertidumbre, ya que se informó que algunos sistemas afectados tenían OpenSLP desactivado, lo que significa que los atacantes debieron haber utilizado otro punto de entrada.
- Ejemplo de nota de rescate. Fuente. -
Una vez los atacantes consiguen acceder al sistema, se descargan los siguientes ficheros: el script encrypt.sh, un binario ejecutable para Linux denominado encrypt, una nota de rescate index.html, otra versión de la nota de rescate para ser mostrada en el arranque del sistema boot/login motd, la clave pública para el cifrado public.pem, y el payload del ataque archive.zip.
Evasión de detección y recuperación
Para eludir la detección, el ransomware utiliza varias técnicas: mata todos los procesos VMX, elimina los registros, y modifica ficheros, lo que dificulta su detección y análisis.
- Sobrescribe fichero de sistema /bin/hostd-probe.sh.
- Sobrescribe fichero de vmware /etc/vmware/rhttpproxy/endpoints.conf.
- Sobrescribe fichero de sistema /etc/rc.local.d/local.sh.
- Sobrescribe fichero de vmware /store/packages/vmtools.py.
- Elimina las tareas de cron: /var/spool/cron/crontabs/root.
- Elimina los ficheros .log.
- Elimina el script de ataque: /bin/rm -- “$0”.
Además, el ataque despliega mecanismos de persistencia basados en la ejecución de /bin/auto-backup.sh.
Cifrado
El bucle de cifrado busca todos los discos virtuales y archivos de memoria en /vmfs/volumes. Se dirigen a los siguientes archivos con extensiones: vmdk, vmx, vmxf, vmsd, vmsn, vswp, vmss, nvram, vmem.
La estructura del código y el proceso de cifrado parecen estar inspirados en el ransomware Babuk, cuyo código se filtró en septiembre de 2021 después de que cerraran todas las operaciones. Varios malware derivaron de él, como PrideLocker y CheersCrypt. Todos ellos apuntan a sistemas ESXi y utilizan el algoritmo de cifrado Sosemanuk. Para cada archivo, el proceso genera 32 bytes utilizando la función RAND_pseudo_bytes de OpenSSL. Luego, esta clave se utiliza con Sosemanuk para cifrar el contenido del archivo. Finalmente, la clave, única para el archivo, se agrega al final de los datos cifrados después de ser cifrada con RSA.
Una particularidad de este malware es que optimiza el rendimiento cifrando solo fragmentos del fichero. Para cada uno, el ataque utiliza un algoritmo de optimización del cifrado, que se basa en cifrar solo una parte del contenido de los ficheros mayores de 128 MB. La investigación de los analistas de seguridad permitió identificar los chunks (o fragmentos) de datos no cifrados y reconstruir las máquinas virtuales a partir de ellos. Desafortunadamente, esta técnica se volvió obsoleta una vez que el actor de amenazas la descubrió. Así pues, los atacantes cambiaron ligeramente el algoritmo para que los fragmentos sin cifrar fueran más pequeños, dificultando la reconstrucción de los ficheros. Además, los ficheros planos se incluyeron en el proceso de cifrado. Con tanta información oculta, es casi imposible recuperarse del ataque. La segunda ola de ataques, lanzada el 8 de febrero ya utilizó esta nueva técnica.
- Gestión de la variable size_step para determinar el tamaño de los bloques de cifrado. Fuente. -
Resumen
La figura a continuación presenta un resumen visual del flujo de ejecución del ataque, detallando los pasos y las interacciones clave que caracterizan la operación del malware ESXiArgs. Este esquema proporciona una vista panorámica de cómo el malware se propaga, infecta, cifra y realiza otras acciones significativas en los servidores VMWare ESXi.
- Flujo de ejecución del cifrado. Fuente. -
Respuesta y desinfección
De forma preventiva, todas las vulnerabilidades pueden corregirse aplicando el parche correspondiente. Además, las últimas versiones del software resuelven el problema.
Otras formas de anticiparse y prevenir este tipo de ataques son: deshabilitar servicios que podrían servir como posibles puntos de entrada, como el servicio SLP y garantizar que los servidores no estén expuestos a Internet sin las medidas de seguridad adecuadas o instalar un firewall delante del hipervisor.
Como último recurso, es posible hacer uso de las herramientas de descifrado disponibles para intentar revertir las consecuencias del incidente en caso de que hayamos sido objeto de este ataque. Sin embargo, es importante tener en cuenta que la efectividad del proceso de descifrado no está asegurada, ya que puede variar según la versión específica del malware que haya sido utilizada. A día de hoy, las técnicas de recuperación de los ficheros cifrados se basan en la reconstrucción de las partes cifradas a partir de las partes no cifradas.
La herramienta de CISA, basada en los hallazgos de Enes Sonmez y Ahmet Aykac, se puede usar si los sistemas afectados fueron atacados durante la primera oleada de la campaña. Se trata de una herramienta sencilla e intuitiva, solo es necesario descargar el script con wget:
Luego, conceder el privilegio de ejecución al script y ejecutarlo desde la carpeta que contiene el archivo de la máquina virtual que se desea recuperar, proporcionando el nombre del archivo como argumento, donde [nombre] sigue la convención [nombre].vmdk.
Utilizar /tmp/recover.sh [nombre] thin si la VM está en thin format.
Si tiene éxito, la salida lo indicará. Si no tiene éxito, es posible que el script de recuperación no pueda funcionar en los archivos afectados. Si el script tuvo éxito, debes volver a registrar la VM. Si la interfaz web de ESXi no es accesible, primero debes eliminar la nota de rescate siguiendo los siguientes pasos:
Manteniendo el archivo ransom.html puede ayudar al equipo de seguridad durante la investigación. Después de reiniciar el servidor ESXi, ya se debería poder volver a acceder a la interfaz web. Si la VM restaurada todavía está registrada, deberá darse de baja.
- Dar de baja la anterior VM. Fuente. -
Ahora puedes seleccionar ‘Crear / Registrar VM’ e ir a ‘Registrar una máquina virtual existente’.
- Registrar nueva VM. Fuente. -
Al seleccionar el datastore, elige el archivo vmx recuperado recientemente. Haz clic en “Siguiente y finalizar’ para cerrar el asistente y usar la VM como de costumbre.
Conclusiones
El caso de la amenaza ESXiArgs ilustra claramente cómo el ransomware se encuentra en un estado constante de evolución y adaptación, especialmente en su capacidad para afectar hipervisores, lo que se traduce en su capacidad para bloquear y tomar el control de las máquinas virtuales que estos hipervisores gestionan.
Una vez más, cabe destacar la importancia crítica de mantener nuestros sistemas actualizados y de adoptar estrategias de prevención activas, ya que los ciberataques siguen aumentando, adaptándose para aprovechar las vulnerabilidades de las organizaciones.
La lección aprendida de casos como el de ESXiArgs es que la anticipación y la acción proactiva desempeñan un papel fundamental en la protección de la integridad de sistemas y datos en el entorno digital actual.
