Hoy le informaremos sobre un nuevo enfoque para enviar malware al grupo Buhtrap.
Módulo de arranque
El 19 de diciembre, nos dimos cuenta de un correo malicioso que contenía un archivo ejecutable (
md5: faf833a1456e1bb85117d95c23892368 ). El archivo tomó varios nombres: "Reconciliación para December.exe", "Docs wednesday.exe", "Documentos 19.12.exe", "Documentos de cierre wednesday.exe".
Interesante: el archivo está escrito en .Net, lo que no es típico de este grupo criminal. Para descompilar .Net, puede tomar cualquier software:
Reflector ,
dotPeek ,
dnSpy ,
ILSpy . En el artículo hablaremos sobre las características de la implementación de este archivo y cómo lo analizamos.
Inspección inicial del cargador de arranque
Para el análisis, usamos
dnSpy , y todas las capturas de pantalla adicionales serán de él.
Por costumbre, abra el ejecutable en
IDA Pro y mire la sección de importación. Ejemplos:
La presencia de algunas funciones sugiere la presencia de una carga útil empaquetada (
LoadCursorW ,
LoadIconW - obtuvo el objeto de los recursos,
VirtualProtect - cambió los atributos de la página, luego puede ejecutar el código) y un simple anti-depuración (
IsDebuggerPresent ). Pero todo resultó ser aún más simple. La ejecución ni siquiera llegó a IsDebuggerPresent, y LoadCursorW y LoadIconW fueron inútiles porque intentaron acceder a recursos inexistentes (LoadCursorW desde "
fiza " y LoadIconW desde "
saxikulatebutohutejijobodugore "):
Pero volvamos al descompilador
dnSpy . En el archivo ejecutable, vemos una cantidad significativa de código no administrado:
Para comprender qué código no administrado está en el archivo bajo investigación, usaremos IDA Pro. La forma más fácil es ver el cuerpo del código no administrado en forma hexadecimal. Para hacer esto, vaya a la compensación de archivo de desplazamiento. Usando la función
_main () como ejemplo:
A continuación, en
IDA Pro, buscaremos por secuencia hexadecimal:
En la salida, obtenemos la función no administrada _main (), con la que puede trabajar convenientemente con la ayuda del descompilador de idv:
Obteniendo carga útil
De vuelta a dnSpy. Se llama la atención sobre la variable
payloadData .
Encontramos esta secuencia en IDA Pro, obtenemos enlaces a ella y descubrimos que la llamada ocurre solo en la función
_main () :
El código descompilado que usa este búfer se ve así:
Las siguientes funciones son responsables de convertir este búfer:
Aquí, la variable
holdrand se
inicializa a
0xEA48CB16 y la función
foo () se llama en un bucle para cada byte desde
payloadData (
parámetro sbyte c ). Cabe señalar que la función t () proviene de un código inseguro: si observa su código, puede asegurarse de que siempre devuelva
0x343FD .
Nos armamos con IDA Pro y, al observar el búfer desempaquetado resultante, notamos que contiene algo de código al principio:
En el desplazamiento
0x15A0 desde el comienzo del búfer, se encuentra un archivo ejecutable:
Guárdelo para su posterior análisis.
Bueno, en el código ejecutable en sí, se implementa algo bastante trivial. Primero, se forma la siguiente estructura (
aquí mz_base es la dirección de desplazamiento en el búfer con el PE desempaquetado, y los campos restantes son las direcciones de las funciones requeridas y los identificadores de la biblioteca ):
Y luego, utilizando las funciones obtenidas, se crea el proceso del mismo archivo ejecutable (
md5: faf833a1456e1bb85117d95c23892368 ), y el ejecutable desempaquetado se asigna a las direcciones virtuales del nuevo proceso. Después de cambiar la dirección de la instrucción ejecutable (
paquete GetThreadContext y
SetThreadContext ), se inicia el subproceso del nuevo proceso y se
elimina el proceso principal.
Bueno, ahora pasamos al análisis del archivo ejecutable resultante (carga útil).
Desempaque de carga útil
La carga útil (
volcado md5: d8f40c7060c44fab57df87ab709f058f ) también está escrita en .Net Framework.
Para protegerse contra el análisis estático y dinámico, los desarrolladores de
malware utilizaron el último protector
ConfuserEx popular:
ConfuserEx es un protector de código abierto bien establecido.
Desembalaje primario
El punto de entrada de los archivos protegidos por este protector es el siguiente:
Después del descifrado, la matriz de bytes se carga en la memoria en forma de un módulo llamado
koi . Luego se determina y se llama el método principal de este módulo. En la plataforma .Net, se puede obtener un método o constructor en un módulo a partir del token de metadatos llamando a la función
Module.ResolveMethod () . Para transferir el control al método obtenido, se utiliza la función
MethodBase.Invoke () .
El código ejecutable en el módulo
koi es el siguiente:
Para quitar la banda de rodadura, utilizamos las siguientes utilidades:
ConfuserEx-Unpacker descifró las líneas y el código dentro de los métodos, y
de4dot hizo que los nombres de los métodos
fueran legibles.
El resultado es un código adecuado para el análisis estático:
Por supuesto, tuvimos la suerte de obtener un código legible. Los creadores de virus pueden modificar el código fuente de la banda de rodadura de
ConfuserEx para complicar aún más el análisis.
Todavía hay dos problemas que tuvieron que resolverse para un análisis cómodo del archivo.
1er problema
Después de quitar la banda de rodadura, el descompilador no pudo analizar algunos de los métodos. Por ejemplo:
Si cambia al código IL, notará llamadas en punteros nulos:
Para corregir los errores de descompilación, reemplace las instrucciones incorrectas con instrucciones nop. (La utilidad
dnSpy le permite modificar tanto el código descompilado como el código IL).
Después del reemplazo, el código descompilado se ve correcto:
Cambiando el código IL en todos los métodos problemáticos, obtuvimos un archivo completamente descompilado.
2do problema
Es poco probable que se inicie el archivo resultante, y esto excluye la posibilidad de análisis dinámico. Para resolver este problema, debe especificar el token del método de entrada en la estructura del archivo ejecutable.
Puede encontrarlo de dos maneras:
- mire debajo de la depuración con qué parámetro se llamó la función
Module.ResolveMethod () antes de descomprimir el archivo:
- en el archivo desempaquetado, encuentre el método con la etiqueta [STAThread] :
En este caso, el token de metadatos para el método de entrada es
0x6000106 . Lo cambiamos usando la utilidad
CFF Explorer :
Después de guardar los cambios, se inicia el archivo desempaquetado y se depura correctamente.
Análisis del gestor de arranque
Inmediatamente después del inicio del trabajo, el gestor de arranque comprueba si se está ejecutando en un entorno virtual.
La ejecución bajo
VMWare o
QEMU se determina buscando las subcadenas "vmware" y "qemu" en el siguiente valor de registro:
- [HKLM \ System \ CurrentControlSet \ Services \ Disk \ Enum \ 0].
Si se detecta una máquina virtual, el gestor de arranque muestra el mensaje de la ventana correspondiente:
Curiosamente, la salida de este mensaje no afecta el funcionamiento del proceso.
Después de eso, el malware intenta cargar las bibliotecas de la siguiente lista en la memoria:
SbieDll.dll, dbghelp.dll, api_log.dll, dir_watch.dll, pstorec.dll, vmcheck.dll, wpespy.dll, snxhk.dll, guard32.dll .
Además, utilizando las llamadas a las funciones
Debugger.IsLogging () y
Debugger.get_IsAttached () , el cargador verifica si se está ejecutando bajo el depurador.
Si al menos una de las bibliotecas se carga correctamente o el cargador detecta que se está ejecutando bajo el depurador, se
eliminará automáticamente mediante el comando "
cmd / C ping 8.8.8.8 -n 1 -w 3000> Nul & Del ". Curiosamente, el gestor de arranque puede auto
borrarse incluso en un sistema real al cargar la biblioteca
dbghelp.dl l.
A continuación, el malware comprueba si se inicia desde el directorio que contiene la subcadena "Mozilla".
Si el proceso no se inicia desde el directorio que contiene la subcadena "Mozilla"
- El malware crea una lista de directorios que se encuentran en el escritorio y contiene las siguientes subcadenas (todas las líneas dentro del gestor de arranque se cifran con el algoritmo AES-256-ECB, las claves de cifrado se generan con contraseñas codificadas):
- Genera una lista de URL del historial del navegador que contiene las siguientes subcadenas:
- Genera una lista de archivos que se encuentran en los directorios "% UserProfile% \\ Desktop", "% AppData%", "C: \\ Program Files (x86)", "C: \\ Program Files (x86) (x86)" y tener los siguientes nombres:
- Cuenta el número de listas no vacías de los indicadores relacionados con las operaciones bancarias (en la versión actual del gestor de arranque, esta funcionalidad no afecta nada).
- Crea una tarea para ejecutar este archivo cada vez que un usuario inicia sesión con el comando "schtasks / create / f / sc ONLOGON / RL HIGHEST / tn LimeRAT-Admin / tr".
- Si no se pudo crear la tarea, crea el acceso directo "% AppData% \\ Microsoft \\ Windows \\ Menú Inicio \\ Programas \\ Inicio \\ MozillaUpdate.lnk", que indica "% Appdata% \\ Mozilla \\ xaudiodg.exe" , lo que garantiza que el archivo xaudiodg.exe se inicia cada vez que se reinicia el sistema.
- Se copia a lo largo de la ruta "% AppData% \\ Mozilla \\ xaudiodg.exe".
- Elimina el archivo <self_path>: Zone.Identifier, ejecuta xaudiodg.exe y se elimina automáticamente.
Si el proceso se inicia desde el directorio que contiene la subcadena "Mozilla"
- El malware también busca los indicadores anteriores de operaciones bancarias dentro del sistema infectado.
- Recopila otra información del sistema para enviarla al servidor de administración.
- En un hilo separado envía información a los C&C y espera una respuesta del servidor.
- En otro hilo, envía una cadena encriptada "PING?" Al servidor en un bucle sin fin.
Interacción del servidor de administración
La dirección IP del servidor en la muestra de malware probada es 213.252.244 [.] 200. La conexión se inicializa mediante un puerto seleccionado al azar de la lista:
• 8989,
• 5656,
• 2323.
Inmediatamente después de que se inicializa la conexión, el gestor de arranque envía información sobre el sistema infectado a los C&C:
• ID de usuario,
• nombre de usuario
• versión del sistema operativo,
• su propia versión (cargador v0.2.1),
• listas de indicadores de operaciones bancarias que se encuentran en el sistema infectado.
Un ejemplo de una línea enviada por el cargador al servidor de administración:
«INFO<NYANxCAT>9D3A4B22D21C<NYANxCAT>IEUser<NYANxCAT> Windows 7 Enterprise SP 1 <NYANxCAT>loader v0.2.1<NYANxCAT><NYANxCAT><NYANxCAT>1c, »
Esta línea se enviará si hay una carpeta "1c" en el escritorio del usuario infectado y no hay otros indicadores.
La función para procesar la respuesta del servidor es la siguiente:
La respuesta descifrada del servidor es la siguiente:
Como se puede ver en la captura de pantalla, COMMAND puede tomar uno de los siguientes valores:
- CERRAR : finaliza la conexión y cierra el proceso actual;
- DW : decodifica el contenido base64 de DATA2, lo escribe en el archivo <temp_file_name> con la extensión de DATA1 e inicia el archivo para su ejecución;
- ACTUALIZACIÓN : decodifica el contenido base64 de DATA1, lo escribe en un archivo con el nombre <temp_file_name> y la extensión .exe, inicia un nuevo archivo ejecutable y se borra solo;
- RD- - envía la cadena "RD-" en respuesta;
- RD + : envía una captura de pantalla al servidor de administración;
- DEL - se elimina automáticamente.
Durante la investigación del cargador de arranque, logramos obtener el comando DW del servidor atacante. Como resultado de esto, el software Punto Switcher se instaló con la DLL maliciosa winmm.dll (md5: 9d25553bb09e2785262b2f7ba7923605), que es un módulo de spyware Buhtrap.
TCP Stream es el siguiente:
Para cifrar los datos transmitidos entre el cliente y el servidor de administración, se utiliza el algoritmo
AES-128-ECB . La clave de cifrado se inicializa con una contraseña codificada.
Después del descifrado, el tráfico es el siguiente:
Desde base64, el instalador NSIS se decodifica con los siguientes contenidos:
Curiosamente, el servidor respondió, aunque la lista de indicadores bancarios estaba vacía.
DLL malicioso
La biblioteca
winmm.dll se ejecuta utilizando la técnica de secuestro de dll. El módulo malicioso envía información sobre el sistema infectado y una lista de lectores de tarjetas inteligentes activos a los C&C. Además, tiene un componente keylogger y puede recibir otros módulos maliciosos del servidor de gestión, ejecutarlos desde el disco o en la memoria del proceso actual. Los servidores C y C de la muestra en estudio se encuentran en las siguientes direcciones:
- hxxp: // my1cprovider [.] xyz: 6060 / klog [.] php
- hxxp: // tinderminderorli1999 [.] xyz: 7764 / klog [.] php
Conclusión
El proceso de infección se puede representar como el siguiente esquema:
A pesar de la buena protección contra el análisis, está claro que en este momento el gestor de arranque no funciona correctamente y es muy probable que esté en proceso de desarrollo:
- puede auto borrarse incluso en un sistema real;
- comprueba la conexión del sistema infectado con las operaciones bancarias antes de copiarse en "% AppData% \\ Mozilla \\ xaudiodg.exe" y antes de interactuar con C&C, pero no utiliza esta información de ninguna manera.
Finalmente, recuerda el extraño mensaje de la ventana. Curiosamente, ¿es esto una falla en los desarrolladores, o se hace específicamente para alentar a los usuarios a abandonar el entorno virtual y comenzar en una máquina real? Bienvenido en los comentarios.
COI
MD5:faf833a1456e1bb85117d95c23892368
9d25553bb09e2785262b2f7ba7923605URLs:hxxp: // my1cprovider [.] xyz: 6060 / klog [.] php
hxxp: // tinderminderorli1999 [.] xyz: 7764 / klog [.] php
IPs:
213.252.244 [.] 200