Windows 64-bit Reverse TCP Shell not working

Question

I am sending shellcode to a 64-bit binary running on a Windows machine. This binary, copies the shellcode to an executable region of memory and executes it.

I am generating the shellcode using msfvenom and I chose the payload: windows/x64/shell_reverse_tcp

On the local machine, I am listening on port 3004 with netcat.

When I send the shellcode, on the listener side, I get the command prompt momentarily and then connection is closed immediately as shown below:

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>

It closes the connection so quickly that I don't get a chance to type in a command.

Note: I do not have access to the server lab environment where the binary is running. All I know is that there is some security solution running on that machine which is preventing this. However, I know the details of the binary and that it takes a shellcode, allocates a new memory, copies it there and executes it.

So, what are my options for bypassing security solutions in this case?

1. There is port blocking issue here because I am able to get the reverse shell through any port. The issue is that the connection is closed immediately. And it's not a network issue, there is some security solution running on the server side. It's a lab environment and so I know it.

2. Is there a way to configure nmap to send a list of commands as soon as it receives response from the server?

Thanks

Answer 1

Usually to get reverse shells working the first ports I use are 80 or 443 because even with firewalling set on victim machine these ports usually works. The reason is obvious, that ports are used to surf websites on internet and even on restricted configurations they may be opened. If they are not open you should check for open ports. To do this let's suppose a scenario:

If you are trying to get a reverse shell is because you have some kind of RCE. If you have elevated privileges then you can check the firewall configuration (using iptables on Linux or netsh commands on Windows) and you can open any needed port.

Even if you don't have elevated privileges, you can try to read the firewall configuration to see if there are any ports open on outbound connections. For windows you can check this using commands like this: netsh advfirewall firewall show rule dir=out name=all status=enabled. That will show all outbound rules and then you can try to search for an open port.

If you have a very weird or strange restricted access and you are not able to check the firewall configuration, you still can perform "bruteforce" to check if any port is open for outbound connections. You can first prepare your attacker machine listening in a lot of ports: for j in {1..1000}; do nc -lvnp $j & done and then you can perform a loop on the victim machine trying to connect to your attacker machine. If the victim machine is Linux you can a bash loop using netcat. If is windows it depends on the available software (maybe you have netcat for windows, or openssl or any other tool) and you can perform a batch loop trying to connect to your machine. Then you can check if any port was successfully connected launching a netstat command on your local machine and filtering to see only ESTABLISHED connections, but as I said this is only for very weird environments and is a desperated way to find an outbound open port.

Hope it helps.

EDIT

How are you listening on netcat? do nc -lnvp <port> to avoid dns hostname resolution (the -n parameter) because on your case it seems there is some kind of problem with that.

EDIT2

After checking your comments and your edit on the question, it seems as you said like a security solution is blocking the connection once established. It's not related to firewall stuff. Maybe you can try to encode your payload in order to evade that (maybe is an antivirus blocking it once executed). For that you can try shellter or unicorn instead of using msfvenom. Shellter works well on linux using wine. That solutions are encoding the payloads are very good to evade AVs. Give them a try!