Event ID 4625: An account failed to log on

Event 4625 belongs to two audit subcategories at once: Audit Logon and Audit Account Lockout. Both must be enabled (Success and Failure, though only Failure matters here) under Advanced Audit Policy Configuration, either directly or through the legacy Account Logon Events policy that Windows still maps onto the newer subcategories for compatibility. The event lands in the Security channel, generated by the Microsoft-Windows-Security-Auditing provider, on whichever machine the logon attempt actually touched.

If someone tries to log on to their own workstation, the workstation logs it. If they try to authenticate against a domain controller over the network, the domain controller logs it. A single failed remote logon can therefore produce a 4625 on the target machine and nowhere else, which is why centralizing collection across workstations, member servers and domain controllers matters more for this event than for almost any other in the security log.

The fields that carry the actual investigative weight sit in three groups. Subject identifies the process or service that reported the failure, usually a system account like NT AUTHORITY\SYSTEM for interactive logons or the local machine account for network logons; it is rarely the attacker's identity.

Account For Which Logon Failed is the target: TargetUserName and TargetDomainName tell you who the adversary was trying to become, and TargetUserSid stays S-1-0-0 (a null SID) whenever the account name doesn't resolve, which itself is diagnostic of an enumeration attempt against a name that doesn't exist. Failure Information carries Status and SubStatus, the two NTSTATUS values that explain why the attempt failed, plus FailureReason, a human-readable string Windows derives from those codes.

Network Information gives you IpAddress and WorkstationName, the source of the attempt, though IpAddress is 127.0.0.1 or blank for local interactive logons and only populates meaningfully for network-originated attempts (LogonType 3, 10, 8). LogonType itself matters as much as the failure code: a wave of failures at LogonType 3 against a domain controller reads very differently from failures at LogonType 10 against an internet-facing RDP host, even with the same failure code.

A SOC sees 4625 in a handful of recurring shapes. The single stale-credential case is a user whose password rotated and whose phone or mapped drive still has the old one cached, generating a handful of 4625s at LogonType 3 against a file server every morning until they re-authenticate somewhere.

The service-account case is a scheduled task or application pool identity that fails after a password change nobody communicated to the application owner, producing 4625 at LogonType 4 or 5 at a fixed interval that maps to the job schedule. The credential-stuffing case is a burst of 4625 events against many different TargetUserName values from one IpAddress, using a password list harvested from an unrelated breach, and it shows up as SubStatus 0xC000006A (bad password) far more than 0xC0000064 (bad username) because the attacker only tries names known to be real.

The reconnaissance case is the opposite ratio: many 0xC0000064 failures as an attacker enumerates a username list against a login form or RDP endpoint, learning which accounts exist before ever guessing a password.

Neighboring events change the read entirely. Event 4624 is the successful counterpart; a 4625 immediately followed by a 4624 for the same TargetUserName from the same source, after several failures, is the signature of a slow guess-then-succeed brute force rather than a locked-out legitimate user.

Event 4740 (account locked out) is the downstream consequence of enough consecutive 4625 failures against one account, and its own LockoutSource field pinpoints which machine did the locking, useful when the lockout itself, not the failed logons, is the alert. Event 4776 is the NTLM-specific credential validation event and often precedes or accompanies 4625 on domain controllers when NTLM rather than Kerberos handled the attempt, giving you a second data source for the same failure with slightly different fields.

Event 4771 is the Kerberos pre-authentication failure equivalent and will often fire alongside or instead of 4625 depending on the authentication path, so an investigation that only pulls 4625 can miss a chunk of the failed-logon picture on a Kerberos-heavy domain.

Attackers who light up 4625 heavily fall into a few TTP buckets. Password spraying tools like Kerbrute or custom scripts deliberately throttle attempts per account to stay under lockout thresholds while rotating through many accounts. Classic brute force tools like Hydra or Medusa hammer a single account or a small set of high-value accounts (Administrator, svc_backup, sa) without regard for lockout. And RDP-facing scanners blast LogonType 10 attempts against internet-exposed hosts around the clock, which is why RDP honeypots see thousands of 4625 events a day that have nothing to do with a targeted campaign against that specific organization.

The benign floor for 4625 is high, and that is the central triage problem: most organizations generate hundreds to thousands of these events daily without a single active attacker. Password rotation lag is the largest source, users and service accounts authenticating with a credential that changed somewhere upstream, and it self-resolves once the cached credential updates, typically within a day.

Typos and fat-fingered passwords produce isolated singletons, one 4625 per user per rare event, with no pattern across accounts or time. Expired accounts and disabled accounts (SubStatus 0xC0000193 and 0xC0000072) frequently reflect IT operations, like accounts disabled during an offboarding process that a departing employee's remaining sessions or scheduled tasks still try to use.

The judgment call an analyst makes rests on four axes read together, never on the failure code alone. Breadth: one TargetUserName with many failures is brute force against that account; many TargetUserName values with few failures each from one IpAddress is spraying; both patterns from many source IPs simultaneously is credential stuffing using leaked-breach lists, and that combination is rarely benign.

Velocity: a burst of failures inside seconds or a couple of minutes is scripted, not a human retyping a password, and legitimate users producing more than three or four failures in a short window is itself unusual enough to warrant a look. Source legitimacy: failures from an IP address, ASN or country that has never authenticated for that account before is a stronger signal than the failure code itself, especially when the LogonType is 3 or 10 (network-facing) rather than 2 (console).

Code-to-context fit: SubStatus 0xC0000064 (account name does not exist) against a fixed dictionary of admin-sounding names (admin, administrator, root, backup) is enumeration, not a mistake; the same code against one plausible internal username, once, is almost always a typo.

SubStatus 0xC0000234 (account locked out) needs its own rule because it is a symptom, not a cause. Every failure that arrives after the lockout is a side effect of whatever drove the account to lock in the first place, so an analyst who only sees the post-lockout 0xC0000234 wave and stops there has found the smoke, not the fire. The investigation has to walk backward to the failures that preceded the lockout, typically 0xC000006A repeats, to find the actual attack pattern, then confirm whether the lockout also produced a 4740 with a LockoutSource that matches expectations, or whether it points at an unfamiliar host acting as an authentication proxy.

Service and admin account failures deserve permanent low-tolerance monitoring regardless of volume: these accounts should almost never fail to log on at all in a well-run environment, so even a single unexplained 4625 against a Tier 0 service account or a domain admin, especially outside its documented schedule or from a workstation it has no business touching, is worth escalating before waiting for a volume threshold to trip.