Windows Event Log Triaging
Security & SOC analysts are frequently tasked with the triaging of event log data. This article serves as a reference point for those in need of investigating failed logon attempts, a.k.a. Windows Event Log ID 4625. Given the numerous opportunities for logging on to computers these days, determining the cause can be challenging to both IT generalists and security teams.
Why you care about failed logons:
- 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
One fundamental investigative operation is to determine how the authentication was attempted. This is answered partially by determining the Logon Type.
| Logon type | Logon title | Description |
|---|---|---|
| 2 | Interactive | A user attempted to log on at a Windows computer’s local keyboard and screen. Most common cause is human error incorrectly typing the user name 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. |
Observations performed by the RocketCyber SOC Team conclude that most but not all Failed Logon events for SMBs tend to result in Type 2, 3, 4 and 5 resulting in non malicious activity but does present a security risk. After triaging numerous failed logons originating from inside the network, most are caused by:
- Fat finger logons (bad password / username entry)
- Cached outdated credentials accessing mapped drives
- Scheduled tasks with outdated credentials
- Batch files with expired accounts
We don’t live in a perfect world and in short, monitoring failed logons should be monitored and triaged. With that said, logon types can play a role for prioritizing remediation efforts. For many security teams, another variable to add to the mix is whether or not such logon activity is originating from inside or outside the network. Eliminating the risk from external attempts tends to be popular among the industry while internal attempts often get shoved aside but shouldn’t be negated.
Event Field Descriptions
Windows Event Log
Example of a Failed Logon Event ID 4625
Beyond and above logon types, there are a number of other important pieces of the puzzle included within the Windows Event Details such as:
Subject / Account Name – Identifies the account that requested the logon (not the user who attempted the logon).
Account Failed / Account Name & Domain – This identifies the user that attempted to logon and failed and in many but not all cases includes the account logon name and domain (computer name if it is a local account)
Network Information – This section identifies where the user was when logged on. If logon is initiated from the same computer this information will either be blank or reflect the same local computers. The computer name and source network address tend to be most helpful when populated. The source port is also provided but does not aid in triaging given that most source ports are random.
Failure Information – The section that details why the logon failed including Reason) a textual description and Status/Sub Status) hexadecimal codes providing additional insight.
Process Information – My favorite when it’s available. The best part is it includes the Process ID (PID) of the process that attempted the logon. Then one can cross reference the PID to the process in Task Manager. One caveat, the event log data outputs hexadecimal which needs to be converted to a decimal value before performing the lookup in Task Manager.
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 over the past few months:
| Status / Sub Status Code | Description |
|---|---|
| 0xC000006A | user name is correct but the password is wrong |
| 0xC0000064 | user name does not exist |
| 0XC000006D | This is either due to a bad username or authentication information |
| 0XC000006E | Unknown user name 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 is not an exhaustive list of event telemetry, it can be served as a primer for those in IT / Security in charge of investigating why failed logons are occurring. I’ve highlighted several reasons to monitor such events spanning Security, Compliance and IT Hygiene. As a managed service provider, we recommend the monitoring of such logons among other important event logs to better improve the security posture for small-medium business customers. If your MSP is lacking tools, skillsets or resources, I’d invite you to learn more about RocketCyber’s SOC-as-a-Service and how we address these challenges by, scheduling a meeting to speak with a RocketCyber security engineer today.