Flare-on 2014 - Challenge 05: 5get it

5get_it, el quinto reto del primer flare-on de Fireeye. No puedo más que decirles que este si que me ha costado. Comencemos con el writeup de este keylogger.

Bien comenzamos por descomprimir el challenge “C5.zip”, el cual esta protegido por la contraseña “malware”.

Nota: Todos los archivos de challenge se encuentran dentro de un zip que se descarga [aquí][c2c76e1c] [c2c76e1c]: http://www.flare-on.com/files/2014_FLAREOn_Challenges.zip “Flare-On 2014”

Tomamos algo de información base sobre el binario:

Ok, tenemos el primer vistazo que nos dice que tratamos con una DLL que no se encuentra empaquetada, con formato PE para 32 bits y que salvo la imagen base, todo parece normal.

Continuemos identificándolo en radare2:

El show info all o ia de radare2 nos entrega mucha información, que coincide con lo primero que empezamos a observar, adicionalmente nos devuelve que tenemos bastante funciones importadas (al menos 82) las cuales no coloco en imagen para no perderlas de vista:

Tenemos básicamente 3 bibliotecas dinámicas de las que importamos funciones: user32.dll, kernel32.dll y advapi32.dll. Decidí que para este writeup tengamos un enfoque mas estático de lo que a continuación sucede, ya que en un análisis mas tradicional, continuaríamos por la parte dinámica.

Comenzamos por llamar al shorcut de análisis:

Ok, con el análisis completado, veamos que funciones pudimos recuperar:

Como el resultado de afl era muy extenso, decidí convertirlo en tabla:

Si ordenamos esta tabla por tamaño, tomando únicamente los 10 primeros lugares tendríamos algo como lo siguiente:

Analicemos esas tres funciones muy grandes que no están identificadas:

Se omiten las variables de inicio y se reduce el font para poder tener mayor visibilidad:

Vaya vaya, parece que aquí se esta cargando algo en el stack… mas aun se nota el texto de Flare-On. Desgraciadamente pdf no logro identificar el tamaño completo de la función, pero eso se puede resolver ampliando el bloque:

Rango: 0x10001240 - 0x10009335

Esta función no recibe nada ni devuelve nada, pero lo que si es que algo hace porque podemos ver claramente en la imagen la palabra flare-on mientras se sube al stack.

Ahora bien, este podría ser nuestro destino final en caso de éxito, es decir, el win msg. Tomare esto como valido y continuare viendo como llegar hasta aquí…

Para ello lo primero seria ver que funciones llaman a esta función, para ello ubicaremos cuales son las referencias cruzadas e iremos de función en función.

Como podemos observar, fnc 0x10009af0 es la primera y única función que llama a 0x10001240, veamos su contenido:

Tenemos una comparación a 0 en 0x100194fc, que en caso de ser mayor a 0, llama a la función winmsg, pero antes va a llamar a otra función, fcn 0x10001060. Veamos que hay en esta función previa:

Esta función como podemos observar se encarga de colocar las equivalencias de esas ubicaciones a 0, como alguna especie de controlador/limpiador. Observamos que tiene 91 referencias! He inclusive por su tamaño no pude extraer toda la función, pero debido a que solo se encarga de inicializar/limpiar (no recibe ni devuelve nada), decidí colocarlo en la siguiente tabla:

Prestando atención al penúltimo resultado, podemos observar que es el valor que hemos evaluado durante la comparación en fcn 0x10009af0, veamos de que manera si podemos escribirlo buscando la referencia hacia esta dirección:

Como podemos ver, estan las dos funciones que acabamos de explorar, mas una tercera, fcn 0x10009b60, que se encarga de almacenar un 1, justo como buscamos romper el if.

Tuve nuevamente que reducir el tamaño de fuente para poder tomar la captura.

Bueno, como podemos apreciar, esta función tiene varias cosas diferentes y a la vez comunes con la función anterior. La primera cosa en común es que también es llamada desde sub.USER32.dll_GetAsyncKeyState_10009eb0, presenta un compare, luego set a 0 y finalmente un set a 1 para activar el siguiente flujo o brinco a función.

Su característica principal, es que pareciera que tenemos varios if concatenados, siendo precisos unos 5 cmp, que si ninguno tiene la flag activada, pone en 0 la flag actual y levanta la siguiente. Pero todos los caminos conducen a roma, es decir, todas las comparaciones al final devuelve “o”.

La función anterior (0x10009af0) devolvía “m”, por lo que sea lo que sea GetAsyncKeyState, esta recibiendo estos valores char cuando llama a las funciones.

GetAsyncKeyState

SHORT GetAsyncKeyState(
  int vKey
);

Esta función básicamente recibe la tecla a evaluar y nos devuelve si fue o esta siendo presionada.

Ok, veamos que hace la función sub.USER32.dll_GetAsyncKeyState_10009eb0:

El primer vistazo, nos revela muchos jumps, inclusive estamos hablando de un switch case, lo cual seria el tipo de loop adecuado para esto.

Las primeras 3 instrucciones corresponden al stack frame de 8 direcciones, las siguientes 11 instrucciones, desde mov eax, 8 hasta cmp edx, 0xde son las condicionales que nos haran mantenernos dentro de un loop de switch case, básicamente desde 8 hasta 222.

Como podemos ver, cuando se rompe el loop, se retorna 0 y termina la función.

Veamos que sucede dentro de este switch:

Después de la evaluación inicial, el counter es pasado como argumento a GetAsyncKeyState, es decir si local_4h vale 0x2b, se evaluara si la tecla ‘*’ fue presionada. Ese valor es compartido (tecla presionada ahora o antes) y se compara en el switch, si es no es igual, se va al caso ultimo, si es igual llama a la función correspondiente y brinca hacia el final (0x1000a3a6). En pocas palabras si la tecla “A” o la que sea es presionada, su función correspondiente es llamada.

Esto implica que nosotros controlamos el valor de las flags, presionándolas en el orden correcto debemos llegar a llamar a la función bandera (0x10001240).

Entonces ya que hemos entendido hagamos el reverso de cada letra presionada mediante el siguiente burdo script en python:

#!/usr/bin/env python
  
import r2pipe, os

keys = ["0x10017000","0x10019460","0x10019464","0x10019468","0x1001946c","0x10019470","0x10019474","0x10019478","0x1001947c","0x10019480","0x10019484","0x10019488","0x1001948c","0x10019490","0x10019494","0x10019498","0x1001949c","0x100194a0","0x100194a4","0x100194a8","0x100194ac","0x100194b0","0x100194b4","0x100194b8","0x100194bc","0x100194c0","0x100194c4","0x100194c8","0x100194cc","0x100194d0","0x100194d4","0x100194d8","0x100194dc","0x100194e0","0x100194e4","0x100194e8","0x100194ec","0x100194f0","0x100194f4","0x100194f8","0x100194fc","0x10019500"]

flag = ""

if os.path.isfile("5get_it"):

    r2 = r2pipe.open("5get_it")
    r2.cmd("aaaa")

    for key in keys:
        xrefs = r2.cmdj("axtj " + key)
        for xref in xrefs:
            if xref["opcode"] == "mov dword [" + key + "], 1":
                fcn_called = r2.cmdj("pdfj@" + xref["fcn_name"])
                for eax_ret in fcn_called["ops"]:
                    if "mov eax, 0x100" in eax_ret["disasm"]:
                        flag += r2.cmd("pr 1 @ " + eax_ret["disasm"].split(",")[1])

r2.quit()
print flag

La salida del comando nos devuelve el string:

l0ggingdoturdot5tr0ke5atflaredashondotco

La letra faltante, “m”, se devuelve a la salida del la función de reseteo.

Validemos el DLL contra yara rules:

xbytemx@laptop:~/flare-on2014/challenge05$ yara ~/git/rules/Antidebug_AntiVM_index.yar 5get_it
anti_dbg 5get_it
keylogger 5get_it
win_registry 5get_it
win_files_operation 5get_it

Vemos que da positivo contra tecnicas de antidbg, keylogger, win_registry y win_files_operation. Por ello crearemos un prefix de wine en donde ejecutemos con calma la dll.

Si ejecutamos el dll e ingresamos la salida del comando nos aparecerá el siguiente mensaje:

wineconsole rundll32 5get_it

Nota: La dll se ejecuta en un prefix recien creado para ser eliminado despues.

Traduciendo al formato de la flag:

flag: l0gging.ur.5tr0ke5@flare-on.com

Espero que les haya gustado.

Saludos,