Windows Event ID 4625: how to read a failed logon

What 4625 is

Event ID 4625 — "An account failed to log on" — is written to the Windows Security log every time an authentication attempt is rejected, whatever the reason: wrong password, account that does not exist, account disabled, logon outside permitted hours. Its successful counterpart is 4624.

It is the single most useful event on an internet-facing Windows server, because it is where a brute-force attack becomes visible before it succeeds. Everything a firewall-level defence does begins by reading this stream.

If you see no 4625 events at all on a server you know is exposed, auditing is off rather than the server being quiet. Check and enable it:

auditpol /get /subcategory:"Logon"
auditpol /set /subcategory:"Logon" /success:enable /failure:enable

The fields that matter

A 4625 record is verbose and most of it is noise. Five fields carry the information:

• Account Name (under "Account For Which Logon Failed") — the username that was tried. On a real attack this is a parade of names that never existed on your machine.
• Source Network Address — the IP the attempt came from. This is the field you act on. It is empty for local console logons.
• Logon Type — how the login was attempted. 10 is RemoteInteractive (RDP), 3 is Network (SMB, or RDP behind some gateways), 2 is a physical console, 5 is a service, 4 is a scheduled task.
• Failure Reason and Status / Sub Status — the hexadecimal code explaining what was wrong. This is where the useful distinction lives.
• Workstation Name — the client-supplied hostname. Attack tools often send garbage, a random string, or leave it blank, which is itself a signal.

Status codes, decoded

The Sub Status field is the one to read; the top-level Status is usually the generic 0xC000006D. Learn these five and you can classify almost any 4625 at a glance:

• 0xC0000064 — the account name does not exist. Almost always an attack: your own users know their own usernames.
• 0xC000006A — the account exists but the password was wrong. Either a real user fumbling, or a bot that guessed a valid username.
• 0xC0000234 — the account is locked out. If you see runs of these, your lockout policy is being used against you.
• 0xC0000072 — the account is disabled. Frequently a dormant account an attacker found and is still trying.
• 0xC000006F / 0xC0000070 — logon outside permitted hours, or from a workstation that is not allowed. Rare, and worth investigating rather than ignoring.

Telling an attack from a typo

Three signals separate them, and you want all three before you act automatically.

Rate and persistence. A person makes two or three attempts within a minute and then either succeeds or calls you. A bot maintains a steady rate for hours, through the night, without a pause and without ever calling anyone.

Account diversity. A person tries one account: their own. A bot works down a list — administrator, admin, user, test, sql, backup, scan — and most of those accounts do not exist on your machine, which is exactly the 0xC0000064 signature above.

Source. Your people log in from a handful of known addresses. Attacks arrive from hosting ranges, from a different address every few hundred attempts, and often from several countries in the same hour.

This groups the last day's failures by source address and account so all three are visible at once:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddDays(-1)} |
  ForEach-Object {
    $d = ([xml]$_.ToXml()).Event.EventData.Data
    [pscustomobject]@{
      IP      = ($d | Where-Object Name -eq 'IpAddress')['#text']
      Account = ($d | Where-Object Name -eq 'TargetUserName')['#text']
      Status  = ($d | Where-Object Name -eq 'SubStatus')['#text']
    }
  } |
  Group-Object IP |
  Sort-Object Count -Descending |
  Select-Object -First 15 Count, Name,
    @{n='Accounts'; e={ ($_.Group.Account | Select-Object -Unique) -join ', ' }}

From reading events to blocking them

Reading 4625 by hand is a diagnostic, not a defence — by the time you run the query, the attack has been going for a week. The step that changes anything is doing it continuously and turning a threshold into a firewall rule.

The naive version subscribes to the Security log, counts failures per source, and calls New-NetFirewallRule when a source crosses the line. It works, and then it runs into the problems every such script runs into: the rule set grows into the thousands and the firewall slows to a crawl, the log rotates under load and events are missed, the script dies quietly after a reboot, and one bad match locks the administrator out of the only way in.

RDP Protector runs that loop as a service, with a single consolidated firewall rule instead of thousands, a whitelist that always outranks a block, and the decision made locally so it holds when the network does not. It reads the same event stream shown above — nothing is hidden from you.