Ir al contenido
Nuevo informe: Consiga su copia del Informe sobre el estado de Internet 2024. | Descargar hoy
Blogs

ESXiArgs: ¡Historia, variantes y SLP!

Resumen ejecutivo

  • Hemos identificado otros 11 hosts que parecen tener una variante de la nota de rescate ESXiArgs que se remonta a octubre de 2022, sólo uno de los cuales parecía pagar el rescate.
  • La nueva variante de ESXiArgs -con cifrado mejorado y sin direcciones Bitcoin en las notas de rescate- sigue siendo la variante dominante, y representa el 95% de las infecciones observadas actualmente.
  • Hemos desarrollado una sonda sencilla para el protocolo SLP con el fin de comprender mejor cuántos hosts infectados ejecutan SLP. Desde el despliegue de la sonda el 15 de febrero, no hemos observado más de un 9% de hosts infectados cada día ejecutando SLP.

La semana pasada, descubrimos dos posibles víctimas tempranas de ESXiArgs(Host-A, Host-B) después de darnos cuenta de que eran los dos únicos hosts con la nota de rescate el 1 de febrero y el 31 de enero de 2023. Buscando manualmente en nuestros datos, determinamos que habían tenido una variante de la nota de rescate desde mediados de octubre de 2022, pero teníamos curiosidad por saber si más hosts se habían visto afectados antes del aumento de la campaña de febrero de 2023.

Huella histórica

Buscamos instantáneas semanales hasta enero de 2022 en todos nuestros datos de análisis de Internet y descubrimos otros 11 hosts con la nota de rescate a partir de octubre de 2022. Esto nos lleva a un total de 13 hosts únicos con una variante de la nota de rescate antes de la campaña de principios de febrero de 2023.

Tanto Host-A como Host-B están alojados en el proveedor de cloud francés OVH, uno de los sistemas autónomos más afectados por esta campaña de ransomware. El desglose del sistema autónomo de los 13 hosts observados en octubre es el siguiente:

Nombre del sistema autónomo Número de huéspedes infectados, octubre de 2022
OVH 7
HETZNER-AS 4
HZ-EU-AS, BG 1
AS-LUCKY Lucky Net Ltd, UA 1

Host-A y Host-B son los únicos hosts que observamos que mantuvieron la nota de rescate desde octubre de 2022 hasta febrero de 2023, cuando comenzó la campaña más reciente.

País Número de huéspedes infectados, octubre de 2022
Francia 4
Alemania 3
Polonia 3
Ucrania 1
Finlandia 1
Rusia 1

 

Primeros rescates

En las notas de rescate de estos 13 hosts se utilizaron un total de 10 direcciones Bitcoin distintas, todas ellas con el prefijo "bc1", que indica direcciones de tipo Bech32. Esto contrasta con la campaña de febrero, en la que la mayoría de las direcciones tenían el prefijo "1", la variante Legacy de las direcciones Bitcoin. No estamos seguros de por qué hubo un cambio en los tipos de direcciones entre estos primeros rescates y la campaña de febrero. Según los datos de una herramienta de exploración de blockchain, sólo una de las direcciones (bc1q46zs36ey53lem5qv2pryumtmdtmtr352fdk4pj) parece haber recibido algún pago en algún momento.

El pago recibido el 14 de octubre de 2023 es de 1,08381000 BTC, o 25.696,74 USD, que puede corresponder a una petición de rescate de 1,08739 en el host 185.104.194[.]13, ya que una nota de rescate con esta dirección y cantidad de BTC apareció en nuestros datos del 19 de octubre, pero no se observó con la nota de rescate de la semana siguiente, el 24 de octubre (requiere cuenta de empresa en Censys para su visualización; los datos JSON sin procesar archivados para este host el 19 de octubre se pueden encontrar aquí).

Todas las direcciones BTC observadas en 2022 notas de rescate:

bc1q46zs36ey53lem5qv2pryumtmdtmtr352fdk4pj*

bc1qumexs7v2qtu5sx54y4mgmefn698gh9qq8cu8sp

bc1q0thcm5cc25u2jj78njxx7e9sa7z2dhdu59d0cw

bc1q2lh5umwu7pgszg56s76x9hx948rrkhjxfkff4x

bc1q6n2xd3zg8lqvtk57g8dq9r60zhz0czz9q87uag

bc1qdcadgtv5d6kqdl70g9vgg7u3vkqvfy3kwz66qj

bc1qh0dmcpd56kpx53ca65mmdnapdz3qw8pqpevh8g

bc1qj8hc3744eu6f8nyxlyl0wuqcdqaa4gcnznv4px

bc1qkrgdmdj4faw8mn0nca089w0crwg8t5hm7fuqz0

bc1qx59nlts3g24xp2j0pwkl3klsf9ue0qcuegxrqe

*Dirección única para recibir el pago.

 

Seguimiento de variantes originales y nuevas

Cuando hablamos de las variantes "original" y "nueva" de ESXiArgs, hacemos la distinción basándonos en el contenido de la nota de rescate. Debido a que nuestros escáneres son pasivos, no podemos determinar nada por nosotros mismos sobre el método de cifrado utilizado en un host determinado. Sin embargo, basándonos en los informes de otros investigadores, nos sentimos cómodos afirmando que si un host tiene la "nueva" variante de nota de rescate (es decir, sin dirección Bitcoin), es muy probable que el método de cifrado sea también de la "nueva" variante.

Desde el 8 de febrero, hemos observado un cambio drástico en la variante dominante de las infecciones por ESXiArgs. Antes del 8 de febrero, el ransomware "original" utilizaba un método de cifrado que podía eludirse con la herramienta de descifrado de CISA, e incluía direcciones Bitcoin en las notas de rescate.

El 8 de febrero, aparentemente como respuesta directa a la herramienta de CISA y a los investigadores que rastreaban los pagos de rescates, el actor cambió el método de cifrado y eliminó las direcciones Bitcoin de las notas de rescate.

Nuestra instantánea del 8 de febrero refleja que el 73% de los hosts infectados ese día (ya fueran infecciones nuevas o "actualizadas") tenían la nueva variante. El 9 de febrero, se disparó al 91% de todos los hosts infectados.

A 20 de febrero de 2023, 49 hosts todavía parecían estar infectados con la variante original que incluía direcciones Bitcoin en las notas de rescate:

País Total de anfitriones con la variante original
Francia 15
Estados Unidos 12
Reino Unido 4
Alemania 4
Canadá 4
Turquía 3
Taiwán 3
Singapur 1
Países Bajos 1
Hong Kong 1
Chequia 1

El papel de SLP en ESXiArgs

Los primeros informes de ataques ESXiArgs apuntaban a CVE-2021-21974, una vulnerabilidad en SLP que se remonta a febrero de 2021, como una posible explicación de cómo los actores de la amenaza podrían haber obtenido acceso a los hosts infectados. Sin embargo, las víctimas que afirmaron que no estaban ejecutando SLP en el momento de la infección no tardaron en aparecer, lo que sugiere que puede haber algo más en la historia. VMWare afirma ahora, como parte de sus preguntas frecuentes sobre ESXiArgs, que las vulnerabilidades implicadas en los ataques siguen sin estar claras.

A raíz de las preguntas sobre el papel de SLP en esta campaña, hemos desplegado una sencilla sonda SLP que nos permite determinar si un host está ejecutando SLP. Nuestra sonda se desplegó el 15 de febrero y, desde entonces, hemos observado lo siguiente:

Fecha Recuento de huéspedes infectados
Ejecutando SLP
Porcentaje de huéspedes infectados
Ejecutando SLP
2023-02-15 69* 5%
2023-02-16 102 8%
2023-02-17 114 9.2%
2023-02-18 116 9.6%
2023-02-19 113 9.5%
2023-02-20 106 9.2%
2023-02-21 102 9.1%

*Esta cifra inferior puede explicarse por nuestra puesta en marcha de la sonda el 15 de febrero de 2023.

Dado el número relativamente bajo de hosts infectados que también parecen estar ejecutando SLP, creemos que es probable que haya otras vulnerabilidades o métodos de acceso implicados en estos ataques.

Puede seguir monitorizando las infecciones de ESXiArgs en nuestro panel de control.

 

Sobre el autor

El equipo de investigación Censys
Soluciones de gestión de la superficie de ataque
Más información