HackBlue

Tools · Windows security and Event Logs · 09 / 27

Find the source of an Active Directory account lockout with Event ID 4740

Locate the PDC emulator, read the Caller Computer Name in 4740, then follow 4625 and 4771 on that host to find the stale credential or attacker.

9 min read · practice only with authorization

Where lockouts are recorded

When a domain account locks out, the domain controller that processed the final failure forwards it to the PDC emulator, which writes Event 4740 “A user account was locked out.” Querying the PDC emulator saves searching every DC. Get-ADDomain shows which DC holds the role.

4740 includes Caller Computer Name, the machine the failed attempts came from. That is the starting point.

Snippet
(Get-ADDomain).PDCEmulator
Get-WinEvent -ComputerName (Get-ADDomain).PDCEmulator -FilterHashtable @{LogName='Security'; Id=4740; StartTime=(Get-Date).AddDays(-1)} |
  Select TimeCreated, @{n='User';e={$_.Properties[0].Value}}, @{n='Caller';e={$_.Properties[1].Value}}

Following the trail

On the DCs, Kerberos pre-authentication failures appear as 4771 with failure code 0x18 (bad password), and NTLM failures as 4776. On the caller computer itself, 4625 may show which process tried. Common culprits are a mapped drive with an old password, a scheduled task or service running as the user, a phone syncing mail, or a disconnected RDP session still holding old credentials.

If Caller Computer Name is blank or shows a non-domain device, the attempts may be coming from a VPN, Wi-Fi authentication, or an internet-facing service such as Outlook Web Access, and the trail continues in those logs.

Lab: lock out a test user

In a lab domain with an account lockout threshold set, map a drive on a member workstation with a test user’s password, change the password from another machine, then wait. The mapped drive keeps retrying the old password and locks the account. Find 4740 on the PDC, then 4771 entries pointing at the workstation, then the drive mapping on the workstation.

Remove the mapping, unlock the account with Unlock-ADAccount, and confirm no new lockouts appear.

Snippet
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4771; StartTime=(Get-Date).AddHours(-1)} |
  Where-Object { $_.Properties[0].Value -eq 'testuser' } |
  Select TimeCreated, @{n='Client';e={$_.Properties[6].Value}}, @{n='Code';e={'0x{0:x}' -f $_.Properties[4].Value}}
Unlock-ADAccount -Identity testuser

When it is not a stale credential

Many accounts locking out at once, from one or a few sources, is a password guessing attack. In that case treat the source as hostile, block it, and check for any successful logons from it.

Consider whether lockout is your best control. Smart lockout features in cloud identity platforms and rate limiting at the edge handle guessing with fewer self-inflicted outages.

Diagram

Tracing a lockout

  1. PDC

    Query 4740 on the PDC emulator.

  2. Caller

    Read Caller Computer Name.

  3. DC detail

    Look for 4771 or 4776 from that client.

  4. Host

    On the caller, check mapped drives, tasks, services, and sessions.

Check yourself

1. Which domain controller is the best place to look for 4740?

2. What does Kerberos failure code 0x18 in 4771 mean?

3. Fifty accounts lock out within minutes from one address. What is most likely?