Win32/VirLock es un ransomware que bloquea las pantallas de las víctimas, y también actúa como un virus parasitario, ya que infecta los archivos existentes de los equipos. Además, es polimórfico, lo que lo convierte en un tipo de malware muy interesante para analizar. Esta es la primera vez que observamos una combinación de funcionalidades maliciosas de este tipo.

NOTA: las víctimas pueden restaurar sus archivos infectados por VirLock con nuestro módulo de desinfección autosostenible.

Tras la publicación del artículo de ESET sobre la investigación completa del ransomware TorrentLocker, ahora podemos aclarar algunas cosas sobre un curioso miembro de la familia de malware que usa la extorsión para exigirles a los usuarios infectados el pago de un rescate.

En la mayoría de los casos, el ransomware es o "bloqueador de pantalla" o del tipo "codificador de archivos". Cuando un codificador de archivos cifra los archivos en el disco rígido de la víctima, no suele bloquear la pantalla ni prevenir que la víctima utilice su equipo de alguna otra forma. La notificación del rescate se muestra de diversas maneras, por ejemplo, en la imagen del fondo de pantalla, en un archivo de texto o, lo más común, dentro de una ventana emergente normal (este también fue el método que usó Cryptolocker).

En algunos casos, el ransomware adopta un enfoque híbrido: cifra archivos a la vez que bloquea la pantalla mediante un mensaje que ocupa la pantalla completa y bloquea los métodos simples para cerrarla. Un ejemplo de esta conducta es Android/Simplocker: el primer codificador de archivos para Android.

En octubre descubrimos un enfoque nuevo, nunca antes visto: Win32/VirLock es un ransomware que bloquea la pantalla y luego no solo cifra los archivos existentes, sino que también los infecta añadiendo su cuerpo al comienzo de los archivos ejecutables, de modo que actúa como un virus parasitario. Sophos también escribió en su blog sobre este interesante malware.

El mes pasado observamos muchas variantes del virus. Esto demuestra que el autor del malware se mantuvo ocupado trabajando en su creación. De hecho, el virus se asemeja a un experimento malicioso y, debido a su naturaleza polimórfica, nos recuerda a los virus de la era del DOS, como el Whale. La forma en que se implementa VirLock demuestra un alto nivel de habilidades de programación, pero aún así, algunas de sus funcionalidades parecen carecer de lógica, lo que resulta desconcertante.

En esta publicación ofrecemos información general sobre la conducta de esta amenaza y explicamos qué lo convierte en un virus polimórfico.

Información general sobre Win32/VirLock

Un archivo infectado con VirLock estará integrado en un archivo Win32 PE con la extensión .EXE añadida a su nombre, a menos que ya se tratara de un archivo ejecutable originalmente. Cuando se ejecuta, descifra el archivo original integrado en su cuerpo, lo coloca en el directorio actual y lo abre. Más adelante en este artículo se describen los métodos de descifrado. Esta conducta lo diferencia claramente de otros codificadores de archivos típicos.

A continuación, VirLock se instala colocando dos instancias con nombres aleatorios de sí mismo en los directorios %userprofile% y %allusersprofile% (no son copias, ya que el virus es polimórfico, por lo que cada instancia es única), y agrega entradas en las claves de registro Run bajo HKCU y HKLM para que se inicien cuando arranca Windows. Luego se inician estas instancias, que solo contienen el cuerpo del virus (sin el archivo host para descifrar).

Las variantes más recientes de VirLock también colocan una tercera instancia que se registra como un servicio. Este enfoque le sirve al malware como un simple mecanismo de defensa, ya que los procesos y los archivos se restauran si se cierran o se eliminan.

Las instancias colocadas son responsables de ejecutar los payloads propiamente dichos.

Un subproceso se ocupa de la infección de los archivos. Win32/VirLock busca archivos que le sirvan para alojarse hurgando minuciosamente en unidades locales y extraíbles, e incluso en redes compartidas, para maximizar su potencial de propagación. Las extensiones de archivos que intenta infectar difieren entre las distintas versiones de VirLock. Una lista de extensiones obtenida de una muestra reciente incluye las siguientes: *.EXE, *.DOC, *.XLS, *.ZIP, *.RAR, *.PDF, *.PPT, *.MDB, *.MP3, *.MPG, *.PNG, *.GIF, *.BMP, *.P12, *.CER, *.PSD, *.CRT, *.PEM, *.PFX, *.P7B, *.WMA, *.JPG, *.JPEG.

Otro subproceso contiene la funcionalidad de bloqueo de pantalla (con las medidas protectoras típicas, como el cierre de explorer.exe, el Administrador de Tareas, etc.) y muestra la siguiente pantalla de rescate.

El mensaje de rescate es suficientemente claro, por lo que solo explicaremos sus aspectos únicos. La captura de pantalla mostrada arriba es de una versión anterior, mientras que las de abajo son de una versión más reciente. Se exige el pago del rescate en Bitcoins y el creador del malware también les da instrucciones claras a las víctimas por si no están familiarizadas con la moneda criptográfica. El bloqueador de pantalla incluso les permite a las víctimas usar un navegador de Internet y el Notepad.

El bloqueador de pantalla es capaz de hacer una localización básica; para ello se fija en si un intento de conexión a google.com es redirigido a google.com.au, google.ca, google.co.uk o google.co.nz y en el valor devuelto de la función GetUserGeoID. Para los países seleccionados se mostrará una bandera, una cotización de Bitcoins y una moneda diferentes. Incluso el importe del rescate parece variar: puede ser de 150 USD o de 250 USD / GBP / EUR / NZD / CAD / AUD.

El código muestra una tasa de cambio de Bitcoins codificada de forma rígida para la moneda correspondiente, pero se actualiza si logra conectarse con su servidor de Comando y Control.

Polimorfismo de VirLock

Desde un punto de vista técnico, la parte más interesante de este malware probablemente sea el hecho de que es un virus polimórfico, es decir que su cuerpo será diferente en todos los archivos host infectados y también cada vez que se ejecute. Pero antes de pasar a explicar cómo cambia el código, tenemos que observar las múltiples capas de cifrado que utiliza.

En la siguiente infografía se muestra el flujo de ejecución simplificado de las variantes anteriores de Win32/VirLock:

Cuando se carga en memoria un archivo binario Win32/VirLock, el único código no cifrado es lo que llamaremos el compilador del stub de cifrado XOR; el resto del código, datos y el archivo original (de estar presente, sino el mismo esquema se aplica a las instancias autosostenibles de VirLock) están cifrados.

La siguiente descripción del compilador del stub de cifrado XOR se aplica a las variantes más viejas de Win32/VirLock. Las variantes más nuevas emplean un mecanismo un poco más complejo. El compilador contiene ocho bloques similares como el del fragmento de código de ejemplo mostrado abajo.

Cada bloque está compuesto por un DWORD calculado específicamente que se escribe en un desplazamiento de memoria específico. Los registros, las operaciones (adiciones y sustracciones) y las constantes se generan aleatoriamente pero producen el resultado deseado. Cada uno de estos bloques genera 4 bytes del stub de cifrado XOR, que corresponde exactamente a 32 bytes de código de ensamble. Este stub es la siguiente fase en la ejecución de Win32/VirLock.

El stub de XOR, como lo implica el nombre en inglés, que significa un "segmento", descifrará una pequeña parte (Parte 1) del código completo de VirLock, el cual contiene varias funciones. En el siguiente ejemplo, la clave XOR utilizada es 0x6B130E06 y el tamaño de la Parte 1 es 0x45C.

El resto del código (Parte 2), así como el contenido del archivo original, permanecen cifrados en este punto.

Una funcionalidad interesante de Win32/VirLock es que el cuerpo de (casi) todas sus funciones también está cifrado y contiene un stub de descifrado al comienzo. Esto dificulta el análisis del malware, ya que ninguna parte del código relevante de las funciones es visible para un desensamblador. El cifrado de la función es simple: se calcula la suma de comprobación del stub de descifrado y se usa como clave XOR para el cuerpo de la función.

Para hacer las cosas más divertidas, tras la ejecución de la función, el cuerpo se vuelve a cifrar. Sin embargo, la clave ahora será diferente: como se muestra en el siguiente fragmento de código, algunas instrucciones desechables del stub de descifrado se cifran con XOR con un número aleatorio (de RDTSC), lo que cambia efectivamente la suma de comprobación que se usa como clave.

Esta es la primera parte del polimorfismo de VirLock: mientras se ejecuta, sus funciones van cambiando efectivamente en memoria a medida que se descifran y se vuelven a cifrar a sí mismas. Y la "instantánea" de memoria modificada de esta manera contribuye (le seguirán más niveles polimórficos) a la exclusividad del virus en cada archivo infectado.

El código que conforma la Parte 1 también contiene otra función de descifrado que se usa para descifrar la Parte 2 y el archivo host integrado. Este tercer tipo de descifrado es apenas más complejo que los anteriores porque usa ROR en lugar de XOR. Las claves de descifrado para el archivo integrado y para la Parte 2 están codificadas de forma rígida.

En resumen, encontramos cifrado en tres niveles:

• La Parte 1 del código se descifra por el stub de XOR al comienzo
• La Parte 2 del código se descifra por una función dentro de la Parte 1
• Casi todas las funciones dentro del código del virus (tanto en Parte 1 como en Parte 2) tienen su cuerpo cifrado. Se descifran cuando deben ejecutarse y luego se vuelven a cifrar

Entonces, ¿qué es lo que hace exactamente que este código sea polimórfico? En un punto de la ejecución del malware, cuando ya se descifraron la Parte 1 y la Parte 2, copia todo su cuerpo en un bloque de memoria asignada. Hay que recordar que las funciones que se ejecutaron antes de crear esta copia en memoria se volvieron a cifrar con una clave diferente. Esta copia se utilizará para infectar los otros archivos, con las siguientes modificaciones en cada uno de ellos.

Trabajando hacia atrás a través de las capas individuales, la copia se vuelve a cifrar. Primero, la Parte 2 y el archivo host que se está infectando se cifran usando claves generadas en forma aleatoria. El archivo host cifrado se añade a la copia en memoria, y las nuevas claves de cifrado, las direcciones de memoria y los desplazamientos se escriben en la Parte 1 del código, de modo que será capaz de extraer la Parte 2 y el archivo original cuando se ejecuta la nueva muestra.

A continuación, la Parte 1 modificada se cifra con XOR con un DWORD generado en forma aleatoria, que se escribe en el stub de XOR al comienzo.

Finalmente, el compilador del stub de cifrado XOR se construye aleatoriamente como se explicó arriba y el stub XOR se sobrescribe con bytes desechables.

Después de todos estos pasos, terminamos con una copia cifrada del virus en memoria que contiene el archivo original integrado. Esto luego se escribe en el disco rígido reemplazando el archivo original. Si el documento original no era un archivo ejecutable (.EXE) Win32 PE, la extensión ".EXE" se añadirá al nombre de archivo tras la extensión original y se eliminará el archivo original. Además, el archivo infectado recién creado tendrá el ícono del archivo host original.

Conclusión

La telemetría LiveGrid® de ESET demuestra que la cantidad de víctimas de este nuevo virus es relativamente baja y que, por ahora, la escala de esta amenaza no se asemeja en nada a la de TorrentLocker u otros ransomware de gran alcance. Sin embargo, el análisis de las transacciones asociadas a las direcciones de Bitcoins utilizadas por el malware revelan que algunas de las víctimas de este fraude ya pagaron. Seguiremos monitoreando la evolución de este nuevo tipo de ransomware.

Lo que destaca a este ransomware por sobre los demás es el hecho de que se trata de un virus parasitario polimórfico funcional. Nuestro análisis del código demostró que el creador del malware realmente se divirtió escribiendo el código de este virus informático.