Port 3389 and RDP Exposure: What an Open Remote Desktop Port Invites

Remote Desktop lets you sit at one Windows machine and drive another as if you were in front of it. Administrators use it to manage servers, help desks use it to fix laptops, and plenty of small offices use it so staff can work from home. All of that traffic arrives on the same number by default: port 3389.

The trouble starts when that port is reachable from the open internet rather than only from a trusted network. A Remote Desktop listener is a login screen for a whole computer, and anyone who can reach it can try to log in. This post covers what that exposure means in practice and what to do about it.

What listens on port 3389#

IANA registers 3389 under the service name ms-wbt-server, an old Microsoft name for what became Remote Desktop. Both TCP and UDP are registered. Unusually for a port this famous, the registry cites no RFC: the protocol, RDP, is documented in Microsoft's own open specifications instead. Our explainer on how IANA port assignments work covers why a vendor protocol can hold a number without an internet standard behind it.

RDP carries screen updates from the remote machine to you and your keystrokes and mouse movements back. It can also redirect the clipboard, printers, drives and audio. On TCP 3389 the whole session runs over a single connection. Since RDP 8.0, the client and server can also use UDP 3389 for lower latency on slow or wireless links, and if UDP is blocked the session simply stays on TCP, so you may find only one of the two open.

The server side is not limited to Windows. Linux machines can run xrdp to accept the same clients, so an open 3389 usually means Windows but not always. The port number tells you what was intended, not what is actually running.

Why an exposed login prompt is the problem#

An RDP login is usually a normal Windows account: a username and a password, the same ones that work at the keyboard. Put that on the internet and it meets automated tools that try common usernames such as administrator with long lists of leaked and guessable passwords, around the clock, from many addresses at once. This is credential stuffing and brute force, and it costs the attacker almost nothing to run.

It only has to work once. A successful RDP login gives the attacker an interactive desktop with whatever rights that account holds, which is far more than most stolen logins provide. From there they can disable security software, move to other machines on the same network, and deploy ransomware by hand. CISA's #StopRansomware guide names exposed and poorly secured remote services among the common ways attackers get their first foothold, and lists RDP specifically. Its advice is blunt: limit the use of remote desktop services, close RDP ports that are not in use, require multifactor authentication, lock accounts after repeated failed logins, and log the attempts.

Notice that none of this needs a software flaw. A fully patched server with a weak password on an internet-facing 3389 is already at risk. Patching protects against the second kind of problem.

BlueKeep and the unpatched tail#

In May 2019 Microsoft patched CVE-2019-0708, a flaw in Remote Desktop Services that became known as BlueKeep. It let an attacker run code on a vulnerable machine just by sending crafted traffic to the RDP service, with no password and no user interaction. CISA's advisory AA19-168A described it as wormable: malware using it could spread from one vulnerable system to the next on its own.

The affected versions were old ones: Windows 2000, XP, Vista and 7, plus Windows Server 2003, 2003 R2, 2008 and 2008 R2. Microsoft took the unusual step of shipping patches for systems that were already out of support. The risk lives in the machines nobody updates, such as a forgotten server in a closet or an industrial PC running an old image. CISA added BlueKeep to its Known Exploited Vulnerabilities catalog in November 2021 and marks it as known to be used in ransomware campaigns. You can look it up in our CVE Explorer, and our guide to CVSS, EPSS and KEV explains why a KEV listing should move a patch to the front of the queue.

BlueKeep is the famous case, not the only one. Remote Desktop Services has had other serious vulnerabilities since, which is the general lesson: any service you expose is a service whose next bug you are also exposing.

Network Level Authentication#

Network Level Authentication, or NLA, makes the client prove who it is before the server builds a full remote session. Without it, the server starts a session and shows the Windows sign-in screen to anyone who connects, which spends server resources on strangers and exposes more of the service to them.

NLA does not stop password guessing. An attacker with a valid username and password passes it exactly as you do. What it does is move the credential check earlier, so unauthenticated visitors reach less of the server. That is why CISA listed enabling NLA on Windows 7 and Server 2008 systems as a mitigation for BlueKeep, alongside patching and blocking TCP 3389 at the perimeter firewall. Treat NLA as a baseline setting that should always be on, not as a reason to leave the port open.

Does moving RDP to another port help?#

Microsoft documents how to change the listening port: it is the PortNumber value under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp, followed by a firewall rule for the new number and a reboot. Clients then connect with the port appended, such as pc1.example.com:3390.

This cuts down the noise from the laziest scanners that only try 3389, and your logs get quieter. It does not hide the service. Scanning tools can sweep every port on an address, and RDP identifies itself during the handshake no matter which number it answers on. A server on port 50000 with a weak administrator password is just as exposed to anyone who looks properly. Moving the port is fine as a noise filter. It is not a security control.

Safer ways to reach a remote desktop#

The goal is simple: 3389 should answer only to people who have already proved who they are by some other route. The usual options:

• A VPN in front. Users connect to the VPN first, with multifactor authentication, and only then reach RDP on the private network. The internet sees the VPN endpoint and nothing behind it. Keep the VPN appliance patched, because it becomes the exposed service instead.
• Remote Desktop Gateway. A Windows Server role that wraps RDP inside HTTPS and brokers connections to internal machines, so the desktops themselves are never directly reachable. It uses a TLS certificate like any web server and lets you control who may connect to what.
• A firewall allowlist. If only a few fixed locations need access, allow 3389 from those source addresses and drop everything else. This is the smallest change and works well for a branch office with a static IP.
• Turn it off. If nobody uses Remote Desktop on a machine, disable it. A service that is not running cannot be attacked.

Whichever you choose, add the basics on the machine itself: NLA on, account lockout after repeated failures, no shared or default administrator accounts, and patches applied on schedule.

What an attack looks like in the logs#

If 3389 has been exposed, the Windows Security log already holds the evidence. Event 4625 records every failed logon, and Microsoft documents the fields worth reading:

• Source Network Address, the IP the attempt came from, and Workstation Name, the name the client reported, which the client is free to make up.
• Logon Type. Type 10, RemoteInteractive, means a Remote Desktop logon. Do not filter on 10 alone, though. With NLA on, the credentials are checked before the remote session exists, and failed attempts are commonly logged as type 3, Network.
• Status and Sub Status. 0xC0000064 means the username does not exist and 0xC000006A means the password was wrong. A run of the first is someone guessing account names. A run of the second against one real account is someone working on that account.

Successful logons appear as event 4624 with the same fields, so the question to ask is whether any 4624 came from an address that also produced a pile of 4625s. You can decode any event number with our Windows Event ID decoder, and our post on what the Security log records covers the surrounding events.

To make sense of the source addresses, paste the exported log lines into Log IP Triage. It pulls out every IP, counts them, and ranks Tor exits, blocklisted addresses and hosting infrastructure ahead of ordinary residential traffic. For a single address, the IP Infrastructure Classifier shows whether it belongs to a datacenter, hosting or VPN network or is a Tor exit node. A login attempt from a cloud server at 3 a.m. is not proof of anything, but it is a strong hint about where to look first.

Checking your own exposure#

The fastest way to know whether 3389 is reachable is to test it from outside your network, since a check from inside tells you nothing about what the internet sees. Our guide to what open ports reveal about an IP walks through checking your public address for exposed services. Check every public address you own, including cloud instances, where Remote Desktop is often how you are expected to connect to a Windows server.

If you find 3389 open and did not mean to, close it at the firewall first and ask questions second. Then read back through the 4625 events to see how long it was exposed and whether any attempt succeeded. If one did, treat the machine as compromised: reset the affected passwords, review what that account touched, and look for new accounts or scheduled tasks you did not create.

The same reasoning applies to its Linux counterpart, SSH on port 22, which faces the same constant guessing. RDP is more dangerous mainly because a successful login lands on a full desktop. Keep it behind something that checks identity first, and an exposed login screen stops being one of your problems.