RDP brute force protection: how to block attacks and keep remote access working

What an RDP brute-force attack looks like in practice

You usually notice RDP brute force the same way: repeated failed sign-ins against a Windows server that is reachable from the internet, often followed by account lockouts, noisy Security logs, and worried users who cannot connect. Many of these attacks are not “targeted” in the human sense. Internet-exposed RDP is constantly scanned, and automated tools will keep trying usernames and passwords until they find a weak credential or create disruption.

In MITRE ATT&CK, this maps to Technique T1110 (Brute Force) , which includes related patterns such as password guessing and password spraying. In practical ops terms, RDP brute force attacks are repeated remote logon attempts (often automated) that try many passwords or many accounts against an exposed RDP service until credentials are found or accounts are disrupted.

Typical symptoms include:

• A sudden spike of failed logons in Windows Security logs
• Many attempts against common account names (Administrator, admin, test, service-style names)
• Failures coming from many external IP addresses, sometimes rotating frequently
• User complaints about account lockouts or slow logon performance
• Higher CPU or authentication load during bursts (LSASS and RDP-related services can be affected)

It helps to name what you are seeing. “Brute force” usually means many passwords against one account. “Password spraying” means a few common passwords against many accounts to avoid lockout thresholds. “Credential stuffing” means testing username and password pairs stolen elsewhere. All three show up as repeated remote logon failures and deserve the same first response: reduce exposure and slow attempts down.

Quick diagnosis: confirm it is RDP brute force (and not a misconfiguration)

Before you change policies and risk locking out legitimate users, confirm what is failing, from where, and at what volume. Microsoft’s own troubleshooting guidance for Azure VMs under brute-force attack uses the same starting point even outside Azure: look for high volumes of failed sign-ins and correlate them with external source IPs.

• Check Windows Security logs for a burst of failed sign-ins during the time users reported issues. Event ID 4625 is a common indicator to review.
• Look for patterns: repeated account names, many different accounts, or the same source IP accessing multiple users.
• Correlate failed sign-ins with successful logons soon after. Successful logons are often recorded as Event ID 4624, depending on your audit policy.
• Confirm exposure: is TCP 3389 (or your custom RDP port) reachable from the internet through a firewall rule, NAT, port forwarding, or cloud security group?
• Verify you are not seeing “false alarms” from legitimate sources (an RDS gateway, a VPN concentrator, a remote management tool, or an internal scanner) that appear as repeated failures due to a saved wrong password.

If you see Event ID 4625 in large volume, from many external IP addresses over short periods, you are likely dealing with active guessing or spraying rather than a single user typing the wrong password.

Stop the bleeding in 15 to 30 minutes (containment actions that work)

When brute-force traffic is active, the priority is to restore control and keep a safe admin path available. The fastest way to reduce RDP brute-force risk is to stop exposing RDP directly to the internet and limit inbound access to a known set of trusted IP addresses or a secured access path (gateway, VPN, or bastion). Microsoft Learn’s guidance for Azure incidents reinforces this same containment approach: restrict inbound access first, then improve the access path.

1. Establish a safe way back in before you change anything. If you are already locked out, use your out-of-band access (hypervisor console, iLO/iDRAC, cloud serial console, bastion, or VPN) so you can still manage the host after firewall changes.
2. Remove direct internet exposure of RDP. Disable the public port forward or tighten inbound rules so RDP is not open to “any source.” If you cannot remove it immediately, restrict inbound access to a short allowlist (your office IPs, your management network, your MSP fixed egress IPs).
3. On Azure or similar clouds, tighten the perimeter immediately. Restrict the inbound rule in your NSG or equivalent. If you have the option, move to Microsoft-endorsed patterns such as Azure Bastion, VPN Gateway, or just-in-time access concepts to reduce exposure windows.
4. Confirm Network Level Authentication (NLA) is enabled. NLA forces authentication before a full remote desktop session is established, which reduces exposure to some pre-auth risks and cuts down on unnecessary resource usage during guessing.
5. Review who can log on via RDP. Validate membership of local Administrators and Remote Desktop Users, and remove any broad groups that do not need interactive remote sign-in.
6. Protect privileged accounts right away. If you suspect a password may be weak or leaked, rotate credentials for privileged accounts in a controlled way, and check for unexpected new local admins or newly enabled accounts.
7. Stabilise access for real users. If users are being locked out, the fix is usually exposure reduction and better throttling, not lowering security. Avoid rushing lockout changes that can create a wider outage.

Once you have the traffic contained, you can make longer-term changes safely. If you want a tool-assisted approach after you regain control, TSplus Advanced Security can help operationalize brute-force blocking and access restrictions on Windows servers, but containment still starts with reducing exposure.

Reduce attack surface: the access architectures that cut brute-force risk

If you only take one lesson from repeated RDP attacks, make it this: architecture beats tweaking. Putting a controlled entry point in front of session hosts changes what attackers can reach and what you can enforce. Microsoft’s Security Blog guidance for remote desktop adoption emphasizes reducing direct exposure, and Microsoft Learn documents RD Gateway as a way to provide secure access over TLS with proper certificate configuration.

The most reliable way to reduce RDP brute-force attempts is to avoid direct RDP exposure and instead require access through a controlled entry point such as RD Gateway , VPN, or a bastion, ideally with strong authentication.

Access pattern	Exposure and brute-force risk	Operational complexity	When it fits	Notes
Direct RDP from the internet	Highest risk and highest noise. Constant scanning and guessing.	Low to set up, high to defend.	Only for short-term emergency access with tight restrictions.	Changing the port may reduce opportunistic scanning, but it does not provide strong protection by itself.
Direct RDP with IP allowlisting	Lower exposure if the allowlist is small and stable.	Medium. Requires maintaining allowlists and handling travel/ISP changes.	Small admin teams with fixed office IPs or fixed MSP egress.	Works best when paired with strong authentication controls and monitoring.
RD Gateway in front of RDS/RDP	Reduces direct exposure of session hosts and tunnels over TLS.	Medium to high. Certificates, availability, and policy design matter.	Windows-centric environments already using RDS patterns.	Microsoft Learn’s RDS planning guidance covers gateway requirements. Microsoft licensing remains your responsibility and should be validated with Microsoft or a qualified licensing partner.
VPN for remote access	Removes RDP from public exposure when done correctly.	Medium. Client deployment, routing, and MFA integration vary.	Admins and staff who need broader network access, not just one app.	Limit VPN users to what they need, then still secure RDP inside the network.
Bastion or jump host	Strong exposure reduction. RDP is only reachable from the bastion context.	Medium. Needs strong control of the bastion itself.	Cloud-hosted servers, regulated environments, and admin-only access.	Often pairs well with just-in-time access windows and conditional controls depending on platform.
Publish applications/desktops via a web portal (HTTPS)	Can reduce or eliminate the need to expose raw RDP publicly, depending on design.	Low to medium. Focuses on delivering what users need, not full network access.	SMBs delivering a set of Windows apps or remote desktops to users and partners.	If your goal is to give users access to Windows applications without leaving raw RDP exposed to the internet, TSplus Remote Access is worth evaluating for app and desktop publishing through a secured web portal.

If you must keep some RDP access available, treat it as a protected admin interface, not a general remote work entry point. If you are moving toward app and desktop publishing through a secured web portal A quickstart guide can help you get started. Your security posture improves significantly when most users never connect to TCP 3389 at all.

Harden authentication for RDP without locking out real users

Good brute-force resistance is a balance between slowing attackers down and keeping legitimate access reliable. Effective brute-force resistance combines NLA and strong credentials with a rate-limiting or lockout policy that slows repeated failures while being tuned to avoid attacker-triggered denial of service. NIST SP 800-63B discusses throttling and handling repeated failed authentication attempts as a core control, because it reduces the feasibility of rapid guessing.

Start with NLA and account hygiene

NLA is a baseline for RDP because it requires authentication before the session is fully established. It will not stop password spraying on its own, but it reduces exposure and wasted resources compared to letting unauthenticated sessions progress further.

Then address the identity basics that brute force feeds on: remove unnecessary admin rights, enforce least privilege, and clean up stale accounts. If you have obvious or shared local admin accounts, rotate them, restrict where they can sign in, and consider renaming or disabling accounts that do not need interactive login. Keep Remote Desktop Users and local Administrators tight, especially on servers that host sensitive data.

Lockout and throttling: why tuning matters

Windows Account Lockout Policy settings are commonly used to reduce brute-force success, and Microsoft Learn documents the key terms lockout threshold, lockout duration, and reset counter. The trade-off is availability. Attackers can intentionally trigger lockouts for real users (or your helpdesk and admins) if your threshold is too low and your exposure is broad.

Use these decision factors when you adjust lockout and throttling:

• How exposed is the service? If RDP is reachable from the whole internet, lockouts are more likely to be weaponised. Reduce exposure first, then tune lockout.
• How do users authenticate? A gateway, VPN, or bastion can reduce the need for aggressive lockouts on the session host because fewer unknown sources can reach it.
• How costly is a lockout? If lockout translates into an outage for a production support team, you may prefer rate limiting and IP-based bans over tight account lockouts.
• How do shared accounts behave? Shared credentials multiply the impact of lockouts. Eliminate shared accounts where possible.

Special case: built-in local Administrator

Many environments still have a built-in local Administrator account on servers and workstations, and its lockout behaviour has been a frequent point of confusion. Microsoft Support KB5020282 provides context on account lockout for built-in local administrators, including how lockout can apply to network logons such as RDP depending on configuration and version. Do not assume the built-in Administrator will behave the same as a normal user account, and test in a controlled way before you rely on lockout behaviour as a primary control.

For teams that want a practical hardening layer, TSplus Advanced Security includes brute-force protection designed to stop repeated unauthorized attempts at the host level. It should complement, not replace, strong Windows authentication policies and careful lockout tuning.

Network controls that help (and the ones people overestimate)

Network controls are often the fastest improvements you can make, but they have different real-world value. Microsoft’s guidance for RDP brute-force issues (including in Azure scenarios) consistently prioritises restricting inbound connectivity over cosmetic changes.

High value: IP allowlisting. If you can restrict RDP to known addresses (office egress IPs, VPN ranges, bastion subnets, MSP fixed IPs), you remove most brute-force traffic immediately. This also makes your monitoring more meaningful because any remaining failures come from a smaller set of sources.

Useful with care: geographic and reputation-based controls. Geo blocking and IP reputation can reduce noise, but they can also block legitimate users who travel, connect from roaming networks, or come through CGNAT. Attackers can also use VPNs and proxies, so treat geo controls as a risk reducer, not a guarantee.

Overestimated: changing the RDP port. IP allowlisting meaningfully reduces RDP brute-force exposure, while changing the RDP port mainly reduces opportunistic scanning and should not be relied on as primary protection. A port change can buy time during an incident, but it does not address password spraying from a determined actor who can discover the port.

In environments where teams want simpler enforcement than maintaining complex rule sets manually, TSplus Advanced Security adds geographic protection and IP-based controls that can be applied consistently across servers.

Monitoring and detection: what to log, alert on, and investigate

Brute force is one of those problems that looks obvious in hindsight and expensive when you spot it late. The goal of monitoring is not to count every failed logon forever. It is to detect abnormal patterns early and to investigate whether those attempts ever turned into a successful sign-in.

Monitor for abnormal spikes in failed logons (often Event ID 4625) and alert on patterns that indicate password spraying or a successful follow-on login after repeated failures. Microsoft’s brute-force troubleshooting guidance highlights the same artifact (4625) because it is a practical starting point when administrators are trying to regain access and understand scope.

For day-to-day operations, focus on three investigation questions:

Is the traffic external or internal? External IPs hitting a public interface point to exposure issues. Internal IPs may indicate a compromised endpoint or a misconfigured service account.

Is it one account or many? One account suggests brute force. Many accounts with low attempts each suggest password spraying.

Did any account succeed after the burst? A successful logon shortly after repeated failures is a high-priority correlation to investigate, especially for privileged accounts.

If you do not already centralise Windows logs, consider Windows Event Forwarding or your existing SIEM so you can alert across multiple servers consistently. For teams that need simple alerts and historical visibility during attack spikes , TSplus Server Monitoring can help you track server health and availability alongside your security logging.

Automated blocking approaches (and how to avoid false positives)

Manual response does not scale when your hosts are internet-facing. Automation is where many teams regain control, as long as it is designed to be reversible and to protect legitimate access. The safest automation blocks repeated failed logons with time-bound bans and clear allowlists, and it must account for shared IP addresses to avoid blocking legitimate users.

What automation looks like in practice

Common approaches include host firewall modules that detect repeated failures and temporarily ban an IP, EDR features that detect password guessing behaviour, and scripts that parse Security logs and apply dynamic firewall rules. Gateway-centric controls (RD Gateway, VPN, bastion) often reduce the need for aggressive host-level blocking because fewer unknown sources ever reach the server.

Where teams get burned

Shared NAT and CGNAT. If many legitimate users come from one public IP (a branch office, a hotel network, some ISPs), blocking that IP can cut off good users along with attackers. Time-bound bans and known-good allowlists reduce the blast radius.

Blocking your own management path. Always allowlist your VPN ranges, bastion subnet, and MSP management egress IPs before you enable aggressive blocking. Document a break-glass path that does not rely on the same network route.

Lockout-driven outages. If your only control is account lockout, attackers can turn it into denial of service. Pair lockout policies with exposure reduction and IP-based throttling so the host does not become the choke point.

TSplus Advanced Security adds practical brute-force protection , IP and geographic controls, and ransomware-focused hardening for Windows servers, which can help you reduce repeated RDP login attempts without deploying a heavyweight security stack.

A practical baseline for SMB and MSP environments

SMBs and MSPs need a baseline that is repeatable, testable, and unlikely to break day-to-day operations. Microsoft’s remote desktop security guidance supports the same general principle: reduce direct exposure, then harden access and monitor actively.

• Remove direct internet exposure of RDP where possible, and route access through VPN, gateway, or bastion patterns.
• If RDP must remain reachable, restrict inbound access to a small IP allowlist and review it regularly.
• Enable Network Level Authentication (NLA) and require strong, unique credentials for all interactive users.
• Tighten privileged access: minimize local admin membership and review Remote Desktop Users membership.
• Set Account Lockout Policy intentionally (threshold, duration, reset counter) and test it to avoid lockout-driven outages.
• Monitor failed logons (for example, Event ID 4625) and investigate success-after-failure patterns promptly.
• Keep Windows, RDP-related components, and internet-facing services patched on a defined schedule.
• Document break-glass access, including how you will regain console access if network rules block remote entry.

If you want a structured review, use our RDP Security Audit: A 20-Point Checklist for 2026 .

For MSPs, standardise what you can (GPO templates, firewall baselines, allowed management IP inventories) and keep customer-specific allowlists and exceptions clearly documented. If you need a practical hardening layer across many customer servers, TSplus Advanced Security can be deployed as part of a standard remote access security package, and TSplus Remote Access can support a “do not expose raw RDP directly” posture for published applications and desktops.

FAQ

Does changing the default RDP port stop brute-force attacks?

No. Changing the RDP port can reduce opportunistic scanning noise, and Microsoft’s own incident guidance mentions it as a temporary mitigation in some scenarios, but it does not stop targeted guessing. Treat it as a secondary tactic and focus first on exposure reduction (allowlisting, gateway, VPN, bastion) and authentication hardening.

What Windows policy settings matter most for RDP brute-force protection?

Start with enabling NLA for RDP, tightening who has the right to log on via Remote Desktop, and configuring Account Lockout Policy (threshold, duration, reset counter) as documented by Microsoft Learn. Strong password policies and least-privilege admin rights also reduce the chance that guessing leads to a meaningful compromise.

Can account lockout settings make RDP outages worse during an attack?

Yes. If RDP is exposed broadly, attackers can intentionally trigger lockouts for real users, which becomes a denial-of-service problem. That is why the recommended order is to reduce exposure first, then tune lockout and throttling in a way that balances security with availability.

Is Network Level Authentication (NLA) enough to secure RDP?

NLA is an important baseline, but it does not prevent password spraying or credential stuffing by itself. You still need exposure reduction, strong credential hygiene, sensible throttling or lockout behaviour, and monitoring for unusual sign-in patterns.

What should I monitor to detect RDP brute-force attempts early?

Look for abnormal spikes in failed logons, commonly visible as Event ID 4625, especially when they come from many external IPs or target many usernames in a short period. Also investigate any successful logon that occurs shortly after repeated failures, because it can indicate a guessed or reused password.

Conclusion: prioritise exposure reduction, then harden and automate

RDP brute force protection is not one setting. It is a layered approach that works best in this order: reduce or remove direct exposure, harden authentication (NLA, strong credentials, least privilege, sensible lockout or throttling), apply network controls that actually limit reachability, monitor for meaningful patterns, and automate blocking carefully to avoid false positives.

Document your changes, test them outside business hours when possible, and validate that your break-glass path still works after firewall and lockout adjustments. If you want to operationalise these protections with less manual effort, TSplus Advanced Security can help with brute-force protection and access restrictions, and TSplus Remote Access can provide a safer delivery model for published Windows applications and desktops through a web portal. To evaluate, you can download a trial and review pricing .