ShrinkLocker: Transformando BitLocker en ransomware

Introducción

Los atacantes siempre encuentran formas creativas para evadir controles defensivos y conseguir sus objetivos. Esto puede conseguirse usando packers, crypters y mediante la ofuscación de código. Sin embargo, una de las mejoras formas para evadir la detección, así como maximizar la compatibilidad, es usar funciones nativas del sistema operativo. En el contexto de las amenazas de Ransomware, un notable ejemplo es el uso de funciones exportadas presente en la librería criptográfica ADVAPI32.dll, tales como CryptAcquireContextA, CryptEncrypt, y CryptDecrypt. De esta forma, los adversarios pueden asegurar que el malware se ejecutará en varias versiones del Sistema Operativo que soporte la DLL y simular un comportamiento normal.

Aunque esto parece muy inteligente, otra técnica interesante capto nuestra atención en un servicio de Respuesta a Incidentes reciente: Los atacantes utilizaron la funcionalidad nativa BitLocker para encriptar volúmenes completos y robar las llaves de des-encripción. El propósito original de BitLocker es hacer frente a las amenazas de robo o exposición de datos procedentes de dispositivos perdidos, robados o desactivados de forma inadecuada. No obstante, los adversarios encontraron que este mecanismo también puede ser usado de forma efectiva para propósitos maliciosos.

En este incidente, los atacantes consiguieron desplegar y ejecutar un script VBScript avanzado capaz de aprovechar BitLocker para la encripción no autorizada de archivos. Identificamos el uso de este script y otras versiones modificadas en México, Indonesia y Jordania. En la siguiente sección, analizamos en detalle el código malicioso recuperado durante el servicio de Respuesta a Incidentes y presentamos información para mitigar esta clase de amenazas.

Esta no es la primera vez que vemos a BitLocker como un método de encripción y demanda de pago por secuestro. Previamente, atacantes utilizaron esta funcionalidad de Microsoft para encriptar sistemas críticos después de acceder y tomar control; pero en este caso los adversarios implementaron pasos adicionales para maximizar los daños del ataque e intentar obstaculizar una respuesta eficaz al incidente.

Análisis del VBScript

Un hecho interesante es que los atacantes no se preocuparon por ofuscar gran parte del código, a diferencia de muchos actores de amenaza. La explicación más probable es que ya habían conseguido control total de los sistemas afectados cuando el script fue ejecutado. El script es almacenado en la ruta C:\ProgramData\Microsoft\Windows\Templates\ con el nombre Disk.vbs. Sus primeras líneas contienen una función encargada de convertir texto en su representación binaria usando un objeto ADODB.Stream. Esta función es utilizada después para codificar datos que serán enviados mediante una petición HTTP POST.

Funcion Stream_StringToBinary

La primera acción ejecutada por la función principal del script hace uso de Windows Management Instrumentation (WMI) para consultar información acerca del sistema operativo mediante la clase Win32_OperatingSystem. Por cada objeto en la respuesta de la consulta, el script verifica si el dominio actual es diferente del dominio atacado, si el dominio es diferente el script finaliza automáticamente. Después de esta validación, el script verifica si el nombre del sistema operativo contiene las siguientes palabras: “xp”, “2000”, “2003”, y “vista”, y si la versión contiene esas cadenas de texto finaliza automáticamente y se borra a sí mismo.

Condiciones iniciales para ejecución

Posteriormente, el script continúa ejecutando comandos WMI para consultar información del sistema operativo. A continuación, realiza una operación modificando el tamaño de los discos, la cual puede varias dependiendo del tipo de sistema operativo. Esa operación se ejecuta exclusivamente en discos fijos (DriveType = 3). La siguiente es la lista de los tipos de unidades existentes en el sistema de archivos:

La razón por la que el malware no intenta ejecutar esta operación en unidades de red (DriveType = 4) es una forma de evitar la detección mediante herramientas de alertamiento basado en actividad de red.

Para modificar el tamaño de las unidades locales en sistemas Windows 2008 y 2012, el script verifica las particiones usadas para iniciar como particiones primarias y guarda la información. También guarda el índice de las diferentes particiones y posteriormente ejecuta las siguientes actividades usando la herramienta diskpart:

• Encoge (Shrink) cada partición que no es usada para arrancar el sistema modificando su tamaño a 100 MB. Esta operación permite crear un espacio no localizado (100 MB para cada partición que no contenga el sistema de arranque).
• Divide el espacio no localizado en nuevas particiones primarias de 100 MB.
• Formatea las particiones con la opción override, que obliga al volumen a desmontarse primero si es necesario, y asigna un sistema de archivos y una letra de unidad a cada una.
• Activa las particiones.
• Si el procedimiento de encoger no es satisfactorio, el script almacena la palabra “ok” en una variable para continuar la ejecución.

Operación de redimensionamiento de disco ejecutada por el script en Windows Server 2008 y 2012

Si la operación se ejecuta de forma satisfactoria, el código invoca la utilidad bcdboot y usa la letra de la unidad almacenada previamente como una unidad de arranque, para reinstalar los archivos de inicialización en la nueva partición primaria.

Reinstalación de los archivos de arranque

La operación de redimensionamiento es similar para cada versión de OS pero implementada con diferentes piezas de código por razones de compatibilidad. El ejemplo a continuación presenta el proceso aplicado para las versiones 7, 8 y 8.1.

Operación de redimensionamiento de discos en sistemas Windows versiones 7, 8 o 8.1

Si la versión de Windows es 2008 o 7, después de encoger la partición, la variable matchedDrives almacena las letras de las unidades separadas por comas (solamente si los sistemas de archivos son NFTS, exFAT, FAT32, ReFS o FAT). El código fue modificado para imprimir en pantalla un ejemplo del resultado de su ejecución:

Contenido de la variable matchedDrives

Posteriormente el script agrega las siguientes entradas al registro de Windows:

• fDenyTSConnections = 1: Deshabilita las conexiones RDP.
• scforceoption = 1: habilita la autenticación con tarjeta inteligente.
• UseAdvancedStartup = 1: requiere el uso de un PIN de BitLocker para autenticación en pre-arranque.
• EnableBDEWithNoTPM = 1: permite el uso de BitLocker sin requerir un chip TPM.
• UseTPM = 2: Permite el uso de TPM si está disponible.
• UseTPMPIN = 2: permite el use de un PIN de inicio con TPM si está disponible.
• UseTPMKey = 2: permite el uso de una llave de inicio con TPM si está disponible.
• UseTPMKeyPIN = 2: permite el uso de una llave de inicio y PIN con TPM si está disponible.
• EnableNonTPM = 1: permite BitLocker sin un chip TPM compatible, requiere una contraseña o llave de inicialización en una unidad externa USB.
• UsePartialEncryptionKey = 2: requiere el uso de una llave de inicio con TPM.
• UsePIN = 2: requiere el uso de un PIN de inicio con TPM.

Si el script detecta algún error, reinicia el sistema.

Modificaciones del Registro

Mediante el análisis dinámico del malware podemos confirmar los cambios de registro ejecutados:

Es interesante resaltar que existen múltiples funciones para ejecutar esas operaciones, cada una diseñada para diferentes versiones de Windows. En algunos condicionales, el script verifica si las herramientas de encripción de BitLocker están activas mediante el ID 266 de las herramientas de administración remota de servidores. El malware luego verifica si el servicio Bitlocker Drive Encryption Service (BDESVC) se encuentra en ejecución. Si no es así, inicia el Servicio en el sistema.

Validación de BDESVC

El script también modifica el nombre de la nueva unidad de arranque configurando el correo del atacante, de esta forma la víctima tiene la información de con quién debe ponerse en contacto:

Modificación del nombre de la unidad

Correo del atacante como nombre de unidad

Después de esto, el malware deshabilita los protectores utilizados para asegurar las llaves de encripción de BitLocker y los elimina. El método de borrado puede variar dependiendo de la versión del sistema operativo. En sistemas Windows Server 2008 y Windows 7 lo ejecuta usando funcionalidades de VBS, posteriormente el script usa PowerShell para forzar el borrado de los protectores.

Una vez completado el borrado, el script habilita el uso de contraseñas numéricas como un mecanismo de protección de la funcionalidad de encripción.

Borrado de los protectores

La razón para borrar los protectores por defecto es evitar la recuperación de las llaves por parte del usuario, como se describe en la siguiente imagen:

Recuperación de las llaves de BitLocker

En el siguiente paso del script, se genera una llave de encripción de 64 caracteres usando una multiplicación y reemplazando los siguientes elementos:

• Una variable con números de 0 hasta 9.
• La famosa frase/pangram “The quick brown fox jumps over the lazy dog” en minúscula y mayúscula (Esta frase contiene todas las letras del alfabeto).
• Caracteres especiales.

La aleatoriedad de la contraseña se consigue con una semilla hecha de varios elementos del sistema afectado, tales como memoria utilizada y estadísticas de red. Posteriormente, esta información es enviada al atacante. Verificamos la lógica del generador de llaves en un ambiente controlado y con una pequeña modificación del script, conseguimos ver las contraseñas generadas:

Proceso de generación de llaves

EL código convierte después la llave de encripción generada a un “string seguro” – una opción de PowerShell para prevenir la creación de objetos string en la memoria del sistema – y efectivamente habilita BitLocker en las unidades existentes:

Luego el script crea una petición HTTP POST usando los siguientes parámetros:

• Usar WinHTTP version 5.1
• Aceptar lenguaje Frances
• Ignorar errores SSL (httpRequest.Option(4) = 13056  ➔ WinHttpRequestOption_SslErrorIgnoreFlags)
• Desahabilitar redirección (httpRequest.Option(6) = false  ➔  WinHttpRequestOption_EnableRedirects)

Los atacantes hacen uso del dominio trycloudflare.com para ofuscar su dirección real. Este corresponde a un dominio legítimo perteneciente a CloudFlare y es usado para proveer túneles ágiles para desarrolladores. El subdominio configurado por los atacantes fue “scottish-agreement-laundry-further”.

Creación de la petición HTTP

EL malware también incluye información acerca de la máquina y la contraseña generada para enviar estos datos dentro de la petición POST:

Información para enviar en la petición POST

El script contiene un ciclo que intenta enviar la información hacia el atacante 5 veces si ocurre algún error:

Procedimiento de reintento

Con algunas modificaciones, conseguimos imprimir los datos enviados hacia el atacante, como se registra en la siguiente imagen. Nótese que los datos transmitidos incluyen el nombre del sistema, la versión de Windows, unidades afectadas y la contraseña. En consecuencia, la dirección IP de la víctima también se registrará en el servidor del atacante, lo que le permitirá rastrear a cada víctima.

Información enviada

Después de eliminar los protectores de BitLocker y configurar la encripción de las unidades, el script ejecuta las siguientes acciones para cubrir sus rastros:

Valida si el nombre del host es el blanco del malware, luego elimina los siguientes archivos:

• \Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\MACHINE\Preferences\ScheduledTasks\ScheduledTasks.xml
• \scripts\Login.vbs
• \scripts\Disk.vbs
• C:\ProgramData\Microsoft\Windows\Templates\Disk.vbs

Operaciones de borrado

Luego, el script borra los logs de Windows PowerShell y Microsoft-Windows-PowerShell/Operational usando la aplicación wevtutil. Inicializa el firewall de sistema y elimina todas sus reglas. También elimina las tareas VolumeInit y VolumeCheck usadas para desplegar el malware. Finalmente, el malware ejecuta un apagado forzado del sistema.

Después del apagado, la victima verá la pantalla de BitLocker. Si el usuario intenta usar las opciones de recuperación, no visualizará otro mensaje más que “No existen más opciones de recuperación de BitLocker en su PC”.

Pantalla de recuperación de BitLocker

Tácticas, técnicas y procedimientos

El análisis confirma que el actor de amenaza tiene un conocimiento extendido del lenguaje VBScript, funcionamiento de Windows y sus utilidades, tales como WMI, diskpart y bcdboot. A continuación, se registran las TTPs identificadas para este escenario.

Artefactos y análisis digital forense

Como parte de la actividad local en cada sistema ejecutada por el script se esfuerza por eliminar sus trazas, eliminando logs importantes, tareas programadas para su ejecución y finalmente encriptando unidades completas. No fue sencillo obtener artefactos forenses para determinar las actividades maliciosas o para tener oportunidades de des-encripción.

Afortunadamente el contenido del script y algunos comandos ejecutados fueron registrados en servicios de terceros y pudieron ser recolectados para análisis. Esto nos permitió obtener las contraseñas creadas como strings seguros en algunos sistemas afectados:

Strings seguros obtenidos

Por otro lado, intentamos recolectar registros de red donde las peticiones POST hacia los servidores de C2 pudieran haber sido recolectadas, pero desafortunadamente la configuración más común para el registro de actividad web corresponde a peticiones GET, muy pocos entornos registran peticiones POST.

Finalmente conseguimos obtener algunas peticiones POST; sin embargo, fue todo un reto. Este caso debe ser una invitación a registrar las peticiones POST y confirmar que la actividad de sistemas críticos también es reenviada a un repositorio central con espacio suficiente de almacenamiento de acuerdo con el tiempo de retención recomendado (seis o más meses de acuerdo a los requerimientos de cada organización), así, será posible evitar la pérdida de evidencia cuando los atacantes ejecutan actividades para eliminar sus rastros en sistemas individuales.

Por último, pero no menos importante, algunos sistemas en la infraestructura del cliente permanecieron des-encriptados e inicialmente fueron manejados como no afectados. Sin embargo, después de nuestro análisis conseguimos identificar que, si fueron afectados, pero BitLocker no consiguió ser configurado en esos sistemas y por consiguiente no se produjo la encripción. Esto permitió obtener los scripts completos, analizar su comportamiento y decidir que evidencia adicional debería ser recolectada.

Recuperación

Aunque conseguimos obtener algunas de las contraseñas y valores fijos implementados por los actores de amenaza para crear las llaves de encripción, el script incluye valores variables que son distintos por cada sistema afectado, haciendo más complicado el proceso de descifrado:

Información de red usada para definir la semilla de la contraseña

Mitigaciones

Se anima a las empresas a utilizar BitLocker u otras herramientas de cifrado (como VeraCrypt) para proteger los secretos corporativos. Sin embargo, se pueden tomar algunas precauciones para evitar que los atacantes abusen de esta función:

• Utilizar una solución EPP sólida y correctamente configurada para detectar amenazas que intenten abusar de BitLocker.
• Implementar Managed Detection and Response (MDR) para buscar amenazas de forma proactiva.
• Si BitLocker está activado, asegúrese de que utiliza una contraseña segura y de que las claves de recuperación están almacenadas en un lugar seguro.
• Asegúrese de que los usuarios sólo tienen privilegios mínimos. De este modo, no podrán activar funciones de cifrado ni cambiar claves del registro por su cuenta.
• Active el registro y la supervisión del tráfico de red. Configure el registro de las solicitudes GET y POST. En caso de infección, las peticiones realizadas al dominio del atacante pueden contener contraseñas o claves.
• Supervise los eventos asociados a la ejecución de VBS y PowerShell, y guarde los scripts y comandos registrados en un repositorio externo que almacene la actividad que puede eliminarse localmente.
• Realice copias de seguridad con frecuencia, almacénelas sin conexión y pruébelas.

Si necesita ayuda para investigar un ataque de Ransomware y recuperar los datos cifrados, póngase en contacto con nosotros en gert@kaspersky.com.

Conclusión

Nuestra respuesta a incidentes y el análisis del malware demuestran que los adversarios perfeccionan constantemente sus tácticas para eludir la detección. En este incidente, observamos el abuso de la función nativa BitLocker para el cifrado no autorizado de datos. El script VBS demuestra que el actor malicioso implicado en este ataque tiene un excelente conocimiento de las funciones internas de Windows. Aunque el análisis del script no era complicado en absoluto, este tipo de amenaza es difícil de detectar, ya que las cadenas únicas dentro del artefacto pueden modificarse fácilmente para eludir las reglas YARA. Por lo tanto, el mejor método de detección en escenarios como este es el análisis de comportamiento, que correlaciona diferentes acciones realizadas por la aplicación para llegar a un veredicto.

Los productos de Kaspersky detectan esta amenaza con los siguientes veredictos:

• Trojan.VBS.SAgent.gen
• Trojan-Ransom.VBS.BitLock.gen
• Trojan.Win32.Generic

Indicadores de Compromiso

URLs:
hxxps://scottish-agreement-laundry-further[dot]trycloudflare[dot]com/updatelog
hxxps://generated-eating-meals-top[dot]trycloudflare.com/updatelog
hxxps://generated-eating-meals-top[dot]trycloudflare.com/updatelogead
hxxps://earthquake-js-westminster-searched[dot]trycloudflare.com:443/updatelog

E-mail:
onboardingbinder[at]proton[dot]me
conspiracyid9[at]protonmail[dot]com

MD5 hashes:
842f7b1c425c5cf41aed9df63888e768