Jugando con exploit/multi/handler

Realizando una serie de pruebas con payloads de Metasploit, encoders y antivirus para preparar una nueva entrada en mi blog, me ha tocado investigar las características y opciones que ofrece el exploit/multi/handler de Metasploit, descubriendo algunas cosas que me parecen útiles e interesantes.

Antes de nada, para los menos iniciados indicaré un par de conceptos relacionados con Metasploit. Para empezar,

¿Qué es meterpreter?

Meterpreter es el payload por excelencia de Metasploit, casi como “pura magia”. Este payload nos ofrece multitud de herramientas para interactuar con la máquina víctima y además permite cargar módulos con más características y herramientas para poder utilizar.

¿Qué es un handler?

En Metasploit, un handler es lo que utilizamos para conectar con un. Dependiendo del payload, el handler quedará a la escucha esperando una conexión por parte del payload (reverse payload) o iniciará una conexión contra un host en un puerto especificado (caso de un bind payload).

Configuración y uso básico de exploit/muli/handler.

La configuración básica y más conocida, simplemente trata de elegir el exploit (exploit/multi/handler), elegir el payload, configurar las opciones del payload (lhost y lport para un reverse shell o rhost y rport para un bind shell) y ejecutar el exploit.

En el caso de esperar un reverse Shell, el handler quedará a la espera como muestra la siguiente imagen.

1_handler_listening

En el momento en que se lance el payload en la maquina víctima, nuestro handler recibirá una conexión y lograremos una shell de meterpreter.

2_meterpreter_gotit

Una vez obtenida nuestra shell, podemos empezar con las tareas de post-explotación.

Pero, ¿qué pasa si el usuario de la máquina víctima cierra el proceso que lanza el payload?

En muchas ocasiones, el payload se lanza o bien desde un exploit “client side” o desde algún archivo que se le hace llegar a la víctima a la cual se engaña para que lo ejecute. Estos exploits, suelen dejar colgada la aplicación vulnerable que utilizan. Por ejemplo muchos de los exploits para plugins de Java, o de Flash Player dejan el navegador colgado.

En estos casos lo normal es que el usuario cierre el navegador, y en la máquina atacante sucede esto:

3_meterpreter_died

Nuestra sesión de meterpreter muere. Para evitar que esto ocurra, en cuanto logramos la sesión de meterpreter podemos realizar una búsqueda de procesos con el comando “ps”, identificar el ID de proceso de algún proceso legitimo del usuario como “explorer.exe” y luego utilizar el comando “migrate ID-proceso”.

Esto migrará el meterpreter al proceso “explorer.exe” y aunque el usuario cierre la aplicación que lanzo el payload, la sesión no morirá.

4_migrate-proc

Otra opción es el script “migrate.rb” que tiene Metasploit el cual se puede llamar desde la sesión de meterpreter utilizando el comando “run”. Este script nos permite migrar a un proceso con solo conocer su nombre (run migrate -n explorer.exe), no necesitamos buscar su ID, o incluso permite lanzar un nuevo proceso y migrar el meterpreter a este (run migrate -f ).

5_run_migrate

¿Y si tenemos más de una víctima?

Otro problema que tiene el uso básico de multi/handler, es que una vez nos conectamos a una sesión, otro payload ya no puede conectar.

Esto se puede solucionar con dos simples pasos.

  • Fijar la variable ExitOnSession a false
msf exploit(handler) > set ExitOnSession false
  • Ejecutar el exploit con la opción –j, lanzando así el handler en segundo plano.
msf exploit(handler) > exploit -j[*] Exploit running as background job.[*] Started reverse handler on 192.168.100.64:4444

[*] Starting the payload handler…

msf exploit(handler) >

Lo que se ejecuta en segundo plano, lo podemos consultar con el comando “jobs” y cuando queramos detenerlo, lo haremos con “jobs –k ID-job”.

Con estos dos pasos, ahora si hemos infectado multiples máquinas con un payload y estas conectan, Metasploit irá almacenando sesiones.

7_multi-sessions

Como se puede observar, dos máquinas distintas han realizado una conexión al puerto 4444 generando las sesiones 3 y 4. Para interactuar con una de las sesiones (la 3 por ejemplo), tan solo hay que ejecutar “sessions –i 3”.

Si nos vienen varias sesiones,

¿Cómo hacemos para evitar que se nos mueran sin tener que estar pendientes de migrar los procesos en cada una de las sesiones?

Pues bien, Metasploit también tiene la solución para esto. Si ejecutamos “show advanced” dentro del handler para ver las opciones avanzadas, entre todas ellas encontraremos “AutoRunScript”.

Esta opción permite configurar un script que se ejecutará en el momento en que se obtenga una sesión automáticamente. Así pues, podemos configurar “AutoRunScript=migrate –n explorer.exe” y cada vez que se cree una sesión, el proceso de meterpreter migrara al de explorer.exe

Así es como funciona:

8_AutoRunScript

Tenemos dos sesiones de meterpreter y además nos hemos asegurado que estas no mueran en cuanto el usuario cierre el proceso que las ha lanzado.

Espero que esta entrada os haya resultado tan interesante como a mi mientras jugaba con todo ello.

5 comentarios en «Jugando con exploit/multi/handler»

  1. hola mi peroblema es que cuando lanzo el payload a una victima lo detecta window defender sabes como puedo soulcinarlo seria de buena ayuda gracias

    • Si, por lo general los AV suelen detectar lo payloads de Metasploit. Yo probaría a generar un «Custom payload» utilizando «Veil», pero no si ya servirá ya que me llego un comentario de que Windows Defender también detectaba los payloads generados por «Veil».

      • Hola, antes que nada quiero agardecerte por tu excelente blog Ignacio Sorribas de verdad han sido de gran utlidad, contestando a simo, pues puedes utilizar el msfencode y alguna plantilla de un exe con firma validad al realizar esto utiliza el AutoRunScript pra migrar el proceso, saludos

  2. EL COMANDO download c:\\windows\\systeam32 este comando no descarga la carpeta systeam32 completa
    la pregunta como descago el disco c completo

Responder a Eduardo Mendoza Cancelar la respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*