Accounts are locking out all day, the Security log is a waterfall of failed logons, and none of your users are even making mistakes. Somebody is knocking on your Remote Desktop from the internet — thousands of times an hour. Lockout policy cannot save you here. Closing the door can.
This is the scenario where admins reach for the wrong tool. Seeing brute-force attempts, they lower the lockout threshold to 3, set duration to 0 — and hand the attacker a weapon: now three stray attempts lock any account, including the admin's, permanently, until manually unlocked. The attacker does not need to guess a single password to shut your office down; they just need usernames. The real problem is not the password policy — it is that port 3389 is reachable from the entire internet. This page shows how to confirm that is what is happening, and the fixes in the order that actually ends it.
Three signs separate an attack from user error:
Check whether 3389 is genuinely exposed: the router's port-forwarding table and the Windows Firewall RDP rule scope will show it in minutes. Many offices discover a forward created years ago "temporarily" for one vendor visit.
Nothing below this step matters as much as this step:
These reduce noise and raise the bar, honestly labelled as secondary: keep Network Level Authentication (NLA) on, so unauthenticated sessions die early. Use long, unique passwords and MFA wherever the remote path supports it. Rename or disable the built-in Administrator for remote use and give admins named accounts instead — it removes the attacker's favourite known username. Changing the RDP port deserves a straight answer: it cuts log noise dramatically, because lazy scanners only check 3389 — but it is obscurity, not security, and any scanner that looks properly finds the new port in minutes. Do it for quieter logs if you like; never count it as protection. Finally, alert on the symptom: a spike of 4625 events or any 4740 against an admin account should ping the admin's phone, because that is the sound of someone at the door.
With the door closed, repair the policy the panic damaged. A strict threshold plus duration 0 was the attacker's denial-of-service lever; return to balanced values — threshold around 10, duration 30 minutes, reset counter 30 minutes — and let the policy go back to its actual job: blunting a targeted guessing attempt against an internal or VPN-authenticated user. Then do the quiet follow-ups: check whether any attempt succeeded (Event 4624 with type 10 from an unknown address is a breach, not a nuisance — treat it as an incident, force password resets, and review what that session touched), and make sure your backups are healthy, because brute force is often the overture to ransomware. The lesson to keep: lockout policy slows down guessing; exposure decides whether guessing can happen at all.
The complete lockout policy walkthrough and all 3 recovery methods, shown live on a real Windows system — this is the video this guide is based on.
▶️ Watch Full VideoCheck Event 4625 on the target machine or DC: an attack shows very high volume at all hours, Logon Type 10 (RDP) or 3, unfamiliar public source IP addresses, and attempts against generic names like administrator, admin and test. User mistakes are few, in office hours, and against one real username.
It reduces the noise because mass scanners mostly probe the default port 3389, but it is not real security — a directed scan finds the new port. The genuine fixes are removing public access entirely and putting RDP behind a VPN or RD Gateway with MFA.
Treat it as a security incident, not a lockout problem: isolate the machine, preserve logs, force password resets for exposed accounts, review what the session accessed, and check backups before trusting the system. Then close the public RDP exposure that made it possible.