Find the source of an account lockout

1. Get the log from the right domain controller

Microsoft: "From Windows Server 2008 onwards, an account lockout event will register on the PDCe as event ID 4740 - 'a user account was locked out' - with the lockout source included" (Tracing the Source of Account Lockouts). Find the PDC emulator, then export only the events this needs, which keeps the file small:

# Which domain controller is the PDC emulator
Get-ADDomainController -Discover -Service PrimaryDC

# On that domain controller (administrator command prompt)
wevtutil epl Security C:\temp\lockouts.evtx /q:"*[System[(EventID=4740 or EventID=4625 or EventID=4771 or EventID=4776)]]"

Bad-password events are logged where the password was checked: 4771 (Kerberos) and 4776 (NTLM) on the domain controller that answered, and 4625 on the computer where the logon failed. If the lockout events name no caller computer, export the same events from the other domain controllers too.

2. Read the Caller Computer Name

In event 4740 the Caller Computer Name is stored in the TargetDomainName field of the XML, and Microsoft defines it as "the name of computer account from which logon attempt was received and after which target account was locked out" (event 4740 documentation). The finder groups the lockouts of each account by that name. To check one account without the file, Microsoft's own PowerShell for the last hour:

$User = 'jsmith'
$PDC = Get-ADDomainController -Discover -Service PrimaryDC
Get-WinEvent -ComputerName $PDC.Name -LogName Security -FilterXPath "*[System[EventID=4740 and TimeCreated[timediff(@SystemTime) <= 3600000]] and EventData[Data[@Name='TargetUserName']='$User']]" |
  Select-Object TimeCreated, @{n='User';e={$_.Properties[0].Value}}, @{n='Caller computer';e={$_.Properties[1].Value}}

In Microsoft Sentinel, where the same field is the TargetDomainName column:

SecurityEvent
| where EventID == 4740
| summarize Lockouts = count(), First = min(TimeGenerated), Last = max(TimeGenerated)
    by Account = TargetUserName, CallerComputer = TargetDomainName
| order by Lockouts desc

3. Match the bad passwords

The Caller Computer Name says where the last attempt came from; the failures before it say how. The finder counts, per account and source, 0xC000006A (wrong password) in 4625 and 4776, 0x18 (pre-authentication failed) in 4771, and attempts made after the lockout (0xC0000234, account locked out). The 4771 shows an address and the 4776 a workstation name, so the same computer can appear twice: once by name, once by address.

4. Find what on that computer holds the old password

Microsoft's advice once the source host is known: "look for stale RDP sessions, mapped drives, schedules tasks, etc." The usual suspects are a mapped drive or a scheduled task saved with the old password, a service running as the account, a Credential Manager entry, a disconnected RDP session, and phones or mail clients still signing in with the old password. On the source computer, its own 4625 events name the logon type and the process that tried.

# On the source computer: services and scheduled tasks that run as the account
Get-CimInstance Win32_Service | Where-Object StartName -like '*jsmith*' | Select-Object Name, StartName, State
Get-ScheduledTask | Where-Object { $_.Principal.UserId -like '*jsmith*' } | Select-Object TaskName, TaskPath
cmdkey /list

If many accounts lock out at once, or the bad passwords come from many addresses or from outside, treat it as password guessing rather than a stale password: the log analyzer flags password spraying and brute force in the same file.