Este es el tercer post sobre el método de postexplotación basado en cuevas de código. En la primera parte te mostré cómo crear una cueva de código básica en un ejecutable para introducir una shell. En la segunda entrega mejoré su tasa de detección utilizando cuevas de código naturales y ocultando el salto a la cueva entre las instrucciones del programa.
En esta parte te voy a mostrar como evitar que los antivirus detecten la shell de la cueva de código mediante un cifrado y descifrado en tiempo de ejecución. De nuevo agradecer a OscarAkaElvis, que fue quien me enseñó estas técnicas.
Método 3: Cuevas de código naturales cifradas
Este método parte del método anterior. Algunos antivirus (solo uno o dos, que yo sepa) pueden detectar el método anterior por la firma de la shell. Dado que las instrucciones que sigue nuestro payload para crear la reverse shell las obtuvimos de metasploit utilizando MSFvenom, sería relativamente sencillo para un antivirus obtener el código de ese payload y detectarlo en los escaneos.
La táctica es la siguiente: utilizaremos dos cuevas de código naturales. En una vamos a hacer un programa de descifrado, y en otra tendremos la shell. La idea es meter una shell cifrada de forma que en un análisis estático (que es el que hace el antivirus) no se pueda detectar que hace ese código. En el momento que decidamos del transcurso del programa, saltamos a una función que al ejecutarse descifre la shell, y después saltamos a la shell ya descifrada.
Como el antivirus no ejecuta el programa, la shell es indetectable. Veámoslo paso a paso.
Vamos a partir del archivo que modificamos en la segunda parte de esta serie. Si tienes cualquier duda, te recomiendo echarle un ojo. A partir del archivo anterior, lo que hacemos es ir a donde saltamos a la cueva de código, y poner el JMP a la segunda cueva de código que nos detectó cave_miner, en mi caso a la dirección 00477857:
En esta nueva sección de código escribimos la función de descifrado. Yo he escogido la función XOR, dado que es bidireccional: si haces el XOR de la shell obtienes la shell cifrada, y si haces el XOR de la shell cifrada obtienes la shell original. El código sería el siguiente:
Explicación del código:
PUSHAD Guardamos los valores de registro.
PUSHFD Guardamos los valores de registro.
MOV EBX, 00479730 Guardamos en EBX la dirección a la shell.
XOR BYTE PTR DS:[EBX], 0E Hacemos XOR de EBX con clave «0E».
INC EBX Incrementamos EBX para pasar a la instrucción siguiente de la shell.
CMP EBX, 00479872 Comprobamos si hemos llegado a la última posición de la shell.
JNE SHORT 0047785E Si no hemos llegado, volvemos a la instrucción de XOR.
JMP 00479730 Si hemos llegado, saltamos al inicio de la shell.
La parte de la shellcode no cambia nada, pero la tenemos que cifrar con XOR. Para ello tenemos dos opciones, o ejecutar una vez el programa poniendo un breakpoint antes de la shell para poder copiarla cuando se le haga el XOR, o buscar mediante alguna calculadora online cual es el XOR del código hexadecimal de la shell con «e0» (he elegido e0 como clave de cifrado, pero puedes escoger cualquier otra clave que desees).
Indistintamente de cómo lo hagamos, pegaremos la shell cifrada donde estaba la shell original:
Recuerda solo cifrar la shell, no lo que añadiremos después. Además, los PUSHAD y PUSHFD del inicio de la shell no los ponemos, puesto que ahora ya lo estamos haciendo en la cueva de código anterior. Por último, calculamos la diferencia de EBP, que va a seguir siendo 200, hacemos el POPFD y POPAD y ejecutamos la instrucción que eliminamos para poner el jmp:
Y listo, al ejecutar el programa e ir a la sección Ayuda -> Acerca de 7-Zip y pulsar el botón que lleva a la web, se nos abre una shell en la máquina atacante. Si analizamos con Kaspersky el archivo, no lo reconoce como un virus. Además, el programa continua funcionando, y aunque lo cierres, no se te cierra la shell.
Ésta es la versión definitiva de la backdoor, indetectable para todos los antivirus.
Lethani.
2 comentarios en «Post Explotation Backdooring III»