RDP Brute Force Protection: Stop Remote Desktop Attacks

By Phil Chiu, ThreatListPro · Published March 14, 2026 · Last verified: October 23, 2026

To protect RDP from brute force, do not expose port 3389 to the internet: reach it through a VPN or an RD Gateway with MFA, or allow only known source addresses. Keep Network Level Authentication on, set an account lockout threshold, and log failed sign-ins. A firewall IP blocklist adds a layer but does not replace these.

Remote Desktop Protocol (RDP) listens on TCP port 3389 by default. Exposed RDP is a well-known ransomware entry point: bots scan for it and guess passwords, and one correct guess gives the attacker an interactive desktop with that account’s rights. This guide explains how the attacks work, why they are dangerous, and the defenses in order of impact.

What Is an RDP Brute Force Attack?

An RDP brute force attack is an automated attack on the Windows Remote Desktop service, which listens on TCP port 3389 by default. Attackers use botnets and automated tools to submit username and password combinations until one works. MITRE ATT&CK tracks the password guessing as T1110.001 — Password Guessing, and the use of RDP to move between systems after a login as T1021.001 — Remote Desktop Protocol.

The process is simple: scanning tools sweep large IP ranges for hosts with port 3389 open. When they find one, they try common usernames like Administrator, admin, user, and backup with passwords from breach lists and common patterns. Many campaigns use password spraying instead: one or two passwords across many usernames, which stays under per-account lockout thresholds.

Unlike VPN brute force attacks that target a login portal, RDP attacks target the desktop session directly. A successful RDP brute force gives the attacker an interactive Windows desktop with whatever privileges the compromised account holds—often local or domain administrator.

Why RDP Is a Common Ransomware Vector

CISA’s #StopRansomware Guide says ransomware actors often get initial access through exposed and poorly secured remote services, and it recommends not exposing services such as RDP to the internet. Here is why RDP draws so much attention:

• Easy to find: internet-wide scanners such as Shodan and Censys index hosts with port 3389 open, so exposed RDP is easy for attackers to list. Many organizations expose it for convenience.
• Direct desktop access: a VPN grants network access; RDP gives the attacker an interactive desktop. With an admin account they can install software, disable security tools, read files, and pivot to other systems.
• Weak authentication: many RDP deployments rely on a username and password with no MFA. Well-known account names like Administrator are the first ones tried.
• No domain lockout by default: in Active Directory’s Default Domain Policy, the account lockout threshold is 0, which means accounts never lock, until you change it. Microsoft also notes that the built-in Administrator account is excluded from lockout policy.
• Access is resold: initial access brokers sell working RDP logins to ransomware groups, so a guessed password has value even if the attacker who found it never uses it.

The Real Impact

The consequences of RDP brute force attacks extend far beyond the initial compromise. Even unsuccessful attacks cause significant operational damage:

Account Lockouts

When Active Directory account lockout policies are configured, RDP brute force attacks trigger lockouts for every username the attacker targets. This locks out legitimate administrators and users, preventing them from signing in to critical systems. Password campaigns against our own VPN portals have caused 50+ account lockouts per day; RDP exposed to domain accounts is open to the same problem. See account lockout prevention for more on lockouts caused by brute force.

Ransomware Deployment

When an attacker guesses an RDP credential, a common next step is ransomware. With interactive desktop access, attackers disable antivirus, exfiltrate sensitive data, and deploy ransomware across the network.

Data Exfiltration

Modern ransomware operations practice “double extortion”—they steal sensitive data before encrypting it. With RDP access, attackers can browse file shares, databases, and email archives, exfiltrating confidential information that is then used as additional leverage for ransom payment.

Compliance Violations

An RDP breach can trigger compliance violations across multiple frameworks. HIPAA requires access controls and audit logging for systems handling protected health information. PCI DSS requires multi-factor authentication for remote network access that could reach the cardholder data environment. A single compromised RDP session can result in reportable breaches, regulatory fines, and loss of certifications.

Incident Response Costs

Even when ransomware is not deployed, responding to an RDP compromise requires forensic investigation, credential resets, system rebuilds, and a review of how RDP is exposed, all of which take significant staff time.

RDP Defenses in Order of Impact

Start by taking RDP off the open internet, then harden the sign-in itself, then add layers that cut noise.

1. Take RDP Off the Internet (VPN or Source Allowlist)

Do not expose port 3389 to the internet. Require users to connect to a VPN first and reach RDP over the tunnel, or, where users have fixed addresses, allow 3389 only from those addresses at the firewall or cloud security group. Either way, port 3389 is no longer reachable by internet scanners and brute force bots.

If you already run a VPN, this is mostly a firewall change: restrict port 3389 to the VPN address pool. Remember that the VPN portal then becomes the internet-facing login, so harden it too (see VPN brute force explained).

2. RD Gateway with MFA

A Remote Desktop Gateway (RD Gateway) is a proxy for RDP connections. Instead of exposing port 3389, users connect to the gateway over HTTPS (port 443), and the gateway brokers the RDP session to the internal server. Add MFA at the gateway (for example through Network Policy Server with the Microsoft Entra MFA extension) so a guessed password alone is not enough.

Deploying an RD Gateway requires a Windows Server with the Remote Desktop Gateway role, a TLS certificate, and connection and resource authorization policies. Note that the gateway itself is now an internet-facing login, so it needs lockout, MFA, and monitoring.

3. Network Level Authentication

Network Level Authentication (NLA) requires users to authenticate before a remote session is created. Without NLA, the server builds a sign-in screen for anyone who connects, which uses resources and exposes more code to unauthenticated users. With NLA, credentials are checked first and only authenticated users get a session.

You can enforce it with the Group Policy setting Require user authentication for remote connections by using Network Level Authentication (Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Security). NLA reduces the attack surface, but it does not stop credential guessing; it only moves the check earlier.

4. Account Lockout, Account Names, and Logging

Set an account lockout threshold; Microsoft’s Windows security baselines suggest 10 failed attempts as a starting point. Lockout slows guessing but can be used to lock out real users, so pair it with a process for unlocking accounts. Disable or rename the built-in Administrator account, since older Windows builds exempt it from lockout unless the "Allow Administrator account lockout" policy is enabled, and keep RDP access to a dedicated group rather than all administrators. Failed sign-ins are logged as Security event ID 4625; alert on bursts of them.

5. Replace Direct RDP

Where possible, remove RDP exposure entirely with a different access path. Options include Azure Bastion for Azure VMs (RDP through the Azure portal with no public IP on the VM), SSH for command-line access, and management tools such as Windows Admin Center or commercial remote access products that do not require port 3389 to be open. How long this takes depends on the size of your environment and the tool you choose.

6. Firewall IP Blocklist (Extra Layer)

An IP blocklist loaded on your firewall as an External Dynamic List (EDL) drops listed IPs before their traffic reaches port 3389. It only helps against IPs already on the list, so it supplements the steps above rather than replacing them.

Be clear about what the ThreatListPro list is: it comes from real attacks on live production Palo Alto GlobalProtect VPN portals in the US, so it is not an RDP-specific feed. It covers RDP attackers only where the same sources also attack VPN portals. To use it, add the list URL as an EDL (see the Palo Alto setup guide or the other firewall setup guides), use it as the source in a deny rule placed above any rule that allows RDP, and commit. You can also check whether IPs from your own RDP logs are on the list.

Where Perimeter Blocking Fits for RDP

RDP differs from a VPN in one important way: it provides direct interactive desktop access. A compromised VPN credential gives network access, and the attacker still has to find and exploit internal systems. A compromised RDP credential gives a working Windows desktop with access to files and applications and the ability to install software.

That is why it matters where a connection is stopped. A firewall rule stops it before any sign-in attempt, unlike reactive tools that wait for failed logins (see ThreatListPro vs Fail2ban for a comparison). The strongest perimeter control for RDP is not exposing it at all; a blocklist helps where some exposure remains.

• Stops listed IPs before they start: the firewall drops the TCP connection, so the attacker never reaches the RDP service
• Fewer lockouts: blocked IPs make no failed sign-ins, so they cannot trigger lockouts
• Defense in depth: works alongside NLA, RD Gateway, and VPN-only access
• Low false-positive risk: entries come from IPs seen attacking; if a legitimate user is blocked, look up their address with the IP checker
• Hands-off updates: ThreatListPro’s list is checked for new attackers every 6 hours, and the firewall re-fetches it on its own schedule