Detecting Password Attacks on Windows

Why Windows Servers and Workstations Are Hot Targets for Password Attacks

In today’s interconnected workplaces, the majority of an organization’s data resides on Windows servers or endpoints. That ubiquity turns them into a tempting playground for attackers. When an adversary can access a machine, they gain a foothold that can expand to the entire network, reveal sensitive files, or allow the launch of denial‑of‑service attacks against customer-facing services.

Many intrusions start with a simple brute‑force or dictionary attack aimed at user credentials. Attackers typically compile a list of commonly used passwords - names, birthdays, or simple phrases - and automatically feed them to the log‑on prompt. If the account’s password is weak, the attacker may succeed in minutes. Even if the password is strong, the repeated failures still generate a flood of event‑log entries that, if monitored, give away the assault in progress.

Corporate networks tend to expose a wide variety of authentication points. Web servers, file shares, VPN gateways, and remote‑desktop services all require user names and passwords. Each of these points offers an opportunity for an attacker to test a dictionary or brute‑force the account. Consequently, the probability that an account will experience a malicious login attempt is high, especially on servers that allow public or semi‑public access.

Internal actors represent another threat vector. Users who already hold legitimate credentials can combine them with stolen network traffic or stolen credential dumps to gain privileged access. Because they appear as “normal” users, their actions are more difficult to detect. That’s why a layered approach - account lockout, detailed auditing, and event‑log monitoring - is essential to guard against both external and insider attacks.

Windows includes built‑in mechanisms to mitigate password attacks, but they are not activated by default. If left unattended, the system will log the failed attempts but offer no automatic protection. Without a policy that locks accounts after a certain number of failures, a determined attacker can try thousands of passwords without interruption. That’s why the first step in hardening Windows is to enable the Account Lockout Policy and to set the thresholds appropriately for your environment.

When a policy is active, each invalid log‑on attempt is recorded in the security event log. Administrators can use these records to detect patterns indicative of an attack, such as a rapid sequence of failures on the same account or on many accounts from a single source. By keeping the lockout thresholds low - often five to ten attempts for sensitive accounts - an attacker’s time window shrinks dramatically. Even a well‑crafted password that passes a dictionary check will eventually trigger a lockout if the attacker continues guessing.

Beyond the obvious benefits of stopping password cracking, lockout policies serve a vital monitoring function. A locked‑out account raises an event that can be forwarded to a centralized monitoring tool. The event provides the attacker’s IP address, the targeted account, and the timestamp. In many environments, that single line of information can be the key to stopping a breach before the attacker moves laterally.

In short, every Windows server and workstation that handles user credentials should enforce an account lockout policy. Coupled with audit logging and real‑time event monitoring, the policy forms the backbone of a proactive defense strategy against password attacks.

How to Spot Failed Logon Attempts That Signal an Attack

Identifying a password attack isn’t hard if you know what to look for. The Windows security event log records every failed authentication attempt as an event. On a system that accepts remote connections, the event ID is 529 for interactive log‑ons and 4625 for domain‑based authentication. These events contain the username, domain, client IP, and a “failure reason” string.

Attackers usually employ a dictionary list that contains hundreds or thousands of common passwords. When an account is brute‑forced, the first ten attempts often hit the most common words. If the password is not in the dictionary, you’ll see a long stream of failures, each one adding to the event‑log backlog. Even a well‑chosen password will still produce many failures because the attacker will cycle through the list until the correct entry appears, if ever.

In contrast, a legitimate user who accidentally mistypes a password a few times will also generate failures, but usually only one or two per session. The key difference lies in the frequency and volume of failures over a short period. If you notice a single account receiving more than five failures within a minute, that should raise a flag. Equally, if you observe an IP address attempting to log on to several accounts in a burst, the pattern points toward credential stuffing.

Another subtle indicator is the “failure reason” string. For typical dictionary attacks, the string reads “The user name or password is incorrect.” In the rare case of a locked‑out account, the string changes to “The user account has been disabled.” A sudden switch from “incorrect” to “disabled” usually means the lockout policy has just triggered. Monitoring for that transition can alert you to the attack before the attacker realizes their account is blocked.

Because Windows does not log failed attempts for the built‑in Administrator account by default, it’s a good idea to rename that account or disable it altogether. Once the name changes, the system will start recording attempts against it. That way you get a complete audit trail and can detect attacks aimed specifically at the most privileged account.

To make sense of the raw events, you’ll need a tool that can aggregate and analyze them. Some organizations use the built‑in Event Viewer with filters, but that approach is manual and error‑prone. A more scalable solution is an event‑log forwarder that pulls events from all servers and pushes them to a central SIEM. From there, you can build correlation rules that fire when thresholds are exceeded.

When configuring such rules, choose conservative thresholds that balance false positives and missed detections. A good starting point is “10 failures from the same IP within 60 seconds.” Adjust the numbers based on your environment’s normal traffic patterns. For a small office with a handful of users, even a single failed attempt might be unusual. For a large data center, a higher threshold may be needed to avoid noise.

In summary, the simplest way to detect a password attack is to watch for rapid, repeated failures, a change in the failure reason, and a spike in failures from a single source. Once you set up an alerting mechanism around these signals, you’ll see almost every attempt before it becomes a compromise.

Enabling and Fine‑Tuning the Account Lockout Policy

The Account Lockout Policy lives inside the Local Security Settings or, in a domain, inside a Group Policy Object. The policy has three components: the lockout threshold, the lockout duration, and the reset counter delay. Setting the threshold to a low number, such as five, forces Windows to disable the account after that many consecutive failures. The lockout duration determines how long the account stays disabled; a common setting is fifteen minutes. The reset counter delay tells Windows how long it takes before the counter starts counting again after a successful login.

After you open the Local Security Policy snap‑in (secpol.msc), navigate to Account Policies → Account Lockout Policy. The default values are usually 0 for threshold and duration, meaning lockout is disabled. Clear the threshold, set it to a small number, and choose a realistic duration. The policy automatically applies to all users on that machine, except for the built‑in Administrator, unless you rename the account.

In a domain, you’ll need to create or edit a GPO that applies to the OU containing your servers. The settings mirror those in the local policy, but the domain controller holds the authority. Once you link the GPO, the settings replicate to all target machines. Because group policies can override local settings, double‑check that no conflicting policies exist.

Lockout alone does not generate an event until the account is actually disabled. By default, Windows does not log a separate event for the lockout itself; it only records the failure events that led to it. To receive a dedicated event when a user gets locked out, you must enable auditing for “Account Management.” Open the Audit Policy section, tick “Success” for that item, and save. After that, you’ll see event ID 644 in the security log each time a lockout occurs.

Note that Windows 2000 without service pack 3 did not log the 644 event. In that case, you could monitor event ID 693, which appears whenever someone tries to log on with a locked‑out account. The event includes a reason string that explicitly states the account is disabled. After installing the latest service pack, the 644 event appears and is more reliable.

Because the event ID can vary by OS, it’s important to verify that the event appears on each system you monitor. If you find a machine that doesn’t log the event, apply the appropriate service pack or consider logging the failure events and deducing the lockout from their pattern.

When you have lockout and auditing enabled, you’ll start receiving a flood of failure events on compromised or heavily targeted accounts. The next step is to filter those events so that only suspicious patterns trigger alerts.

From Raw Events to Alarms: Building a Rule Set with MonitorWare

Once you know the event IDs that matter - 529, 4625, 644, and optionally 693 - you can feed them into a monitoring tool that watches the security log in real time. MonitorWare Agent, for example, can ingest the event log, apply filters, and send email or syslog alerts. The core idea is to create rules that fire when the number of failures from a single IP or account exceeds a threshold within a short window.

First, configure the Agent to monitor the local security log. In the MonitorWare console, create a new rule set and bind it to the Event Log Monitor service. Inside the rule set, add a filter for event ID 644. This filter is straightforward: whenever a lockout event occurs, the rule fires. Attach an action that sends an email to the security team and optionally writes the alert to a centralized syslog server.

Next, create a more elaborate rule that counts failures. Set the filter to match event ID 529 or 4625. Add a condition that the event’s “Failure Reason” equals “The user name or password is incorrect.” Wrap the filter in a “time window” constraint: if more than ten matching events occur within sixty seconds, the rule should trigger. You can also add a minimum wait time of two minutes to prevent alert storms if a single attacker continues to generate failures over an extended period.

For domain environments, add a second rule that monitors event ID 4625 on domain controllers. Because domain controllers log the authentication attempt before it reaches the target machine, this rule captures attempts that might bypass local lockout policies. Ensure that all domain controllers forward their security logs to the same MonitorWare instance so that you have a complete picture.

When the rule set is live, you’ll receive a notification the moment a user account is locked or a suspicious burst of failures is detected. The email or syslog entry should include the account name, the source IP, the timestamp, and a link to the event details in Event Viewer. If you need deeper context, you can configure the Agent to add a screenshot or the raw event JSON to the alert.

Fine‑tuning is essential. A too‑tight threshold may trigger false positives during a legitimate password reset. A too‑loose threshold may let an attacker continue undetected. Start with the default values and adjust based on your organization’s baseline. Use the Agent’s audit logs to review past alerts and tweak the parameters accordingly.

Because the monitoring system can alert on any event that matches the filter, you can extend the rule set to include other events, such as account creation or password changes. This way, you keep a single rule set that covers the entire user‑account lifecycle, from creation to compromise.

Beyond Lockouts: Watching for Suspicious Configuration Changes

Even if you block most password attacks, a determined attacker can still move laterally by modifying system settings. Windows logs an extensive list of configuration changes, many of which are rare in normal operations but signal a potential intrusion when they appear out of the ordinary.

Events related to account management - IDs 624 to 642 - capture actions such as creating, enabling, disabling, or deleting users and groups. For example, event 624 indicates a new user was created. If you see a batch of new accounts appear overnight on a production server, that is a red flag. Similarly, event 627 signals a password change attempt; multiple attempts on the same account could indicate credential stuffing.

System events like 512 and 513 record the machine starting up or shutting down. Unexpected shutdowns (event 513) can indicate that an attacker forced the system to reboot, possibly as a cover for installing malware.

Policy change events, such as 608 to 612, track modifications to user rights, trust relationships, and audit policies. If an attacker grants themselves administrative rights, event 608 will appear. A sudden change in the audit policy (event 612) can hide future attacks by turning off critical logging.

To monitor these events, enable auditing for “Account Management,” “System,” and “Policy Change” in the Audit Policy section. Then, in MonitorWare, create separate rule sets for the “highly suspicious” events - those that almost never happen under normal operation - and for the “moderately suspicious” events - those that can occur occasionally but should still be reviewed.

For highly suspicious events, set the rule to fire immediately upon the event’s appearance. Attach an action that escalates the alert, perhaps sending an SMS or triggering a ticket in an incident‑management system. Because these events are rare, you can afford a low tolerance for false positives.

For moderately suspicious events, add a threshold that requires at least two occurrences from the same source within an hour before firing. This filters out legitimate administrative tasks that happen infrequently. Use the same alerting actions as the high‑risk set, but consider a lower urgency level.

When designing the rules, take into account the role of each server. A web server that only hosts a public website will have a smaller set of expected changes than a domain controller that manages users across the entire network. Adjust the thresholds accordingly to avoid drowning the team in alerts while still maintaining a meaningful security posture.

Finally, remember that the event log is only as useful as the context you provide. Store the event details in a searchable archive, tag each event with the associated system, and document the normal baseline so that when a flag appears, you can quickly determine whether it’s truly anomalous.

What Attack Vectors Slip Through the Event‑Log Net

While the Windows event log captures most authentication failures and configuration changes, it does not record every possible attack. One notable omission is the anonymous FTP login. If a server allows anonymous connections, the FTP service bypasses the operating‑system authentication mechanism, meaning no event is logged for the user attempting to access the file system.

In such cases, the attacker can read or write files without triggering any lockout or audit event. The only indication that something is wrong might come from the FTP server’s own log file, which is separate from the Windows event log. Administrators who rely solely on the event log may never see this type of intrusion.

Another blind spot involves credential theft via phishing or malware that captures user credentials from memory or from the Windows credential store. Once an attacker has the password, they can log in normally, and the event log will record a successful authentication. The attack becomes invisible because no failure event appears.

Similarly, attacks that use valid privileged accounts to elevate privileges or modify system settings may not be caught if the account is already trusted. An attacker who gains access to an administrative account and then changes the account lockout policy will effectively disable the very protection you set up, all without generating a new event that indicates malicious intent.

Because of these limitations, a layered approach is essential. Combine the event‑log monitoring with network traffic analysis, host‑based intrusion detection, and file‑integrity monitoring. For FTP, enable logging at the application level and review those logs regularly. For credential theft, enforce multifactor authentication and deploy a credential‑guard solution that detects unusual credential usage patterns.

In environments where security is paramount, consider deploying a dedicated SIEM that ingests logs from all layers - network, host, and application. A well‑configured SIEM can correlate an anomalous file access with a known attack pattern, even when the event log shows no red flags.

By understanding the gaps in the event‑log net, you can fill them with complementary controls, ensuring that every attack vector is monitored and mitigated.