BIND shells do not return a prompt after remote connection

[stutopp]

The bind shell powercat -l -p 4444 -e cmd.exe does not return a prompt until I press Up Arrow in the prompt running powercat.

This may be due to latency involved with an OpenVPN/rdesktop set-up, but this latency would likely be involved in operational use. I did not attempt to recreate locally to see if latency was a factor.

Replication: In PowerShell: powercat -v -l -p 4444 -e cmd.exe The prompt will report: Listening on [0.0.0.0] (port 443) On connecting device: nc -nv 123.123.123.123 4444

After connecting, the connecting device displays: (UNKNOWN) [123.123.123.123] 4444 (?) open The bind device does not display the connection in the prompt, but the connection is visible in netstat.

In PowerShell Prompt: <press up arrow> The prompt will report Connection from [123.123.123.123] port [tcp] accepted (source port 5555) and proceed as normal.

[peetKh]

I could replicate.

It seems to be due to this part of the code:

if($Host.UI.RawUI.KeyAvailable)
      {
        if(@(17,27) -contains ($Host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown").VirtualKeyCode))
        {
          Write-Verbose "CTRL or ESC caught. Stopping TCP Setup..."
          if($FuncVars["l"]){$Socket.Stop()}
          else{$Socket.Close()}
          $Stopwatch.Stop()
          break
        }
      }

If there is latency, when we press enter to run powercat, the KeyUp event from pressing enter arrives after powercat is started. So the KeyUp event goes into the input stream, KeyAvailable returns True, and the first IF statement is executed. However the ReadKey in the second IF statement does not "IncludeKeyUp" and blocks the execution until a KeyDown is caught.

[Parzival2027]

I could replicate as well. Used OpenVPN/rdesktop to connect to a lab vm.

[tjakobsen90]

I am experiencing this issue as well, the workaround works for me.

[AHewitt]

I have this issue as well, but it doesn't seem to be specific to the up arrow. I can press any key and it loads the shell.

I recorded this in a four second gif for you all to see: https://i.imgur.com/dApxP4Y.gif

[jblandrum]

Replacing this $Host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown").VirtualKeyCode)

with this (MSDN Uses something like this) $Host.UI.RawUI.ReadKey([System.Management.Automation.Host.ReadKeyOptions]"IncludeKeyDown"-bor[System.Management.Automation.Host.ReadKeyOptions]"NoEcho"-bor[System.Management.Automation.Host.ReadKeyOptions]"IncludeKeyUp").VirtualKeyCode)

or just $Host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown,IncludeKeyUp").VirtualKeyCode)

Look at the way the craft the options in the MSDN examples. It doesn't look like calling comma separated strings is the correct nomenclature.

EDIT: I'm pretty sure this is what's already been suggested but hopefully seeing it this way may help someone.

https://docs.microsoft.com/en-us/dotnet/api/system.management.automation.host.pshostrawuserinterface?view=powershellsdk-7.0.0 https://docs.microsoft.com/en-us/dotnet/api/system.management.automation.host.pshostrawuserinterface.readkey?view=powershellsdk-7.0.0

[besimorhino]

Can someone else please validate? This seems to work... would like another verification.

Thanks @lukebaggett !!

[QxF7]

Can someone else please validate? This seems to work... would like another verification.

Confirmed — I had the same symptom in the same circumstance, and applying the change in cb66833 resolved it.

Thanks @besimorhino !

[zormit]

Had the same issues. I can confirm the mentioned patch working as well.

[pippobaudo1]

Same problem, but if you just use "Arrow Up" in the Windows target the bind shell works(for example)

[BreakthroughTactics]

Very glad you spotted this! At least I can get it to work with the workaround :D

[ah-jota]

I am also having this problem. Can confirm hitting the up arrow as a workaround as well.

[mcduffchannel]

Can someone else please validate? This seems to work... would like another verification.

Thanks @lukebaggett !!

I only appended the 'IncludeKeyUp' for TCP but can confirm it worked instantly first go.