RDP (Remote Desktop Protocol) on port 3389 is Microsoft's remote desktop protocol — used to access Windows servers and workstations remotely with full graphical desktop. It is the standard remote-administration tool for Windows environments. It is also one of the most-attacked ports on the public internet, alongside SSH and SMB.
The standard attack pattern is credential brute force followed by full system compromise. Successful RDP login gives the attacker the same privileges as the user — for admin accounts, that is full system control. Worse, RDP has historically had wormable vulnerabilities — BlueKeep (CVE-2019-0708) was a remote-code-execution vulnerability that allowed compromise without credentials, affecting older Windows versions. The pattern recurs: complex protocol surface plus widespread internet exposure produces severe vulnerabilities.
For defenders, the answer is unambiguous: RDP should never be directly exposed to the internet. The standard remote-access pattern for Windows in 2026 is RDP behind a VPN, RDP behind a Remote Desktop Gateway (RD Gateway) with proper authentication, or modern zero-trust solutions like Microsoft Entra Private Access or alternative ZTNA products. Direct RDP on port 3389 to public IPs is a critical finding in any security assessment.
Five real-world scenarios involving port 3389
External pentest — finding internet-exposed RDP
Standard external pentest reconnaissance includes scanning client IP ranges for RDP. Findings are usually critical-priority — internet-exposed RDP is a known attack vector with active exploitation. Standard tooling: nmap with rdp-enum-encryption script, masscan for fast wide scans, Shodan queries for the client's IP space. Pair with credential brute force using hydra or rdesktop-based tools.
Red team — RDP as initial access vector
Many red-team operations begin with RDP brute force against discovered exposed instances. Common credential combinations work surprisingly often — administrator/Password123, the user's name as both username and password, default service account credentials. Once inside, RDP gives full graphical session and the ability to install tools, dump credentials, and pivot.
Ransomware investigations frequently trace initial access to RDP. Indicators in event logs: successful RDP logins from unusual IPs, unusual hours, or with unusual user accounts. Look for Event ID 4624 with Logon Type 10 (RemoteInteractive). The attacker often dwells for days or weeks before deploying ransomware, so the actual compromise date is usually before any obvious symptoms.
Attack surface reduction — auditing RDP access in your environment
Periodic audit: scan your internal network for RDP-listening hosts, identify which need RDP and which can have it disabled, restrict access to specific source networks (admin VPN, jumphost), enable Network Level Authentication on all RDP services, configure account lockout after failed attempts. Many environments have legacy hosts running unnecessary RDP services that can simply be disabled.
Compliance — RDP requirements for security frameworks
Most security frameworks (PCI DSS, HIPAA, SOC 2, ISO 27001) require remote access to be MFA-protected and logged. RDP without MFA fails these requirements. Solutions: RDP via RD Gateway with MFA (Duo, Azure MFA), Entra Private Access with conditional access policies, or modern ZTNA replacing RDP with browser-based access patterns.
Common mistakes & edge cases
Exposing RDP directly to the public internet
The single most common mistake. Even with strong passwords, the next wormable RDP CVE makes you vulnerable regardless. Never expose RDP directly. Behind VPN, RD Gateway, or ZTNA — those are the only acceptable patterns.
Using port 3389 → 3390 → 3391 thinking port change provides security
Same as SSH — non-standard port reduces opportunistic scanner traffic but does not stop targeted attacks. Modern scanners (masscan, Shodan) check all ports. Port change is operational hygiene, not security. The actual fix is removing public exposure.
Disabling Network Level Authentication for "compatibility"
Network Level Authentication (NLA) requires the user to authenticate before the full RDP session is established — protects against connection-flooding and pre-auth vulnerabilities. Disabling NLA for old client compatibility is a common bad pattern. Modern Windows clients all support NLA; legacy clients should be upgraded, not accommodated.
No RDP-specific audit logging
Default Windows logging captures RDP logins but the data is buried in Security event logs. Set up log forwarding to a SIEM, alerting on unusual RDP patterns (logins from unusual countries, unusual hours, multiple failures), and regular review of RDP usage. Without monitoring, attackers dwell undetected for weeks.
Sharing RDP credentials across users or computers
Each admin needs their own account; don't share "administrator" credentials across the team. Each computer needs its own local accounts; don't use the same credentials across machines (lateral-movement amplifier). Use Microsoft's LAPS (Local Administrator Password Solution) or Windows LAPS (the built-in successor) to manage per-machine local admin passwords.
Treating "behind a firewall" as sufficient for RDP
Firewall protection is necessary but not sufficient. Firewalls fail open occasionally, rules get changed, and attackers who breach the perimeter can pivot to RDP from inside. Layer defences: firewall + NLA + MFA + account lockout + monitoring + restricted source IPs. Each layer compensates for failures in others.
Frequently Asked Questions about port 3389
Remote Desktop Protocol — Microsoft's protocol for remote desktop access to Windows machines. Provides full graphical session including desktop, applications, audio, file transfer, printer redirection. Default port 3389. The standard remote-administration tool for Windows environments. Equivalent to VNC for Windows but with better performance and integrated authentication.
Three reasons: (1) RDP has historically produced wormable pre-authentication CVEs that bypass credentials entirely (BlueKeep, DejaBlue), (2) credential brute force is highly automated and effective against weak passwords, (3) successful access gives full graphical session — attacker can install tools, dump credentials, pivot. Unlike SSH where an attacker is dropped into a shell with limited tooling, RDP gives them the full Windows GUI.
CVE-2019-0708 — a wormable RDP vulnerability in older Windows versions (XP, 7, Server 2003/2008). Required no authentication and could spread automatically. Microsoft considered it severe enough to release patches for end-of-life Windows XP. The active exploitation period saw mass-scanning for vulnerable hosts. The lesson: complex protocols + widespread exposure produce severe vulnerabilities periodically.
NLA requires the user to authenticate before the full RDP session is established. Protects against pre-auth vulnerabilities (the auth happens before the vulnerable RDP code path runs) and reduces server resource consumption from connection floods. Always enable NLA. The performance and security benefits are unambiguous; only legacy clients without NLA support need it disabled, and those clients should be upgraded.
A reverse proxy for RDP — clients connect to the RD Gateway over HTTPS (port 443), the gateway authenticates them, then proxies to internal RDP servers. Allows RDP without exposing port 3389 directly. Supports MFA integration. Standard pattern for organisations not yet on ZTNA. Configuration requires AD/LDAP integration and proper certificate setup.
Several modern options: Microsoft Entra Private Access (zero-trust replacement for VPN+RDP), Cloudflare Access with Remote Browser Isolation, AnyDesk / TeamViewer for individual access, Apache Guacamole for browser-based RDP, Citrix Virtual Apps for managed remote desktop. The right choice depends on scale, existing identity infrastructure, and security requirements.
GUI: System Properties → Remote tab → Allow Remote Connections. Command line: netstat -an | findstr 3389 shows whether anything is listening. PowerShell: Get-Service TermService. The Windows Firewall rule for "Remote Desktop" governs whether external connections are allowed.
Yes — multiple RDP clients exist for Linux (rdesktop, freerdp, Remmina), macOS (Microsoft Remote Desktop), iOS/Android (Microsoft Remote Desktop apps). All implement the RDP protocol and connect to Windows servers identically.
Windows Security event log captures RDP logins under Event ID 4624 with Logon Type 10 (RemoteInteractive). Failed logins are Event ID 4625. Forward these to a SIEM, alert on: logins from unusual countries, unusual hours, multiple failures from one source, successful logins after many failures. Sysmon adds richer logging including process creation post-login.
3389 TCP is the primary connection port. UDP 3389 is used for the multipath transport in newer RDP versions (improves performance). 443 is used by RD Gateway when configured. Some advanced features use additional ports — block all of them at the perimeter unless explicitly needed.