Port 3389 – RDP (Remote Desktop Protocol)

Port 3389 is the default port for RDP (Remote Desktop Protocol), Microsoft’s protocol for driving a full graphical desktop on a remote Windows host — the same session you get from the mstsc.exe client. On Windows the listener is the Remote Desktop Services role (TermService); on Linux it is usually xrdp. RDP is primarily a TCP service, but modern Windows also opens an optional UDP 3389 transport to accelerate the session. Because a single working login over port 3389 hands an attacker an interactive desktop, an exposed RDP port is one of the highest-value findings on any Windows estate — and, over the last several years, the single most common way ransomware crews get their first foothold.

Why It’s Open

RDP is the standard way to administer Windows remotely with a GUI. You’ll find it on domain controllers, file and application servers, jump boxes, developer workstations, VDI pools, and cloud VMs where an admin enabled “Remote Desktop” for convenience. It is genuinely useful, which is exactly why it spreads: help-desk staff RDP into user machines, sysadmins RDP into servers, and third-party vendors get RDP access for support. The trouble starts when that convenience is pointed at the internet — a VM with a public IP and 3389 open, a firewall port-forward “just for now,” or a home-office box exposed through a router. Where you see RDP, the rest of the Windows management surface is usually one scan away: SMB on port 445, Kerberos on port 88, LDAP on port 389, and WinRM over HTTPS on port 5986. On Linux, the equivalent remote-admin channel is SSH on port 22. Don’t confuse an RDP session into a Windows guest with Hyper-V’s VMConnect console on port 2179, which hands you a virtual machine’s console from the host rather than an RDP login into the guest OS.

Common Risks

• Exposure to the internet. This is the headline problem. An internet-facing port 3389 is a magnet for brute-force, password-spraying, and credential-stuffing bots the moment it appears in Shodan or a mass scan. Exposed RDP has repeatedly ranked as the number-one initial-access vector for ransomware.
• Weak passwords and no lockout. Many hosts allow local administrators to log on over RDP with no account-lockout policy, so an attacker can grind through password lists indefinitely. One cracked credential equals a full interactive desktop.
• NLA disabled. With Network Level Authentication off, the server negotiates a session before credentials are checked, which both widens the pre-auth attack surface (BlueKeep-class bugs) and leaks host, domain, and OS-build details to an unauthenticated scanner.
• Wormable pre-auth RCE bugs. BlueKeep (CVE-2019-0708) and DejaBlue (CVE-2019-1181/1182) let an unauthenticated attacker execute code before login, no user interaction required — the WannaCry-style “one packet, whole network” scenario.
• MITM and session hijacking. If the RDP server uses only RDP Standard Security or a self-signed certificate that users click past, a man-in-the-middle (for example Seth) can downgrade the connection and lift cleartext credentials.
• Lateral movement. Inside a network, RDP is a favourite pivot: reuse a captured password or hash to hop admin-to-admin across hosts, harvesting more credentials at each stop.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Detect the service and grab version info

nmap -sV -p 3389 <target>

Leak host, domain, and OS build (NLA info disclosure)

nmap -p 3389 --script rdp-ntlm-info <target>

With NLA/CredSSP reachable, rdp-ntlm-info sends a null CredSSP request and reads back the NTLMSSP reply — NetBIOS and DNS computer/domain names, plus the exact OS build (e.g. 10.0.14393).

Check the security layer and encryption

nmap -p 3389 --script rdp-enum-encryption <target>

Check for MS12-020

nmap -p 3389 --script rdp-vuln-ms12-020 <target>

Fingerprint and BlueKeep check with Metasploit

msfconsole -q
use auxiliary/scanner/rdp/rdp_scanner
set RHOSTS <target>
run

# Safe BlueKeep vulnerability check (does not crash the target)
use auxiliary/scanner/rdp/cve_2019_0708_bluekeep
set RHOSTS <target>
run

Connect with a client

xfreerdp /v:<target> /u:administrator /p:'Passw0rd!'
rdesktop <target>

Brute-force with Hydra or Ncrack

hydra -t 1 -V -f -l administrator -P passwords.txt rdp://<target>
ncrack -vv --user administrator -P passwords.txt rdp://<target>:3389

Confirmed BlueKeep exploitation via exploit/windows/rdp/cve_2019_0708_bluekeep_rce is ranked Manual for a reason: the wrong target profile blue-screens the host, so treat it as a lab-only test, not a click-and-run. Record every exposed RDP host, weak credential, and vulnerable build as you confirm it so the evidence lands in the pentest report rather than a scratch terminal.

What to Look For

Known CVEs and Exploits

• CVE-2019-0708 — BlueKeep. A use-after-free (CWE-416) in Remote Desktop Services that gives an unauthenticated attacker remote code execution before login, and is wormable. CVSS 3.1 base 9.8 (Critical). Affects Windows 7 SP1, Server 2008 SP2, and Server 2008 R2 SP1 (Microsoft also shipped emergency patches for the end-of-life Windows XP and Server 2003). Weaponised as Metasploit’s exploit/windows/rdp/cve_2019_0708_bluekeep_rce (Manual rank — it BSODs on the wrong target) with a safe check in auxiliary/scanner/rdp/cve_2019_0708_bluekeep, and archived as Exploit-DB 47416.
• CVE-2019-1181 / CVE-2019-1182 — DejaBlue. The same class of pre-auth, no-interaction RCE in Remote Desktop Services, both 9.8 (Critical), but reaching newer builds BlueKeep did not — Windows 7 SP1 through Windows 10 and Server 2012 through 2019. NLA still helps here because it forces authentication before the vulnerable code path is reached.
• CVE-2020-0609 / CVE-2020-0610 — BlueGate. Pre-auth RCE in the Windows RD Gateway role (Server 2012, 2012 R2, 2016, 2019), reachable over the gateway’s UDP/TCP 3391 and HTTPS paths — an important reminder that publishing RD Gateway is not automatically safe. Both 9.8 (Critical); public PoCs exist.
• CVE-2012-0002 — MS12-020. A flaw in how RDP handles the T.125 maxChannelIDs field. NVD rates it code execution (CVSS v2 9.3), but in practice no reliable public RCE ever materialised; it was widely used as a denial-of-service that blue-screens the host (the paired DoS is CVE-2012-0152). Metasploit ships it as auxiliary/dos/windows/rdp/ms12_020_maxchannelids, the nmap rdp-vuln-ms12-020 NSE checks for it, and it is archived as Exploit-DB 18606.
• CVE-2018-0886 — CredSSP Remote Code Execution. Improper authentication (CWE-287) in the CredSSP provider RDP uses for NLA: a man-in-the-middle who intercepts the handshake can relay it and run commands in the session. CVSS 3.0 base 7.0 (High); the fix is the “CredSSP Encryption Oracle Remediation” hardening rolled out from May 2018.

Mitigation

• Never expose RDP directly to the internet. Put it behind a VPN, an RD Gateway, or Azure Bastion so port 3389 is reachable only after a separate authenticated tunnel — and patch the gateway itself (see BlueGate above).
• Enforce Network Level Authentication (NLA). NLA requires valid credentials before a session is established, closing off pre-auth RCE paths and stopping the rdp-ntlm-info information leak.
• Add MFA and strong passwords. Require multi-factor authentication for RDP (via RD Gateway, Azure MFA, or Duo) and enforce long, unique passwords — this is what defeats brute-force and credential stuffing.
• Turn on account lockout and monitor logons. Set a lockout threshold and alert on failed-logon storms; watch Windows Event ID 4625 (failed logon) and 4624 (successful logon) for RDP spikes.
• Patch relentlessly. BlueKeep and DejaBlue are the reason — keep Remote Desktop Services and RD Gateway current on every reachable host.
• Restrict who can RDP and from where. Limit the “Remote Desktop Users” group, block local administrators from logging on over RDP where you can, and firewall port 3389 to specific management ranges with geo/network restrictions.
• Use a valid certificate. Replace the default self-signed RDP certificate with one from your PKI so downgrade and MITM tooling like Seth can’t quietly slip in.

Real-World Example

For several years running, incident-response firms have put exposed RDP at or near the top of the ransomware initial-access chart. Coveware, Sophos, and others repeatedly found that a large share of ransomware cases — Ryuk, Dharma/CrySIS, and later crews among them — began with an internet-facing port 3389 that was brute-forced or opened with credentials bought from an access broker. The pattern is mundane: a server gets a public IP for “temporary” remote access, bots find it within hours, a weak or reused administrator password falls, and the attacker walks in through a legitimate desktop session, disables defences, and detonates. Separately, in November 2019 the first mass BlueKeep (CVE-2019-0708) exploitation appeared in the wild — a campaign that dropped a Monero coin-miner, and crashed a great many unpatched hosts into a blue screen in the attempt, exactly as the vulnerability’s wormable, memory-corruption nature predicted. Both stories point the same way: RDP is powerful, and that is precisely why it must never sit unguarded on the internet.

FAQ

What is port 3389 used for?

Port 3389 is the default port for the Remote Desktop Protocol (RDP), which lets you control a full Windows graphical desktop from another machine — the connection made by the mstsc.exe Remote Desktop client. On Windows the service is Remote Desktop Services; on Linux, xrdp provides a compatible listener.

Is port 3389 dangerous to expose?

Yes. An internet-facing port 3389 is one of the most heavily attacked services online and has repeatedly been the single most common entry point for ransomware. Even with a strong password, exposed RDP invites constant brute-force and risks pre-auth exploits like BlueKeep. Keep it behind a VPN or RD Gateway, never on a raw public IP.

What service runs on port 3389?

Remote Desktop Services (the Windows TermService), which speaks RDP. Clients connect with mstsc.exe on Windows or xfreerdp / rdesktop on Linux. On Linux servers, the xrdp daemon offers the same protocol on the same port.

Does RDP use TCP or UDP?

RDP is primarily a TCP service on port 3389. Since Windows 8 / Server 2012 it can also open a UDP transport on port 3389 to improve responsiveness over lossy links, but the core connection and authentication happen over TCP, which is what you scan and secure first.

How do I secure or close port 3389?

Take RDP off the public internet — reach it only through a VPN, RD Gateway, or Azure Bastion — then enforce NLA, require MFA, set an account-lockout policy, restrict the Remote Desktop Users group, and patch Remote Desktop Services. If a host does not need remote desktop at all, disable Remote Desktop and firewall TCP/UDP 3389, then rescan with nmap -p 3389 <target> to confirm it is closed.

TL;DR

• Service: RDP (Remote Desktop Protocol) via Remote Desktop Services / xrdp
• Default port: 3389/TCP (optional 3389/UDP acceleration transport)
• Biggest risk: internet exposure — the top ransomware initial-access vector — plus pre-auth RCE (BlueKeep, DejaBlue) and brute-force
• Mitigation: never expose RDP directly; require VPN/RD Gateway + NLA + MFA + lockout, and patch