To monitor unsuccessful logins, account unlocks, and system startups in Windows 11, you must enable specific audit policies via Group Policy and then filter the Security Event Log. The critical Event IDs are 4625 for failed logons, 4780 for account unlock attempts, and 6005 or 6006 for service start and stop events that indicate boot cycles. This process requires administrative access to configure both the policy settings and the log viewer filters.
Enabling Audit Policies for Security Events
The foundation of effective monitoring lies in configuring the correct audit policies. By default, Windows may not record every failed login attempt or startup event with sufficient detail for security analysis. You need to instruct the operating system to log these specific activities in the Security log. Open the Local Group Policy Editor by pressingWin + R, typing gpedit.msc, and hitting Enter. Navigate to the following path: Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Logon/Logoff. Here, you will find several sub-policies that control what gets recorded.
You should explicitly enable the following settings:
- Audit Logon: Set this to Success and Failure. This captures standard logon events (Event ID 4624) and failed attempts (Event ID 4625).
- Audit Other Logon/Logoff Events: Specifically, enable Audit Account Unlock. This is crucial for tracking brute-force attacks where an attacker might trigger lockouts repeatedly. Note that generic "Other" settings are less useful than targeting the specific Account Unlock policy.
gpupdate /force to apply the policies immediately. Without this step, no logs will be generated regardless of how you view them later.
Identifying Key Event IDs
Understanding which Event IDs correspond to specific actions is vital for accurate monitoring. Windows uses a standardized numbering scheme within the Security log. Misidentifying these IDs can lead to false positives or missed security incidents. For unsuccessful logins, the primary identifier is Event ID 4625. This event is generated whenever a user account fails to authenticate against the local machine or domain controller. The details pane of this event provides the source IP address, the logon type (e.g., Type 3 for network, Type 2 for local console), and the failure reason code. Reason codes such as 0xC000006D indicate invalid passwords, while 0xC000006E indicates unknown user accounts. For account unlocks, look for Event ID 4780. This event triggers when a locked-out account is unlocked, either manually by an administrator or automatically after the lockout duration expires. Monitoring this helps distinguish between a user forgetting their password and an automated script attempting to bypass security locks. If you are investigating a potential intrusion, a spike in 4780 events followed by successful logons (4624) is a significant indicator. For system startups, the relevant events are found in the System log rather than the Security log. Event ID 6005 ("The Event log service was started") indicates that the logging service itself has initialized, which happens shortly after boot. Event ID 6006 ("The Event log service was stopped") marks the shutdown sequence. While these do not directly prove a user logged in, they confirm the machine powered on or cycled, which is essential context for correlating login attempts with physical access times.Filtering and Analyzing the Logs
Once the policies are active and events are being generated, you need a method to isolate them from the thousands of other entries in the log. The built-in Event Viewer provides powerful filtering capabilities that allow you to focus on only the data relevant to your security posture. Open Event Viewer by searching for it in the Start menu. Expand Windows Logs and select Security. To filter for failed logins, right-click the Security log and choose Filter Current Log.... In the field labeled All Event IDs, enter4625. Click OK. This view now shows only authentication failures. You can sort by date to identify patterns, such as multiple failures from the same IP address within a short timeframe.
To monitor unlocks, repeat the process but enter 4780 in the Event ID field. For startups, switch to the System log instead of Security, filter for Event IDs 6005 and 6006, and review the timestamps. Combining these views allows you to build a timeline: did the system start (6005), were there failed attempts (4625), was the account locked and then unlocked (4780), and finally, was there a successful logon (4624)?
For more advanced monitoring, consider exporting these filtered logs or setting up alerts. However, for most administrators, manual review using these specific filters is sufficient for detecting immediate threats. Regularly checking these logs ensures that unauthorized access attempts are identified before they escalate into full compromises.
Integrating with Broader Security Strategies
Monitoring individual Event IDs is just one layer of defense. Effective security requires correlating these logs with other system behaviors and network traffic. For instance, if you notice frequent Event ID 4625 entries from external IPs, it may indicate a scanning attack rather than a targeted breach. In such cases, reviewing firewall logs and blocking offending IPs becomes necessary. Furthermore, ensure that your system time is synchronized with a reliable time server. Timestamps in Event IDs are critical for correlation. If your clock drifts, aligning startup events (6005) with login attempts (4625) becomes difficult, potentially obscuring the window of opportunity for attackers. Use thew32tm /resync command to force time synchronization if discrepancies arise.
It is also important to protect the integrity of the logs themselves. Unauthorized users could clear the Event Log to hide their tracks. Enable auditing for the Security Log itself by adding a rule in the Advanced Audit Policy to audit Audit Object Access specifically for the registry key that controls log clearing. This adds another layer of accountability.
For related troubleshooting on system stability, see our guide on Monitoring Windows Event IDs for Unsuccessful Logins, Unlocks, and Startups in Windows 11 for deeper dives into automation scripts. Additionally, understanding file system behavior can help when investigating if files were accessed during these login sessions, as detailed in Windows Explorer Not Finding Files in Downloads, Pictures, and Documents Folders After Recent Manual Moving.
Frequently Asked Questions
Why am I not seeing Event ID 4625 even after enabling audit policies?
You may have enabled the policy but failed to apply it correctly. Run gpupdate /force in an elevated command prompt and verify the policy status with auditpol /get /category:*. Ensure you are viewing the correct log level in Event Viewer, as some systems default to showing only warnings.
Can I automate the alerting for Event ID 4625?
Yes, you can use Task Scheduler to trigger an action when Event ID 4625 occurs. Create a new task, set the trigger to "Custom" > "New Event Subscription," select the Security log, and specify Event ID 4625. Configure the action to send an email or run a script that notifies your security team.
What is the difference between Event ID 4625 and 4771?
Event ID 4625 is the modern, comprehensive log for failed logon attempts in Windows Vista and later. Event ID 4771 is specific to Kerberos pre-authentication failures. While 4625 is generally preferred for broad monitoring, 4771 can provide additional detail on why a Kerberos ticket request failed, often indicating incorrect passwords or expired tickets.
How do I prevent Event ID 4625 from cluttering my logs?
You cannot prevent legitimate failed attempts from being logged if audit policies are enabled. However, you can reduce noise by configuring account lockout policies to limit the number of failed attempts before locking the account. This stops repeated guessing attempts from generating excessive 4625 entries.
Are startup events logged in the Security log?
No, startup and shutdown events like Event ID 6005 and 6006 are recorded in the System log, not the Security log. You must switch your view in Event Viewer to the System log to filter for these specific IDs, as they relate to system service states rather than user authentication.