La nueva variante utiliza esteganografía y carga en memoria de múltiples etapas para robar datos


Quick Heal Security Lab ha visto un aumento repentino en las muestras de dotnet que utilizan esteganografía. Inicialmente, en el análisis estático, no se dispone de mucha información. Se parece a una aplicación sencilla que se llama método. En el lado dinámico, algunos muestran la actividad pero otro cheque para el entorno de sandboxing. Aparte de esto, incluso en ejecución, carga múltiples etapas de memoria que contienen numerosos períodos largos de sueño. Uno de esos archivos recibidos en nuestro laboratorio fue de malware Formbook. El ladrón de Formbook se ha vendido en formularios de piratería desde 2016 como servicio.

En este blog, pasaremos por esas múltiples etapas y analizaremos la carga útil final. La carga útil final también es complicada debido a la creación de varios subprocesos y los períodos de inactividad intermedios.

Análisis técnico

SSO.exe

En el recurso de sso.exe, hay una imagen que indica el uso de esteganografía. Sin embargo, este recurso no se utiliza en este nivel. Hay un recurso más presente que inicialmente es difícil de encontrar. Mientras revisaba el código de descifrado, este segundo recurso se identificó como la etapa 1.

Figura 1 GregorianCalendar en Resource, contiene el archivo de la etapa 2

Figura 2 Otro árbol de nombres de recursos, justo debajo de la línea azul hay algunos puntos rojos visibles, contiene el archivo de la etapa 1

En el punto de entrada, hay un código de una sola línea para ejecutar el formulario.

Figura 3 Función principal, llama al constructor de Form1 que descifra el archivo de la etapa 1

Si vamos al código Form1, no hay mucha información presente. Pero cuando revisamos la clase Form1, podemos ver en su constructor una llamada al método ISectionEntry.

Figura 4 Código de constructor, llamada a la rutina de descifrado del archivo de la etapa 1

ISectionEntry contiene el código para obtener píxeles (Fig. 5), convertirlo a entero y guardarlo en una matriz (Fig. 6) y luego llamar a MessageSurrogateFilter (matriz) con el búfer pasado como parámetro.

Figura 5 Rutina de descifrado de la imagen, descifrado del archivo PE de la etapa 1

Figura 6 Búfer que contiene el archivo PE de la etapa 1

El método MessageSurrogateFilter () luego carga el ensamblado descifrado (SimpleUI.dll) en la memoria e invoca su método SeclectorX () con algunos argumentos, que se explicarán más adelante en la Etapa 1.

Figura 7 Ensamblando Carga de la etapa 1 en la memoria e invocando a su miembro SelectorX con el nombre del recurso, la clave de descifrado y el nombre del ensamblado

Figura 8 SimpleUI.dll cargado en memoria

Nivel 1:

Figura 9 SimpleUI.dll

  • Dado que no hay muchos métodos presentes en este archivo, revisamos directamente el código del método SelectorX. Como podemos ver en la Figura 7, hay tres valores pasados ​​a esta función que son:
  • RestrictedError = 477265676F7269616E43616C656E646172 = GregorianCalendar (Nombre del recurso en el archivo principal, el recurso se muestra en la figura 1)
  • ValueEnumerator = 72584C4F594D6D556D = rXLOYMmUm (Clave para descifrar)
  • Nombre del proyecto = Agente común (archivo principal)
  • El método cba () contiene el código para obtener los píxeles de la imagen y convertirlos a Integer y guardarlos en una matriz, y XeH contiene código para convertir el valor hexadecimal en una cadena.

Figura 10 El método SelectorX accede al recurso GregorianCalendar desde el ensamblado principal y lo descifra usando la clave pasada bajo el método fgh ()

Figura 11 Tamaño del búfer que se inicializará para la etapa 2

La rutina de descifrado del método fgh () es un XOR simple con 2 valores en los que la matriz de "bytes" contiene una versión Unicode de la clave (mencionada como ValueEnumerator más arriba).

Figura 12 código del método fgh () para el descifrado, xoring normal

Después del descifrado, el ensamblaje se vuelve a cargar en la memoria.

Figura 13 Ensamblaje de la etapa 2 cargado en la memoria

Etapa 2:

Figura 14 Montaje de la etapa 2

Se vuelve difícil de analizar con estos nombres de función sin codificar.

Figura 15 Nombres de métodos Unicode de Stage2

En este ensamblado de la etapa 2, se llama a un método llamado Fedree (), cuyo constructor contiene el código para descifrar e inyectar la carga útil final.

En la rutina de descifrado primero, el nombre del recurso se descifra a s2pCN (recurso en la etapa 2), carga el recurso y lo pasa al XOR_DEC junto con una CLAVE. El búfer descifrado se pasa luego a la función Descifrar donde trae otro archivo dotnet.

Figura 16 Rutina de descifrado en la Etapa 2 que trae la carga útil final

XOR_DEC contiene xor simple con código ofuscado.

Figura 17 El método Xor_Dec descifra la carga útil final

La función de descifrado forma la carga útil final.

Figura 18 El código del método de descifrado trae el archivo PE de carga útil final

Después del descifrado, procesa el vaciado creando el proceso de sso.exe en modo suspendido.

Figura 19 Procesar código hueco para inyectar la carga útil final

Figura 20 Bandera para CreateProcess en modo suspendido

Carga útil final:

El archivo inyectado es la carga útil final de Formbook, que tiene alrededor de 1500 métodos con nombres aleatorios.

Contiene 2 cadenas codificadas en Base64 diferentes.

Figura 21 La cadena codificada 1 contiene información y configuración de CnC

2Dakota del Norte La cadena base64 contiene 5 módulos que luego se cargan en la memoria y se ejecutan.

Figura 22 Cadena codificada 2

Las cadenas se convierten de base64, luego se invierten y se reemplazan por caracteres especificados y nuevamente se decodifican en base64.

Figura 23 Rutina de descifrado para descifrar detalles de CnC en la cadena 1 y diferentes módulos presentes en la cadena 2

Los datos resultantes para 1S t La cadena decodificada es servidores CnC, nombre de mutex y algunas configuraciones.

Figura 24 Datos decodificados de la cadena 1

También crea un archivo bat para comprobar la conexión de red y volver a iniciar el proceso y eliminar el archivo bat.

Figura 25 Contenido del archivo Bat

Después de descifrar los datos, busca el mutex, si ya está presente, sale. En la configuración, el valor de la etiqueta "AUR" es verdadero, toma 2 nombres de procesos en ejecución, de 1 toma el nombre del proceso, de la otra toma cualquier nombre de carpeta del directorio principal y se copia a sí mismo en esta ubicación con el primer proceso nombre. Junto con esto, mantiene un archivo con un nombre como un hash del nombre del proceso y algunos datos basura generados aleatoriamente.

Figura 26 Se copia a sí misma en varias ubicaciones obtenidas de la ruta de los procesos en ejecución y también obtiene el nombre de la misma

También programa tareas para estos archivos copiados.

Figura 27 Crea una tarea de programación para los archivos copiados

A continuación, carga diferentes módulos que ha decodificado inicialmente y los carga en la memoria e invoca diferentes métodos.

Figura 28 código para cargar diferentes módulos y llamar a diferentes métodos según su disponibilidad

Luego intenta robar información del navegador como cookies, contraseñas, formularios, historial, autocompletar, la información de la tarjeta de crédito también toma capturas de pantalla, datos del portapapeles, tokens de discordia, FileZilla, datos de telegramas, tokens de discordia, datos de Steam.

También había un módulo que compilaría el código para DCRat en tiempo de ejecución al recibir comandos de CnC.

Figura 29 Código para compilar código DCRat en tiempo de ejecución

Otros módulos diferentes presentes son:

  1. Módulo anti-análisis

Ha mantenido todas las cadenas en forma encriptada bajo una lista de varias técnicas.

Figura 30 Valores codificados para cadenas utilizadas en el módulo antanálisis

Contiene varias técnicas para identificar si se está ejecutando en un entorno de VM o Sandboxing si hay algún proceso de monitoreo en ejecución. Además, una forma de identificar VM / Sandboxing es verificando la memoria física.

Figura 31 Módulo anti-análisis

  1. Módulo USBSpreadDCLIB

Contiene código para propagarse a unidades USB mediante la creación de una ejecución automática.

Figura 32 Módulo USBSPreadDCLIB

  1. MisceláneaInfoGraber módulo

Contiene código para recopilar una lista de software instalado, procesos en ejecución, información de zona horaria, conexiones TCP activas, conexiones de red local disponibles, lista de unidades USB conectadas.

Figura 33 Recopila el registro para desinstalar entradas

Figura 34 Lista de procesos en ejecución

Figura 35 Información de la zona horaria

  1. Módulo FileGrabber

Recoge todos los archivos

Figura 36 Los módulos de captura de archivos recopilan archivos

  1. Módulo de protección BSOD

En este punto, este módulo no se encuentra en un estado completo. Esto muestra que todavía está en desarrollo.

Conclusión:

Este parece ser un malware que aún se está desarrollando. Aún no hemos recibido Initial Vector, pero parece que lo descarga un archivo doc / Xls malicioso, que se propaga a través de correos electrónicos. Los usuarios deben evitar abrir correos electrónicos, documentos enviados por remitentes desconocidos y mantener actualizado el AV. Detectamos todos los módulos y etapas con Trojan.Formbook y Trojan.YakbeexMSIL.ZZ4

MITRE ATT & CK TTP:

Virtualización / Evasión de espacio aislado: comprobaciones del sistema T1497.001
Tarea / trabajo programado T1053
Inyección de proceso: Proceso de vaciado T1055.012
Mascarada T1036
Credenciales de almacenes de contraseñas T1555
Datos del portapapeles T1115
Datos del repositorio de configuración T1602

COI:

  • 1D13A84AA671B75F66F4C7FCE8339619291D4A43 exe
  • 6C73DC53F1AF57E1B2B404F2E20A9AECBAA80051 dll
  • DC7CF9544AA5B4928697B4C49C94A60211F025A1 dll
  • 9577B2B5C4FBA6B2AFA65C5161FCE75F48E75D5D dll
  • 7E314AE69FC9A613A4A5356556F73E027B540141 dll
  • 32D97D1729D9A5919CBE1AE76F46BCDB9620153C dll

Rumana Siddiqui



Enlace a la noticia original