Blocking Basic RDP Brute Force Attacks

What it stops

This control prevents automated scripts from guessing passwords on exposed remote desktop services. It blocks simple brute force attacks where an attacker tries thousands of variations against a single username. High-entropy credentials make the mathematical cost of guessing prohibitively expensive for any attacker without significant compute resources. A lockout policy ensures that after a set number of failures, the account becomes unavailable for further attempts. This stops the most basic tools from cycling through common passwords such as Welcome1 or Spring2024. It eliminates the noise generated by low-skill botnets and forces an attacker to move from fast automation to slower, more targeted methods.

What it does not stop

It provides no protection against credentials stolen via phishing. A strong password is useless if the user hands it over willingly to a fake login page. It fails against credential stuffing where attackers use pairs of usernames and passwords leaked from other sites in large combo lists. These attackers often try one single common password across thousands of different accounts to avoid triggering lockout thresholds on any single identity. This low and slow approach bypasses standard lockout settings entirely. It also does not stop session hijacking or attacks using stolen cookies. Some administrators disable lockout for service accounts to avoid operational outages. This creates a permanent open window for any attacker who identifies the username. Vendor marketing suggests these controls are a primary defence. They are merely a filter for the least skilled attackers.

What it looks like when it is working

The Windows Security Log records Event ID 4625 for every failed logon attempt. When the lockout threshold is reached, the log generates Event ID 4740. A functioning system shows a high volume of these failure events originating from an external IP address, followed immediately by the lock event. There is no subsequent Event ID 4624 indicating a successful interactive logon for that account from the same source. Telemetry reveals patterns of failed attempts across multiple accounts from a single IP, but no account ever transitions to a success state. The traffic looks like a wall of noise that results in nothing. Logons occur only during expected business hours and originate from known corporate gateways rather than residential IP ranges in distant countries.

How to prove it

Select one exposed RDP endpoint and a dedicated test account with standard user permissions. Use a tool such as Hydra to attempt ten consecutive logons using an incorrect password. The pass criterion is the account locking out after exactly five failed attempts. Record the specific number of failures before lockout occurs. Capture the timestamp of Event ID 4740 from the security logs and save it as evidence. Document the source IP address used for the test. Confirm that no successful logon event was registered in the logs during the process. This proves the lockout threshold is active and functioning according to the defined policy.