Reverse Engineering de Código Cifrado

En ocasiones cuando te pones a intentar analizar un fichero sospechoso de ser Malware, es posible hacerse una idea de lo que hace simplemente observando el contenido del binario. Otras veces el Malware se encuentra cifrado, por lo que únicamente podremos ver el contenido de la rutina de descifrado.

Sin embargo, cualquier software que se cifra y se tiene que descifrar automáticamente sin intervención humana es necesario que almacene hardcodeada la contraseña de descifrado (o se la descargue de Internet, o por algún otro medio), así que para saber que hace este tipo de malware podemos optar por buscar la contraseña de descifrado en la rutina, o bien optar por dejar que el propio malware descifre el código y analizarlo en memoria. Esta segunda es la aproximación que suelo utilizar yo, y así lo hice recientemente para intentar averiguar el formato enviado y sobretodo devuelto por el Malware ASPROX al acceder a la web forum.php durante un ejercicio que nos pusimos los miembros de Pentester.es durante nuestro último "Hacking Day".

1. Lo primero es dejar que el malware se ejecute libremente, controlando con una traza de red o monitorización del equipo que su ejecución haya llegado al punto que queremos (en este caso mandar una conexión POST /forum.php). En ese momento lanzamos OLLYDBG y hacemos Attach (File->Attach) del proceso aspimgr.exe, con lo que pasaremos a tener acceso al espacio del proceso.




2. Una vez tenemos el espacio del proceso nos vamos a la zona de memoria (M) y buscamos la cadena "forum.php". Esta cadena la encontraremos tanto en el sitio original donde la rutina de descifrado la escribirá como en otros sitios donde se haya copiado, así que sabemos que al menos una de las direcciones que saquemos va a ser el sitio donde originalmente va a estar. Conocer esta dirección nos va a ser tremendamente útil para analizar el malware, puesto que a partir de ahí vamos a saber todas las acciones que realiza el malware utilizando esta cadena.





3. Una vez tenemos esas direcciones de memoria, paramos el proceso, y esta vez lo lanzamos junto con el depurador desde el primer momento, es decir, antes de que descifre, y antes de ejecutarlo, buscamos en la memoria esta misma zona que, por supuesto, no contendrá todavía la misma información, y colocamos un "breakpoint, memory on access" para que el software se detenga cuando se acceda a esta dirección.




4. Ahora sólo tenemos que dejar que el malware siga su ejecución. Observaremos que se para una primera vez al realizarse una escritura (cuando la rutina de descifrado escribe encima), así que lo lanzamos otra vez y esta vez sí que se detiene en un acceso para lectura.



5. En muchas ocasiones, la función que accede directamente a la información es una función del Kernel que ha sido llamada desde el malware, así que esa zona del código no es la que nos interesa. Para ir a la zona interesante iremos al menú "Debug->Execute till user code" (ejecutar hasta el código del usuario) para acabar en el código del malware que estamos analizando.


6. A partir de ahí podriamos proseguir con el análisis. Como podemos ver ya estamos en una zona donde se pueden apreciar cosas interesantes:

Después de acabar este proceso nos encontramos con el código descifrado en la zona de datos, con o que a partir de este punto se puede empezar a analizar los accesos a las cadenas que nos interesan, en este caso un strlen de la cadena que contiene la URL a la que accede el malware.

De esta manera podemos realizar análisis de malware con zonas de código cifradas sin tener que ir ejecutando paso a paso cada instrucción, lo cual nos llevaría mucho tiempo y esfuerzo.