Failed logon attempts are one of the most critical security indicators in any IT environment. Whether you're dealing with a forgotten password, a misconfigured service account, or a potential brute-force attack, identifying the source of these failures is essential for maintaining system security and operational stability. This comprehensive guide will walk you through the methods and tools needed to track down failed logon attempts across various platforms.
Before diving into detection methods, it's important to understand what constitutes a failed logon attempt and why tracking them matters.
A failed logon occurs when an authentication attempt is rejected by the system. This can happen for several reasons including incorrect passwords, disabled accounts, expired credentials, or accounts that don't exist. From a security perspective, multiple failed logon attempts often indicate reconnaissance activity, credential stuffing attacks, or brute-force attempts by malicious actors.
The Windows Event Viewer is your primary tool for investigating failed logon attempts on Windows systems. Failed logon events are recorded in the Security log with specific Event IDs that help you categorize the type of failure.
The most important Event ID to monitor is 4625, which indicates a failed logon attempt. This event contains valuable information including the username attempted, the source workstation or IP address, the logon type, and the failure reason code.
To access these events, open Event Viewer by pressing Win+R and typing eventvwr.msc. Navigate to Windows Logs, then Security. You can filter the log by Event ID 4625 to see only failed logon attempts. The event details provide critical forensic information including the source network address, which tells you where the attempt originated from.
Understanding logon types helps you determine the nature of the authentication attempt. Logon Type 2 represents an interactive logon at the console, Type 3 indicates a network logon such as accessing a shared folder, Type 10 is a Remote Desktop connection, and Type 5 represents a service logon.
Failure codes provide insight into why the logon failed. Status code 0xC000006D means the username is correct but the password is wrong, while 0xC000006A indicates both the username and password are incorrect. Code 0xC0000234 suggests an account lockout, and 0xC0000072 means the account is disabled.
PowerShell provides powerful querying capabilities for analyzing failed logon attempts programmatically. You can use the Get-WinEvent cmdlet to extract and filter security events with greater flexibility than the GUI.
A basic PowerShell command to retrieve failed logon attempts looks like this:
Get-WinEvent -FilterHashtable @{LogName='Security';ID=4625} -MaxEvents 100 | Select-Object TimeCreated, Message
For more detailed analysis, you can parse the event properties to extract specific fields like the source IP address and username:
Get-WinEvent -FilterHashtable @{LogName='Security';ID=4625} -MaxEvents 500 | ForEach-Object {
$xml = [xml]$_.ToXml()
[PSCustomObject]@{
TimeCreated = $_.TimeCreated
UserName = $xml.Event.EventData.Data | Where-Object {$_.Name -eq 'TargetUserName'} | Select-Object -ExpandProperty '#text'
SourceIP = $xml.Event.EventData.Data | Where-Object {$_.Name -eq 'IpAddress'} | Select-Object -ExpandProperty '#text'
WorkstationName = $xml.Event.EventData.Data | Where-Object {$_.Name -eq 'WorkstationName'} | Select-Object -ExpandProperty '#text'
FailureReason = $xml.Event.EventData.Data | Where-Object {$_.Name -eq 'Status'} | Select-Object -ExpandProperty '#text'
}
} | Format-Table -AutoSize
This script creates a more readable output showing the essential details of each failed logon attempt.
Linux systems track authentication failures in various log files depending on the distribution and configuration. The primary locations are /var/log/auth.log on Debian-based systems like Ubuntu, and /var/log/secure on Red Hat-based systems like CentOS and RHEL.
To view recent failed SSH logon attempts on Ubuntu, use:
grep "Failed password" /var/log/auth.log
For more detailed information including the source IP address:
grep "Failed password" /var/log/auth.log | awk '{print $1,$2,$3,$11,$13}'
On CentOS or RHEL systems:
grep "Failed password" /var/log/secure
The lastb command displays a list of bad login attempts recorded in the system. This provides a quick overview of failed authentication attempts:
sudo lastb
To see more entries or filter by username:
sudo lastb | head -50
sudo lastb username
Combining standard Linux tools allows for powerful analysis of authentication patterns. To count failed attempts by IP address:
grep "Failed password" /var/log/auth.log | grep -oP '(\d+\.){3}\d+' | sort | uniq -c | sort -nr
This command extracts all IP addresses from failed password entries, counts occurrences, and sorts them by frequency, helping you identify potential attack sources.
For domain environments, investigating failed logons often requires checking multiple domain controllers. The Active Directory Administrative Center provides a centralized view of authentication events across your domain.
Navigate to the Authentication Policy Silos node or use the Global Search feature to find accounts with recent authentication failures. You can filter by specific users or time ranges to narrow down your investigation.
Since authentication can occur at any domain controller, you need to query multiple servers to get a complete picture. PowerShell can help automate this process:
$DCs = Get-ADDomainController -Filter * | Select-Object -ExpandProperty HostName
foreach ($DC in $DCs) {
Write-Host "Checking $DC..." -ForegroundColor Cyan
Get-WinEvent -ComputerName $DC -FilterHashtable @{LogName='Security';ID=4625} -MaxEvents 50 -ErrorAction SilentlyContinue
}
This script queries all domain controllers in your environment for failed logon events, providing comprehensive visibility across your domain.
Account lockouts often result from repeated failed logon attempts. Event ID 4740 indicates an account lockout and includes the name of the computer that triggered it. This information is recorded on the PDC Emulator role holder by default.
To find which domain controller holds the PDC Emulator role:
Get-ADDomain | Select-Object PDCEmulator
Then query that specific server for lockout events:
Get-WinEvent -ComputerName PDCEmulatorName -FilterHashtable @{LogName='Security';ID=4740}
Your network firewall logs can reveal authentication attempts before they even reach your servers. Many attacks are blocked at the perimeter, and these logs provide early warning of targeting activity.
Most enterprise firewalls log denied connection attempts including source IP, destination IP, port, and protocol. Review logs for repeated connection attempts to authentication ports like TCP 22 for SSH, TCP 3389 for RDP, or TCP 445 for SMB.
IDS and IPS solutions like Snort, Suricata, or commercial alternatives can detect authentication attack patterns in network traffic. These systems often have pre-built rules for detecting brute-force attacks, credential stuffing, and other authentication-related threats.
Configure your IDS to alert on suspicious authentication patterns such as multiple failed attempts from a single source, authentication attempts from blacklisted IP ranges, or unusual authentication timing patterns.
For enterprise environments, centralized logging is essential for effective security monitoring. Solutions like Splunk, Elastic Stack (ELK), or Graylog aggregate logs from multiple sources, enabling cross-system correlation and analysis.
Centralized logging allows you to identify distributed attacks where an attacker targets multiple systems from various source addresses, create baselines for normal authentication patterns, retain logs for compliance and forensic purposes, and implement automated alerting for suspicious activity.
SIEM platforms enable you to create correlation rules that detect attack patterns across your infrastructure. Effective rules for failed logon detection might include alerting on more than five failed attempts from a single IP within ten minutes, detecting failed logons using privileged account names from external sources, identifying authentication attempts outside normal business hours, and recognizing geographic anomalies such as logons from unexpected countries.
Understanding normal authentication patterns is crucial for identifying anomalies. Document typical failed logon rates for your environment, common sources of legitimate failures such as users with expired passwords, peak times for authentication activity, and expected geographic sources of authentication attempts.
Not all failed logon attempts warrant the same level of concern. Prioritize investigation of failures against administrator accounts, service accounts with elevated privileges, critical systems like domain controllers and financial systems, and externally accessible services.
A comprehensive investigation requires correlating data from multiple sources. Cross-reference Windows Security logs with firewall logs and VPN logs, compare timestamps across systems accounting for time zone differences, and correlate usernames with HR data to identify terminated employees or contractors.
Maintain detailed records of your investigations including the timeline of events, affected accounts and systems, identified source addresses and their reputation, actions taken to remediate the issue, and recommendations to prevent recurrence.
Proactive security requires real-time alerting for suspicious authentication activity. Configure your monitoring tools to send immediate notifications when critical thresholds are exceeded.
For Windows environments, you can use Task Scheduler to trigger actions based on Event IDs. Create a task that monitors Event ID 4625 and sends an email when multiple failures are detected within a short timeframe.
For Linux systems, tools like fail2ban automatically detect and respond to failed authentication attempts by temporarily blocking offending IP addresses.
Security dashboards provide at-a-glance visibility into authentication patterns. Effective dashboards should display failed logon attempts over time with trend analysis, top source IP addresses generating failures, most targeted usernames, geographic distribution of authentication attempts, and ratio of successful to failed authentication attempts.
When you identify suspicious failed logon attempts, take immediate action to protect your environment. Block the source IP address at your firewall, reset passwords for targeted accounts, enable additional monitoring on affected systems, and notify your security team or management.
Beyond immediate response, implement longer-term security improvements including enforcing account lockout policies to limit brute-force effectiveness, implementing multi-factor authentication for all users, deploying geofencing to restrict authentication from expected locations, conducting security awareness training about password security, and regularly auditing authentication logs for suspicious patterns.
Finding the source of failed logon attempts is a fundamental security skill that protects your infrastructure from unauthorized access. By leveraging the tools and techniques outlined in this guide, from Windows Event Viewer and PowerShell to Linux log analysis and SIEM platforms, you can quickly identify authentication threats and respond appropriately.
Remember that effective security is not just about detection but also prevention and response. Combine robust monitoring with strong authentication policies, user education, and defense-in-depth strategies to create a comprehensive security posture. Regular review of authentication logs should be part of your routine security operations, allowing you to detect and respond to threats before they result in a successful breach.
Event ID 4625 in the Event Viewer logs represents a failed logon attempt.
Enable auditing for logon events on the domain controller and analyze logs in Event Viewer or use PowerShell.
Yes, you can use firewall rules or network intrusion detection systems to block malicious IP addresses.
Microsoft’s Account Lockout Tools, SIEM solutions, and PowerShell are effective for analyzing failed logons.
These could be due to automated processes, incorrect service account credentials, or malicious attempts.