Security and SOC analysts regularly triage Windows event logs to identify potential threats. One of the most common — and often misunderstood — alerts is the failed logon attempt, known as Windows Event ID 4625. With so many ways users, services and systems authenticate today, pinpointing the root cause can be challenging for both IT generalists and security teams.
Why you care about failed logons
Failed logon events may seem routine, but they often signal underlying security, operational or compliance concerns. Monitoring and triaging these events is important for several key reasons:
- Security – To detect brute force / password related attacks and malicious internal activity.
- IT hygiene – Housecleaning of devices failing to authenticate should be remediated as stale administrative accounts or users with expired passwords can pose security risks.
- Compliance – Most industry regulations mandate log monitoring and auditing of failed logons.
Logon Types
When triaging a failed logon event, one of the first questions to answer is how the authentication attempt occurred. Windows assigns a specific logon type to each authentication attempt, providing important context about whether the activity was interactive, network-based, service-driven or automated. Understanding these logon types helps narrow the investigation and prioritize response efforts.
The table below outlines the most common Windows logon types you’ll encounter when investigating Event ID 4625:
| Logon type | Logon title | Description |
| 2 | Interactive | A user attempted to log on at a Windows computer’s local keyboard and screen. The most common cause is human error, specifically, incorrectly typing the username and/or password. |
| 3 | Network | A user or computer logged on to this computer from the network. This logon mostly occurs when you access remote file shares or printers. If IIS is in play, Internet Information Server attempts are recorded as a network logon also. |
| 4 | Batch | Batch logon type is used by batch servers, where processes may be executing on behalf of a user without their direct intervention. The most common failed event is scheduled tasks here. |
| 5 | Service | A service was started by the Service Control Manager. Most common failed event is when services and service accounts attempt to log on to start a service. |
| 7 | Unlock | This workstation was unlocked. This occurs when you attempt to unlock your Windows system. |
| 8 | NetworkCleartext | A user logged on to this computer from the network while the user’s password was passed to the authentication package in its unhashed form (in clear text). Most failed logons occur here when a user uses basic authentication to authenticate to an IIS server. |
| 9 | NewCredentials | A caller cloned its current token and specified new credentials for outbound connections. The new logon session has the same local identity but uses different credentials for other network connections. Failed events here are mostly caused when a user starts a program with RunAs /netonly. |
| 10 | RemoteInteractive | A user logged on to this computer remotely using Terminal Services or Remote Desktop. |
| 11 | CachedInteractive | A user logged on to this computer with network credentials that were stored locally on the computer. The domain controller was not contacted to verify the credentials. |
Based on observations from the RocketCyber SOC team, most failed logon events in small and medium-sized businesses (SMBs) fall under logon Types 2, 3, 4 and 5. In many cases, these events are not malicious — but they can still introduce security risk if left unaddressed.
After investigating numerous failed logons originating from inside the network, the most common causes include:
- Fat finger logons (bad password / username entry)
- Cached outdated credentials accessing mapped drives
- Scheduled tasks with outdated credentials
- Batch files with expired accounts
Failed logons are inevitable, but they should never be ignored. Consistent monitoring and triage are essential to distinguishing harmless user error from genuine security threats. Logon types can help prioritize remediation efforts, especially when determining whether activity originated inside or outside the network. While external attempts often receive immediate attention, internal failed logons are frequently overlooked — even though they can indicate misconfigurations, stale credentials or malicious activity.
Event field descriptions
To better understand how failed logons appear in practice, let’s examine a real-world example of a Windows Event ID 4625 entry. The screenshot below highlights the key fields analysts review during triage.
Beyond logon type, several additional event fields provide critical context when investigating a failed logon. These details help analysts determine who initiated the attempt, where it originated and why it failed.
Subject / account name – Identifies the account that requested the logon. This is not necessarily the same as the user account that ultimately failed authentication.
Account for which logon failed (account name & domain) – Identifies the account that attempted to authenticate and failed. In most cases, this includes both the username and the associated domain (or computer name if it is a local account).
Network information – Indicates where the logon attempt originated. If the attempt was initiated from the same system, this section may be blank or reflect the local machine. When populated, the workstation name and source network address are especially valuable for triage. The source port is also listed, but it is typically less useful since most source ports are dynamically assigned.
Failure information – Explains why the logon attempt failed. This includes a textual failure reason along with status and substatus codes (in hexadecimal format), which provide more granular insight into the cause of the failure.
Process information – When available, this section can be particularly useful. It includes the process ID (PID) of the application that initiated the logon attempt. Analysts can cross-reference the PID in Task Manager to identify the associated process. Note that Windows logs the PID in hexadecimal format, which must be converted to decimal before performing the lookup.
Top 10 status / sub status codes
The table below is provided as a reference for the most frequent status / sub status codes observed by the RocketCyber SOC team:
| Status / sub status code | Description |
| 0xC000006A | Username is correct but the password is wrong |
| 0xC0000064 | Username does not exist |
| 0XC000006D | This is either due to a bad username or authentication information |
| 0XC000006E | Unknown username or bad password |
| 0xC0000193 | Account expired |
| 0xC0000070 | Logon attempt from unauthorized workstation |
| 0xC0000071 | Password expired |
| 0xC0000072 | Logon attempt to account disabled by administrator |
| 0xc000015b | The user does not have logon rights to authenticate to this computer |
| 0xC0000234 | Logon attempt with account locked |
Summary of triaging Windows event log 4625 (failed logon)
While this overview does not cover every possible telemetry detail, it serves as a practical foundation for IT and cybersecurity professionals investigating failed logon events. Monitoring Event ID 4625 supports stronger security oversight, improved IT hygiene and regulatory compliance.
For managed service providers supporting small and medium-sized businesses, consistent monitoring and triage of failed logons — alongside other critical security events — can significantly strengthen overall security posture. Organizations that lack the tools, expertise or resources to effectively monitor and respond to these events should consider evaluating modern security solutions designed to deliver continuous visibility, threat detection and response.
To learn how Kaseya’s security portfolio can help enhance monitoring, detection and response capabilities, request a demo with a security specialist.
