How to Find Bad Password Attempts in Active Directory?

5.5K

If the user has entered an incorrect password when authenticating with Active Directory, an error message will appear on the Windows sign-in screen:

The user name or password is incorrect. Try again.

How incorrect password logs work

When a user attempts to authenticate with an incorrect password, Active Directory updates the badPasswordTime and badPwdCount attributes on the DC that processes the authentication request.

Important. The badPwdCount and badPasswordTime attributes are not replicated between DCs. Each DC maintains its own values. Therefore, querying a user through Get-ADUser returns the values stored on the specific DC that processes the LDAP query, not a domain-wide total.

If the badPwdCount value exceeds the threshold specified in the Account lockout threshold parameter of your Account Lockout Policy, the user account will be locked for a period of time.

Based on the lock event, you can keep track of the device from which the user account has been locked out (check the post to get the account lockout source in AD).

You can use the PowerShell command to get the current values of these AD user attributes:

Get-ADUser -Identity j.brion -Properties badPwdCount, LastBadPasswordAttempt | Select-Object Name, badPwdCount, LastBadPasswordAttempt

This query is useful for checking the bad password information stored on the DC queried by the Active Directory module. However, because badPwdCount and badPasswordTime are not replicated, these values do not represent the complete picture across all DCs.

To investigate bad password attempts across the domain and identify their source, you should query the Security event logs on all DCs, as shown later in this article.

Enable audit policy on AD domain controllers

To track failed authentication attempts with bad passwords, you must enable an audit policy on AD domain controllers:

1. Open the Group Policy Management Console (gpmc.msc);
2. Expand the Domain Controllers Organizational Unit and edit the Default Domain Controllers Policy;
   

   

3. Go to the following Group Policy section: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy > Audit Policies > Logon/Logoff;
4. Configure Advanced Audit Policy on DCs. Enable the following settings:
   Enable:
   Audit Logon → Success and Failure
   Audit Account Logon → Success and Failure
   Audit Kerberos Authentication Service → Failure
   Audit Kerberos Service Ticket Operations → Failure
   Audit Credential Validation → Failure
5. Force update the GPO settings with the command gpupdate /force (or wait for 5 minutes; this is the default policy refresh interval for Domain Controllers).

Check the tracking

Now, if a user tries to log in with an incorrect password, an event with the Event ID 4625 will appear on the domain controller which they are trying to authenticate against (logonserver).

Note. In modern AD environments, Event ID 4625 is not sufficient. You should also analyze the following:

• 4740 → Account lockout events (best starting point for investigations)
• 4771 → Kerberos pre-authentication failures (password guessing/spray detection)
• 4768 → Kerberos TGT requests (normal vs suspicious patterns)
• 4769 → Service ticket requests (lateral movement detection)
• 4776 → NTLM authentication failures (legacy systems/relay attacks)

1. Open the Event Viewer MMC snap-in (eventvwr.msc);
2. Expand Windows Logs;
3. Right-click on the Security and select Filter current log;

   

4. Enter the code 4625 in the Event ID field;

   

5. Only failed login events remain in the list of events;
6. Open the latest event An account failed to log on.
7. The event description contains lots of useful information. It contains the name of the user who attempted to authenticate.
   Account For Which Logon Failed:
   Account Name: j.smith
   And the reason for the login error:
   Failure Reason: Unknown user name or bad password.
   
   Now scroll down the event description. The name and IP of the computer from which the failed login attempt was made will be listed here:
   Network Information:
   Workstation Name: DESKTOP-D0MA607
   Source Network Address: 192.168.79.1
   Source Port: 0
   

   

LogonType in Event ID 4625

Note that Event ID 4625 includes a LogonType field that defines how the authentication attempt was performed. You need to understand LogonType as it is critical for identifying attack vectors:

• LogonType 2. Interactive logon (local console access)
• LogonType 3. Network logon (SMB, file shares, LDAP, service authentication)
• LogonType 9. New credentials (RunAs, secondary logon sessions)
• LogonType 10. Remote Interactive (RDP sessions)

So, why this matters? You need to consider the following:

• LogonType 10. This often indicates RDP brute-force attacks
• LogonType 3. It’s commonly used in password spray attacks and lateral movement
• LogonType 9. This may indicate credential reuse/privilege escalation attempts

Use PowerShell to list computers that attempted to log on with incorrect password

You can use PowerShell to display a list of computers (host name + IP address) that have attempted to log on with an incorrect password as the specified user:

$username = "cyril"

Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4625
} | ForEach-Object {

    $xml = [xml]$_.ToXml()
    $data = $xml.Event.EventData.Data

    [PSCustomObject]@{
        TimeCreated = $_.TimeCreated
        TargetUser  = ($data | Where-Object { $_.Name -eq "TargetUserName" }).'#text'
        IPAddress   = ($data | Where-Object { $_.Name -eq "IpAddress" }).'#text'
        Workstation = ($data | Where-Object { $_.Name -eq "WorkstationName" }).'#text'
        LogonType   = ($data | Where-Object { $_.Name -eq "LogonType" }).'#text'
    }

} | Where-Object { $_.TargetUser -eq $username }

Keep in mind that this method parses the event XML structure, which is more reliable across different Windows Server versions than using fixed Property indexes.

Because badPwdCount and badPasswordTime are maintained separately on each DC, querying a single DC may miss bad password activity recorded by other DCs. For domain-wide investigation, query the Security event logs on all DCs. The following example searches all domain controllers for Event ID 4625 events for the specified user:

Note. The following example requires PowerShell 7 or later because it uses ForEach-Object -Parallel. Run it in pwsh.exe, not Windows PowerShell 5.1 (powershell.exe). If you need to run the script in Windows PowerShell 5.1, remove -Parallel and -ThrottleLimit and process the DCs sequentially.

$username = "cyril"
$startTime = (Get-Date).AddHours(-24)

try {
    $domainControllers = Get-ADDomainController -Filter * -ErrorAction Stop
}
catch {
    Write-Error "Failed to enumerate domain controllers: $($_.Exception.Message)"
    return
}

$domainControllers | ForEach-Object -Parallel {

    $dc = $_.HostName

    try {
        Get-WinEvent -ComputerName $dc -FilterHashtable @{
            LogName   = 'Security'
            Id        = 4625
            StartTime = $using:startTime
        } -ErrorAction Stop | ForEach-Object {

            $xml = [xml]$_.ToXml()
            $data = $xml.Event.EventData.Data

            $targetUser = ($data | Where-Object { $_.Name -eq "TargetUserName" }).'#text'

            if ($targetUser -eq $using:username) {

                [PSCustomObject]@{
                    DC          = $dc
                    TimeCreated = $_.TimeCreated
                    TargetUser  = $targetUser
                    LogonType   = ($data | Where-Object { $_.Name -eq "LogonType" }).'#text'
                    IPAddress   = ($data | Where-Object { $_.Name -eq "IpAddress" }).'#text'
                    Workstation = ($data | Where-Object { $_.Name -eq "WorkstationName" }).'#text'
                }
            }
        }
    }
    catch {
        Write-Warning "Failed to query $dc : $($_.Exception.Message)"
    }

} -ThrottleLimit 10

Note. Querying the remote Security event log requires appropriate permissions on the target DCs and remote Event Log access. The account running the script must be able to read the Security log remotely. If remote access/permissions are not configured, Get-WinEvent -ComputerName may return Access is denied.

Keep in mind that using StartTime significantly reduces event volume and improves performance in large AD environments. If the script reports Access is denied for one or more DCs, you need to check if the account running the script has permission to read the remote Security logs and that Windows Firewall allows remote event log access. A warning for a DC does not mean that no matching events exist; it may mean that the script could not read that DC’s Security log.