RDP Port 3389: The Security Risk and How to Close It

By Katia Belokon

Quick Answer

The rdp port 3389 security risk centers on visibility and attack surface, not just whether the port is open. When Remote Desktop Protocol runs on its default TCP port 3389, automated scanners across the internet continuously probe that port looking for weak credentials, unpatched systems, and misconfigurations. The risk is not theoretical—exposed RDP endpoints face thousands of login attempts daily, and successful breaches often lead to ransomware deployment, data theft, or lateral network movement.

Understanding rdp port 3389 security risk requires separating the protocol’s legitimate function from the exposure created when that port faces the public internet without layered controls. A public IP address check using MyIPScan shows your visible network endpoint, but it does not reveal whether port 3389 is open, whether RDP is listening, or whether your firewall rules permit inbound connections. Those details require port scanning, firewall review, and network configuration analysis.

This guide walks through the specific risks, how attackers exploit port 3389, what changes when you secure or relocate the service, and how to verify your configuration without relying on vague security promises.

Why Port 3389 Attracts Constant Attack Traffic

Port 3389 is the IANA-assigned default for Remote Desktop Protocol. Because this assignment is public and consistent across Windows systems, attackers do not need to guess—they scan entire IP ranges looking for any system responding on TCP 3389. Once a response is detected, automated tools attempt credential stuffing, brute force attacks, and exploit probes against known RDP vulnerabilities.

The volume is significant. Security telemetry from honeypots and intrusion detection systems shows that newly exposed RDP endpoints receive login attempts within minutes of becoming visible. These are not targeted attacks; they are opportunistic scans run continuously by botnets, ransomware operators, and credential harvesters.

The rdp port 3389 security risk escalates when organizations or home users expose the port directly to the internet without additional authentication layers, network segmentation, or rate limiting. Even strong passwords face erosion over time when subjected to millions of automated attempts, especially if account lockout policies are weak or absent.

How Attackers Enumerate and Exploit RDP

Attack workflows typically follow this sequence:

• Port scanning: Tools like Masscan or Shodan identify systems with port 3389 open and responsive.
• Service fingerprinting: Attackers confirm RDP is running and may identify the Windows version or patch level through protocol responses.
• Credential attacks: Brute force, credential stuffing from leaked password databases, or default credential lists are applied against discovered endpoints.
• Exploitation: If credentials succeed, attackers gain interactive desktop access. If credentials fail but a vulnerability exists (such as BlueKeep or similar RCE flaws), exploitation may proceed without valid credentials.
• Post-compromise: Once inside, attackers disable logging, create persistence mechanisms, move laterally, exfiltrate data, or deploy ransomware.

This sequence is automated. A single compromised RDP session can become the entry point for network-wide compromise, especially when the compromised account has administrative privileges or when internal network segmentation is weak.

Specific Vulnerabilities That Amplify the Risk

Beyond brute force, several RDP-specific vulnerabilities have been exploited in the wild. Understanding these helps clarify why the rdp port 3389 security risk is not just about password strength.

BlueKeep (CVE-2019-0708)

BlueKeep is a remote code execution vulnerability affecting older Windows versions (Windows 7, Server 2008, and earlier). It allows an unauthenticated attacker to execute arbitrary code by sending specially crafted requests to an RDP service. No user interaction or valid credentials are required. Microsoft issued patches in May 2019, but unpatched systems remain vulnerable, and exploit code is publicly available.

DejaBlue (CVE-2019-1181, CVE-2019-1182)

DejaBlue refers to a set of RCE vulnerabilities in RDP services on Windows 10 and Server 2019. Like BlueKeep, these flaws allow pre-authentication remote code execution. Exploitation can lead to full system compromise without any user action.

Man-in-the-Middle and Encryption Downgrade

RDP supports multiple encryption levels. Misconfigured servers may accept weaker encryption or fail to enforce certificate validation, allowing attackers on the network path to intercept or modify RDP sessions. While this is less common when RDP is exposed directly to the internet, it becomes relevant in shared or untrusted network environments.

Session Hijacking

If an attacker gains local administrator access on a system with active RDP sessions, they can hijack those sessions without needing the user’s password. This is a post-compromise technique, but it illustrates how RDP can be leveraged for lateral movement once initial access is achieved.

What Changes When You Secure Port 3389

Securing RDP does not mean disabling remote access. It means reducing the attack surface and adding authentication layers that make automated exploitation impractical. Here are the controls that materially change the risk profile.

Change the Listening Port

Moving RDP from port 3389 to a non-standard port (such as 49152 or another high-numbered port) reduces visibility to automated scanners. This is security through obscurity, not a robust defense, but it eliminates the majority of opportunistic scanning traffic. Attackers who specifically target your organization will still find the service through full port scans, but casual botnets will move on.

To change the RDP port on Windows, modify the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\PortNumber and restart the Remote Desktop service. Ensure your firewall rules are updated to allow the new port and block the old one.

Require Network-Level Authentication (NLA)

Network-Level Authentication forces users to authenticate before an RDP session is established. This prevents unauthenticated attackers from reaching the login screen and reduces exposure to pre-authentication exploits. NLA is enabled by default on modern Windows versions but should be verified in Group Policy or system settings.

Use a VPN or Bastion Host

Instead of exposing RDP directly to the internet, place it behind a VPN or bastion host. Users connect to the VPN first, then access RDP over the private network. This adds a strong authentication layer (VPN credentials, certificates, or multi-factor authentication) before RDP is even reachable. The public IP address visible to the internet no longer responds on port 3389, eliminating the primary attack vector.

Enable Multi-Factor Authentication

Multi-factor authentication (MFA) requires a second factor beyond username and password—such as a time-based one-time password, hardware token, or push notification. Even if credentials are compromised through phishing or a data breach, MFA blocks unauthorized access. Windows Server supports MFA through third-party providers or Azure AD integration.

Restrict Access by IP Address

Firewall rules can limit RDP access to specific IP addresses or ranges. If remote users connect from known locations or through a VPN with a static IP, restrict port 3389 to those addresses only. This is effective for small teams but becomes difficult to manage when users connect from dynamic IPs or mobile networks.

Apply Rate Limiting and Account Lockout Policies

Configure account lockout policies to disable accounts after a small number of failed login attempts. Combine this with rate limiting at the firewall or intrusion prevention system to slow down brute force attacks. Be cautious with lockout thresholds—too aggressive, and legitimate users may be locked out; too lenient, and attackers have room to guess.

How to Verify Your RDP Exposure

Verification requires checking both your public-facing network configuration and your internal RDP settings. A public IP check alone does not reveal whether port 3389 is open or listening.

Check Your Public IP and Network Visibility

Start by identifying your public IP address. Use MyIPScan to see the address, ISP, and approximate location visible to external services. This is the address attackers will scan when probing your network.

Next, verify whether port 3389 is reachable from the internet. Use an external port scanner (such as Nmap from a remote system or an online port checking service) to test whether TCP 3389 responds. If the port is open and responsive, your RDP service is exposed.

Review Firewall Rules

Check your router, firewall, or cloud security group rules. Look for any rule that permits inbound traffic on TCP 3389 from any source (0.0.0.0/0 or ::/0). If such a rule exists, your RDP service is exposed to the internet. Remove or restrict the rule to specific trusted IP addresses.

Inspect RDP Configuration on the Host

On the Windows system running RDP, verify the listening port, NLA status, and encryption settings. Open the Registry Editor and navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp. Check the PortNumber value (default is 3389 in hexadecimal: 0xD3D). Confirm that UserAuthentication is set to 1 (NLA enabled).

Test DNS and Network Path

If you use a VPN or DNS-based filtering, verify that RDP traffic routes through the expected path. A DNS leak test can reveal whether DNS queries bypass your VPN, which may indicate that other traffic (including RDP) is also leaking outside the tunnel.

Common Misconfigurations That Increase Risk

Misconfiguration	Risk	How to Fix
Port 3389 open to 0.0.0.0/0	Exposes RDP to global scanning and brute force	Restrict firewall rules to specific IPs or place behind VPN
Weak or default passwords	Credential attacks succeed quickly	Enforce strong password policies and enable MFA
NLA disabled	Allows unauthenticated access to login screen and pre-auth exploits	Enable Network-Level Authentication in system settings
Unpatched RDP service	Vulnerable to BlueKeep, DejaBlue, and other RCE exploits	Apply all Windows security updates and enable automatic patching
No account lockout policy	Unlimited brute force attempts possible	Configure account lockout after several failed attempts
Administrator account enabled for RDP	Successful compromise grants full system control	Disable built-in Administrator account or rename it; use limited accounts

How to Interpret Security Check Results

When you run a port scan or network check, the result tells you whether port 3389 is reachable, not whether your overall RDP configuration is secure. A closed port is good, but it is only one layer. If the port is open, the next questions are: Is NLA enabled? Is MFA required? Are firewall rules restrictive? Are patches current?

A public IP check shows your visible network endpoint. If you connect through a VPN, the public IP should reflect the VPN server, not your ISP. If it shows your ISP, the VPN may not be active, or RDP traffic may be bypassing the tunnel. Repeat the check after connecting to the VPN and verify that the IP address changes.

DNS behavior can also reveal configuration issues. If your DNS resolver does not match your VPN provider, DNS queries may be leaking. This does not directly affect RDP, but it suggests that network traffic is not fully routed through the VPN, which could apply to RDP as well.

Before and After Comparison

Run a baseline check before making any changes. Record your public IP, open ports, DNS resolver, and RDP configuration. Then apply one security control—such as enabling NLA, changing the port, or adding a firewall rule—and repeat the checks. Compare the results to confirm the change had the intended effect.

If the port remains open after you believe you closed it, check for multiple network interfaces, cloud security group rules, or upstream firewall configurations that may override local settings.

When RDP Exposure Is Acceptable

There are scenarios where exposing RDP to the internet is unavoidable, such as remote support for systems without VPN infrastructure or legacy applications that require direct RDP access. In these cases, the rdp port 3389 security risk must be managed through layered controls rather than eliminated.

Use a non-standard port, enforce MFA, enable NLA, apply strict account lockout policies, restrict access by IP where possible, and monitor logs for failed login attempts. Deploy an intrusion detection system to alert on suspicious activity, and ensure all systems are patched promptly.

Even with these controls, understand that exposure increases risk. The goal is to make exploitation difficult enough that attackers move to easier targets, not to achieve perfect security.

How Attackers Use Compromised RDP Sessions

Once an attacker gains RDP access, the session provides interactive desktop control equivalent to physical access. Common post-compromise actions include:

• Disabling security tools: Antivirus, endpoint detection, and logging services are stopped or uninstalled.
• Creating persistence: New user accounts, scheduled tasks, or registry modifications ensure continued access even if the original credentials are changed.
• Lateral movement: The compromised system is used to scan the internal network, access file shares, or pivot to other systems using cached credentials or pass the-hash attacks.
• Data exfiltration: Sensitive files are copied to external storage or uploaded to attacker-controlled servers.
• Ransomware deployment: Encryption tools are executed across the network, often targeting backups first to prevent recovery.

The time between initial compromise and ransomware deployment can be hours or days. Attackers often wait to understand the network, identify high-value targets, and disable backups before triggering encryption.

Monitoring and Logging for RDP Activity

Effective monitoring can detect compromise attempts before they succeed. Enable detailed logging for RDP events in Windows Event Viewer. Key event IDs include:

• Event ID 4624: Successful logon (Type 10 indicates RDP)
• Event ID 4625: Failed logon attempt
• Event ID 4778: Session reconnected
• Event ID 4779: Session disconnected

Forward these logs to a centralized SIEM or log management system. Set alerts for patterns such as multiple failed logins from the same IP, successful logins from unexpected geographic locations, or logins outside normal business hours.

Review logs regularly. A sudden spike in failed login attempts indicates an active brute force attack. Immediate response should include blocking the source IP, verifying that account lockout policies are active, and checking for any successful logins from the same source.

Alternatives to Direct RDP Exposure

Several technologies provide remote desktop access without exposing port 3389 to the internet.

Remote Desktop Gateway

Remote Desktop Gateway (RD Gateway) is a Windows Server role that brokers RDP connections over HTTPS (port 443). Users connect to the gateway via HTTPS, and the gateway forwards the session to the internal RDP server. This eliminates the need to expose port 3389 and allows integration with MFA and certificate-based authentication.

VPN with Split or Full Tunneling

A VPN creates an encrypted tunnel between the user and the internal network. Once connected, the user accesses RDP over the private network. Full tunneling routes all traffic through the VPN; split tunneling routes only internal traffic. For RDP security, full tunneling is preferable to prevent DNS leaks or traffic bypassing the VPN.

Zero Trust Network Access (ZTNA)

ZTNA solutions authenticate users and devices before granting access to specific applications, including RDP. Unlike VPNs, which grant broad network access, ZTNA enforces least-privilege access and continuous verification. This reduces the attack surface and limits lateral movement if credentials are compromised.

Cloud-Based Remote Access Solutions

Services such as Azure Bastion or third-party remote access platforms provide browser-based RDP access without exposing port 3389. These solutions handle authentication, encryption, and session management, offloading security complexity from the end user.

Practical Checklist for Reducing RDP Port 3389 Security Risk

• Verify that port 3389 is not exposed to the internet (0.0.0.0/0) in firewall rules.
• Change the RDP listening port to a non-standard value if direct exposure is unavoidable.
• Enable Network-Level Authentication (NLA) on all RDP servers.
• Require multi-factor authentication for all RDP sessions.
• Restrict RDP access to specific IP addresses or place behind a VPN.
• Apply all Windows security updates and enable automatic patching.
• Configure account lockout policies to limit brute force attempts.
• Disable or rename the built-in Administrator account.
• Enable detailed RDP logging and forward logs to a centralized system.
• Set alerts for failed login attempts, unusual login times, or unexpected source IPs.
• Review firewall rules, security group settings, and router configurations regularly.
• Test RDP access from an external network to confirm controls are effective.
• Use a VPN, RD Gateway, or ZTNA solution instead of direct internet exposure when possible.

Understanding IP Address Visibility and RDP Risk

Your public IP address is the network endpoint visible to external systems. According to Cloudflare’s explanation of IP addresses, this address is assigned by your ISP or network provider and serves as the routing destination for inbound traffic. When port 3389 is open on this IP, any system on the internet can attempt to connect to your RDP service.

Changing your public IP (by switching ISPs, using a VPN, or reconnecting to obtain a new dynamic IP) does not eliminate the rdp port 3389 security risk if the port remains open on the new address. Attackers scan entire IP ranges continuously, so a new IP will be discovered and probed within hours or days.

The effective mitigation is not to hide the IP address but to close the port, restrict access, or place RDP behind an authentication layer that cannot be bypassed through network scanning.

Configuration Hardening If Exposure Is Unavoidable

In rare cases where direct RDP exposure cannot be avoided, layered hardening measures can reduce (but not eliminate) risk. These controls should be treated as mitigation, not as a substitute for proper network isolation.

Network Level Authentication (NLA)

Enable Network Level Authentication in RDP settings. NLA requires users to authenticate before a full RDP session is established, reducing the attack surface for pre-authentication exploits. This setting is enabled by default on modern Windows versions but should be verified.

Strong, Unique Passwords and Account Lockout Policies

Use complex, unique passwords for all accounts with RDP access. Implement account lockout policies to limit brute-force attempts, but be aware that aggressive lockout thresholds can be exploited for denial-of-service attacks against legitimate users.

IP Whitelisting

If the remote user’s IP address is static or falls within a known range, configure firewall rules to allow RDP connections only from those addresses. This dramatically reduces exposure, though it is not practical for users on dynamic IP addresses or mobile networks.

Multi-Factor Authentication (MFA)

Enforce multi-factor authentication for RDP access. This can be implemented through third-party tools, Group Policy configurations, or integrated identity platforms. MFA adds a second verification step, making credential-based attacks significantly harder.

Change the Default Port (Limited Effectiveness)

Changing RDP from port 3389 to a non-standard port reduces automated scan noise but does not prevent determined attackers. Port scanning tools check all 65,535 ports, so obscurity alone is not a security control. This measure can be combined with other hardening steps but should never be relied upon as the primary defense.

Decision Checklist: Should You Expose RDP?

Use this checklist to evaluate whether RDP should be exposed to the internet in your environment:

• Is there a business requirement for direct internet access to RDP, or can a VPN or gateway solution meet the need?
• Are all systems with RDP enabled fully patched and running supported operating system versions?
• Is Network Level Authentication (NLA) enabled on all RDP endpoints?
• Are strong, unique passwords enforced, and is multi-factor authentication in place?
• Is IP whitelisting feasible based on the remote user’s network configuration?
• Are RDP connection attempts logged, monitored, and reviewed regularly?
• Is there a documented incident response plan for unauthorized RDP access?
• Have you tested the exposure using external port scans and verified firewall rules?

If the answer to any of these questions is no, direct RDP exposure introduces unacceptable risk. Implement alternative access methods or additional hardening controls before allowing internet-facing RDP.

FAQ

Is it safe to expose RDP port 3389 to the internet?

Exposing RDP port 3389 directly to the internet is not safe without multiple layers of security controls. Automated scanners continuously probe port 3389, and successful credential attacks or exploitation of RDP vulnerabilities can lead to full system compromise, ransomware, or data theft. If direct exposure is unavoidable, use a non-standard port, enable Network-Level Authentication, require multi-factor authentication, restrict access by IP address, apply all security patches, and monitor logs for suspicious activity. Whenever possible, place RDP behind a VPN, Remote Desktop Gateway, or zero trust network access solution instead of exposing it directly.

How do I check if my RDP port is exposed to the internet?

First, identify your public IP address using a service like MyIPScan. Then use an external port scanner (such as Nmap from a remote system or an online port checking tool) to test whether TCP port 3389 is open and responsive from the internet. Also review your router, firewall, or cloud security group rules for any inbound rule that permits traffic on port 3389 from any source (0.0.0.0/0). If the port responds to external scans or if such a firewall rule exists, your RDP service is exposed. Close the port in your firewall or restrict access to specific trusted IP addresses.

What is the difference between changing the RDP port and using a VPN?

Changing the RDP port from 3389 to a non-standard port reduces visibility to automated scanners that only probe common ports. This is security through obscurity and does not prevent a determined attacker who performs a full port scan. Using a VPN places RDP behind an encrypted tunnel and requires VPN authentication before RDP is reachable. The VPN adds a strong authentication layer (often including multi-factor authentication) and hides RDP from internet scanning entirely. A VPN is a more robust security control than changing the port alone, but both can be combined for defense in depth.

Can attackers exploit RDP without valid credentials?

Yes. Vulnerabilities such as BlueKeep (CVE-2019-0708) and DejaBlue (CVE-2019-1181, CVE-2019-1182) allow remote code execution on unpatched RDP services without requiring valid credentials or user interaction. These are pre-authentication exploits, meaning an attacker can compromise the system before the login screen is reached. Enabling Network-Level Authentication (NLA) reduces exposure to some pre-authentication attacks, but the most effective mitigation is to apply all security patches promptly and avoid exposing RDP to the internet.

Does using a VPN hide my RDP traffic from my ISP?

Yes. When you connect to a VPN before initiating an RDP session, the RDP traffic is encrypted and tunneled through the VPN server. Your ISP can see that you are connected to a VPN, but it cannot see the contents of the traffic or that you are using RDP. The VPN server’s IP address becomes the visible endpoint, not your ISP-assigned IP. Still, if the VPN connection drops or if RDP traffic bypasses the VPN due to split tunneling or misconfiguration, your ISP may see the RDP traffic. Use a DNS leak test and verify your public IP address while connected to the VPN to confirm that all traffic routes through the tunnel.

What should I do if I detect a brute force attack on my RDP service?

Immediately block the source IP address at your firewall. Review Windows Event Viewer logs (Event ID 4625 for failed logins) to identify the scope of the attack and check for any successful logins (Event ID 4624, Type 10). If successful logins occurred, assume compromise and initiate incident response: disconnect the system from the network, change all passwords, review user accounts for unauthorized additions, scan for malware, and restore from a known-good backup if necessary. After containment, implement stronger controls such as multi-factor authentication, account lockout policies, IP whitelisting, or moving RDP behind a VPN to prevent recurrence.