Cómo fortiedr protege contra microbackdoor

Consulta técnica sobre FortiEDR

Introducción

A principios de marzo, CERT-UA identificó una campaña de phishing dirigido a organizaciones gubernamentales dentro de Ucrania que resultó en el despliegue de la puerta trasera de código abierto ‘MicroBackdoor’. CERT-UA atribuyó esta campaña a UAC-0051/UNC1151/Ghostwriter sospechoso de estar alineado con el gobierno bielorruso. La campaña comienza con un archivo .zip titulado ‘reference.zip’ que contiene un archivo de ayuda HTML compilado de Microsoft (.chm) llamado ‘dovidka.chm’ (que se traduce como ‘ayuda’ en búlgaro). Este archivo de ayuda sirve como cargador de primera etapa que desempaqueta y ejecuta gradualmente una carga útil de MicroBackdoor que brinda al adversario acceso remoto a un punto final de la víctima. La cadena de ataque de este archivo de ayuda tiene una serie de capas que se visualizan en la Figura 1 a continuación.

Si bien la campaña de spear-phishing analizada en este artículo se centró en las víctimas ucranianas, este análisis tiene como objetivo proporcionar información sobre los TTP empleados en lugar de centrarse en la orientación y los resultados estratégicos asociados con esta campaña. Los TTP combinan un método de ejecución simple basado en phishing encadenado con el uso de una puerta trasera de código abierto, TTP que cualquier actor de amenazas podría reutilizar fácilmente, incluso con un bajo nivel de habilidad técnica.

Este artículo describe la cadena de ataque, así como una inmersión más técnica en las diversas capas de VBScript que conducen a la ejecución de la carga útil de MicroBackdoor, y observa cómo FortiEDR protege los endpoints de este malware.

Cadena de ataque

Figura 1 . Cadena de ataque UNC1151 MicroBackdoor

Ejecución inicial

Como se describió anteriormente, la cadena de ataque comienza con un correo electrónico que contiene un archivo zip. El archivo zip contiene un solo archivo de ayuda HTML compilado de Microsoft (.chm). Los archivos de este tipo contienen una serie de recursos internos almacenados en un formato HTML comprimido. El proceso de alojamiento para la ejecución del archivo .chm de forma predeterminada es el archivo ejecutable de ayuda HTML de Microsoft® o ‘hh.exe’, que reside en ‘C:Windowshh.exe’ de forma predeterminada. Este ejecutable de ayuda HTML es un binario de Microsoft firmado y MITRE rastrea el uso de este ejecutable para la ejecución de proxy como ‘T1218.001 – Ejecución de proxy binario del sistema: archivo HTML compilado’. La figura 2 a continuación muestra los archivos incrustados en el documento chm. De la lista de archivos, concéntrese en el ‘archivo.htm’ que contiene el VBScript de etapa inicial que se ejecutará cuando se abra el archivo.

Figura 2 . archivos dentro del archivo chm

Una vez que se abre el archivo .chm de muestra (dovidka.chm), el proceso de hosting hh.exe escribirá y mostrará el documento señuelo ‘image.jpg’ en una ventana de ayuda como se muestra en la Figura 2 a continuación. El documento señuelo contiene información relacionada con ‘Información sobre el procedimiento para frecuentes bombardeos de artillería’ y contiene varias insignias del gobierno de Ucrania.

 Figura 3 . Documento/imagen de señuelo mostrado al abrir el archivo chm. Tenga en cuenta que la imagen se muestra como parte de una ventana de ayuda predeterminada.

El ‘file.htm’ contiene VBScript ofuscado que genera un archivo VBScript de segunda etapa llamado ‘ignit.vbs’ y lo coloca en la carpeta ‘C:UsersPublic’. La siguiente figura (Figura 4) muestra algunos de los VBScript ofuscados dentro de ‘file.htm’. La primera función definida en VBScript (‘oollllo1l0’) es el descifrador de primera etapa para el resto del código.

 Figura 4 . VBScript contenido en el archivo ‘file.htm’ incrustado en el archivo de ayuda compilado ‘dovidka.chm’. La primera función vista en este ejemplo es el descifrador de primera etapa (‘oollllo1l0’).

Ejecutar la función de descifrado produce el código VBScript más legible que se muestra en la Figura 5 a continuación. El VBScript busca un archivo ‘C:UsersPublicFavouritesdesktop.ini’ y, si está presente, descarta el archivo VBScript de la segunda etapa, ‘ignit.vbs’, y lo ejecuta junto con el VBScript dentro del ‘escritorio’ mencionado anteriormente. archivo .ini’.

Figura 5 . Versión descifrada del VBScript de primera etapa contenido en el archivo ‘file.htm’ incrustado en el archivo de ayuda compilado ‘dovidka.chm’. Tenga en cuenta las llamadas para ejecutar los archivos ‘ignit.vbs’ y ‘desktop.ini’.

VBscript de segunda etapa – ignit.vbs

La segunda etapa de VBScript contiene varias funciones, y la mayoría de ellas se utilizan para descifrar/Desofuscar ejecutables incrustados y cargas útiles de VBScript adicionales. Una muestra del VBScript contenido en el archivo ‘ignit.vbs’ se muestra a continuación en la Figura 6.

 Figura 6 . Extracto de VBScript tomado del archivo ‘ignit.vbs’ descartado luego de la ejecución de ‘dovidka.chm’. Tenga en cuenta la ruta de la cadena invertida que describe uno de los archivos que escribirá en la ejecución

Al ejecutar este VBScript de segunda etapa, ‘ignit.vbs’ genera y suelta los siguientes archivos: ‘c:UsErspUbLIcLIbRARiEScore.dll’, ‘(Carpeta de inicio)Windows Prefetch.lNk’ y ‘C: USUARIOSPÚBLICOFAVORITOSdesktop.ini’. FortiEDR detecta la ejecución de este archivo VBScript como un evento de ‘Ejecución de secuencia de comandos sospechosa’ a pesar de su ejecución de proxy desde el ejecutable ‘hh.exe’ firmado. Esta detección evitaría que el script ‘ignit.vbs’ de la segunda etapa se ejecute y escriba sus cargas útiles incrustadas en el disco. A continuación, en la Figura 7, se muestra una instantánea del evento de seguridad de FortiEDR relacionado.

Figura 7 . FortiEDR detecta la ejecución anómala de VBScript ‘ignit.vbs’. Esta actividad se bloquearía en el modo ‘Proteger’ evitando que este ataque progrese.

Cargador MicroBackdoor – core.dll

El primer archivo generado y eliminado de ‘ignit.vbs’ es ‘c:UsErspUbLIcLIbRARiEScore.dll’, que es un binario .NET que actúa como un cargador para la carga útil final de MicroBackdoor. Este cargador se crea a partir de matrices de 5 caracteres dentro del script ‘ignit.vbs’ que se decodifica mediante la función ‘RvsJvhGamf5XD’ que se muestra a continuación en la Figura 8.

 Figura 8 . Función interna dentro del archivo ‘ignit.vbs’ que reconstruye y suelta el ejecutable ‘core.dll’ en el directorio ‘c:UsErspUbLIcLIbRARiES’.

El core.dll es un ejecutable .NET que contiene una copia cifrada del código del lado del cliente para MicroBackdoor que contiene un dominio C2 codificado. Cuando se ejecuta core.dll, descifra la carga útil incrustada de MicroBackdoor, la carga reflexivamente en la memoria y la ejecuta directamente. La carga útil cifrada se puede ver en la Figura 9 a continuación almacenada como varios recursos dentro del ejecutable core.dll.

Figura 9 . Código parcial del ejecutable .NET ‘core.dll’ que muestra partes de la carga útil cifrada de MicroBackdoor que se descifra, carga y ejecuta en tiempo de ejecución.

MicroBackdoor es una puerta trasera de código abierto escrita por Dmytro Oleksiuk, también conocido como ‘Cr4sh’. El proyecto de código abierto ( https://github.com/Cr4sh/MicroBackdoor ) tiene componentes de cliente y servidor disponibles en GitHub. El ejecutable no asignado cargado por core.dll es el mismo que el código de ejemplo de client.dll disponible a través de la página principal de proyectos de GitHub. Las siguientes figuras muestran un código similar del ejecutable no asignado cargado por core.dll y el client.dll original de MicroBackdoor tomado de su página de GitHub. La Figura 10 muestra una llamada a las API gethostbyname e inet_addr para obtener la dirección de Internet del servidor C2, ‘xbeta[.]online’. La Figura 11 muestra las conexiones reales a ‘xbeta[.]online’ utilizando la dirección IP equivalente (194[.]195.211.98).

 Figura 10 . Comparación de código entre el ejecutable no asignado cargado por core.dll y el MicroBackdoor client.dll original

Figura 11 . Otra comparación de código entre el ejecutable no asignado cargado por core.dll y el MicroBackdoor client.dll original.

VBScript de tercera etapa – desktop.ini

Otro archivo generado y soltado por ‘ignit.vbs’ es ‘C:usErspuBLICfAVORIteSdesktop.ini’. Este archivo contiene un tercer VBScript que eventualmente se usa para ejecutar el microbackdoor, ‘core.dll’. Desktop.ini VBScript ejecuta el archivo core.dll a través de la herramienta de registro de ensamblaje (regasm.exe), otro binario de Windows utilizado para la ejecución de proxy, esta vez para ejecutables .NET (seguido por MITRE como T1218.009 – Ejecución de proxy binario del sistema: Regsvcs/Regasmo). La Figura 12 a continuación muestra las funciones dentro de ‘ignit.vbs’ que generan el archivo ‘desktop.ini’, mientras que la Figura 13 muestra el contenido de ‘desktop.ini’ que finalmente llama a regasm.exe.

 Figura 12 . Código dentro de ‘ignit.vbs’ que decodifica y crea el VBScript de tercera etapa ‘desktop.ini’.

Figura 13 . Contenido del archivo ‘desktop.ini’ que muestra instrucciones para ejecutar core.dll.

FortiEDR detecta y bloquea la ejecución del VBScript de tercera etapa, ‘desktop.ini’, como se muestra en la Figura 14 a continuación.

Figura 14 . Eventos de seguridad de FortiEDR generados como resultado de la ejecución de VBScript ‘desktop.ini’. FortiEDR detectará y bloqueará este comportamiento de forma inmediata (políticas predeterminadas).

Como se destacó arriba, ‘Desktop.ini’, ejecuta regasm.exe para ejecutar ‘core.dll’, el cargador MicroBackdoor. FortiEDR detecta y bloquea esta ejecución de proxy del ejecutable .NET ‘core.dll’ del proceso wscript como un evento de ‘Ejecución de secuencia de comandos sospechosa’, como se muestra en la Figura 15 a continuación.

 Figura 15 . ForitEDR detecta la ejecución del proxy ‘regasm.exe’ desde wscript. FortiEDR detectará y bloqueará este comportamiento de forma inmediata (políticas predeterminadas).

Luego de la carga exitosa del cliente MicroBackdoor en el proceso del host regasm, MicroBackdoor intenta conectarse a su servidor C2 para comando y control. La muestra de MicroBackdoor analizada en este artículo contenía un solo dominio codificado de forma rígida ‘xbeta[.]online’ como su C2. FortiEDR detecta y bloquea los intentos del cliente MicroBackdoor no asignado de establecer una conexión de red con este dominio C2, como se muestra en la Figura 16 a continuación.

 Figura 16 . Evento de seguridad de FortiEDR relacionado con el ejecutable no asignado (ejecución de MicroBackdoor ‘regasm.exe’ desencadenada por el VBscript que se conecta al servidor C2

El dominio ‘xbeta[.]online’ actualmente se resuelve en la dirección IP ‘194[.]195.211.98’. Es probable que la dirección IP sea diferente al momento de escribir este artículo, ya que ha cambiado varias veces desde que CERT-UA informó por primera vez.

El Sistema de amenazas central (CTS) de FortiGuard muestra que ‘xbeta[.]online’ está relacionado con Ghostwriter/UNC1151, como se muestra en la siguiente figura.

Figura 17 . CTS que muestra la inteligencia de amenazas de FortiGuard relacionada con el dominio ‘xbeta[.]online’.

Cuarta etapa: ‘Windows Prefetch.lNk’

La tercera etapa de VBscript, ‘desktop.ini’, se ejecuta a través del archivo de acceso directo ‘Windows Prefetch.lNk’, que se colocó en la carpeta de inicio de Windows. Esta es una forma de persistencia rastreada por MITRE como T1547.001 – Ejecución de inicio automático de inicio o inicio de sesión: claves de ejecución del registro/carpeta de inicio’. Siempre que la computadora se reinicie, se ejecutarán los ejecutables y los enlaces de acceso directo que se encuentran en la carpeta Inicio.

Mirando hacia atrás en la Figura 5, se puede ver que cuando el archivo chm original ejecuta el VBScript inicial, activará la ejecución de la última etapa del VBScript, ‘desktop.ini’. Después de esta ejecución inicial, la ubicación de ‘Windows Prefetch.lNk’ en la carpeta de inicio de Windows garantizará que la puerta trasera se reinicie cuando se reinicie el extremo de la víctima.

La Figura 18 a continuación muestra las funciones que generan ‘Windows Prefetch.lNk’.

 Figura 18 . VBScript dentro de ‘ignit.vbs’ que genera y suelta ‘Windows Prefetch.lNk’ en el directorio de inicio de Windows para persistencia.

La siguiente figura muestra el uso del campo de destino del archivo lnk para ejecutar el VBScript contenido en el archivo ‘desktop.ini’. En los últimos meses, esta técnica ha ganado popularidad y se emplea como parte de las nuevas campañas de Bumblebee y Emotet en todo el mundo. Se espera que la prevalencia de este TTP que se usa para ejecutar cargas útiles continúe creciendo y puede convertirse en el principal método de ejecución para campañas de phishing a medida que Microsoft avanza para bloquear la ejecución de macros de forma predeterminada en Windows 11.

 Figura 19 . Propiedades del archivo ‘Windows Prefetch.lNk’ utilizado para la persistencia como parte de esta campaña. Observe que el campo ‘Objetivo’ contiene instrucciones para ejecutar el contenido de ‘desktop.ini’ como VBScript.

Caza de amenazas

Para buscar la creación del VBscript de segunda etapa, ‘ignit.vbs’:

Type: ("File Create") AND Target.File.Path: ("Users\Public") AND Target.File.Name: ("ignit.vbs")

Para buscar la creación del VBscript de la tercera etapa, “desktop.ini”:

Type: ("File Create") AND Source.Process.Name: ("wscript.exe") AND Target.File.Path: ("Users\Public\Favorites") AND Target.File.Name: ("desktop.ini")

Para buscar la creación del microbackdoor, “core.dll”:

Type: ("File Create") AND Source.Process.Name: ("wscript.exe") AND Target.File.Path: ("Users\Public\Libraries") AND Target.File.Name: ("core.dll")

Para buscar la creación de ‘Windows Prefetch.lNk’ en la carpeta de inicio:

Type: ("File Create") AND Source.Process.Name: ("wscript.exe")  AND Target.File.Path: ("Startup") AND Target.File.Name: ("Windows Prefetch.lNk")

Para buscar hh.exe generando wscript.exe para ejecutar desktop.ini:

Type: ("Process Creation") AND Source.Process.Name: ("hh.exe") AND Target.Process.File.Name: ("wscript.exe") AND Target.Process.CommandLine: ("//B //E:vbs C:\Users\Public\Favorites\desktop.ini")

Para buscar hh.exe generando wscript.exe para ejecutar desktop.ini o cualquier archivo vbs:

Type: ("Process Creation") AND Source.Process.Name: ("hh.exe") AND Target.Process.File.Name: ("wscript.exe")

Para buscar hh.exe creando archivos vbs o img (ignit.vbs o image.jpg):

Type: ("File Create") AND Source.Process.Name: ("hh.exe") AND Target.File.Ext:("vbs" or "jpg")

Para buscar la conexión al servidor C2:

Type: ("Socket Connect") AND Source.Process.Name: ("RegAsm.exe") AND Source.Process.CommandLine: ("/U C:\Users\Public\Libraries\core.dll") AND RemoteIP: ("194.195.211.98")

Para buscar la carga de la biblioteca «core.dll» usando regasm.exe:

Type: ("Library Loaded") AND Source.Process.Name: ("RegAsm.exe") AND Source.Process.CommandLine: ("/U C:\Users\Public\Libraries\core.dll") AND Target.Executable.File.Name: ("core.dll") AND Target.Executable.File.Path: ("Users\Public\Libraries")

Para buscar regasm.exe generando conhost.exe para ejecutar core.dll:

Type: ("Process Creation") AND Source.Process.Name: ("RegAsm.exe") AND Target.Process.File.Name: ("conhost.exe") AND Source.Process.CommandLine: ("/U C:\Users\Public\Libraries\core.dll")

MITRE ATT&CK

TA0001 – Acceso Inicial

TA0002 – Ejecución

TA0003 – Persistencia

TA0005 – Evasión de defensa

TA0011 – Comando y Control

COI

¡Déjanos cualquier duda sobre FortiEDR aquí abajo!

Mila y César

Hola, somos Mila Jiménez y César Sánchez. Dos apasionados de la ciberseguridad con muchos años de experiencia. Hemos trabajado en muchas empresas del mundo TI y ahora nos apetece compartir nuestro conocimiento con cualquiera que lo necesite.

¡Si te gusta nuestro contenido puedes invitarnos a un café AQUÍ!