Event ID 4740: A user account was locked out

Event 4740 belongs to the Audit User Account Management subcategory inside the Account Management audit category, and it fires exactly once per lockout, the moment a user's bad-password count crosses the domain's Account Lockout Threshold policy. It is not a per-attempt event.

If a policy locks an account after ten failures, you get nine failed-logon events and then a single 4740 when the tenth attempt trips the counter. That single-fire behavior matters for triage: a 4740 tells you a threshold was crossed, not how many attempts preceded it or what password was tried.

The Subject fields (SubjectUserSid, SubjectUserName, SubjectDomainName, SubjectLogonId) describe who performed the lockout operation, and in the overwhelming majority of cases that subject is SYSTEM, not a person or an attacker account. Microsoft's own monitoring guidance calls this out directly: report the event whenever Subject\Security ID is not SYSTEM, because a non-SYSTEM subject means someone (or some script) locked the account deliberately rather than Windows enforcing policy. Don't mistake the Subject fields for the attacker; they almost never are.

The field analysts actually chase is CallerComputerName, under Additional Information. It names the computer account from which the logon attempts that triggered the lockout were received, for example a workstation hostname, a jump box, or a server running a scheduled task under a stale credential. This is the only field in 4740 that points outward, toward where the failed authentication actually originated, which is why every triage runbook for this event starts and ends with it.

Where the event actually lands is the detail most SOC onboarding projects get wrong. Microsoft's documentation states that for user accounts this event generates on domain controllers, member servers, and workstations, but that phrasing hides an important split: local account lockouts are logged locally, on whichever member server or workstation owns the account, while domain account lockouts are logged on domain controllers, and specifically most reliably on the DC holding the PDC emulator FSMO role.

Netlogon replication forwards bad-password-count updates to the PDC emulator so lockout state stays consistent across DCs, and that DC is where the authoritative 4740 for a domain account tends to surface, even though the event is not itself replicated between domain controllers the way most AD data is.

If your onboarding scope covers member servers and workstations but skips the domain controllers, or worse, only forwards logs from a subset of DCs and never the PDC emulator, you will miss domain-account lockouts almost entirely in your SIEM. This is a common, quiet gap: teams onboard the servers people actually log into and treat domain controllers as infrastructure noise, then wonder why 4740 volume looks suspiciously low for an organization with thousands of domain accounts.

A realistic SOC scenario: Monday morning after a mandated password rotation, helpdesk tickets spike alongside a wave of 4740 events, each with a different TargetUserName but many sharing the same CallerComputerName values belonging to ordinary end-user laptops. That is expiry-driven noise.

Contrast that with an RDP-facing jump box where a single privileged account gets locked out three times in an hour with CallerComputerName pointing at an unfamiliar host outside the asset inventory. Same event ID, very different story.

4740 has close neighbors that carry information it does not. Event 4625 (an account failed to log on) fires on every failed attempt, not just the one that trips the lockout, and carries a Status/SubStatus failure code (0xC000006A for bad password, 0xC0000234 once the account is already locked) plus a LogonType that tells you whether the attempt was interactive, network, RDP, or a service logon.

Event 4771 (Kerberos pre-authentication failed) is the domain-controller-side equivalent for Kerberos logons and carries its own failure code table. Event 4776 covers NTLM credential validation failures, common when legacy protocols or non-Kerberos-aware applications are involved.

None of these three tell you a lockout actually happened; 4740 is the only event that confirms the account crossed the threshold. Pair them and you get the full story: the attempts (4625/4771/4776) plus the consequence (4740). After the lockout resolves, event 4767 records who unlocked the account and when, closing the loop for incident timelines.

What lights 4740 up when it's actually an attacker: password spraying tools that cycle through many usernames from one source in a short window, deliberately hammering a known privileged or service account to force a fallback authentication path or an emergency helpdesk reset, and credential-stuffing runs where reused leaked passwords happen to match enough real accounts that lockouts become a side effect rather than the goal.

Most 4740 volume in a healthy environment is benign, and the benign patterns repeat daily. Cached credentials on a phone, tablet, or unattended laptop retry an old password against Wi-Fi, VPN, or Exchange ActiveSync every few minutes after a rotation, generating a slow drip of lockouts for the same account from the same device long after the user has moved on with the new password.

Scheduled tasks and Windows services configured to run under a domain account will do the same thing at fixed intervals once that account's password changes and nobody updated the service's stored credential, producing lockouts with suspiciously regular timing and a CallerComputerName that is a server, not a workstation.

Mapped network drives, mobile mail profiles, and third-party apps that cache credentials locally are the other repeat offenders. All of these share a signature: one account, one or a small handful of known devices, and a pattern that traces cleanly back to a password change or app misconfiguration once you pull the preceding 4625/4771/4776 events for the same TargetUserName and time window.

The malicious signature looks different in shape, not just volume. Many distinct TargetUserName values locked out within a short window, all pointing back to the same CallerComputerName, is the classic spray footprint, one source hammering a list of usernames rather than one username being guessed repeatedly.

Repeated lockouts of a single privileged or service account from a CallerComputerName that has never authenticated as that account before is worth escalating even if the volume is low, because attackers often only need a handful of attempts against a high-value target before pivoting elsewhere or giving up on brute force in favor of another technique.

Lockouts whose CallerComputerName resolves to a server rather than an end-user workstation deserve extra scrutiny too; legitimate interactive logon failures overwhelmingly originate from workstations, so a server-origin lockout often means an automated process, a compromised service account, or lateral movement staging.

The field that breaks this triage the most is CallerComputerName arriving empty. That happens most often when the failed attempts came in over NTLM or through a path where the domain controller never captured the originating hostname, or when cached credentials are involved and the source never resolves cleanly.

An empty CallerComputerName is not itself suspicious, but it does mean you cannot stop at 4740; you have to pull 4625, 4771, or 4776 events for the same account and timestamp to recover IP address, logon type, and failure code before you can call the lockout benign.

Analysts who skip that correlation step and close every 4740 as noise are the ones who miss the spray hiding inside a busy Monday morning.