Seguir recursos, métodos y llamadas de un binario administrado para describir su comportamiento.
Notas de la práctica
Las capturas corresponden al análisis original del autor. Puedes seguir la lectura del código y las evidencias desde esta página. El trabajo dinámico con muestras requiere un laboratorio Windows separado del equipo de uso habitual.
Prepara el análisis con el agente
Comparte esta lección y sus evidencias con tu agente. Pídele que te ayude a organizar la lectura y que justifique cada conclusión con una observación concreta.
Estoy estudiando «Ziraat: análisis de malware .NET» del curso de Lobera. Ayúdame a interpretar las funciones, estructuras y capturas de esta lección. Distingue las observaciones del caso de las hipótesis y cita la evidencia que sostiene cada conclusión.
El análisis se apoya en las evidencias disponibles para este caso. Preparación y funcionamiento.
Dado el interés que ha generado este curso de reversing con radare2, continuaré profundizando en el análisis de malware, un campo extenso donde las habilidades de reversing son fundamentales. Empezaremos desde los conceptos más básicos e iremos subiendo el nivel. Usaremos las herramientas de la FLARE-VM de MANDIANT junto con radare2 en Windows 10. Comenzaremos con herramientas de código abierto orientadas a extraer información general del malware e IoCs, y después pasaremos a radare2 para el reversing más intensivo. En las dos o tres primeras partes no usaremos r2 demasiado; la dificultad irá aumentando progresivamente.
Repasemos un par de conceptos generales: análisis estático y análisis dinámico. El análisis estático consiste en examinar el programa sin ejecutarlo libremente. En este tipo de análisis nos centraremos en el desensamblado del programa, tratando de entender sus algoritmos, las acciones que realiza y detectar firmas relevantes. En general buscaremos:
- Sus capacidades (¿qué puede hacer?)
- Ficheros que pueda soltar o descargar
- Ficheros que pueda crear
- Mecanismos de mando y control
- Sus algoritmos
- Cualquier IoC relevante que podamos obtener
Usaremos esa información para evaluar el riesgo e intentar articular una respuesta o defensa.
El análisis dinámico, en cambio, consiste en dejar que el programa se ejecute y examinar las acciones que realiza en la máquina: el tráfico de red que genera, los ficheros y claves de registro que crea, y acciones similares.
Introducción al análisis estático
El caso documenta el análisis estático de un stealer para Windows escrito en C#. Seguiremos sus funciones de captura de datos, las comunicaciones con el servidor y los binarios que incorpora.
Como el malware que vamos a analizar está escrito en C#, podemos usar la herramienta DNSPY, incluida en la FLARE-VM de Windows. Primero, hacemos clic derecho sobre el ejecutable (o usamos rabin2 -i) para comprobar que el malware es x32; después lo arrastramos a dnspy (x86) para empezar el análisis:
Nos movemos a ziraat_limpi (información del programa) y vemos la siguiente información básica:
"MiniTool Power Data Recovery". Con esto ya podemos intuir que el programa intenta hacerse pasar por una herramienta de soporte técnico o recuperación de datos. Podemos saltar ahora a "GonnyCam.Main", la función de entrada.
El programa arranca directamente con un keylogger que funciona mediante hooks de teclado. Si bajamos un poco, veremos el "main" del programa:
En Main() identificamos claramente un conjunto de hilos paralelos que el programa lanza. Por esta estructura podemos pensar que los autores usaron algún tipo de plantilla para escribir la aplicación. Conviene prestar atención a varios hilos: RecordKeys, ClipboardLogging, ScreenLogging, DownloadAndExecute, ExecuteBindedFiles y, especialmente, PasswordRecovery.
También podemos mirar el panel izquierdo de dnspy y revisar las funciones del programa. Encontraremos algo interesante:
Hay una función concreta que ha sido ofuscada para dificultar el análisis; la anotamos porque será relevante más adelante. También detectamos un par de recursos interesantes adjuntos al programa:
Si intentamos examinarlos, veremos que parecen estar cifrados:
Lo anotamos y volvemos al bucle principal. Veremos que la mayoría de los hilos del bucle principal están vacíos, lo que confirma la hipótesis de que el programa se creó a partir de algún tipo de plantilla:
La funcionalidad de keylogger
Si nos movemos a GetCurrentWindow, vemos cómo entra en juego el keylogger:
Básicamente detecta si hay una ventana activa y empieza a registrar sus datos: título de la ventana, hora y pulsaciones de teclas para esa ventana. Probablemente para capturar contraseñas y datos privados sabiendo si la víctima está navegando en un banco, una red social o cualquier otra aplicación de interés. También vemos un KeyStrokeLog. Vamos a seguirlo buscando dónde se referencia:
Siguiéndolo en el programa, vemos que se envía a SendLog(). ¿Qué es eso? Veámoslo:
Servidor de mando y control
Empieza con un WebClient, referencia un "Link" y construye lo que parece una petición POST. Es el módulo del programa encargado de la comunicación con el servidor de mando y control (C2).
También vemos que puede realizar distintas llamadas al servidor según si la petición está relacionada con el envío de una contraseña, el portapapeles, las pulsaciones de teclado u otros datos.
¿Y a dónde lo envía?
Siguiendo "P_link" en el código, identificamos rápidamente el sitio web "ziraat-helpdesk". Esa es la URL del servidor de mando y control.
Más allá del hilo del keylogger, identificamos otros hilos interesantes como ClipboardLogging. Este detecta si el portapapeles tiene contenido y, si es así, usa SendLog para enviarlo:
Extracción de contraseñas
Y el hilo más interesante, PasswordRecovery:
En este punto podemos deducir fácilmente que intenta extraer credenciales de servicios como Outlook, ThunderBird y similares, así como contraseñas de los navegadores más populares como Chrome o Firefox, aplicaciones de descarga como Filezilla o JDownloader, y redes sociales como PalTalk (popular en Turquía).
Siguiendo las acciones realizadas por la llamada de recuperación de correo, llegamos a la función ReadMail().
Si la examinamos, vemos algo parecido a la recuperación de una clave junto con una llamada a una función extraña y GetExecutingAssembly, una función que puede usarse para ejecutar un programa desde memoria. En este punto podemos intuir que el programa podría descifrar algún bloque de datos —shellcode o un malware secundario— y ejecutarlo. También vemos una referencia a "RecoverMail".
El código está ofuscado en este punto; podemos desofuscarlo usando de4dot.exe, que desofusca la mayor parte del código C#.
Ofuscación y binarios embebidos
Volviendo al código en su versión limpia, vemos RSMDecrypt. Tenemos nueva evidencia para nuestra hipótesis.
Analizando RSMDecrypt vemos que básicamente descifra el bloque mediante AES y lo devuelve como un array de bytes. Podemos colocar un breakpoint ahí para ver qué descifra exactamente y, si es posible, volcarlo al disco y analizarlo con r2.
Colocando el breakpoint y ejecutando, vemos algo que parece un PE de Windows (fíjate en los bytes 0x4D, 0x5A, los bytes mágicos MZ). Podemos inspeccionar el volcado de memoria haciendo clic derecho y seleccionando "show memory region".
Efectivamente lo es. Podemos seleccionar toda la región de memoria y guardarla en un fichero:
Ahora podemos abrir ese exe en radare2 para, por ejemplo, inspeccionar las cadenas y descubrir rápidamente referencias a servicios de correo y contraseñas:
Enseguida empiezan a aparecer referencias a "NirSoft":
Confirmado también por rabin2:
En este punto podríamos hacer reversing de este exe, pero basta con visitar el sitio web de NirSoft para comprobar que se trata de una herramienta de recuperación de contraseñas y correo que ha sido embebida dentro de este malware para ser invocada y enviar esos datos al servidor C2 junto con las pulsaciones de teclado y el contenido del portapapeles.
Si continuamos, descubriremos que lo mismo ocurre con la llamada "passwordrecover": vuelca otro programa de NirSoft y lo llama. Otras llamadas recuperan información personal de forma más directa copiando ficheros del disco o leyendo claves de registro.
Conclusiones
El programa, al que llamaremos "ziraat_stealer", comienza instalando un keylogger mediante hooks de teclado; esa información se envía a un servidor de mando y control identificado en "ziraat-helpdesk", junto con el título de la ventana donde el usuario escribe. También monitoriza el portapapeles y envía su contenido al C2. El malware intenta acceder a los datos de correo y contraseñas almacenados en servicios populares como ThunderBird, Outlook, Chrome, Firefox, Internet Explorer o Safari, entre otros. Para ello utiliza herramientas de recuperación de contraseñas y correo de la empresa NirSoft, que están cifradas y embebidas dentro del ejecutable, y que se descifran y ejecutan en memoria al arrancar para evitar su detección. El malware también intenta recuperar datos de aplicaciones de descarga populares y redes sociales.
El hecho de que intente recuperar datos de PalTalk, una aplicación muy popular en Turquía, y de que suplante el tráfico del "Ziraat Bank" (un banco agrícola turco), apunta a que este malware puede haber sido utilizado en campañas dirigidas a Turquía.
Identificar un ejecutable .NET.
Una primera inspección del archivo suministrado con el companion permite reconocer su formato y orientar la lectura posterior del código administrado.
Leer la explicación y los comandos
La consulta
Consulta los metadatos del archivo y responde en cuatro líneas: formato declarado; tipo de código detectado; biblioteca y función importada; nombres de las secciones. Omite tamaños, direcciones y banderas. Añade una frase sobre la herramienta adecuada para continuar con sus métodos.
Qué muestra la sesión
radare2 identifica el archivo como PE32 y su código como CIL. La tabla de importaciones contiene _CorExeMain, procedente de mscoree.dll.
Las secciones observadas son .text, .rsrc y .reloc. Las cabeceras y la importación del entorno de ejecución aportan contexto para continuar la investigación con un descompilador de .NET.
La grabación consulta cabeceras, importaciones y secciones del archivo. El proceso de la muestra no se inicia.
Comprobación desde la consola
Desde la consola del companion se revisan estas instrucciones y datos:
iI~arch;iI~bits;iI~class;iI~lang
ii
iS
Se utiliza la muestra incluida en el companion para este capítulo. La descripción del arranque corresponde a este ensamblado de .NET Framework; las modalidades actuales de despliegue de .NET pueden utilizar otros mecanismos. Preparar el companion ↗
Antes de continuar
Describe la etapa analizada, sus datos de entrada y la evidencia que muestra su resultado. Relaciona cada captura con una función o transición concreta del caso.
El progreso se guarda en este navegador. Puedes recorrer las lecciones en cualquier orden.