5 Signs Your Windows Server Is Under an RDP Brute Force Attack

Most admins discover an RDP brute force attack the same way: they read the ransomware note on Monday morning. By then, the attacker has been inside for hours or days, and the cleanup costs more than any preventive control would have.

According to the Mandiant M-Trends 2026 report, the median time from initial access to attacker hands-on activity has collapsed from 8 hours in 2022 to roughly 22 seconds in 2025. Once credentials fall, automation takes over almost instantly. Detection has to be earlier, and it has to be checkable today.

This guide walks through 5 specific signs your Windows Server is being attacked right now, with PowerShell checks and Event Viewer paths you can run in the next 10 minutes. If two or more of these match what you are seeing, treat it as an active incident. For background on how these attacks work, see our primer on what an RDP brute force attack is.

Are you seeing thousands of failed login events?

The single clearest signal is a flood of Event ID 4625 (failed logon) entries in the Security log. On a healthy internal Windows Server, the baseline is usually under 50 per day, mostly from forgotten passwords or stale service accounts. An exposed server under active brute force will sit at thousands per day or more.

For reference, a public Microsoft Sentinel honeypot project by researcher Jeffrey Appel recorded 209,335 failed logins in 7 days on a single exposed test machine, roughly 30,000 per day. If your numbers are anywhere near that range, you are not looking at user error.

To check, open Event Viewer, navigate to Windows Logs → Security, and filter for Event ID 4625. Or run this from an elevated PowerShell prompt:

Get-WinEvent -FilterHashtable @{LogName='Security';Id=4625;StartTime=(Get-Date).AddDays(-7)} | Measure-Object

A count above 1,000 over the past 7 days on an internal-only server is suspicious. Above 1,000 per day is a clear attack pattern. Microsoft documents the full event schema in the Event 4625 reference, and we cover the field-by-field meaning in our Event ID 4625 guide.

Is RDP login slow and is LSASS pegging the CPU?

Every credential check Windows handles costs CPU cycles inside the LSASS (Local Security Authority Subsystem Service) process. A normal RDP login completes in 5 to 10 seconds. When thousands of brute force attempts arrive in parallel, LSASS gets saturated, and real users notice.

The symptom looks like this: RDP suddenly takes 30 to 60 seconds to reach the desktop, the credential prompt feels sluggish, and Task Manager shows LSASS consistently above 5% CPU on an otherwise idle server. On a server with no real workload, LSASS should usually sit below 1%.

Open Task Manager, switch to the Details tab, and sort by CPU. If lsass.exe is steadily near the top, that is a network-driven workload, and on an exposed server it almost always means authentication traffic you did not authorize.

Are random user accounts getting locked out?

If your domain has an Account Lockout Policy enabled, attackers brute forcing real usernames will eventually trip it. The side effect is that legitimate users get locked out of their own accounts at the worst times, often in batches.

Help desk teams see this as a sudden spike in lockout tickets that does not match any deployment, password change, or vacation pattern. In the Security log, this maps to Event ID 4740 (a user account was locked out). On a healthy network, 4740 events should be rare. More than 10 per day, especially across different accounts, is a strong indicator of active credential spraying.

Microsoft's Event 4740 documentation shows where the source workstation name is logged, which often points at the attacking host. The Account Lockout Policy reference explains how to tune thresholds without locking the entire org out.

Did a new admin or local account appear that you did not create?

This is the sign you do not want to find. If a new local user or, worse, a new member of the local Administrators group has appeared and you did not create it, the attack already succeeded. The brute force phase is over and the attacker is building persistence.

Run this from PowerShell to list current local administrators:

net localgroup administrators

Then check the Security log for Event ID 4720 (a user account was created) and Event ID 4732 (a member was added to a security-enabled local group). Microsoft documents both events in detail: Event 4720 and Event 4732. Anything in there that does not match a change ticket or a known admin action is a confirmed compromise indicator.

If you see this, do not start changing passwords on the live machine. Isolate the server from the network first (pull it from the VLAN or block it at the firewall), capture the Security and System event logs, and treat it as an incident. The credential that let them in was probably guessable in the first place, which is why our piece on how long it takes to crack a weak password over RDP keeps coming up. CISA's Stop Ransomware hub has practical post-compromise guidance worth following from this point on.

Are RDP sessions starting at strange hours?

Attackers rarely log in during business hours. Sophos's 2025 Active Adversary Report found that 83% of ransomware was deployed outside the victim's business hours, with weekends and the early morning being clear favorites. If your only RDP users are office staff but Event ID 4624 shows successful logons at 03:00 on a Sunday, something is wrong.

Microsoft's Event 4624 reference describes the logon type field, which is the most useful filter. Logon type 10 is RemoteInteractive (RDP). To list off-hours RDP logons in the past week:

Get-WinEvent -FilterHashtable @{LogName='Security';Id=4624;StartTime=(Get-Date).AddDays(-7)} |
  Where-Object { $_.TimeCreated.Hour -ge 22 -or $_.TimeCreated.Hour -le 6 }

A handful of after-hours events from a known admin doing maintenance is fine. A pattern of overnight logons from accounts that should not be using RDP at all is not.

What should you do right now?

Five Event IDs to keep in mind cover most of the picture: 4625 (failed logon), 4624 (successful logon), 4740 (account lockout), 4720 (account created), and 4732 (admin group change). If your monitoring covers those five, most brute force activity becomes visible long before it succeeds.

The action plan below is tiered by urgency. Work top to bottom; do not skip the 5-minute fixes to chase the long-term ones.

Immediate (5 minutes):

1. Enable Account Lockout Policy in Group Policy if it is not already on. Microsoft's official policy reference covers safe threshold values.
2. Enable Network Level Authentication (NLA) on the RDP host. It blocks pre-auth brute force entirely.
3. Rename the default Administrator account. It removes the most-guessed username from the equation.

Today (1 hour):

4. Restrict RDP in Windows Firewall to known IP ranges (your office, VPN gateway, jump host).
5. Set strong, unique passwords on every admin account. Our breakdown on how long weak passwords actually last under RDP brute force shows why length matters more than complexity.
6. Add MFA where the environment supports it (Duo, Microsoft Authenticator, or RD Gateway with conditional access).

This week:

7. Deploy an automated IP blocking tool that watches Event 4625 and bans repeat offenders. Our 2026 RDP brute force protection guide walks through the category. BruteFence is one option in that space and offers a 7-day free trial that installs in about 5 minutes.
8. Plan a layered defense beyond a single tool. The full inventory lives in our Windows Server security checklist for 2026.

How can you quickly verify how bad it already is?

If running PowerShell against the Security log feels like too much for a Monday morning, the free BruteFence Checker on GitHub does the same audit in about 30 seconds. It reads the local Security log, looks back 30 days, and prints total failed attempts, the top 10 attacker IPs, and a daily breakdown.

Run it once, look at the daily numbers, and decide. If the Checker shows under 50 failed attempts per day, you are at a normal baseline. If it shows over 1,000 per day, you have an active campaign hitting the server, and the manual blocklist approach will not keep up. The BruteFence 7-day free trial automates the blocking and takes about 5 minutes to install, but the Checker output is useful even if you never install BruteFence.

The honest version: most Windows servers behind a firewall and a VPN never see any of these signs. The ones that do are usually exposed directly on port 3389, often by accident, often for years. If even one of the 5 signs above matches what you are seeing today, the next 24 hours matter more than the next quarter's roadmap.