Evolución del ransomware JSWorm

Introducción

Durante los últimos años, el panorama de las amenazas del ransomware ha ido cambiando gradualmente, dando lugar a un nuevo paradigma. Desde los brotes masivos ocurridos en 2017, como WannaCry, NotPetya y Bad Rabbit, muchos actores de ransomware han pasado a usar una táctica encubierta pero muy rentable: la “caza mayor”. La noticia de que el ransomware es la causa de la interrupción de los servicios de alguna corporación global se ha convertido en algo común en el mundo de hoy.

En algunos casos, esta tendencia global no es más que el reflejo del ciclo de vida constante de las amenazas: viejas familias de ransomware que caen y otras nuevas que aparecen persiguiendo nuevos objetivos. Sin embargo, hay ocasiones en las que una misma familia de ransomware ha pasado de ser una operación a escala masiva a una amenaza muy selectiva, todo en un par de años. En este artículo nos referiremos a una de esas familias: JSWorm.

Cronología

El ransomware JSWorm fue descubierto en 2019 y a lo largo de su historia, sus diferentes variantes han ganado notoriedad bajo varios nombres, como Nemty, Nefilim, Offwhite, entre otros.

Dentro de cada variante “rebautizada” se lanzaron otras versiones, con códigos alterados en diferente medida, con otros nombres de extensiones de archivos, otros esquemas criptográficos y otras claves de cifrado.

El diagrama siguiente presenta algunos de los nombres utilizados por este troyano junto con las fechas en que la variante correspondiente se distribuyó activamente en Internet (no la fecha de la primera vez que se la detectó). Cabe destacar que esta lista no es exhaustiva, pero marca los principales hitos en la evolución de JSWorm.

Junto con los cambios de nombre, los desarrolladores de este ransomware también han estado reescribiendo su código y probando diferentes enfoques de distribución.

En algún momento de 2020 incluso cambiaron el lenguaje de programación de C++ a Golang, reescribiendo completamente el código desde cero; sin embargo, la similitud en el esquema criptográfico, las notas de rescate y el uso de la misma dirección de la web de fuga de datos nos llevan a pensar que se trata de la misma campaña.

La versión original del malware, así como algunas de sus posteriores “reediciones”, por ejemplo Nemty, fueron anunciadas en un foro clandestino con un cartel con el nombre de usuario jsworm.

 

Anuncio en el foro de una variante temprana de JSWorm

Métodos de distribución

Desde su creación en 2019 hasta la primera mitad de 2020, JSWorm se ofreció como un RaaS público y se observó su propagación a través de:

• Kit de explotación RIG
• Red de bots Trik
• Sitios web de pago falsos
• Campañas de spam

A partir del primer semestre de 2020 el RaaS público se cerró y los operadores pasaron a la “caza mayor”. Hay evidencia de una brecha inicial por la explotación de un software vulnerable del lado del servidor (Citrix ADC) y un acceso RDP inseguro.

Información técnica

Describiremos algunas variantes notables de la familia JSWorm encontradas durante la historia de este malware. No intentamos cubrir todas las variantes descubiertas de este malware, ya que son demasiado numerosas. Las fechas indican el periodo aproximado en el que se observó la variante correspondiente de ITW.

Mayo de 2019: JSWorm

MD5: a20156344fc4832ecc1b914f7de1a922

Esta muestra es una de las primeras variantes descubiertas del ransomware JSWorm y, a diferencia de sus sucesores, no contiene un número de versión interno. El ejemplo está desarrollado en C++ y compilado en MS Visual Studio.

Además de cifrar los archivos, realiza otras acciones, como detener una serie de procesos y servicios en ejecución para maximizar la cantidad de archivos de la víctima disponibles para el cifrado. Además, elimina todas las copias de seguridad del sistema, las copias instantáneas, desactiva el modo de recuperación del sistema y borra los registros de eventos.

Esquema de cifrado

Los archivos se cifran utilizando una modificación personalizada del cifrado Blowfish con una clave de 256 bits. La clave se genera al principio de la ejecución del programa y se basa en la concatenación de cadenas: nombre de usuario, dirección MAC del dispositivo y número de serie del volumen (valores de ejemplo en los comentarios).

Proceso de generación de claves

A continuación, se genera una cadena a la que las notas de rescate se refieren como “JSWORM PUBLIC KEY”. De hecho, el cifrado asimétrico no se utiliza aquí y el uso de la palabra “pública” no tiene sentido en este contexto. Lo que el desarrollador del ransomware llama “JSWORM PUBLIC KEY” es en realidad la mencionada clave Blowfish XOR con la cadena “KCQKCQKCQKCQ” y codificada en Base64.

XOR con la clave “KCQKCQKCQKCQ”

A continuación, se muestra un ejemplo del cálculo de claves; los valores del número de serie y la dirección MAC se han elegido a modo de ilustración:

• Clave Blowfish: “53385773534FE:ED:00:DE:AF:00user”
• Clave pública, después de XOR: “5xpi~tfxvbx05x14qx06x15qsaqx07x14qx02x17qsa>049”
• Clave pública, tras la conversión a Base64: “NXhwaX50Znh2Yn8FFHEGFXFzYXEHFHECF3FzYT4wNDk=”

Se utiliza una versión personalizada de Blowfish para cifrar el contenido de cada uno de los archivos de la víctima. No se cifran más de 100 000 bytes, quizá para acelerar el cifrado de archivos grandes. Los datos cifrados se escriben sobre el original.

Los desarrolladores cambiaron la implementación interna del cifrado Blowfish, para que sea incompatible con las implementaciones estándar, en un intento de dificultar el trabajo de descifrado de los investigadores.

Después de cifrar el contenido del archivo, el programa lo renombra. Se añade una extensión adicional “.[ID-…][mail@domain.tld].JSWORM” al nombre del archivo.

Fallas en el cifrado

El malware guarda esencialmente la clave que puede utilizarse para el descifrado en las notas de rescate. La decodificación de Base64 y el descifrado XOR es trivial, y los datos de la víctima pueden salvarse sin tener que pagar el rescate. Incluso si la nota de rescate se pierde por alguna razón, la clave puede ser fácilmente regenerada en la máquina infectada.

Julio de 2019: JSWorm 4.0.3

MD5: 5444336139b1b9df54e390b73349a168

Se trata de una versión mejorada y actualizada de JSWorm que intenta corregir los fallos encontrados en las variantes anteriores.

Esta muestra contiene una comprobación del idioma de la máquina infectada. Lo más probable es que esto sirva para evitar el cifrado de datos en los sistemas en los que se utilizan los siguientes idiomas: RU (ruso), BE (bielorruso), UZ (uzbeko), KY (kirguís), TG (tayiko), TK (turcomano), KK (kazajo), UK (ucraniano).

Determinación del idioma del usuario

Sin embargo, probablemente debido a un error, esta versión del ransomware cifra los archivos solo si el idioma del sistema es el ruso. Si observamos detenidamente las condiciones anteriores, nos daremos cuenta de que la primera condición es ‘!=’ (‘no igual’). Esto hace que el troyano ejecute la rama de código que sale sin cifrado en los sistemas que no tienen el idioma ruso. Si la condición fuera ‘==’, se habría tomado la otra rama, resultando en el comportamiento original y probablemente previsto del troyano.

La nota de rescate en esta variante se implementa como un archivo HTA llamado <ID>-DECRYPT.hta, donde <ID> es el ID único de la víctima asignado por el malware. El archivo HTA se lanza al final de la codificación del archivo y también se añade a la ejecución automática a través del registro:

• reg add HKLMSOFTWAREMicrosoftWindowsCurrentVersionRun /v “zapiska” /d “C:UsersuserJSWRM-DECRYPT.hta”
• reg add HKCUSOFTWAREMicrosoftWindowsCurrentVersionRun /v “zapiska” /d “C: UsersuserJSWRM-DECRYPT.hta”

Nota de rescate de JSWorm 4.0.3

Esquema de cifrado

Esta versión de JSWorm utiliza la implementación WinAPI de RSA y una implementación personalizada de AES para cifrar los archivos. JSWorm genera dos valores aleatorios de 128 bits (IV) y 256 bits (clave), que se limitan al alfabeto formado por: a…z, A…Z, 0…9. La clave pública RSA está incrustada dentro del ransomware:

Clave pública RSA utilizada en JSWorm 4.0.3

Usando esta clave, JSWorm cifra la clave AES y el vector de inicialización (IV) y los codifica en Base64:

Cifrado WinAPI RSA en JSWorm 4.0.3

Después, este valor se añade a la nota del ransomware <ID>-DECRYPT.hta, pero el valor en sí no se muestra visualmente porque se encuentra dentro del archivo como un comentario HTML.

Valores dentro del archivo de la nota de rescate .hta

Para dificultar los intentos de descifrado de los investigadores, los desarrolladores del malware implementaron una variante personalizada del cifrado en bloque AES que es incompatible con el algoritmo estándar. El contenido de los archivos de la víctima se cifra usando este método con la clave y el IV descritos anteriormente.

Para optimizarlo, como antes, solo se cifran los primeros 160.000 bytes en los archivos grandes. Tras el cifrado, se añade una extensión adicional al nombre del archivo, que nos resulta familiar por el ejemplo anterior: “<nombre de archivo>.[ID-NQH1J49][doctorSune@protonmail.com].JSWRM”.

Fallas en el cifrado

En esta variante de JSWorm los desarrolladores intentaron arreglar los fallos encontrados por los investigadores en versiones anteriores. Sin embargo, todavía era posible el descifrado sin pago. El generador de números seudoaleatorios utilizado para generar la clave y el IV no es criptográficamente seguro y permite a los investigadores restaurar la clave y el IV atacando el algoritmo de generación. Si se conocen estos valores, se puede descifrar los datos de las víctimas.

Agosto de 2019: Nemty 1.4

MD5: 1780f3a86beceb242aa81afecf6d1c01

El cambio de código entre JSWorm y Nemty es significativo. Según nuestro análisis, los desarrolladores del malware podrían haber reescrito su troyano desde cero, posiblemente para contrarrestar los anteriores intentos de descifrado exitoso que permitieron a las víctimas de varias variantes de JSWorm restaurar sus datos sin pagar.

Este ejemplo también está desarrollado en C++ y compilado en MS Visual Studio. Implementa un pequeño truco anti-análisis que consiste en un algoritmo de ofuscación de cadenas. Las cadenas (por ejemplo, el nombre y el contenido de la nota de rescate, la clave pública RSA, la URL de pago, etc.) se cifran con el método de flujo RC4 con una clave codificada “fuckav” y se codifican en Base64.

Nota de rescate de Nemty 1.4

Tras el lanzamiento, la muestra recopila la información sobre los dispositivos de almacenamiento conectados a la máquina infectada, obtiene su dirección IP externa mediante una petición HTTP a http://api.ipify.org, determina el país de la víctima solicitando datos a http://api.db-ip.com/v2/free/, genera un par de claves de cifrado de sesión RSA-2048 y combina toda la información recopilada en una estructura JSON. Esta estructura se cifra con la clave RSA pública de los actores de la amenaza y se guarda al final de las notas de rescate como “NEMTY DECRYPTION KEY”.

Información recopilada antes de ser cifrada por RSA

Algunos de los campos de interés de esta estructura:

• isRU: especifica si el país de la víctima determinado por su dirección IP externa es uno de los siguientes: Rusia, Bielorrusia, Kazajistán, Tayikistán, Ucrania;
• versión: versión interna del troyano;
• CompID: ID único de la máquina infectada
• FileID: ID de la infección generado en cada lanzamiento del malware
• UserID: ID del afiliado, codificado en la muestra del troyano
• clave: clave codificada en base64 para el cifrado de archivos (a detallar más adelante)
• pr_key: clave RSA-2048 de sesión privada codificada en base64 (a detallar más adelante)

Esquema de cifrado

La muestra del troyano contiene una clave pública RSA-8192 codificada del actor de la amenaza, que llamaremos clave pública RSA maestra.

Cuando se ejecuta en la máquina de la víctima, el troyano también genera un par de claves RSA-2048 de sesión con la clave privada vista anteriormente como pr_key. Además, también genera una clave de 256 bits que se utilizará con un cifrado de bloques personalizado basado en AES.

La clave de 256 bits y la pr_key se cifran con la clave pública RSA maestra y se guardan en las notas de rescate.

Al cifrar cada uno de los archivos de la víctima, Nemty 1.4 genera un IV de 128 bits y utiliza la clave de 256 bits con este IV para cifrar el contenido del archivo mediante un método personalizado basado en AES. El IV se cifra con la clave RSA pública de la sesión y se añade al archivo cifrado.

Cada archivo cifrado es renombrado para que obtenga una extensión adicional “._NEMTY_<…>_” donde la parte omitida es el ID de la infección mencionado anteriormente como FileID.

Fallas en el cifrado

Al igual que en algunas de las variantes anteriores de JSWorm, la implementación del esquema de cifrado en Nemty 1.4 no es impecable. El descifrado de los archivos de las víctimas fue posible gracias a la explotación de dos puntos débiles:

1. El PRNG para la generación de claves no es seguro;
2. La clave de sesión RSA no se elimina del almacén del sistema.

Utilizando la primera debilidad se puede restaurar la clave de 256 bits y utilizando la segunda, la clave pr_key. Conociendo la clave pr_key, se puede descifrar el IV y luego, teniendo la clave de 256 bits y el IV, se puede descifrar el contenido del archivo de la víctima.

Comunicaciones con el C&C

La muestra descarga el cliente TOR desde https://dist.torproject.org/torbrowser/8.5.4/tor-win32-0.4.0.5.zip, lo extrae y lo ejecuta en la máquina infectada. Después de esperar 30 segundos (obviamente considerados por los desarrolladores del malware como suficientes para permitir la conexión a la red TOR), el troyano envía la información sobre la infección a su servidor C&C codificado en la muestra:

Nemty 1.4 utiliza HTTP GET con URI /public/gate?data=

La información que se envía al servidor es la misma que se guarda en cada nota de rescate y, esencialmente, es una versión cifrada de la estructura JSON de la que hablamos anteriormente.

Otras versiones de Nemty

La marca “Nemty” se utilizó hasta marzo de 2020. Una de las últimas variantes tenía la versión interna 3.1.

Durante estos meses, se descubrieron varias versiones intermedias. Entre los cambios se encuentran diferentes nombres de mutex, direcciones de C&C, la capacidad añadida de terminar procesos en ejecución y detener servicios, eliminar copias instantáneas, criptografía mejorada que impedía el descifrado sin pago, cambio del texto del rescate y numerosos ajustes.

Como nota adicional, los desarrolladores de este malware tienden a codificar las cadenas en ruso (transliterado) aparentemente como una broma o tal vez como una forma de llamar la atención de los investigadores. Algunas de las cadenas contienen vulgaridades que resultaron ser citas de canciones de rap.

Cadenas en una muestra de Nemty 2.4

Cadenas en una muestra de Nemty 2.6

Marzo de 2020: Nefilim

MD5: 5ff20e2b723edb2d0fb27df4fc2c4468

Alrededor de marzo de 2020 los desarrolladores cambiaron la marca de su troyano a Nefilim. Para cuando empezaron a aparecer las primeras variantes de Nefilim, el modelo de distribución de esta familia ya había cambiado. Los desarrolladores pasaron de un esquema RaaS público utilizado con las variantes de JSWorm y Nemty, a una cooperación privada con afiliados destinada a la “caza mayor”. Los actores de la amenaza comenzaron a dirigirse a víctimas de alto perfil y a operar manualmente dentro de la red de la víctima, extrayendo datos confidenciales y amenazando con filtrarlos para intimidar a la víctima.

Todas las funcionalidades auxiliares, como la terminación de procesos, el borrado de copias instantáneas o la comunicación con el C&C, fueron eliminadas del código del troyano. El troyano se convirtió en un binario de propósito único, utilizado solo para cifrar archivos, y cualquier acción adicional, si se consideraba necesaria, era llevada a cabo por los actores de la amenaza de forma manual o con ayuda de herramientas adicionales de terceros.

Nefilim está desarrollado en C++ y compilado en MS Visual Studio al igual que Nemty, y el solapamiento de código entre las versiones posteriores de Nemty (2+) y Nefilim es muy sustancial y nos permite sugerir que el desarrollo se realizó a partir del mismo código fuente.

Como ejemplo de superposición de código, los procedimientos de descifrado de cadenas son idénticos con la única diferencia de la clave RC4.

Procedimientos de descifrado de cadenas idénticos. Izquierda: Nemty 2.6(141dbb1ff0368bd0359972fb5849832d), derecha: Nefilim

El solapamiento no se limita a la ofuscación de cadenas y los fragmentos de código coinciden a lo largo de las muestras en diferentes procedimientos, incluyendo las funciones de generación de claves y de cifrado de archivos.

Similitud de código en los procedimientos de codificación de archivos. Izquierda: Nemty 2.6 (141dbb1ff0368bd0359972fb5849832d), derecha: Nefilim

A diferencia de Nemty, la muestra de Nefilim está firmada por una firma digital que era válida en el momento de la distribución activa de esta variante de malware, pero que ha sido revocada desde entonces.

Al iniciarse, el malware comprueba los argumentos de la línea de comandos. En caso de no haber argumentos, procede a buscar los archivos de la víctima en todas las unidades locales y remotas. Si se da un argumento, el troyano comprueba si es una ruta de directorio existente, en cuyo caso cifra los archivos de este directorio. En el caso contrario, interpreta el argumento como una ruta de acceso a un archivo e intenta cifrarlo. Las comprobaciones de los argumentos de la línea de comandos pueden haberse añadido para permitir a los ciberdelincuentes elegir manualmente los archivos a cifrar o simplemente como una funcionalidad de depuración.

Esquema de cifrado

El cuerpo del troyano contiene una clave pública RSA-2048 maestra codificada perteneciente a los actores de la amenaza.

Al procesar cada archivo de la víctima, Nefilim genera una clave de 128 bits y un IV de 128 bits, y cifra el contenido del archivo mediante AES en modo CBC. La clave y el IV se cifran con la clave maestra RSA y se guardan al final del archivo cifrado.

El archivo cifrado se cambia de nombre, añadiéndole la extensión adicional .NEFILIM

Las notas de rescate se guardan como NEFILIM-DECRYPT.txt en los directorios procesados y contienen direcciones de correo electrónico para ponerse en contacto con los extorsionadores.

Nota de rescate lanzada por Nefilim

Abril de 2020: Offwhite

MD5: ad25b6af563156765025bf92c32df090

Con el cambio de marca de Nefilim a Offwhite el código del malware se ha recortado aún más para reducir el tamaño del binario resultante. Para conseguirlo, los desarrolladores dejaron de utilizar la biblioteca STL y se deshicieron del código de ejecución C++ que añadía un volumen innecesario. Por lo demás, sigue siendo el mismo Nefilim de siempre. Además de las capacidades que ya hemos comentado en la sección anterior, se ha añadido una característica notable al código del troyano que le permite generar un fondo de pantalla a partir del texto del rescate y guardarlo como “scam.jpg”.

Fondo de pantalla generado por Offwhite

Junio de 2020: Telegram

MD5: 004f67c79b428da67938dadec0a1e1a4

Los cambios entre las variantes Offwhite y Telegram del troyano son mínimos. El código es casi idéntico, siendo las principales diferencias la extensión del archivo cifrado (.TELEGRAM), el nombre de la nota de rescate (TELEGRAM-RECOVER.txt) y el hecho de que los nombres de las funciones de la API importadas no están codificados como cadenas HEX.

Noviembre de 2020: Fusion

MD5: f37cebdff5de994383f34bcef4131cdf

Esta variante del troyano está escrita en el lenguaje de programación Go. Como mencionamos, las variantes anteriores fueron desarrolladas en C++, lo que significa una reescritura completa desde cero, posiblemente por otro desarrollador.

Sin embargo, la semejanza del modus operandi general del malware, el esquema de cifrado, las notas de rescate que coinciden y el hecho de que el binario está firmado, sugieren que esta muestra es una nueva variante de la familia JSWorm.

Además, las direcciones de los sitios de fuga de datos codificadas en el cuerpo del troyano son las mismas que las que estos actores de amenazas utilizaron anteriormente, lo que constituye un argumento innegable que apoya nuestra sugerencia sobre el vínculo entre Fusion y sus predecesores.

Además, al igual que las variantes anteriores, el programa Fusion acepta un argumento en la línea de comandos: el nombre del archivo a cifrar (posiblemente, utilizado para depurar el ransomware).

Esquema de cifrado

El programa genera dos números aleatorios de 128 bits (IV y clave), que se utilizan para cifrar los archivos utilizando AES en modo GCM según el siguiente esquema: si el archivo es inferior a 1,5 MB, se encripta todo el archivo; si el archivo es mayor, entonces procede de forma secuencial:

• 320 KB de información están cifrados;
• 320 KB omitidos (no cifrados);
• los siguientes 320 KB están cifrados;
• se saltan los siguientes 320 KB;
• …
• y así sucesivamente hasta el final del archivo.

Esto significa que, si el archivo es grande, resulta cifrado en un 50 por ciento (pero en orden de partes alternas).

Una clave pública RSA maestra está incrustada dentro del programa, que se utiliza para cifrar el IV y los valores de la clave. Una vez cifrados, se añaden al final de cada archivo cifrado.

Clave pública RSA utilizada por Fusion

Y por último, la línea “FUSION” se escribe al final del archivo. A continuación, se añade la extensión “.FUSION” al nombre del archivo. La muestra también deja una nota con contactos para la comunicación (FUSION-README.txt):

Notas de rescate lanzadas por Fusion

Enero de 2021: Milihpen

MD5: e226e6ee60a4ad9fc8eec41da750dd66

Con la variante Milihpen, los actores detrás de la familia JSWorm han vuelto a escribir por completo el código del malware, o quizás más bien han contratado a otro desarrollador para implementarlo desde cero. Esta muestra se desarrolla una vez más en C++ (como Nefilim y las variantes anteriores) y no en Golang (como Fusion).

A pesar de esto, se conservan la funcionalidad principal, el flujo de ejecución, el esquema criptográfico y las direcciones laterales de fuga de datos. Además, el nombre del troyano revela la conexión con una de las variantes anteriores del malware, pues la palabra “Nephilim” está escrita al revés.

El troyano ahora registra todas sus acciones en la consola, lo que probablemente facilita al operador del malware controlar el proceso de infección.

Registro en la consola de Milihpen

Al igual que las variantes anteriores, la muestra de malware está firmada por un certificado digital. Tras el lanzamiento, Milihpen analiza los datos de configuración codificados en el cuerpo del troyano. Esta estructura de configuración se almacena en formato JSON y contiene los siguientes campos:

Tras analizar los valores de la configuración, Milihpen crea un mutex, analiza los argumentos de la línea de comandos y procede a operar con la misma lógica que Nefilim y las variantes más recientes de JSWorm. Si se proporciona un argumento de línea de comandos, el troyano comprueba si es una ruta de directorio. Si es así, cifra los archivos que se encuentren en su interior, de lo contrario la interpreta como una ruta de archivo e intenta cifrarla. Si no se da ningún argumento, el troyano busca los archivos de la víctima en todas las unidades locales y remotas.

Estructura JSON de configuración en la muestra de Milihpen

Esquema de cifrado

Al igual que con los demás aspectos, Milihpen imita al detalle la lógica de alto nivel de las variantes anteriores, empezando por Nefilim y sus sucesores. El análisis del código muestra, sin embargo, que la implementación ha sido completamente reescrita.

Para cifrar los archivos, Milihpen utiliza los mismos algoritmos AES en modo CBC y RSA. La clave AES y el IV también son de 128 bits y se guardan después del cifrado mediante la clave pública RSA maestra al final del archivo cifrado.

Para la generación de números aleatorios y el cifrado RSA, a diferencia de sus predecesores, Milihpen utiliza funciones de la API BCrypt, que forma parte de la reciente biblioteca CNG (Cryptography Next Generation) introducida en Windows Vista. Este hecho no da ninguna ventaja significativa a Milihpen, pero es una característica notable, ya que hoy en día la API de BСrypt no suele utilizarse en el ransomware cifrador.

Los archivos cifrados se renombran con una extensión adicional .MILIHPEN y las notas de rescate se guardan como MILIHPEN-INSTRUCT.txt.

La nota de rescate contiene un texto similar al de otras variantes anteriores de esta familia, así como las mismas direcciones de sitios de filtración de datos.

Nota de rescate lanzada por Milihpen

Febrero 2021: Gangbang

MD5: 173ab5a59490ea2f66fe37c5e20e05b8

La variante Gangbang es idéntica a Milihpen y es actualmente la última cepa descubierta de esta familia de ransomware. La única diferencia notable es el hecho de que la estructura de configuración se almacena ahora cifrada por AES con una clave y un IV codificados en lugar de estar en texto plano como en Milihpen. Además, a diferencia de las versiones anteriores, la firma digital de esta muestra no es válida.

Configuración de la muestra Gangbang (redactada)

Sitio web de la fuga de datos

En la primavera de 2020, los actores responsables de la familia JSWorm se pasaron a la “caza mayor” y crearon su propia página web en la que podían publicar los datos confidenciales robados a sus víctimas.

Al momento de redactar este artículo, el sitio web seguía funcionando y contenía publicaciones sobre más de un centenar de organizaciones víctimas de este malware.

Página sobre las condiciones de los términos de la amenaza

La página de “contacto” enumera las direcciones de correo electrónico utilizadas actualmente por los actores de la amenaza para las negociaciones.

Página con direcciones de correo electrónico de contacto

Para algunas de las víctimas también hay una serie de páginas individuales que permiten descargar algunos de los datos que les fueron robados.

Página de descarga de datos robados

Víctimas

Basándonos en nuestra telemetría KSN, hemos creado un gráfico que ilustra la distribución geográfica de los ataques del ransomware JSWorm.

Los 10 países más atacados por JSWorm según las estadísticas de KSN

	País	%*
1	China	21,39%
2	Estados Unidos de América	7,96%
3	Vietnam	7,46%
4	México	6,97%
5	Federación de Rusia	6,47%
6	Brasil	5,47%
7	India	5,47%
8	Alemania	4,98%
9	Francia	4,48%
10	República de Corea	2,99%

Porcentaje de los usuarios únicos de Kaspersky atacados por JSWorm en el país, del total de usuarios atacados por JSWorm

Además, analizamos los datos sobre las víctimas publicados por los propios actores de la amenaza en su sitio de filtración de datos. A partir de estos datos, hemos creado un gráfico que ilustra la distribución de las víctimas del JSWorm por sectores.

Según la lista de víctimas publicada por los actores de la amenaza, dos quintas partes (41%) de los ataques de JSWorm iban dirigidos a empresas del sector de la ingeniería y la fabricación. La energía y los servicios públicos (10%), las finanzas (10%), los servicios profesionales y de consumo (10%), el transporte (7%) y la sanidad (7%) también ocupan los primeros lugares de la lista.

Conclusión

La familia JSWorm lleva ya dos años evolucionando y durante este tiempo ha cambiado de modelo de distribución y el troyano ha sufrido varias remodelaciones completas. Desde su aparición en 2019, ha pasado de ser el típico ransomware a escala masiva que amenazaba sobre todo a usuarios individuales, a ser el típico ransomware de “caza mayor” que ataca objetivos de alto perfil y exige pagos masivos de rescate.

Al igual que con otras amenazas selectivas de ransomware de hoy en día, lo esencial para la prevención de incidentes de infección de JSWorm es un enfoque complejo de la seguridad de la red de una organización. Cualquier punto débil puede convertirse en un punto de entrada para los actores de la amenaza, ya sea una versión vulnerable del software del servidor, un empleado que active un enlace malicioso, una contraseña débil para los sistemas de control remoto, etc.

Para reforzar las defensas contra el ransomware de “caza mayor”, recomendamos llevar a cabo una auditoría de seguridad de su red para encontrar y corregir proactivamente cualquier fallo de seguridad.

Otras recomendaciones pertinentes para maximizar la seguridad de su organización:

• No exponer los servicios de escritorio remoto (como RDP) a las redes públicas, a menos que sea absolutamente necesario y utilizar siempre contraseñas seguras para ellos.
• Asegurarse de que las soluciones VPN comerciales y otro software del lado del servidor estén siempre actualizados, ya que la explotación de este tipo de software es un vector de infección común para el ransomware. Mantener siempre actualizadas las aplicaciones del lado del cliente.
• Enfocar la estrategia de defensa en la detección de movimientos laterales y la extracción de datos a Internet. Prestar especial atención al tráfico saliente para detectar las conexiones de los ciberdelincuentes. Hacer copias de seguridad de los datos con regularidad. Asegurarse de poder acceder de inmediato a los datos respaldados en caso de emergencia. Utilizar la información más reciente de Threat Intelligence para estar al tanto de las TTPs reales utilizadas por los actores de las amenazas.
• Utilizar soluciones como Kaspersky Endpoint Detection and Response y el servicio Kaspersky Managed Detection and Response que ayudan a identificar y detener el ataque en las primeras etapas, antes de que los atacantes alcancen sus objetivos finales.
• Para proteger el entorno empresarial, se debe educar a los empleados. Los cursos de formación específicos pueden ayudar, como los que se ofrecen en la Plataforma de Concienciación de Seguridad Automatizada de Kaspersky.
• Utilizar una solución de seguridad para puntos finales fiable, como Kaspersky Endpoint Security for Business, que cuenta con prevención de exploits, detección de comportamientos y un motor de corrección capaz de revertir las acciones maliciosas. KESB también cuenta con mecanismos de autodefensa que pueden impedir su eliminación por parte de los ciberdelincuentes.

IoC (muestra MD5)

JSWorm (variante temprana)
MD5: a20156344fc4832ecc1b914f7de1a922

JSWorm 4.0.3
MD5: 5444336139b1b9df54e390b73349a168

Nemty 1.4
MD5: 1780f3a86beceb242aa81afecf6d1c01

Nefilim
MD5: 5ff20e2b723edb2d0fb27df4fc2c4468

Offwhite
MD5: ad25b6af563156765025bf92c32df090

Telegram
MD5: 004f67c79b428da67938dadec0a1e1a4

Fusion
MD5: f37cebdff5de994383f34bcef4131cdf

Milihpen
MD5: e226e6ee60a4ad9fc8eec41da750dd66

Gangbang
MD5: 173ab5a59490ea2f66fe37c5e20e05b8