Esta es la segunda parte del conjunto de entradas sobre Post Explotation Backdooring. Si no has leido la entrada anterior, te recomiendo que lo hagas para entender este post. De nuevo quiero agradecer a OscarAkaElvis, quien me enseñó estas técnicas de PE Backdooring.
En el anterior post vimos como introducir el código de una reverse shell en un programa, creando un troyano. Sin embargo, en la vida real esta técnica es más que conocida por los antivirus, y no funcionará.
En primer lugar, porque es muy raro que un programa tenga como primera instrucción un JMP.
Por otro lado, es sencillo comprobar que el tamaño del ejecutable es mayor que el original, ya que tuvimos que crear una cueva de código para introducir la shell.
En esta segunda entrada te voy a explicar cómo evitar estos dos problemas, haciendo el troyano indetectable para casi cualquier antivirus.
Cueva de código natural
Vamos a evitar tener que crear un nuevo fragmento de código y añadirlo al programa, puesto que al hacerlo aumentamos su tamaño y creamos una sección nueva, algo muy detectable.
Para ello, vamos a buscar una cueva de código natural. Esto es, una sección del programa que ya esté vacía. Es habitual encontrar en los ejecutables segmentos de código que no se utilizan en el programa y están a null. Solo hay que encontrar uno lo suficientemente grande como para que quepa el código de la shell.
Hay varios programas que te pueden permitir encontrar fácilmente una cueva de código natural. El que yo utilizo es un programa de linux llamado cave_miner. Como la shell ocupa 324 bytes, seleccionamos una cueva de unos 500 bytes, para ir holgados:
La herramienta ha detectado dos cuevas de código de ese tamaño en el programa. Escoge una cualquiera, en este caso la de abajo, y apunta la dirección de inicio (la vaddress): 0047972e.
Ahora vamos a solucionar el segundo problema del post anterior: el JMP inicial.
Salto camuflado
En vez de realizar el salto a la cueva de código al inicio del programa, vamos a debuggear el código y seleccionar un punto del código más adelantado, para que cuando el flujo natural del programa pase por ahí, salte a la cueva de código. Lo usual es hacerlo en un punto en el que el programa tenga que pasar sí o sí sin que se necesite interacción del usuario, así el malware se ejecuta transparente al usuario. Sin embargo para hacer más clara esta PoC yo voy a utilizar como punto de salto la instrucción ques se ejecuta cuando el usuario aprieta el botón que puedes pulsar en 7-zip (que te lleva a la página oficial) y que está en Ayuda -> Acerca de 7-Zip:
Para encontrar esta funcionalidad en el código, usando Immunity Debugger, primero pulsas el botón de play para que te lleve a la primera línea que se ejecuta, después haces clic derecho, Search for, All referenced text strings, y vas subiendo hasta encontrar el string «www.7-zip.org»:
Ve a la dirección de memoria 0044A8E5 y allí ejecutas el jmp a la natural code cave, acordándote de guardar las instrucciones siguientes para restaurarlas después:
0044A8E5 . 68 0C084600 PUSH 7zFM_met.0046080C ; |FileName = «http://www.7-zip.org/»
0044A8EA . 50 PUSH EAX ; |Operation => NULL
0044A8EB . 50 PUSH EAX ; |hWnd => NULL
En este caso no ha corrompido ninguna de las instrucciones de abajo, por lo que después solo hay que restaurar la instrucción que hemos sobreescrito con el jmp. Vamos ahora a la cueva de código y volvemos a hacer lo mismo que en el método anterior: guardamos el estado de los registros ( PUSHAD, PUSHFD), pegamos la shell, corregimos con los 3 NOPs, ponemos los breakpoints al inicio y al final, calculamos la diferencia del registro ESP (recuerda que para que llegue al segundo breakpoint tienes que ponerte a la escucha en la máquina atacante y tienes que pulsar en Ayuda -> About 7-Zip), corregimos las instrucciones que sobreescribimos con el JMP y hacemos un JMP a la siguiente instrucción que tocaría ejecutar. Si tienes alguna duda sobre este proceso, consulta el post anterior. Esta es toda la parte de abajo del código de la cueva, tal y como quedaría finalmente:
Y ya tendrías tu programa con backdoor, y con muy pocos antivirus que lo detecten. Sin ir más lejos, a día de hoy el propio Kaspersky es incapaz de detectar malware si escaneas el ejecutable.
Sin embargo, aún quedan algunos antivirus que lo detectan. Esto se debe a que las instrucciones de los payloads que crean una reverse shell son conocidas por algunos antivirus. Son pocos, pero la idea es hacer un malware indetectable, no uno poco detectable. Esto lo solucionaremos en la siguiente entrada.
Lethani.
Good day very nice web site!! Man .. Excellent ..
Wonderful .. I’ll bookmark your site and take the feeds additionally?
I am satisfied to search out so many helpful information here in the submit,
we want work out more techniques in this regard, thanks for sharing.
. . . . .