Windows 64-bit Reverse TCP Shell no funciona

Question

Windows 64-bit Reverse TCP Shell no funciona

#1 de OscarAkaElvis (1 votos)

1

Estoy enviando shellcode a un binario de 64 bits que se ejecuta en una máquina con Windows. Este binario, copia el shellcode a una región ejecutable de la memoria y lo ejecuta.

Estoy generando el shellcode usando msfvenom y elegí la carga útil: windows / x64 / shell_reverse_tcp

En la máquina local, estoy escuchando en el puerto 3004 con netcat.

Cuando envío el shellcode, en el lado del oyente, recibo el indicador de comando momentáneamente y luego la conexión se cierra inmediatamente como se muestra a continuación:

listening on [any] 3004 ...
connect to [192.168.2.10] from (UNKNOWN) [192.168.2.20] 42485
Microsoft Windows [Version 10.0.17134.112]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>

C:\Users\user\Documents\netcat-win32-1.11>

Cierra la conexión tan rápido que no tengo la oportunidad de escribir un comando.

Nota: No tengo acceso al entorno de laboratorio del servidor donde se ejecuta el binario. Todo lo que sé es que hay una solución de seguridad que se ejecuta en esa máquina que lo impide. Sin embargo, conozco los detalles del binario y que toma un shellcode, asigna una nueva memoria, la copia allí y la ejecuta.

Entonces, ¿cuáles son mis opciones para evitar las soluciones de seguridad en este caso?

Aquí hay un problema de bloqueo de puertos porque puedo obtener el shell inverso a través de cualquier puerto. El problema es que la conexión se cierra inmediatamente. Y no es un problema de red, hay alguna solución de seguridad que se ejecuta en el lado del servidor. Es un entorno de laboratorio y, por eso, lo sé.
¿Hay alguna forma de configurar nmap para enviar una lista de comandos tan pronto como reciba la respuesta del servidor?

Gracias

windows shellcode metasploit msfvenom

pregunta Neon Flash 27.10.2018 - 01:04

fuente

1 respuesta

Lea otras preguntas en las etiquetas windows shellcode metasploit msfvenom

Si C usa bibliotecas compartidas, ¿es posible escribir un programa que modifique el código que abre un archivo? Se detectó un protocolo TLS desconocido en la red

score 1 · Answer 1

Por lo general, para que los shells inversos funcionen, los primeros puertos que uso son 80 o 443 porque, incluso con el firewall configurado en la máquina víctima, estos puertos generalmente funcionan. El motivo es obvio: los puertos se utilizan para navegar por sitios web en Internet e incluso en configuraciones restringidas que pueden abrirse. Si no están abiertos, debe verificar si hay puertos abiertos. Para ello supongamos un escenario:

Si está intentando obtener una shell inversa es porque tiene algún tipo de RCE. Si tiene privilegios elevados, puede verificar la configuración del firewall (usando iptables en Linux o los comandos netsh en Windows) y puede abrir cualquier puerto necesario.

Incluso si no tiene privilegios elevados, puede intentar leer la configuración del firewall para ver si hay puertos abiertos en las conexiones salientes. Para Windows puede verificar esto usando comandos como este: netsh advfirewall firewall show rule dir=out name=all status=enabled . Eso mostrará todas las reglas de salida y, a continuación, puede intentar buscar un puerto abierto.

Si tiene un acceso restringido muy extraño o extraño y no puede verificar la configuración del firewall, aún puede hacer "fuerza bruta" para verificar si hay algún puerto abierto para las conexiones salientes. Primero puede preparar su máquina atacante escuchando en una gran cantidad de puertos: for j in {1..1000}; do nc -lvnp $j & done y luego puede hacer un bucle en la máquina víctima tratando de conectarse a su máquina atacante. Si la máquina víctima es Linux, puede hacer un bucle de bash usando netcat. Si es Windows, depende del software disponible (tal vez tenga netcat para Windows, o openssl o cualquier otra herramienta) y puede realizar un bucle por lotes tratando de conectarse a su máquina. Luego, puede verificar si algún puerto se conectó con éxito ejecutando un comando netstat en su máquina local y filtrando para ver solo las conexiones ESTABLECIDAS, pero como dije, esto es solo para entornos muy extraños y es una forma desesperada de encontrar un puerto abierto saliente.

Espero que ayude.

EDIT

¿Cómo estás escuchando en netcat? haga nc -lnvp <port> para evitar la resolución del nombre de host dns (el parámetro -n) porque en su caso parece que hay algún tipo de problema con eso.

EDIT2

Después de revisar sus comentarios y su edición en la pregunta, parece que una solución de seguridad está bloqueando la conexión una vez establecida. No está relacionado con cosas de firewall. Tal vez pueda intentar codificar su carga útil para evadir eso (tal vez un antivirus lo esté bloqueando una vez que se haya ejecutado). Para eso, puede probar shellter o unicorn en lugar de usar msfvenom. Shellter funciona bien en linux usando vino. Que las soluciones están codificando las cargas útiles son muy buenas para evadir los AV. ¡Pruébalos!