How to Stop RDP Brute-Force Attacks

RDP services exposed directly to the internet are common targets for automated scanning and password attacks. This article explains how to detect an RDP brute-force attack and stop it with a well-designed protection policy. For a broader discussion of every RDP security layer, start with our guide, How to Secure RDP; here we focus specifically on brute-force protection.

What is an RDP brute-force attack?

A brute-force attack is an automated attempt to discover an account password by making a large number of sign-in attempts. On RDP it commonly takes several forms:

• Classic brute force: Thousands of passwords are attempted against a single account.
• Password spraying: A small number of common passwords are attempted across many accounts, often without triggering lockouts.
• Credential stuffing: Username/password pairs from previous breaches are tested; the attacker may succeed on the first attempt.

The last example explains why monitoring only the number of attempts is not enough: a valid password may succeed on the first try. An effective defense must address both attack volume and identity.

How can you tell whether you are under attack?

Failed RDP password attempts are commonly recorded in the Windows Security log as Event ID 4625. Signals worth monitoring include:

• Hundreds or thousands of failed sign-ins in a short period
• Many different usernames attempted from the same source
• Increased activity outside normal working hours
• Attempts from different countries and autonomous systems (ASNs)
• Common account names such as Administrator, admin, and user being targeted

The following fields are useful when examining an Event 4625 record (values may vary by sign-in path):

Field	Example
Event ID	4625
Account Name	Administrator
Logon Type	a value representing a network sign-in (varies by access path)
Source Network Address	203.0.113.42 (when available)
Failure Reason	Unknown user name or bad password

An important nuance: the source network address is not present in every Event 4625 record. Depending on the authentication provider, NLA, local sign-in path, or network architecture, the field may be empty or may not identify the client you expect. We’ll cover interpreting failed sign-in events in a separate article.

Does the source IP really belong to the attacker?

This is the most important question to answer before enabling automatic blocking. With a direct RDP connection, the source IP is usually the client’s address. However, if a VPN gateway, RD Gateway, NAT device, or reverse proxy sits between the client and the machine, the Windows server may see the intermediary’s address instead of the real client.

A poorly designed policy can have serious consequences:

“Twenty failed attempts came from the gateway IP → block the gateway” → every user is locked out.

So before enabling automatic blocking, test which address appears in the logs; confirm whether it belongs to the real client or an intermediary; and add trusted gateways, VPN egress IPs, and management networks to the allowlist only after verification.

Reduce the attack surface

When RDP is placed behind a VPN or RD Gateway, the service is no longer directly reachable from the public internet. This prevents random internet scanners from reaching the RDP sign-in surface directly and reduces the volume of password attempts. For a broader explanation, see the RDP security guide.

Design an automatic blocking policy

The core mechanism is to correlate failed sign-ins by source IP and automatically block an address that exceeds a threshold in the machine’s Windows Firewall. But a good policy is more than “there were too many attempts, so block the IP”:

A well-designed blocking policy defines these components:

Component	Question
Threshold	After how many attempts should action be taken?
Time window	Over what period should attempts be counted?
Initial block duration	How long should the first block last?
Repeat-offender policy	How should the duration increase after another attack?
Long-term block	When should a persistent attacker get an extended block?
Allowlist	Which trusted sources are excluded?
Reversal	How and by whom can an incorrect block be removed?
Audit trail	Are the reason, duration, and rule changes recorded?

Tools such as IPBan, RdpGuard, and CrowdSec provide this type of protection, and Dynacop Shield performs it for supported RDP and SSH attack sources. Note: CrowdSec is not simply an “IP blocker” — it separates detection from remediation across distinct components.

Account for distributed and low-and-slow attacks

Modern attacks do not always originate from a single IP. An attacker may make only two or three attempts from each address, use thousands of proxy/botnet IPs, and spread attempts over a long period — staying below the threshold for every individual address. In that case, a policy based only on “N attempts per IP” may miss the attack. Two patterns should be monitored:

• One IP → many usernames (fan-out / password spraying)
• One username → many source IPs (distributed credential attack)

So the system should evaluate more than the total attempts from a single IP: how many accounts the same address targets, how many addresses attempt the same account, and how the attempts are distributed over time. IP blocking alone cannot fully stop distributed attacks — this is where MFA becomes decisive.

Stop valid-password attacks with MFA

Blocking reduces attack noise but does not verify identity. A valid or stolen password from an unblocked address may still succeed. MFA closes this gap by requiring a second factor even after the correct password has been entered.

Risk	IP blocking	MFA
Large numbers of incorrect passwords	✓	Limited
Stolen valid password	—	✓
Distributed botnet	Partially	✓ (prevents a successful sign-in)
Accountability	—	✓ with person-based MFA

For a distributed botnet, MFA does not remove the attack traffic from the network — it prevents that activity from becoming a successful authenticated session. We explore why MFA and brute-force blocking solve different problems in MFA vs. brute-force blocker.

Use account lockout as a complementary control

Account lockout can be a useful additional control, but it should not be used by itself. Very low thresholds may let an attacker deliberately submit incorrect passwords against legitimate accounts until they lock — preventing employees and administrators from signing in, and turning the protection into a denial-of-service tool. Account lockout is therefore not inherently bad; it is a complementary control that can create a denial-of-service risk when configured incorrectly. Use it together with reasonable thresholds, source-IP analysis, MFA, and event monitoring.

Monitor and tune the policy

Automatic blocking is not a “set it and forget it” control. Review regularly:

• False positives, including legitimate users being blocked
• The number and frequency of blocks over time
• The most frequently targeted accounts
• Repeat attacker IPs and network ranges
• Whether blocked addresses continue attempting attacks

An example attack signal (for illustration only):

Field	Value
Source IP	203.0.113.42
Attempts	43
Usernames	12 different accounts
First seen	03:41
Last seen	03:47
Target	RDP
Decision	Blocked for one hour

Checklist

• RDP is behind a VPN or RD Gateway where possible (port 3389 not directly exposed)
• The source IP in logs is verified as the real client (gateway/NAT tested)
• Failed sign-ins are monitored by both source IP and account
• Threshold, window, duration, repeat-offender policy, allowlist, and reversal are defined
• MFA is enabled for Windows console and RDP sign-ins
• Account lockout uses reasonable thresholds and is monitored for DoS abuse
• Account-based behavior is monitored for distributed / low-and-slow attacks
• Block counts, false positives, and targeted accounts are reviewed regularly

Summary

Stopping RDP brute-force requires two controls working together: reduce attack noise with a well-designed source-IP policy, and verify the person signing in with MFA. Reducing the attack surface lowers exposure; automatic blocking suppresses botnet traffic; MFA is the final barrier against valid/stolen credentials and distributed attacks. Before enabling automatic blocking, verify the logs contain the real client address rather than a VPN/gateway/NAT address, and do not rely on account lockout alone.

Dynacop Shield monitors supported RDP and SSH attack sources and blocks addresses in Windows Firewall; Dynacop’s Windows Login MFA separately verifies the person opening Windows console and RDP sessions — without requiring Active Directory.

Sources

• Microsoft — Event 4625: An account failed to log on
• Microsoft — Account lockout policy
• Microsoft — Windows Defender Firewall
• Microsoft — Remote Desktop and NLA
• IPBan (DigitalRuby) · RdpGuard · CrowdSec