← All posts

RDP Is Still the #1 Ransomware Front Door: A Practical Hardening Guide

Exposed Remote Desktop remains the most common ransomware initial-access vector. Here is how to find, lock down, and continuously audit RDP across your Windows machines.

Year after year, incident-response retrospectives land on the same unglamorous finding: a huge share of ransomware intrusions begin with Remote Desktop Protocol. Not a zero-day, not a phishing payload that defeated EDR — just TCP 3389 reachable from somewhere it shouldn't be, protecting an account whose password was guessable or already for sale on a credential market. RDP is convenient, which is exactly why it keeps killing people. This guide is the checklist I actually use to take it off the table.

Why RDP is such a reliable entry point

Three properties make exposed RDP irresistible to operators and access brokers alike:

The dangerous RDP server is rarely the one you remember setting up. It is the forgotten jump box, the developer VM someone exposed "temporarily," or the workstation a port-forward outlived.

The hardening checklist

Work top-down — the first item eliminates the entire attack class, the rest are defense in depth for the cases where you genuinely need remote access.

1. Don't expose 3389 to the internet at all

This is the single highest-leverage control. Remote access should terminate at a VPN, a Zero Trust gateway, or an RD Gateway — never a raw port forward on a perimeter firewall. If you think nothing is exposed, verify it from the outside rather than trusting the config you remember. Internally, confirm what is actually listening:

Get-NetTCPConnection -LocalPort 3389 -State Listen
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Where-Object Enabled -eq True

If a machine doesn't need inbound RDP, disable it outright and block the port for the Public profile:

Set-ItemProperty "HKLM:\System\CurrentControlSet\Control\Terminal Server" `
  -Name fDenyTSConnections -Value 1

2. Require Network Level Authentication (NLA)

NLA forces the client to authenticate before a full session is established, which blunts pre-auth exploitation and most resource-exhaustion attacks. It should be mandatory:

Set-ItemProperty "HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" `
  -Name UserAuthentication -Value 1

3. Eliminate weak and reused credentials

Brute force only works against weak passwords, and credential stuffing only works against reused ones. The account that can RDP in must have a long, unique password, and ideally not be a built-in administrator at all. Pair this with a lockout policy so automated guessing dies fast, and remove the local Administrator account from the Remote Desktop Users group entirely. For shared local admin passwords across many machines, Windows LAPS (rotating a unique per-machine password) is the right fix.

4. Scope who can connect

Membership in Remote Desktop Users is an access-control decision, not an afterthought. Audit it and keep it to named individuals or a tightly managed group:

Get-LocalGroupMember -Group "Remote Desktop Users"

Then layer "Deny log on through Remote Desktop Services" on accounts and service identities that should never use it.

5. Add MFA and turn on the right logs

If RDP must face anything beyond a trusted network, multi-factor authentication in front of it (via the gateway or an MFA agent) turns a stolen password into a non-event. Equally important, you cannot investigate what you didn't record: ensure logon auditing is on so Event ID 4624/4625 (success/failure) and RDP session events are captured. A spray of 4625 failures followed by a single 4624 from an unfamiliar source is the signature of a successful brute force.

Auditing it once isn't the hard part — keeping it true is

Any competent admin can lock down one box on a Tuesday. The failure mode is drift: six months later someone re-enables RDP for a quick fix, a firewall exception sneaks back in, or a new machine ships with defaults nobody reviewed. Hardening that isn't continuously verified quietly rots.

On a single machine, you don't need a fleet or a subscription to stay honest. WinSentinel is free and runs at full power on one box — all modules, no limits — so a single command tells you whether RDP is exposed, whether NLA is enforced, who is in Remote Desktop Users, and how that rolls into your overall posture score:

winsentinel audit
winsentinel score

The network-posture and configuration checks flag a listening 3389, NLA being off, and risky group membership the same way a reviewer would — but every run, not once. Re-run it after any change and the score moves if you regressed.

When you have more than one machine to keep honest

The math changes across an org. Manually re-auditing 50 or 100 endpoints is where good intentions go to die, and a single re-exposed jump box is all an attacker needs. That continuous, centralized assurance is what WinSentinel Pro exists for: lightweight agents report each machine's posture to a central node, so a host that re-enables RDP or drops its firewall rule surfaces as a drift alert instead of a breach notification. Pro rolls the same per-machine findings up into fleet-wide compliance evidence — the depth of each machine's audit is identical to the free single-machine scan; Pro adds the orchestration, history, and alerting you need to trust dozens of machines at once.

The takeaway

RDP keeps topping the initial-access charts not because it is unfixable, but because the fix is boring and the regressions are silent. Get it off the public internet, require NLA, kill weak and reused credentials, scope access tightly, and put MFA and logging in front of whatever remains. Then make the audit continuous — free on the machine in front of you, fleet-wide with Pro when one machine becomes many. The front door is easy to lock. The discipline is in checking, every day, that it stayed locked.