612 failed logins in an hour: reading Event ID 4625 to tell an attack from… an old laptop
TL;DR
Event ID 4625 is Windows’ “failed logon” event. A flood of 4625s from one source may be brute force — or just a machine, service or scheduled task still using an old password. Reading the right fields avoids false alarms.
Midnight, an alert fires: one account just failed to log in 612 times in an hour. The first reflex is "brute force!", but tracing the source IP leads to an old machine in the office. The account owner had just changed their password, and the old machine was still logging in automatically with the old one. A large part of SOC work is telling cases like this apart from real attacks, and the first tool is understanding Event ID 4625, the Windows "failed logon" log.
Fields to read
| Field | Meaning |
|---|---|
| Account Name | The targeted account; admin/domain admin accounts take priority |
| Source Network Address | Source IP: internal or from the Internet? |
| Logon Type | How the logon happened: network, interactive, RDP, service… |
| Status / Sub Status | Why it failed: wrong password, nonexistent account, locked out, clock skew with the DC… |
| Workstation / Process | The machine and process sending the request: a service or a user? |
Two easily overlooked but very useful fields are Logon Type (RDP from the Internet is far more suspicious than an internal service logon) and Sub Status (distinguishing "wrong password" from "account doesn't exist"; the latter is common when attackers enumerate usernames).
Brute force or misconfiguration?
| Signs of an attack | Signs of misconfiguration / an old password |
|---|---|
| Many different accounts from one IP (password spraying) | Always the same account, from one fixed machine |
| Unknown IPs from the Internet | Internal IPs, familiar machines |
| Nonexistent account names | A steady rhythm matching a service or scheduled task |
| Followed by a 4624 (successful logon) from the same source | A recent password change or an expired service account password |
Suggested triage process
- Identify the failure reason (Status/Sub Status) and the targeted account.
- Prioritise privileged accounts; determine whether the source IP is internal or external.
- Look for other alerts involving the same user/machine in the last 48 hours.
- Check whether the credentials are used by a service or scheduled task; ask the account owner.
- Look for a successful 4624 from that source, a sign the account may have been compromised.
- If it's an attack: isolate the machine, reset the password, scan for malware, address the initial entry point.
Query idea
Whatever SIEM you use, the search idea is similar: group 4625 events by account and source IP, count per time window, then look at the distribution.
event.code: 4625
| group by source.ip, user.name, winlog.event_data.SubStatus
| count per 5m
# Ask: one IP, many users? one user, many IPs? steady rhythm or bursts?Tuning to reduce false alarms
- Keep a list of known internal IPs/machines (scanners, monitoring systems) and handle them separately.
- Track password change and expiry schedules for service accounts; tag alerts that follow a change.
- Use different thresholds for normal and privileged accounts.
- Combine with 4624 and 4740 (account lockout) to see the full picture.
How to apply it
- Analyst/IT: always ask "is this a person, a service or an attacker?" before escalating.
- Tech Lead/Admin: after changing a service account password, find everywhere the old password is still used to avoid mass lockouts.
- PM: a high alert count doesn't mean many attacks; measure the false-alarm rate too when judging monitoring quality.