Novedades de TorrentLocker: el ransomware criptográfico sigue activo

En diciembre de 2014, ESET publicó un white paper sobre TorrentLocker, una familia de ransomware criptográfico que se propaga a través de mensajes de correo electrónico de spam haciéndose pasar por empresas de servicios postales, energía o telecomunicaciones locales. En dicho documento se describen el esquema de distribución, las funcionalidades básicas y el protocolo de red utilizado, y además se mencionan algunas similitudes con el troyano bancario Hesperbot. Durante los últimos meses, analizamos las nuevas muestras detectadas para comprobar el estado actual de esta familia de malware. En el presente artículo resumimos los resultados de nuestro análisis y comparamos las campañas de 2016 con nuestra investigación anterior, realizada a fines de 2014.

En 2014, el nombre que TorrentLocker utilizaba en su pedido de rescate era el famoso "CryptoLocker". Por razones desconocidas, un año más tarde las letras "o" se reemplazaron por ceros y quedó "Crypt0l0cker". Sin embargo, no hubo cambios significativos en la distribución, la infraestructura de C&C ni las muestras de malware que indiquen que se trata de un ransomware diferente. Creemos que sus operadores son la misma banda criminal. Por lo tanto, para evitar confusiones, decidimos mantener el nombre original TorrentLocker en vez de Crypt0l0cker cuando hacemos referencia a esta familia de malware.

Esquema de distribución

La distribución actual es muy similar a las técnicas de propagación utilizadas en 2014. Los mensajes de correo electrónico contienen un enlace a una página donde se le indica a la víctima que debe descargar un documento (supuestamente una factura o un código de seguimiento de un pedido). Si el usuario descarga el documento (malicioso) y lo abre, ejecuta el malware TorrentLocker, que inicia la comunicación con el servidor de C&C y comienza a cifrar los archivos de la víctima.

Algunas de las empresas por las que se hizo pasar TorrentLocker entre abril y agosto del año 2016 son:

Como ya documentamos en 2014, para acceder a las direcciones URL distribuidas, es necesario hacerlo desde una dirección IP ubicada en el país objetivo de la campaña. En consecuencia, las páginas son difíciles de rastrear para los investigadores o rastreadores que no se encuentran en dicho país.

Imagen 1: Página de descarga de una campaña dirigida a España que se hace pasar por Correos

Imagen 2: Spam para Austria que parece haber sido enviado de Österreichische Post

Imagen 3: Página de descarga de una campaña dirigida a Austria que se hace pasar por A1 Telekom

Imagen 4: Página de descarga de una campaña dirigida a Australia que se hace pasar por AFP

Aunque el esquema de distribución a simple vista tiene el mismo aspecto, hay algunos cambios subyacentes. Por ejemplo, se agregaron capas de redirecciones durante la cadena que conduce al archivo ejecutable malicioso final. El vínculo en el mensaje de correo electrónico de spam ahora lleva a la víctima hasta un script PHP alojado en un servidor infectado. Este script comprueba si el visitante está navegando desde el país objetivo de la campaña. De ser así, vuelve a redirigirlo a otra página desde donde se descarga la siguiente etapa del malware. De lo contrario, redirige al visitante a Google.

Además, el ZIP descargado ahora contiene un archivo JScript cifrado que descargará y ejecutará el archivo TorrentLocker PE. ReaQta publicó un artículo en dos partes donde describe el esquema con mayor detalle. Para resumir, a continuación mostramos un ejemplo de la cadena de eventos que termina dejando a la víctima con sus archivos cifrados:

Mensaje de spam con un enlace para imprimir el código de seguimiento: hxxp://diniyat.com/jKu8xT.php?id=victim@domain.nl
El usuario es redirigido a hxxp://azrs.postnl-tracking24.org/yr7mb.php?id=dmljdGltQGRvbWFpbi5ubA==
El usuario hace clic para descargar hxxp://azrs.postnl-tracking24.org/file/PostNL-pakket.zip
El usuario abre el archivo y hace doble clic en el archivo PostNL-pakket.js
Este archivo JScript descarga y ejecuta TorrentLocker desde hxxp://sudoimpex.ru/administrator/file.exe

TorrentLocker aún cuenta con la capacidad de extraer la libreta de direcciones y la configuración SMTP de la víctima para seguir propagándose.

Contraseña adicional de 4 dígitos agregada para evitar el acceso a las páginas de pago

Hacia fines del análisis realizado en 2014, los investigadores de ESET descubrieron que los "códigos de usuario" generados por el servidor de C&C para identificar a las víctimas son secuenciales y predecibles. Esto nos permitió acceder a todas las páginas de pago y elaborar estadísticas sobre el número de víctimas que terminaron pagando el rescate, la cantidad de casos por país, etc. Para cuando publicamos nuestro white paper, los operadores de TorrentLocker ya habían añadido un campo de contraseña de 4 dígitos llamado "user pass" para acceder a las páginas de pago.

Según un post en el blog de TrendMicro, el parámetro user_pass (pase de usuario) se encontró por primera vez el 9 de diciembre de 2014, una semana antes de la publicación del white paper de ESET. Por lo tanto, los operadores del malware probablemente no se enteraron de esta falla al leer nuestro paper, sino mediante la inspección de sus propios registros. Cuando los operadores notaron que los investigadores habían accedido a todas las páginas de pago, agregaron este campo de contraseña para evitar accesos futuros.

En las campañas actuales, el "código de usuario" se sigue generando con el mismo algoritmo predecible. Sin embargo, no hemos encontrado nada que pudiera ayudar a predecir el valor del "user pass". Parece un número entero aleatorio que se añade a la base de datos del servidor de C&C.

Imagen 5: URL en 2014

Imagen 6: URL con contraseña

Ofuscación

Para este análisis, elegimos tres muestras de TorrentLocker que fueron empaquetadas usando diversos crypters. No perdimos demasiado tiempo haciendo ingeniería inversa con estos archivos. Como vimos en 2014, hay múltiples niveles de descifrado del código, y el payload final se inyecta en el proceso explorer.exe. El núcleo de TorrentLocker exporta las mismas funciones que en el año 2014, a saber, "_local_entry" y "_remote_entry". Sin embargo, este sistema cambió en la muestra de la campaña "main-13", dado que TorrentLocker ya no se sigue inyectando en explorer.exe.

Una vez desempaquetado, el núcleo de TorrentLocker utiliza técnicas de ofuscación adicionales para dificultar su análisis. A continuación describiremos dos técnicas nuevas que no estaban presentes en las muestras de 2014. En primer lugar, las strings se cifran utilizando una clave codificada (hardcoded). La clave es la misma en todas las campañas, pero se trunca, por lo que cambia de tamaño. Las cadenas codificadas se decodifican bajo demanda simplemente utilizando el algoritmo XOR con la clave truncada. Publicamos un script IDA en el repositorio de ESET en Github para ayudar a decodificar las cadenas de una muestra sin empaquetar.

Las funciones importantes de la API de Windows se resuelven en forma dinámica a partir de un hash de 32 bits. La función resultante procesa una iteración en las exportaciones de la biblioteca solicitada y calcula los valores hash de los nombres exportados hasta que encuentra una coincidencia. Esta función toma un número variable de parámetros: el primer parámetro es el índice de una serie de nombres de archivo de la biblioteca, el segundo es el hash del nombre de la función, el tercero es el número de parámetros pasados a la función de la API y el resto son los valores de dichos parámetros. Por ejemplo, así es como se ve una llamada a InternetOpenW:

resolve_and_call_function(
    23,        // wininet.dll
    0xF190D96, // hash("InternetOpenW")
    5,         // nargs
    0, 0, 0, 0, 0x8404C700 // args
);
// calls InternetOpenW(NULL, INTERNET_OPEN_TYPE_PRECONFIG, NULL, NULL,
INTERNET_FLAG_PRAGMA_NOCACHE|INTERNET_FLAG_NO_UI|INTERNET_FLAG_HYPERLINK|\
INTERNET_FLAG_IGNORE_REDIRECT_TO_HTTPS|INTERNET_FLAG_IGNORE_REDIRECT_TO_HTTP|\
INTERNET_FLAG_NO_AUTH|INTERNET_FLAG_NO_CACHE_WRITE|INTERNET_FLAG_RELOAD)

Comunicaciones con el servidor de C&C

Uno de los cambios más interesantes de TorrentLocker son las formas en que se pone en contacto con su servidor de C&C. Como solía hacerlo en 2014, TorrentLocker intenta llegar a un dominio codificado (hardcoded) a través de HTTPS. Sin embargo, ahora antepone un subdominio al azar. Los dominios codificados en forma rígida por lo general tienen una vida corta y son cerrados en poco tiempo.

Lo que resulta interesante es que, en caso de que falle la comunicación, ahora pasa a usar los servicios ocultos de Tor. Hay una pequeña implementación de Tor vinculada estáticamente en el archivo binario, lo que asegura que no necesitará de dependencias externas para conectarse a la red Tor con éxito. La táctica de usar los servicios ocultos de Tor para ponerse en contacto con el servidor de C&C se está volviendo cada vez más popular entre los atacantes que desarrollan ransomware; esto hace que sea mucho más difícil para los investigadores de malware encontrar la ubicación física de dicho servidor.

Imagen 7: Rutas que muestran que la biblioteca Tor incluida está usando LibreSSL

A continuación se muestra la lista de dominios utilizados en las tres muestras analizadas:

Dominio	IP	Campaña
goanfilter.net	164.132.15.78	main-9
axgumdgrlnup.net	62.76.184.225	main-12
gyhigtotna.com	77.246.149.85	main-13

Los siguientes tres dominios con ruta .onion se encuentran en este orden en todas las muestras analizadas:

Servicios ocultos
mz7oyb3v32vshcvk.onion
h453liaclp7vmxnb.onion
vrympoqs5ra34nfo.onion

No hemos notado ningún cambio significativo en el protocolo de comunicación, excepto que cuando se usa Tor se incluye un nuevo campo para la dirección IP pública de la víctima. Debido a las características de Tor, el servidor de C&C no conoce la dirección IP de origen de la solicitud que recibe. Por eso es importante que se incrusten las direcciones IP públicas de las víctimas en el informe enviado al servidor de C&C, ya que solo así podrá geolocalizarlas. TorrentLocker utiliza la dirección IP para generar páginas de rescate en el idioma más probable de la víctima y usa la moneda local cuando muestra el precio, como veremos más adelante en este post.

Aunque TorrentLocker antes solo se basaba en HTTPS para cifrar las comunicaciones con el servidor de C&C, las variantes actuales añaden una capa de cifrado. TorrentLocker utiliza la codificación AES-256-CBC para cifrar el informe antes de integrarlo en una petición HTTP POST, que luego se cifra, ya sea con SSL en el caso de HTTPS, o por Tor. La clave está codificada (hardcoded) en el binario y no se modifica muy a menudo, porque si se cambia en el servidor de C&C de TorrentLocker, las muestras anteriores no serán capaces de volver a comunicarse con el servidor. Las claves AES figuran listadas en los apéndices.

Comportamiento geolocalizado

Una de las características más conocidas de TorrentLocker es la localización de la descarga, el rescate y las páginas de pago. Las víctimas reciben información en sus propios idiomas y en su moneda local. Para este análisis, tratamos de recopilar información sobre los países que están recibiendo estos detalles localizados sobre el rescate y el pago.

Para ello, tuvimos en cuenta que cada vez que se cifran los archivos de una víctima con éxito, se informa a través de la red Tor. En este contexto, la dirección IP externa (utilizada para localizar a la víctima) se envía al servidor de C&C como un parámetro (controlado por el usuario). Entonces, tomamos una dirección IP de cada país, informamos un evento de cifrado de archivos exitoso al servidor de C&C asegurando provenir de esa dirección IP y solicitamos el mensaje de rescate y la página de pago.

La página predeterminada está en inglés y la moneda está en dólares. Descubrimos que 22 países recibieron una versión traducida del pedido de rescate o la página de pago. Ésta es la lista de los países:

Australia
Austria
Bélgica
República Checa
Dinamarca
Francia
Alemania
Italia
Japón
Martinica
Holanda
Noruega
Polonia
Portugal
República de Corea
España
Suecia
Suiza
Taiwán
Tailandia
Turquía
Reino Unido

Hemos visto campañas de spam de TorrentLocker en todos los países de la lista resaltados en negrita. No está claro si los otros países son objetivos pasados o futuros, o si para ellos se usa un mecanismo de propagación diferente.

También hay que destacar que TorrentLocker se rehúsa a cifrar los archivos de las víctimas de algunos pocos países específicos. Aunque este comportamiento ya fue documentado, aún no tenemos la lista de países. En el momento de nuestro experimento, TorrentLocker se negó a cifrar los archivos de las víctimas procedentes de estos cuatro países:

China
Rusia
Ucrania
Estados Unidos

Criptografía

Mientras que el esquema criptográfico global de TorrentLocker no cambió, algunos aspectos de su implementación sí lo hicieron. En 2014, TorrentLocker utilizaba una biblioteca criptográfica llamada LibTomCrypt. Sin embargo, hemos visto variantes recientes que en cambio utilizaban Microsoft CryptoAPI (de las campañas denominadas "main-9" a "main-12"). Lo más sorprendente es que los autores de TorrentLocker decidieron usar LibTomCrypt de nuevo en una muestra del 10 de agosto de 2016 (en la campaña "main-13"). No sabemos por qué cambian de una biblioteca a otra, pero se trate de LibTomCrypt o CryptoAPI, el vector de inicialización siempre está conformado por 32 bytes nulos.

Como mencionamos anteriormente, se cifra toda comunicación con el servidor de C&C. Lo mismo ocurre con los archivos de configuración y de estado que quedan en el disco. Éstos se cifran con AES-256, utilizando una clave codificada en forma rígida que cambia de una campaña a otra. Además, los nombres de archivo ahora también son cadenas aleatorias en vez de números secuenciales.

Imagen 8: Directorio de configuración de TorrentLocker

TorrentLocker cifra los archivos de la víctima con AES-256-CBC, así como los archivos de configuración y los informes que envía al servidor de C&C. La clave se genera con una llamada a CryptGenRandom, donde pide 32 bytes. Cada uno de estos bytes se añaden al byte menos significativo del valor de retorno de una llamada a GetTickCount.

Imagen 9: CFG de la generación de clave AES

La clave es la misma para todos los archivos cifrados. Luego se cifra con una clave pública RSA incrustada y se envía al servidor de C&C. Encontramos la misma clave pública en todas las muestras analizadas; los datos se proporcionan en los apéndices.

TorrentLocker se asegura de que el sistema siga siendo utilizable; para ello, no cifra los archivos del sistema. Antes incluía una lista de las extensiones de los nombres de archivo que debía cifrar, como por ejemplo, ".doc", ".docx", ".xls", etc. Ahora, es exactamente lo opuesto: incluye una lista con las extensiones que nunca debe cifrar, como ".exe", ".dll", ".sys", entre otras. La lista completa figura en el apéndice.

Otro pequeño cambio: en 2014, TorrentLocker cifraba los primeros 2 MB de los archivos. Como indicó Sophos, ahora se redujo a solo el primer 1 MB.

Conclusión

TorrentLocker continúa mostrando bastante actividad y suele pasar desapercibido debido a la forma en que elige a sus víctimas potenciales mediante spam dirigido. Si te gustaría obtener más información sobre este tema, lee el artículo de Lysa Myers “11 formas de protegerte del ransomware" en WeLiveSecurity.

Agradecemos a Frédéric Vachon por su ayuda en el análisis y la redacción de este artículo.

Referencias

Lawrence Abrams, TorrentLocker changes its name to Crypt0L0cker and bypasses U.S. computers, 2015‑04‑28.

Lilia Elena Gonzalez Medina, Insights on TorrentLocker, 2016‑07‑25.

Marc Rivero López, TorrentLocker Campaign Exploits Spanish Utility Brand, 2016‑06‑01.

Nicholas Griffin, TorrentLocker is Back and Targets Sweden & Italy, 2016‑03‑15.

Paul Pajares and Christopher Ke, TorrentLocker Ransomware Hits ANZ Region, 2015‑01‑11.

The current state of ransomware: TorrentLocker, 2015‑12‑23.

Thomas White, Crypt0L0cker – TorrentLocker Rebranded, 2015‑05‑13.

TorrentLocker Campaign affecting Spain and Italy, 2014‑12‑26.

TorrentLocker Ransomware targeting Swiss Internet Users, 2016‑01‑21.

Trojaner-Warnung: Gefälschte “A1” Online-Rechnung, 2016‑08‑16.

Uncovering a ransomware distribution operation – Part 1, 2016‑04‑11.

Uncovering a ransomware distribution operation – Part 2, 2016‑04‑11.

Kelvin Heath, TorrentLocker Ransomware Outbreak, 2016‑05‑19.

Apéndices

Archivos analizados

SHA-1	Fecha y hora de compilación del archivo PE	Campaña	Detección de ESET
2BF11BD7C946F36A690BD2DDB6623BF478E8F37B	Martes 17 de mayo de 2016, 07:13:48	main-9	Troyano Win32/Filecoder.TorrentLocker.C
BFF8090E21C020E989E4C36EBFE50B6C33DDC733	Martes 7 de octubre de 2014, 00:40:23	main-12	Troyano Win32/Injector.DCIZ
EB7BF6B79CCA5FD6B73F32049560AE57C9988A70	Miércoles 10 de agosto de 2016, 08:55:29	main-13	Troyano Win32/Filecoder.TorrentLocker.A

Claves estáticas AES-256

El vector de inicialización siempre está compuesto por bytes nulos.

Muestra SHA-1	Clave de comunicación	Clave del archivo de configuración
2BF11BD7C946F36A690BD2DDB6623BF478E8F37B	4D78C23939EBDE78B5BAFCAB47D199169AF6821F3D276B5324DF9D79ECC7BAD4	BA14569ABB28C1B53ED02F2255EC0EBC9C1AC04F8F044062FBDF08B5ACB65C54
BFF8090E21C020E989E4C36EBFE50B6C33DDC733	4D78C23939EBDE78B5BAFCAB47D199169AF6821F3D276B5324DF9D79ECC7BAD4	34A43BC9495064A464BCCF82B43D8F03273528FE1A497E55B23EFA7D8D3B8DAF
EB7BF6B79CCA5FD6B73F32049560AE57C9988A70	BEABC25657C4D67F84D0E517A654F3663EA2F79793221AA9247486A7584E6F79	3664D810C09ED7B2A0EC9CB29426C92D7EC3B9592A7A86AE7E51D1895778B94C