Event ID 4625 Flooding Your Logs? Here's What to Do

You opened Event Viewer on your Windows server and found hundreds — maybe thousands — of entries labeled "Audit Failure." Each one is Event ID 4625. The list keeps growing. Something is clearly wrong, but is it serious?

Let's walk through what these events mean, how to tell whether you are under attack, and what to do about it.

What is Event ID 4625?

Event ID 4625 means one thing: someone tried to log in and failed. Windows records every failed logon attempt in the Security log — whether the wrong password was typed, a nonexistent username was tried, or an expired account was used. That is all this event is. One failed attempt, one log entry.

A handful of these per day is completely normal. People mistype passwords. Sessions expire. Service accounts rotate credentials. Windows logs each one as a 4625.

The problem starts when you see hundreds or thousands of them.

Is this normal, or am I under attack?

This is the question that matters. Here is a simple way to tell:

Normal activity looks like 1 to 5 failed logons per user per day. The usernames are real accounts on your system. The source IPs are internal or belong to your users. According to Huntress, this kind of low-volume failure is routine and rarely a concern.

An attack looks very different. You will see hundreds or thousands of failures per hour. The usernames cycle through common names — Administrator, admin, user, test, guest. The source IPs are external and unfamiliar. The activity runs around the clock, often spiking outside business hours.

The numbers from real exposed servers are striking. A honeypot study by Jeffrey Appel recorded 209,335 failed logon attempts in just seven days — roughly 29,900 per day. Over 80% of those attempts targeted the "Administrator" account. If your 4625 count looks anything like those numbers, your server is being brute forced.

How to check your Event ID 4625 entries

Open Event Viewer and navigate to Windows Logs > Security. Click Filter Current Log in the right panel and enter 4625 in the Event ID field. This filters out everything else and shows only failed logons.

Click on any entry and look at three fields in the detail pane:

• Source Network Address — The IP where the attempt came from. External IPs you do not recognize are the clearest sign of an attack.
• Logon Type — The number that tells you how the logon was attempted (more on this below).
• Account Name — The username that was tried. Random or generic names like "admin" or "test" point to automated scanning.

If you want a quick count of how many failures happened in the last 24 hours, run this in an elevated PowerShell window:

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

A number in the single digits is routine. Anything in the hundreds or thousands needs your attention.

If you prefer a visual summary instead of PowerShell, BruteFence Checker is a free, portable tool that reads your Event Log and shows a 30-day report of failed RDP login attempts — attack count, unique IPs, top attackers, and daily breakdown. No installation needed, just download and run.

What the key details mean

Each 4625 event contains a Logon Type and a Status code that tell you exactly what happened.

Logon types

| Logon Type | Name | What it means | |------------|------|---------------| | 2 | Interactive | Someone at the physical keyboard | | 3 | Network | Remote logon over the network (SMB, mapped drives) | | 10 | RemoteInteractive | RDP or Terminal Services — this is the one that matters most for brute force |

If most of your 4625 events show Logon Type 10, someone is trying to break in through Remote Desktop.

Failure codes

The Status and Sub Status fields use hex codes that look intimidating but have straightforward meanings:

| Code | What it means | |------|---------------| | 0xC000006D | Bad username or authentication info (generic failure) | | 0xC0000064 | The username does not exist on this system | | 0xC000006A | Correct username, wrong password | | 0xC0000234 | Account is locked out | | 0xC0000072 | Account is disabled |

In a brute force attack, you will typically see large volumes of 0xC0000064 (attackers guessing usernames that do not exist) mixed with 0xC000006A (right username, wrong password). That pattern — cycling through names and passwords at high speed — is the fingerprint of automated credential stuffing.

For the full list of status codes and field definitions, see the Microsoft documentation for Event 4625.

What to do about it

Once you have confirmed that the failures are coming from external IPs with Logon Type 10, here is what to do — roughly in order of urgency.

Block the attacking IPs

Open Windows Firewall with Advanced Security, create a new inbound rule, and block the source IPs you found in the 4625 events. This stops the immediate bleeding, but it is a game of whack-a-mole — attackers rotate IPs constantly.

Automate the blocking

Manually adding firewall rules does not scale when you are getting thousands of attempts per day from hundreds of IPs. Automated blocking tools monitor the Security log in real time and add firewall rules the moment an IP crosses a failure threshold.

BruteFence does exactly this — it watches for 4625 events, detects the pattern, and blocks offending IPs automatically. It runs locally on the server with no cloud dependency. It is not the only tool in this category, but if you are dealing with RDP brute force specifically, it was built for this problem. You can try it free for 7 days to see whether it fits your environment.

Review your account lockout policy

If you do not have an account lockout policy, a brute force attack can try passwords indefinitely. Open Local Security Policy (or Group Policy on a domain), navigate to Account Policies > Account Lockout Policy, and set a lockout threshold. Even a threshold of 10 failed attempts with a 30-minute lockout window significantly slows down automated attacks.

Consider removing RDP from the internet

If your server's RDP port is directly reachable from the internet, the long-term answer is to put it behind a VPN or gateway. Automated blocking and lockout policies are important layers, but reducing the attack surface is always the strongest move. We wrote a detailed guide on this: Is it safe to expose RDP to the internet?

Check whether anyone actually got in

This is the step people forget. Filter your Security log for Event ID 4624 — that is a successful logon. If you see a 4624 from any of the same external IPs that were generating 4625 failures, the attacker found a working password. That is an immediate incident: change all passwords, audit what was accessed, and check for new user accounts or services you did not create.

You are not alone in seeing this

If your Event Viewer is filled with thousands of 4625 entries, your server is not uniquely targeted. Every Windows machine with RDP exposed to the internet sees this. The honeypot data confirms it — tens of thousands of attempts per day is the baseline.

The good news is that the fix is straightforward. Check the source IPs and logon types, block what does not belong, automate the blocking so you are not doing it by hand, and consider whether RDP needs to be internet-facing at all. For more on how RDP brute force attacks work, see our guide: What is an RDP brute force attack?