How to Prevent Unauthorized Access to Your RDP Server

If you want to prevent unauthorized access to your remote desktop server, the most important action you can take right now is closing inbound TCP port 3389 to the public internet and enforcing multi-factor authentication on every login path. RDP was abused in 90% of incident response cases in 2023 (full-year aggregate, Sophos threat research), and compromised credentials drove more than half of those attacks. That is not a software flaw or an obscure vulnerability. It is the result of servers sitting on the public internet with port 3389 open, no MFA, and default configurations that automated brute-force tools were literally designed to exploit. If your remote desktop server is reachable from the internet right now, it has already been scanned. It is probably being queued for credential guessing as you read this.

The good news is that the fix is not complicated. It is layered. This guide covers five distinct security controls, starting with removing public exposure and finishing with monitoring and incident response. Whether you manage your own on-premises Windows Server or run hosted infrastructure through a provider like DashRDP, these controls apply directly to your environment.

Why your remote desktop server is already being targeted

The attack scale most admins underestimate

RDP was leveraged in 95% of attacks in the first half of 2023 (H1 figure, Cybereason incident data), a higher rate than the 90% full-year figure in the introduction because H1 2023 saw a concentrated ransomware campaign surge before midyear. That figure was up from 88% the year before. Southeast Asia alone documented 35.2 million RDP attacks in 2025, and historical data from peak pandemic periods shows brute-force attempts surging past 400 million per month globally. These numbers matter because they reveal the nature of the threat: this is not a sophisticated, targeted operation. It is automated infrastructure sweeping every internet-facing port 3389 it can find, cycling through credential lists, and moving on. Your server does not need to be a high-value target to get hit.

In 2024, security researchers tracked over 23 million brute-force attempts against RDP infrastructure in Southeast Asia in just the first six months of the year. That regional figure alone puts the global scope in perspective. Verizon’s 2025 Data Breach Investigations Report confirmed that RDP remains a preferred ransomware entry point, present in 44% of breaches studied. The attack volume has not declined; it has professionalized.

How attackers actually get in

The typical attack chain is straightforward: an automated scanner identifies open port 3389, a brute-force tool cycles through credential lists purchased from previous data breaches, and once a match is found, RDP becomes the vehicle for lateral movement through the rest of the network. MFA was absent in 39% of incident response cases in the first half of 2023, and that absence was the deciding factor in most successful intrusions. The entry point is almost never a zero-day exploit. It is a predictable configuration gap that the attacker’s tooling was built to find.

Lateral movement is where the real damage happens. In 77% of 2023 RDP incidents, attackers used RDP internally after initial access to move through the network, up from 65% the year before. Understanding this attack chain is what drives every decision in the sections below. You are not just protecting a login prompt. You are cutting off an entire post-breach playbook.

Remove public exposure to prevent unauthorized access to your remote desktop server

Block port 3389 at the perimeter: this is step one

The single most impactful action you can take is closing inbound TCP port 3389 on your firewall, cloud security group, or network security group. Until that port is invisible to the public internet, every other control you layer on top is playing defense against an open front door. In Windows Firewall, scope the built-in “Remote Desktop” inbound rule to your VPN subnet instead of “Any.” On cloud-hosted infrastructure, enforce this restriction at the network security group or security group level, not just the OS firewall, so the rule survives any OS-level misconfiguration.

Changing the default port from 3389 to a high random port (like 45289) reduces automated scanning noise, and it is worth doing as a secondary measure. But be clear-eyed about what it buys you: a reduction in log volume, expect to see several hundred fewer scan attempts per day in most environments, not actual protection. Targeted attackers run full port scans. Port obscurity is time-buying, not security.

Replace direct exposure with a VPN tunnel or RD Gateway

Once port 3389 is closed, access needs a secure path back in. Two options work well here. The first is a VPN gateway: users connect to an encrypted private network first, then reach RDP internally as if they were on a local network. WireGuard is the preferred choice for Windows VPS environments due to its simpler setup and better performance compared to OpenVPN. The second option is Microsoft’s RD Gateway, which proxies RDP traffic over HTTPS on port 443, eliminating the need to expose port 3389 at all while supporting MFA and NLA natively.

RDP servers on DashRDP come with full admin access and support VPN layering directly, meaning you can configure a WireGuard or OpenVPN tunnel on top of your existing environment without working around hosting restrictions. For teams that want this protection in place without building a self-hosted VPN stack from scratch, that admin-level flexibility means the configuration actually gets deployed rather than remaining a plan on paper. Once the VPN is active, disable public RDP access at the firewall or your provider’s security group, and your remote desktop server becomes unreachable from the public internet entirely.

Harden authentication to prevent unauthorized access to your remote desktop server

Enable Network Level Authentication on every Windows host

Network Level Authentication forces users to authenticate before the RDP session is even established. That blocks most brute-force tools from reaching the login prompt in the first place. To enable it via the GUI, go to System Properties (run sysdm.cpl), click the Remote tab, and select “Allow connections only from computers running Remote Desktop with Network Level Authentication.” For scripted or remote deployment, set the UserAuthentication value to 1 under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp.

For domain-joined machines, use Group Policy at Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security and enable “Require user authentication for remote connections by using Network Level Authentication.” Group Policy overrides local settings, so it is the right enforcement layer for any managed environment. Also set the Security Layer registry value to 2 (SSL) or 3 (SSL + NLA) to force TLS encryption and prevent legacy protocol downgrade attacks.

Add multi-factor authentication to the RDP login flow

MFA is the most important single addition for stopping credential-based attacks. The integration path depends on your environment. If you are running RD Gateway, the Azure AD plus NPS Extension approach is the native Microsoft path: install the NPS Extension on your NPS server, configure Conditional Access to require MFA, and set the MFA method to push notifications via Microsoft Authenticator. OTP codes do not work for standard RDP because the login prompt has no input field for them.

For direct RDP connections without RD Gateway, agent-based solutions are the right choice. Three options cover most environments:

• LoginTC, installs a Windows Credential Provider directly on the RDP host; supports push, FIDO2, and offline codes
• IS Decisions UserLock, agentless and AD-integrated; works for external RDP connections without requiring a gateway and can enforce MFA based on logon origin
• FIDO2 hardware tokens, the appropriate choice for CISA-aligned environments or privileged admin accounts

One critical note: Windows Hello for Business does not work for standard RDP authentication. Push-based or hardware token methods are what the protocol actually supports.

Set strict account lockout policies

Configure account lockout at a threshold of five invalid attempts, with a 15-minute lockout duration and a 15-minute reset counter. The Group Policy path is Local Security Policy > Account Policies > Account Lockout Policy. This setting alone makes brute-force attacks computationally impractical against any account where the password is not already in a breach list. Rename the built-in Administrator account to something non-obvious, assign a dedicated service account with login-hour restrictions for any automated processes, and ensure no accounts combine “password never expires” with weak credentials.

Firewall rules and automated blocking that stop brute-force cold

IP whitelisting is your most effective firewall control

IP whitelisting eliminates the attack surface for any IP not on the approved list. In Windows Firewall, scope the “Remote Desktop” inbound rule to your specific source IP range, such as your office subnet or VPN address pool, instead of “Any.” For Linux-based hosts or perimeter firewalls, the iptables approach is direct: iptables -A INPUT -p tcp, dport 3389 -s [trusted-IP] -j ACCEPT, followed by a catch-all DROP rule for everything else. Geo-blocking adds a medium layer of protection by blocking traffic volumes from untrusted regions, but it fails against attackers operating through infrastructure in allowed countries, so it should supplement whitelisting rather than replace it.

Automate threat response with Fail2ban or IPS rate limiting

Fail2ban monitors /var/log/auth.log and dynamically adds DROP rules after a configurable number of failures. The key configuration block: set maxretry = 5, bantime = 1h, and findtime = 10m. That combination bans any IP that fails five times within a 10-minute window for one hour, which makes brute-force computationally expensive before it ever produces a valid session.

For advanced firewall environments running pfSense or iptables with ipset, state-tracking patterns add another layer. Track repeated new connections to port 3389, escalate through staged lists, and move repeat offenders into a DROP list with a 30-minute timeout. The logic is: a new connection goes into rdp_stage1, repeats escalate through stages, and once an IP hits rdp_drop, all traffic from that IP is discarded for the timeout window. This architecture makes sustained brute-force attacks functionally impossible without burning through a massive pool of source IPs.

Monitor login attempts and know what to do when something looks wrong

What to log and which signals actually matter

The Windows Security Event Log is your primary data source. The critical Event IDs to monitor are 4625 (failed logon), 4624 (successful logon), 4648 (logon with explicit credentials), and 4778/4779 (RDP session connected/disconnected). For RDP-specific filtering, look for Event ID 4625 where Logon Type equals 10 (RemoteInteractive). A high volume of these events from the same source IP within a short window is a brute-force indicator. If NLA is enabled, failed attempts may also generate Event ID 4771 (Kerberos pre-authentication failed) before reaching the RDP service.

Set alert thresholds for three patterns: repeated 4625 events from the same IP within any 10-minute window, successful 4624 logons from unrecognized geographic locations, and after-hours successful logins on admin accounts. SIEM tools like Elastic or Splunk make correlation at scale significantly easier, but even Windows Event Forwarding to a central log server gives you enough visibility to catch active attacks before they escalate.

Incident response checklist when something looks suspicious

When a suspected unauthorized access event occurs, speed matters more than thoroughness in the first few minutes. Isolate the compromised server from the network immediately. Revoke all active RDP sessions and rotate every credential on the affected machine. Pull the 4624 and 4648 logs to check for lateral movement indicators: look for logons to other internal hosts that trace back to the compromised session timeframe.

Check scheduled tasks and local accounts for persistence mechanisms added during the intrusion window. Preserve logs before starting remediation, because log data is often the only forensic trail available. The 77% statistic on lateral movement is not just a data point: speed of containment directly limits the blast radius. An attacker who has been in your network for 20 minutes has a fundamentally different capability than one who has been in for six hours.