Ramsay: un framework de ciberespionaje diseñado para comprometer redes aisladas

Investigadores de ESET descubrieron un framework para ciberespionaje no reportado anteriormente, al cual han denominado Ramsay. El mismo está diseñado para recolectar y exfiltrar documentos sensibles y es capaz de operar dentro de redes aisladas, también conocidas como redes air-gapped.

Inicialmente se descubrió una instancia de Ramsay en VirusTotal a partir de una muestra cargada desde Japón, lo que nos llevó al descubrimiento de otros componentes y versiones del framework, además de evidencia suficiente para concluir que el mismo está en etapa de desarrollo.

La visibilidad actual de los blancos de ataque de Ramsay es baja. Basados en los datos de la telemetría de ESET, pocas víctimas han sido descubiertas a la fecha actual. Creemos que esta escasez de víctimas refuerza la hipótesis de que este framework está bajo un continuo proceso de desarrollo, aunque la baja visibilidad de las víctimas puede tener que ver también con la naturaleza de los sistemas apuntados, siendo redes air-gapped.

Por otra parte, se descubrieron artefactos compartidos junto con el backdoor Retro. Este malware ha estado asociado al grupo de APT Darkhotel, conocido por haber llevado adelante operaciones de ciberespionaje desde el año 2004 que apuntaban a entidades gubernamentales de países como China o Japón.

Vectores de ataque

En cuanto a los vectores de ataque, hemos descubierto que Ramsay ha estado haciendo uso de distintas versiones:

Figura 1. Visión general de las distintas versiones descubiertas de Ramsay

Documentos maliciosos que droppean la versión 1 de Ramsay

Este vector de ataque consiste en el uso de documentos maliciosos que explotan la vulnerabilidad CVE-2017-0199 con el objetivo de eliminar una versión anterior de Ramsay. Este documento entrega un Script Visual Basic inicial (OfficeTemporary.sct, el cual se puede observar en la siguiente captura de pantalla, que extraerá, del cuerpo del documento, el agente Ramsay enmascarado como una imagen JPG que presenta un PE codificado en base64 bajo un encabezado JPG.

Tabla 1. Diseño del objeto OLE contenido en el archivo RTF de Ramsay versión 1 como lo ven los oletools

Notamos que la instancia específica de Ramsay eliminada por estos documentos mostró una baja complejidad en su implementación y carecía de muchas de las características más avanzadas que hemos visto en versiones posteriores de Ramsay.

Varias instancias de estos mismos documentos maliciosos los hemos descubierto cargados en motores de sandbox públicos, etiquetados como artefactos de prueba bajo nombres como 'access_test.docx' o 'Test.docx', lo que denota un esfuerzo continuo para probar este vector de ataque específico.

Teniendo en cuenta la baja complejidad del agente Ramsay distribuido, los operadores detrás de esta amenaza probablemente estén incorporando esta instancia específica dentro de estos documentos maliciosos para fines de evaluación.

Uso de instaladores como señuelo para droppear la versión 2.a de Ramsay

Encontramos una instancia de Ramsay cargada en VirusTotal enmascarada como un instalador de 7zip.

La razón por la que decidimos llamar Ramsay a este malware es debido a algunas de las strings contenidas en este binario, como las siguientes:

Figura 2. Strings que contienen “Ramsay”

Esta versión de Ramsay muestra una mejora en cuanto a las tácticas de evasión y persistencia utilizadas, además de la introducción de nuevas características, como es un componente Spreader y un rootkit. Los detalles de este componente Spreader se explican con mayor profundidad en la sección “Capacidades”.

Documentos maliciosos que droppean la versión 2.b de Ramsay

Este vector de ataque consiste en la entrega de un documento malicioso diferente que abusa de la vulnerabilidad CVE-2017-11882. Este documento droppeará un instalador de Ramsay llamado lmsch.exe, tal como se aprecia en la Tabla 1.

Tabla 2. Diseño del objeto OLE contenido en el archivo RTF de la versión 2.b de Ramsay, como lo muestran los oletools

La versión de Ramsay que hace uso de este documento es una versión ligeramente modificada de la versión 2.a, con la principal diferencia de no aprovechar el componente spreader. En cuanto a la funcionalidad de los componentes restantes es la misma con respecto a la versión 2.a de Ramsay.

Ejecución de los archivos infectados en el cliente

Como se mencionó anteriormente, la versión 2.a de Ramsay presenta un componente Spreader que se comportará como un infectador de archivos, cambiando la estructura de los archivos ejecutables PE benignos que se encuentran dentro de unidades extraíbles y compartidas en red para embeber artefactos maliciosos de Ramsay que son activados en la ejecución del archivo host.

El componente spreader es altamente agresivo en su mecanismo de propagación y cualquier ejecutable PE que resida en las unidades de destino serían candidatos para la infección.

Según las marcas de tiempo de compilación entre los componentes de las distintas versiones encontradas de Ramsay podemos estimar la siguiente línea de tiempo de desarrollo de este framework:

Figura 3. Estimación de la línea de tiempo relacionada al desarrollo de Ramsay

El análisis de las diferentes marcas de tiempo de compilación encontradas a lo largo de diferentes componentes implica que este framework ha estado en desarrollo desde finales de 2019, con la posibilidad de que existan actualmente dos versiones bajo mantenimiento diseñadas en función de la configuración de diferentes objetivos.

Mecanismos de persistencia

Según la versión, Ramsay implementa varios mecanismos de persistencia de diferente complejidad. Algunos de estos son los siguientes:

• Clave de registro AppInit DLL

El sistema operativo Windows ofrece una funcionalidad que permite que las DLL personalizadas se carguen en el espacio de direcciones de casi todos los procesos de aplicación a través de la clave de registro AppInit DLL. Esta técnica no es particularmente compleja. Se implementa en las primeras versiones de Ramsay y es común en otras familias de malware.

• Tarea programada a través de la API COM

Las tareas programadas permiten a los administradores ejecutar tareas o "trabajos" en los momentos designados en lugar de hacerlo cada vez que se inicia el sistema o el usuario inicia sesión. Esta característica, incluida en las primeras versiones de Ramsay, se puede implementar a través de la API COM de Windows. Teniendo en cuenta el alto porcentaje de similitud que presenta con la implementación en Carberp, es muy probable que en el caso de Ramsay, la misma haya sido una adaptación del código fuente de Carberp que está disponible de manera pública.

• Hijacking de Phantom DLL

Las versiones más maduras de Ramsay denotan un aumento en la complejidad de sus técnicas de persistencia, lo que incluye el uso de una técnica a veces denominada "Hijacking de Phantom DLL".

Esta técnica se aprovecha del hecho de que muchas aplicaciones de Windows usan dependencias obsoletas que no son estrictamente necesarias para la funcionalidad de la aplicación en sí, lo que permite la posibilidad de hacer uso de versiones maliciosas de estas dependencias.

Dos servicios serán apuntados para hacer cumplir esta técnica. Estos son:

• Hijacking de WSearch (búsqueda de Windows) msfte.dll:

Figura 4. Hijacking del servicio de búsqueda de Microsoft msfte.dll

• El servicio MSDTC (Microsoft Distributed Transaction Coordinator) secuestra una dependencia de oracle descrita a continuación como oci.dll:

Figura 5. Secuestro de la dependencia del servicio MSDTC oci.dll

Esta técnica de persistencia es muy versátil, permitiendo a los agentes de Ramsay distribuidos como archivos DLL que fragmenten su lógica en secciones separadas, implementando diferentes funcionalidades adaptadas a los procesos donde se cargará el agente. Además, el uso de esta técnica hace que la detección sea más difícil, ya que la carga de estas DLL en sus respectivos procesos/servicios no necesariamente activarán una alerta.

Capacidades

La arquitectura de Ramsay proporciona una serie de capacidades monitoreadas a través de un mecanismo de registro que tienen como objetivo ayudar a los operadores al proporcionar un feed de inteligencia accionable para llevar a cabo acciones como exfiltración, control y movimiento lateral, así como proporcionar información general del sistema comprometido y estadísticas de cada sistema. La realización de estas acciones es posible debido a las siguientes capacidades:

• Recolección de archivos y almacenamiento encubierto

El objetivo principal de este framework es recopilar todos los documentos de Microsoft Word existentes dentro del sistema de archivos del objetivo. Las etapas generales de recolección se muestran en la Figura 6:

Figura 6. Mecanismo de recolección de documentos.

Los documentos Word primero se recopilarán y almacenarán en un directorio de recopilación preliminar. La ubicación de este directorio puede variar según la versión de Ramsay. Dos de los directorios que observamos siendo utilizados para este propósito fueron APPDATA%\Microsoft\UserSetting y %APPDATA%\Microsoft\UserSetting\MediaCache.

Dependiendo de la versión de Ramsay, la recopilación de archivos no se limitará a la unidad del sistema local, sino que también buscará unidades adicionales, como unidades de red o extraíbles:

Figura 7. Salida Hex-Rays de procedimiento para escanear unidades extraíbles para su recolección

Figura 8. Salida Hex-Rays de procedimiento para escanear unidades de red para su recolección

Los documentos recopilados son cifrados utilizando el algoritmo de cifrado RC4.

La clave RC4 utilizada para cifrar cada archivo será un hash MD5 calculado a partir de una secuencia de 16 bytes generada aleatoriamente, con salto de 16 bytes hardcodeados en la muestra de malware. Los primeros 16 bytes del buffer donde se guardará el archivo cifrado corresponderán a la actual clave RC4 utilizada:

Figura 9. Salida Hex-Rays de la clave RC4 de generación y almacenamiento

Los archivos recopilados en el directorio de recopilación preliminar se comprimirán utilizando una instancia de WinRAR que droppea el instalador de Ramsay. Este archivo comprimido se guardará dentro del directorio de recopilación preliminar y luego generará un artefacto contenedor de Ramsay:

Figura 10. Salida Hex-Rays de la generación del contenedor de Ramsay

Como se muestra en la captura de pantalla anterior, estos contenedores de Ramsay contienen un valor mágico al comienzo del archivo, junto con un GUID del perfil del hardware que muestra un identificador de la máquina de la víctima. Asimismo, una capa de cifrado adicional basada en XOR se aplicará al archivo comprimido generado. El siguiente diagrama muestra la estructura de estos artefactos:

Figura 11. Estructura del contenedor de Ramsay <{i>

Ramsay implementa una forma descentralizada de almacenar estos artefactos entre el sistema de archivos de la víctima mediante el uso de hooks en línea aplicados en dos funciones de Windows API: WriteFile y CloseHandle.

El propósito principal del procedimiento WriteFile hookeado es guardar el identificador de archivo del archivo de asunto para escribir e instalar otro hook en la función API CloseHandle. El procedimiento de hookeado de CloseHandle verificará si el nombre del archivo de asunto tiene una extensión .doc; si ese es el caso, se agregará al final del documento de asunto el artefacto del contenedor Ramsay seguido de una secuencia de 1024 bytes denotando un pie de página del documento de Microsoft Word.

Esto se realiza como una medida de evasión para proporcionar un medio para ocultar a simple vista el artefacto embebido dentro del documento de asunto:

Figura 12. Salida Hex-Rays del código para agregar el pie de página en el documento Word.

Los contenedores Ramsay añadidos a los documentos de Word se marcarán para evitar que se añadan artefactos redundantes a los documentos ya afectados y el directorio de almacenamiento preliminar se borrará para generar un artefacto Ramsay nuevo en intervalos.

Aunque los documentos afectados serán modificados, no afectarán su integridad; cada documento de Word permanece completamente operativo después de que se haya agregado el artefacto.

La exfiltración de estos artefactos se realiza a través de un componente externo que no hemos podido recuperar. Sin embargo, según la metodología descentralizada que Ramsay implementa para el almacenamiento de los artefactos recolectados, creemos que este componente escaneará el sistema de archivos de la víctima en busca de los valores mágicos del contenedor de Ramsay, para de esta manera identificar la ubicación de los artefactos que se van a filtrar.

• Ejecución del comando

A diferencia de la mayoría del malware convencional, Ramsay no tiene un protocolo de comunicación C&C basado en la red ni intenta conectarse a un host remoto con fines de comunicación. El protocolo de control de Ramsay sigue la misma filosofía descentralizada implementada para el almacenamiento de artefactos recolectados.

Ramsay escaneará todas las redes compartidas y las unidades extraíbles (excepto A: y B: unidades generalmente reservadas para disquetes) en busca de posibles archivos de control. Primero, Ramsay busca documentos Word y también, en versiones más recientes, archivos PDF y archivos ZIP:

Figura 13. Salida Hex-Ray del procedimiento de escaneo de Ramsay para la recuperación del archivo de control

Estos archivos son parseados por la presencia de un marcador mágico específico para el formato del archivo de control. Más específicamente, Ramsay busca cualquiera de los dos GUIDs de perfil de hardware codificados proporcionados. Uno de estos está hardcodeado como se muestra en la Figura 14, mientras que el otro se genera de forma dinámica en función de la máquina de la víctima comprometida. Si se encuentra alguno de los identificadores de asunto, se intentará analizar una firma de comando.

Figura 14. Salida Hex-Rays del análisis de los archivos de control de Ramsay

La búsqueda de estas dos instancias de GUID implica que los documentos de control de Ramsay pueden ser elaborados deliberadamente con la capacidad de desplegar, en varias víctimas, la misma instancia de documento de control al aprovechar un GUID "global" dentro de los mismos. Por otro lado, los documentos de control pueden elaborarse incorporando un GUID específico destinado a ser entregado exclusivamente en la máquina de una sola víctima.

El protocolo de control de Ramsay admite tres comandos diferentes:

Tabla 3. Comandos de control de Ramsay

Después de que una firma de comando dada es recuperada, el artefacto contenido a ejecutar se extraerá dentro del cuerpo del documento de control para luego ser restaurado, modificando el asunto del documento de control a su forma original después de la ejecución del comando.

• Componente spreader

Entre los diferentes archivos eliminados por las últimas versiones de Ramsay, encontramos un componente spreader. Este ejecutable intentará buscar recursos compartidos de red y unidades extraíbles, excluyendo las unidades A: y B:

Figura 15. Salida Hex-Ray de las rutinas de exploración del spreader

Es importante notar que existe una correlación entre las unidades apuntadas que Ramsay escanea para la propagación y la recuperación de documentos de control. Esto evalúa la relación entre las capacidades de difusión y control de Ramsay mostrando cómo los operadores de Ramsay aprovechan el framework para el movimiento lateral, denotando la probabilidad de que este framework haya sido diseñado para operar dentro de redes air-gapped.

La técnica de propagación consiste principalmente en la infección de archivos como un infector de archivos prepender para generar ejecutables de estructura similar a los instaladores señuelo de Ramsay para cada archivo PE accesible dentro de las unidades objetivo anteriormente mencionadas. El siguiente diagrama ilustra los cambios aplicados a los ejecutables apuntados después de que la infección tuvo lugar y cómo estos componentes interactúan en la ejecución:

Figura 16. La estructura del archivo cambia durante una infección y ejecución

Todos los artefactos diferentes involucrados en la etapa de infección están dentro del contexto del spreader o han sido droppeados previamente por otro componente de Ramsay. Algunos de los artefactos son parseados para los siguientes tokens:

Figura 17. Salida de Hex-Ray de tokens para buscar diferentes artefactos dentro del contexto del spreader

Después de que un archivo determinado ha sido infectado, se marcará escribiendo un token específico al final para proporcionarle al spreader un identificador para evitar una infección redundante.

Además, algunos componentes de Ramsay han implementado un escáner de red destinado al descubrimiento de máquinas susceptibles a la vulnerabilidad EternalBlue SMBv1 dentro de la subred del host comprometido. Esta información estará contenida junto a toda la información registrada que Ramsay recopila y puede ser utilizada por los operadores para realizar, en una etapa posterior, un movimiento lateral sobre la red a través de un canal diferente.

Más observaciones

Se descubrió que el componente spreader de la versión 2.a de Ramsay había reutilizado una serie de tokens vistos anteriormente en el backdoor Retro de Darkhotel. Estas fichas son las siguientes:

Figura 18. Salida Hex-Rays de la reutilización de tokens con Retro

Figura 19. Reutilización de tokens en el diseño de URL de Retro

Ramsay serializa a las víctimas utilizando la API GetCurrentHwProfile para luego recuperar un GUID para la máquina específica de la víctima. Esto también se ve implementado en Retro. Ambos usan el mismo GUID predeterminado en caso de que falle la llamada a la API:

Figura 20. Generación de GUID de Ramsay y Retro

Tanto Ramsay como Retro comparten el mismo algoritmo de codificación para codificar el GUID recuperado.

Figura 21. Esquema de codificación de GUID de Ramsay y Retro

El GUID recuperado por GetCurrentHwProfile es específico para el hardware del sistema, pero no para el usuario o la instancia de PC. Por lo tanto, es probable que simplemente aprovechando este GUID, los operadores puedan encontrar duplicados destinados a serializar diferentes víctimas.

El propósito de este esquema es generar un GUID que es menos probable que sea propenso a duplicarse 'saltándolo' con la dirección ethernet de la máquina. Esto implica que Retro y Ramsay comparten el mismo esquema para generar identificadores únicos.

También encontramos similitudes en la forma en que Ramsay y Retro guardaron algunos de sus archivos de registro, compartiendo una convención de nombre de archivo similar:

Figura 22. Parte de la convención de nombres de archivo de Ramsay y Retro

Es importante resaltar que entre las técnicas documentadas de Retro, aprovecha las instancias maliciosas de msfte.dll, oci.dll y lame_enc.dll y a través de Phantom DLL Hijacking. Como se documentó anteriormente, Ramsay también utiliza esta técnica en algunas de sus versiones, que también utilizan msfte.dll y oci.dll.

Además, también observamos similitudes entre Ramsay y Retro en lo que respecta a las herramientas de código abierto utilizadas entre sus conjunto de herramientas, como son el aprovechamiento de UACMe para escalar privilegios y ImprovedReflectiveDLLInjection para implementar algunos de sus componentes.

Finalmente, notamos metadatos en coreano dentro de los documentos maliciosos utilizados por Ramsay, denotando el uso de templates en coreano.

Figura 23. Metadatos de documentos maliciosos que muestran la palabra "título" en coreano

Conclusión

A partir de las diferentes instancias del framework que hemos descubierto, Ramsay ha pasado por varias etapas de desarrollo, lo que denota una creciente progresión en el número y la complejidad de sus capacidades.

Los desarrolladores a cargo parecen estar probando varios enfoques, como los viejos exploits para las vulnerabilidades de Word de 2017, así como también implementando aplicaciones troyanizadas para ser utilizadas muy probablemente a través de ataques de spearphishing.

Interpretamos esto como que los desarrolladores tienen un conocimiento previo del entorno de las víctimas y están confeccionando vectores de ataque que puedan introducirse satisfactoriamente en los sistemas objetivo sin la necesidad de desperdiciar recursos innecesarios.

Algunas etapas del framework de Ramsay aún están bajo evaluación, lo que podría explicar la baja visibilidad actual de las víctimas, teniendo en cuenta que los objetivos de Ramsay pueden estar redes aisladas, lo que también afectaría a la visibilidad de las víctimas.

Continuaremos monitoreando las nuevas actividades de Ramsay y publicaremos información relevante en nuestro blog. Para cualquier consulta, contáctenos como threatintel@eset.com. Los indicadores de compromiso también se pueden encontrar en nuestro repositorio de GitHub.

Indicadores de Compromiso (IoCs)

Técnicas de MITRE ATT&CK