Lab ReverseShell01 - Primera experiencia analizando un malware

El binario que usaremos esta disponible en http://ccom.uprrp.edu/~rarce/ccom4995/misc/mal01.exe

El programa que analizaremos no es muy nocivo pues no deja trazos en el sistema, e.g. no se copia o crea archivos en otros directorios, no altera el registry para tratar de autoejecutarse después. Por lo tanto no tenemos que tomar la precaución de hacer un snapshot al virtual machine antes de correr el malware para luego restaurar su estado.

  1. A modo de demostración de los pasos que toma el programa cuando corre, haremos un monitoreo usando Process Monitor.

Process Monitor. Filter -> Filter -> Process Name is mal01.exe. Add. Clear. Run. ../img/pmonfilter.png

Luego si edit clear display y corres el mal01.exe, obtendrás una lectura como la siguiente. Lo importante es que el programa comenzó y terminó.

../img/pmonscreen01.png

  1. Abre mal01.exe en IDA. Uno de las primeros pasos al analizar malware es tener una idea de las funciones que usa del API de Windows (o de las librerías de C). La forma más fácil de ver esa información en IDA es en la ventana de Imports. El binario mal01.exe hace import de más de 40 funciones, entre ellas algunas que nos hacen pensar que estará creando alguna conexión de red (gethostbyname, connect, WSASocket). Otros imports que estaremos investigando son GetModuleFileNameA y CreateProcessA.

  2. Otra verificación fácil que suele hacerse a un malware en IDA son sus "strings". Ya que aparentemente este binario crea una conexión, quizás en los strings podemos averiguar a qué servidor está tratando de conectarse. Revisa la ventana de strings en IDA. Mala suerte :-(, lamentablemente IDA solo identificó strings que corresponden a nombres de imports y a mensajes de error. La función gethostbyname y otras que usa este binario requieren parámetros tipo string, pero, ¿dónde están?

  3. En la ventana de disassembly de IDA (IDA View-A) observa la función main. Una de las primeras cosas que hace main es escribir muchos bytes sencillos al stack. Esto es indicativo de que está creando un stack-framed string. Determina los dos stack-based strings (cada uno está terminado por el caracter nulo). En lugar de hacerlo manualmente en IDA, abre mal01.exe en OllyDBG. Coloca un breakpoint en la primera instrucción que copia un byte a memoria y corre el programa (para que pause en esa instrucción). Para que puedas ver el string formándose en memoria da right click sobre la instrucción donde se detuvo y escoge Follow in dump - memory address. Luego dale a step into para que veas como se guardan los siguientes strings en memoria: 1qaz2wsx3edc y ocl.exe. Obtén un pantallazo de ese gran descubrimiento!.

  4. De vuelta en IDA, nota que lo próximo que sucede en la función main es una invocación a la función GetModuleFileNameA. Esa función determina el path y nombre del programa que se está ejecutando (C:\whatever\it\is\mal01.exe). El parámetro que IDA identificó como lpFileName es donde GetModuleFileNameA devuelve su resultado. En OllyDbg, trata de darle follow in dump a la dirección donde GetModuleFileNameA escribe su resultado ([EBP-300]). Pon un breakpoint justo en el CALL a GetModuleFileName y luego has un step over para encontrar en memoria un string como C:\Users\....\mal01.exe. Pantallazo de celebración!

  5. Un poco más abajo, notarás que hay una invocación a _strcmp cuyo resultado afecta el flujo del programa. Si el resultado es diferente de 0, el programa termina. ¿Qué dos strings se están comparando? Veamos. Crea un breakpoint en el CALL de _strcmp (nota que OllyDbg fue incapaz de identificar el nombre de _strcmp (no tiene algunos de los superpoderes de IDA) así que ayúdate con la información que provee IDA. Crea un pantallazo de celebración mostrando el contenido de los registros EAX y ECX. Esos son los dos strings que se están comparando.

  6. Aparentemente el binario se tiene que llamar ocl.exe para que esta comparación se cumpla y el programa pueda seguir su curso. Cierra OllyDbg y cambia el nombre del binario mal01.exe a ocl.exe.

  7. Más adelante, el programa parece estar preparándose para crear una conexión por red. Verás llamadas a WSAStartUup y WSASocketA. Entre esta última y la llamada a gethostbyname se invoca una función local identificada por IDA como sub_411089. ¿Qué dos parámetros se le están pasando a esa función? Muestra un pantallazo en el que se puedan apreciar el contenido de esos dos strings. La función sub_411089 utiliza uno de los strings que fue construido al principio de main (1qaz2wsx3edc) para descifrar los bytes del segundo parámetro (que comienzan con 46 06 16). El resultado es devuelto mediante EAX y es un URL (www......). ¿Lo ves?

  8. Si el proceso de crear la conexión a ese URL (usando connect) es exitoso, el programa llega a invocar la función que IDA ha llamado sub_401000. Entra a esa función en IDA. Verás que invoca a una función muy peligrosa: CreateProcessA (create a new process and its primary thread). Puedes ver en la lista de parámetros que el proceso que se está creando corre a cmd.exe. Otro de los parámetros que se le pasa a CreateProcessA es una estructura llamada StartupInfo. Como puedes ver en la siguientes instrucciones, se está estableciendo que wShowWindow = 0, i.e. no se mostrará la ventana donde corre el proceso, y el hStdInput , hStdError, hStdOutput se están igualando al parámetro que le llega a esta función, que corresponde al socket creado durante el connect. Es decir el input y el output del comand line que se está creando provendrá de servidor al que se conectó.

    mov     [ebp+StartupInfo.wShowWindow], 0
mov     edx, [ebp+arg_10]
mov     [ebp+StartupInfo.hStdInput], edx
mov     eax, [ebp+StartupInfo.hStdInput]
mov     [ebp+StartupInfo.hStdError], eax
mov     ecx, [ebp+StartupInfo.hStdError]
mov     [ebp+StartupInfo.hStdOutput], ecx

    En otras palabras, se está creando un reverse shell con el puerto 9999 de www.practicalmalwareanalysis.com. Si en ese servidor ponemos a escuchar en el puerto 9999, cuando una computadora corra este malware quedaremos conectados con un shell con los privilegios de la persona que haya corrido ocl.exe.

  9. Si quieres ver el software acción debes hacerlo creer que en efecto se está conectando al website www.practicalmalwareanalysis.com. Para eso usaremos dos softwares:

    1. ApateDNS - interceptará la consulta al DNS y lo redirigirá al localhost. Descargalo de aquí: sdl-apatedns.zip e instálalo.
    2. Netcat - crearemos una conección tipo listen en espera de la conexión que establece el ocl.exe. Descargar de netcat-win32-1.11.zip. El puerto al que se trata de conectar el malware ocl.exe es 9999. El comando para crear la conexión tipo listen es nc -l -p 9999.
  10. Muestra un pantallazo donde se vean las pantallas de nc que demuestre conexión.