Port 3389 open to the internet: what actually happens

What 'exposed' means in practice

A server with TCP 3389 reachable from any address on the internet is not obscure. It is enumerated. Scanning services index the entire IPv4 space continuously — Shodan and Censys both publish searchable results — and the number of Windows machines answering on 3389 at any moment runs into the millions.

That means exposure is not a probability, it is a schedule. Your address does not have to be discovered by anyone in particular; it is already in a list, and that list is bought, shared and re-scanned by everyone running credential attacks.

The practical consequence is that a newly exposed server has no quiet period. There is no window during which you can leave the default settings and get around to hardening it next week.

The first week, hour by hour

The pattern is consistent enough to predict. These are the figures you should expect on a fresh Windows Server with RDP open and no protection:

• First hour — the first connection attempt from a scanner. Often within minutes, because mass scanners sweep continuously rather than on a schedule.
• First day — dozens to low hundreds of failed logins. Account names come off a standard list: Administrator, admin, user, test, sql, backup, scanner.
• First week — a few thousand a day, steady around the clock. Multiple distinct botnets have you now, and they do not coordinate, so the volumes add up.
• First month — often tens of thousands. The Security log begins rotating fast enough that older events age out before anyone reads them.
• Ongoing — the rate stabilises. It does not decay: there is no mechanism by which the bots conclude you are not worth trying.

What they are actually trying

Two different techniques share the same traffic profile, and telling them apart matters because the defences differ.

Classic brute force works one account hard — usually Administrator — and cycles through a password list. It is loud, it triggers lockout policies, and it fails against any password that is not on the list.

Password spraying inverts it: one common password tried once against many account names, then a pause, then the next password. It stays below lockout thresholds by design, and it is the technique that actually succeeds, because in any organisation with enough accounts somebody is using the seasonal password.

Both are visible in the same 4625 stream, and both are stopped by the same thing: blocking the source before it gets through the list. Neither is stopped by a lockout policy — spraying is built to evade it, and brute force turns it into a self-inflicted outage.

Checking whether you are exposed

Do this from outside your own network. Inside the LAN everything answers, which tells you nothing. From another machine on a different connection:

# From a machine outside your network, against your server's public IP:
Test-NetConnection -ComputerName 203.0.113.10 -Port 3389

# On the server itself, see what is listening and on which interface:
Get-NetTCPConnection -State Listen |
  Where-Object LocalPort -in 3389,3390 |
  Select-Object LocalAddress, LocalPort, OwningProcess

# And which firewall rules currently allow RDP in:
Get-NetFirewallRule -Direction Inbound -Enabled True -Action Allow |
  Where-Object { ($_ | Get-NetFirewallPortFilter).LocalPort -contains 3389 } |
  Select-Object DisplayName, Profile

Closing it, in order of preference

Ranked by how much risk each option actually removes:

• Do not expose it at all. Reach the server over a VPN, an RD Gateway or a bastion host. This removes the exposure rather than managing it, and everything below is a compromise against it.
• Restrict the source. If the set of legitimate addresses is small and stable — office ranges, a VPN exit, a jump host — allow only those in the firewall and drop everything else. Excellent when it fits, and it stops fitting the moment somebody travels.
• Ban attacking sources automatically. Watch the failed-login stream and firewall-block anything that crosses a threshold, by subnet, permanently. This is what to do when the service has to stay reachable from arbitrary addresses.
• Move off 3389. Cuts the untargeted volume by roughly 90% and protects against nothing that looks for you specifically. Useful as noise reduction on top of one of the above, never as a substitute.

If it has to stay open

Plenty of servers cannot go behind a VPN — contractors, client-owned machines, teams that connect from anywhere. If that is you, the exposure is a given and the job is to make it survivable.

Turn on Network Level Authentication so a session is never created for an unauthenticated client. Enforce long passwords and multi-factor authentication for every account that can log in remotely. Rename or disable the built-in Administrator account, because it is the first name every list tries. Keep the host patched — RDP has had pre-authentication vulnerabilities before and will again.

Then add the piece Windows does not ship: something that watches the failure stream and converts it into firewall rules. RDP Protector does exactly that, with subnet bans, permanent blocks that survive reboots, and a whitelist populated with your own address before anything is blocked. One server is free forever, which is enough to see your real exposure numbers rather than estimating them.