(http://i61.tinypic.com/wi1or9.jpg)
Antes de comenzar, podéis ver qué son los CPL maliciosos aquí:
https://underc0de.org/foro/tutoriales-y-manuales/archivos-cpl-mecanismo-para-propagar-malware/ (https://underc0de.org/foro/tutoriales-y-manuales/archivos-cpl-mecanismo-para-propagar-malware/)
De la misma forma que una
DLL no puede ejecutarse por sí sola (requiere de un
EXE que invoque alguno de los
exports de la DLL, por ejemplo,
rundll32.exe ruta_DLL, export_a_ejecutar), un CPL también requiere que alguien llame a
CPlApplet. Sin embargo, dado que
CPlApplet recibe diversos
mensajes específicos, la ejecución directa con
rundll32.exe no será adecuada en tanto esos mensajes no sean enviados.
La clave está entonces en observar que cada vez que se hace doble clic en un CPL se ejecutará
control.exe, quien llamará a
rundll32.exe con los parámetros adecuados. Luego,
control.exe es un buen punto de partida para empezar nuestra sesión de
debugging.
(http://i62.tinypic.com/ebcuia.jpg)
En la imagen anterior vemos cómo empezaremos a
debuggear control.exe con la ruta hasta el CPL como argumento (esto puede configurarse desde el menú
"File > Set New Arguments...", recordando que hay que presionar
Ctrl+F2 para que se tomen los cambios). Luego, vamos a comprobar los nombres referenciados por
control.exe, donde se destaca
ShellExecuteEx, dado que es el único
import que vemos que podría ejecutar
rundll32.exe.
(http://i61.tinypic.com/241mas1.jpg)
Si buscamos en qué partes del código de
control.exe se referencia a
ShellExecute, encontraremos que esto sucede en un único punto. Así, colocamos un
breakpoint en esa instrucción y continuamos la ejecución hasta obtener lo que vemos en la próxima imagen.
Allí, puede apreciarse que
rundll32.exe va a ser llamado con los argumentos:
"Shell32.dll,Control_RunDLL <ruta_CPL>". Esto nos da un indicio de por qué no es correcto ejecutar directamente
rundll32.exe con el CPL como argumento: es el código contenido en
Control_RunDLL, de la librería
Shell32.dll, el que sabe cómo pasar los mensajes a
CPlApplet.Asimismo, es importante notar que, la próxima vez que tengamos que
debuggear un CPL, podemos empezar por
rundll32.exe con estos argumentos que hemos encontrado, sin necesidad de
debuggear control.exe antes.
(http://i59.tinypic.com/alq4h5.jpg)
Una vez que estamos detenidos en
rundll32.exe, debemos buscar la llamada a
Control_RunDLL. Una forma de hacer esto es buscar las referencias a GetProcAddress hasta encontrar aquella que trata de resolver la ubicación del import que buscamos. Así, colocamos
breakpoints en todas las llamadas hasta obtener la dirección de
Control_RunDLL en Shell32.dll.
(http://i57.tinypic.com/2vbq2rp.jpg)
Podemos colocar un
breakpoint allí y continuar la ejecución. En este momento nos encontramos dentro del código de
Control_RunDLL, con lo cual podemos buscar nuevamente las referencias a
GetProcAddress para la resolución de
CPlApplet.
Sin embargo, queremos capturar el momento en que el CPL se carga en memoria y se ejecuta el entry point
(DllMain), ya que allí podría haber algún que otro truquito anti-VM , o incluso el mismo payload malicioso. Entonces, sería conveniente buscar en qué parte del código se llama a
LoadLibrary para nuestro CPL.
(http://i60.tinypic.com/2qitqtg.jpg)
Como se observa en la imagen, obtendremos muchos puntos del código de
Shell32.dll desde donde se llama a
LoadLibraryA o
LoadLibraryW. A pesar de esto, si luego de colocar todos los
breakpoints continuamos la ejecución, el primer
LoadLibrary que se ejecutará es el de nuestro CPL. Para que la ejecución quede detenida en la primera instrucción de
DllMain, una de las opciones es configurar
Olly para que se detenga al cargar el CPL en memoria:
(http://i60.tinypic.com/2dklbox.jpg)
Ahora bien, si volvemos al punto posterior de la llamada a
LoadLibrary, encontraremos la referencia a
CPlApplet a unas pocas instrucciones de distancia. Eso sí, una vez que estemos en el código de
CPlApplet, tenemos que prestar atención a los mensajes que se pasan como argumentos: sólo nos interesa el mensaje CPL_DBLCLK.
(http://i58.tinypic.com/3143xi0.jpg)
Si bien los pasos seguidos en este análisis son interesantes para comprender la ejecución de los archivos CPL, podemos formular un método más práctico para
debuggear este tipo de amenazas. Para ello, podemos apoyarnos en la utilización de algún desensamblador como
IDA Pro, con el cual podamos identificar la dirección del
entry point y de
CPlApplet.Una vez conocidas estas direcciones, podemos abrir directamente el CPL en
Olly (haciéndole creer que es un archivo de tipo EXE, y
setear los
breakpoints en esas direcciones. Luego, si cerramos esa instancia de
Olly y abrimos una nueva para
debuggear rundll32.exe, tal como hemos descripto,
Olly "recordará" esos
breakpoints establecidos en el CPL.
En resumen, para
debuggear un CPL en forma rápida:
-Observar la dirección de
DllMain y de
CPlApplet, por ejemplo con
IDA Pro.
-Abrir el CPL con
Olly y
setear los
breakpoints donde nos interese. Cerrar
OllyDbg.
-Abrir
rundll32.exe con
Olly, e ingresar
"Shell32.dll,Control_RunDLL <ruta_CPL>" en los argumentos.
-Ejecutar hasta que se alcance el primer
breakpoint en el CPL.
Fuente: welivesecurity.com