Event ID 4740: A User Account Was Locked Out — Finding the Source

What it records

Event 4740 is the audit record Windows writes when the account lockout policy trips: “This event generates every time a user account is locked out.” It belongs to the Audit User Account Management subcategory, and Microsoft states that for user accounts it generates on domain controllers, member servers, and workstations — so domain account lockouts land on the DCs, and local account lockouts on the machine that owns the account.

The record has three parts. Subject is the account that performed the lockout operation, with its Security ID, Account Name, Account Domain and Logon ID; the Logon ID is the hexadecimal value Microsoft describes as correlating this event with recent events that contain the same value, such as 4624. In Microsoft’s own sample XML the Subject SID is S-1-5-18 and the Subject name is DC01$, which is why the monitoring guidance treats anything other than SYSTEM here as worth reporting.

Account That Was Locked Out carries the Security ID and Account Name of the victim — the SID being the value Microsoft’s recommendations tell you to watch for high-value accounts such as domain administrators.

Additional Information holds the single most useful pivot in the event: Caller Computer Name, “the name of computer account from which logon attempt was received and after which target account was locked out.”

What 4740 does not contain matters just as much. There is no IP address, no logon type, no sub status code and no count of failed attempts — the record says only that the threshold in your account lockout policy was reached. The reason lives in the authentication failures that preceded it.

When it matters

Pattern	Reading
One lockout, one account, user calls the service desk	Mistyped or newly changed password
Same account locked repeatedly at regular intervals from one Caller Computer Name	Credential cached in a service, task, mapped drive or mail client on that host
Many different accounts locked inside a short window	A spray or brute-force run that pushed past the threshold — see 0xC0000234
Caller Computer Name not from your domain	Microsoft recommends monitoring for all 4740 events where this is the case
Caller Computer Name is a machine the account should never authenticate from	Microsoft’s guidance is to trigger an alert on exactly this
Subject\Security ID is not SYSTEM	Microsoft recommends reporting it — the lockout was not applied by the system
Lockout of a domain administrator or other high-value account	Microsoft recommends monitoring every lockout for those SIDs

Lockouts cut both ways. They can be the collateral damage of password guessing against real accounts, which is the 0xC000006A and Kerberos 0x18 shape, or they can be the goal — deliberately locking out accounts to deny access. A wave of 4740s across unrelated accounts deserves the same urgency either way.

How to investigate

Start with every lockout in the window and who or what applied it:

SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4740
| project TimeGenerated, Computer, LockedOutAccount = TargetUserName, TargetUserSid,
          AccountDomainField = TargetDomainName, SubjectUserName, SubjectUserSid, SubjectLogonId
| order by TimeGenerated desc

Separate the one-off from the recurring, because repeat lockouts on one account are a different investigation from one lockout on many accounts:

SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 4740
| summarize Lockouts = count(), DCs = make_set(Computer, 10), Callers = make_set(TargetDomainName, 10),
            First = min(TimeGenerated), Last = max(TimeGenerated)
    by TargetUserName
| order by Lockouts desc

Then get what 4740 withholds — the source address and the failure reason — by joining each lockout to the failures that preceded it:

let lockouts = SecurityEvent
    | where TimeGenerated > ago(24h) and EventID == 4740
    | project LockTime = TimeGenerated, TargetUserName, LockedOnDC = Computer;
SecurityEvent
| where TimeGenerated > ago(25h) and EventID == 4625
| join kind=inner lockouts on TargetUserName
| where TimeGenerated between (LockTime - 30m .. LockTime)
| summarize Failures = count(), SubStatuses = make_set(SubStatus, 5), Sources = make_set(IpAddress, 10),
            Workstations = make_set(WorkstationName, 10), LogonTypes = make_set(LogonType, 5)
    by TargetUserName, LockTime, LockedOnDC
| order by LockTime desc

For Kerberos clients the failures appear as 4771 instead, where Status carries the Kerberos code and IpAddress arrives with an ::ffff: prefix:

SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4771 and Status =~ "0x18"
| extend SourceIp = replace_string(IpAddress, "::ffff:", "")
| summarize Failures = count(), DCs = make_set(Computer, 5), Services = make_set(ServiceName, 5)
    by TargetUserName, SourceIp
| order by Failures desc

Finally, surface the lockouts Microsoft flags as abnormal — anything the system did not apply:

SecurityEvent
| where TimeGenerated > ago(30d)
| where EventID == 4740
| where SubjectUserSid != "S-1-5-18"
| project TimeGenerated, Computer, TargetUserName, TargetUserSid, SubjectUserName, SubjectUserSid, SubjectLogonId
| order by TimeGenerated desc

From there, pivot on the Caller Computer Name and work that host; check 4776 Error Codes on the DC for NTLM validation attempts; use the Subject Logon ID to find the matching 4624 if a session performed the operation; and watch for 4767 (account unlocked) followed by a 4624 success, which means the account is live again and you need to know who used it. If the failures that caused the lockout cross many accounts from one source, work it as a spray — the Windows 4625 password-spray rule groups failures that way. With no SIEM to hand, export the Security log as XML from Event Viewer and load it into the free browser log analyzer.