Detecting Password Attacks on Windows

Why care about Password Attacks

Windows servers and workstations have become a primary target for malicious users. Be it hackers that try to deface a web site, the Warez community in search for “free” FTP server space or just your internal users interested in restricted files. One common thing about them is that the need to break in either via a software vulnerability or by breaking in into a user account. This article focuses on the later scenario, the try to break in into an account. Fortunately, this occurs not only often but is also relatively easy to spot – and the countermeasures are very simple and effective.

I have used Windows 2000 Server while creating this text. There may be differences for other versions, so you might want to check if you are using a different environment.

Detecting Failed Logons
Numerous failed logons are a good indication that someone is trying to guess user passwords. This is typically done using a so-called “dictionary attack”, where a list of words often used as passwords (the dictionary) is simply tried on a given account. If the account password is carefully chosen, not only the dictionary attack fails but there are many failed logon events. Even if the password is contained in the dictionary, chances are quite good that it is not in the first 5 to 10 words the attacker tries. Windows allows you to lock out an account that has too many invalid password attempts. If the configured threshold is reached, the account will be disabled for a given period of time and Windows will also log an event in the security event log.

Please note that there is a second type of attack, the so called “brute-force” attack. Here, a massive amount of passwords is automatically generated and tried. During a brute force, theoretically all combinations are tried, making it a very lengthy operation. Obviously, the brute force attack will easily be caught by the technique we describe here – it will generate much more failed logins than the dictionary attack. In reality, brute force is seldom used against a server online. Brute force attacks are often used against system files (like the security registry) that have been obtained by some other means.

Configuring Windows
By default, Windows does not check for those kind of attacks. It must be turned on by the administrator. This is done in the “Account Lockout Policy” (part of the “Account Policies”). On a single server, this is configured with the “Local Security Settings” administrative tool. In a domain environment, this is part of the group policy set that is to be applied. For simplicity reasons, we concentrate on the single server environment here. If you administrator a domain, you should be able to adapt the settings quickly to your domain plocies.

Below is a snapshot of a typical configuration for the account lockout policy:

Please note that this policy does not apply to the build-in administrator account. It will never be locked out. This is another very good reason to rename it.

Activating this policy does not automatically write events to the Windows Event Log when an user is locked out by the system. So you will not yet see any evidence just by turning it on. To see evidence, you also need to turn on auditing. This is done with the same tool, under the “Local Policies”, “Audit Policy”. There, you need to enable at least “Success” audits for the “Audit account management”. This is circled in the screen-shot below.

Please note that I have also enabled Logon-related events in the screenshots. We will later see why I have done this.

With these settings, we will receive an security event 644 as soon as an account is locked out.

Screen-shot of the 644 Event

Important: our testing has shown that the 644 security event does not occur under all Windows versions. While testing with Windows 2000 without a service pack, these events did not occur. After applying service pack 3, they appeared. So be sure to check that the events occur in your environment.

As Eric Fitzgerald of Microsoft pointed out in [3], please take good note that the presence of a 644 events does not automatically mean a password attack. There could probably a number of other things go on. But in any case, it means that some account was locked out and this should not happen on a regular basis and as such is worth some attention.

If the 644 event is not generated on your systems and you are not able to patch it to the service pack level that makes it appear, you can alternatively look into the 693 logon failure events. When someone tries to use a locked out account, they look as follows:

Please note the reason text (encircled in red). This specific reason only happens when an account is locked out. However, this reason does only occur after the account has been locked out. The login failure leading to the lockout still has the normal “invalid password” text in it. As such, lockouts may be left undetected or detected only after the incident when using this event as notification. Not only for this reason we highly recommend to apply the most recent service pack.

Filtering these Events
In order to receive notifications from incoming events, I have used MonitorWare Agent to monitor the event logs, filter the events and generate alarms.

Now that we have the proper events present in the Windows Security Event Log, we can build MonitorWare Agent rules to detect unusual patterns. Please keep in mind that the rule set must be either bound to an event log monitor service or be included from another rule set that is bound to one. Without that, the rule set will not be executed. We will not explain this process here in this chapter. We just focus on the filters and rule set itself.

We will create a rule that fires if our 644 event is seen:

We use an email action to notify the admin once this happens:

Of course, we could also have done other things. Good example might be sending a syslog message to a syslog server specifically monitoring such events. The proper action is mainly depending on your intended result.

This rule detects attacks that will lead to an account becoming locked out. It will also fire if a user actually mistypes his password often enough to become locked out. This rule does not help against attacks where the user id changes together with the password. There are some tools out doing so.

Fortunately, we can detect those attacks, too. The key to it is counting failed logons. If the number of failed logons reaches a threshold within a given amount of time, we can suspect that something is wrong. Of course, the threshold is different for different types of machines. A web server, for example, that is just serving web pages and where only administrators and web authors log on, the number of failed logons should be really low. On a busy file server, on the other hand, that threshold should probably be much higher. As such, the actual numbers we use in our sample here should be treated with care. They need to be replaced by some values that match your typical environment and expectations. If in doubt, consult your past event logs to find out what is normal.

We have two different event ids to lock at: the 529 event is generated when somebody logs onto the machine itself. This must not be an interactive logon. It can also be a logon via the network, via the web server, the ftp server or any other logon that is done either by the user himself or a process on his behalf on the local machine.

There is also the 681 event. That event is logged whenever a user is authenticated by the security authority. This event typically is logged on domain controllers when domain users authenticate. A domain controller can log this event even when no local logon happens afterwards. Also, as any domain controller can authenticate a user, the 681 event can occur on every domain controller. Thus, the amount of those events on a single domain controller can not reliable be used to detect the threshold. On a stand-alone server, event 681 is logged together with 529.

For our needs this means we should monitor the 529 event if we are interested in the local failed logon activity and the 681 if our scope is the network. In the later case, it might be helpful to ensure that security events from all domain controllers are passed to a central MWAgent. Only this ensures that MWAgent has the full overview over network logon activity.

In our sample, we monitor a stand-alone server. So our filter looks like this:

Please note the area red encircled. This is the important part here. The “Fire Only if Event Occurs” setting means that there must be at least 10 failed logons within 60 seconds. If there are fewer, the filter will not apply, even though the filter condition would otherwise apply. Similarly, the “Minimum Wait Time” specifies that at least 120 seconds need to have been passed since the last time this filter condition fired. Again, if the last match was more recent, the filter condition as whole does not evaluate as true. So with the above filter, we will receive a notification at most once every 2 minutes (120 seconds).

Obviously, the two global filter conditions need to be adjusted to your environment.

What can not be tracked using this technique
We can only track and detect intrusion attempts that show up in the Windows event log. One popular thing we can not detect for this reason is an attempt to break user passwords via the FTP service. When the FTP service is set to allow anonymous connections, only, it will never try to authenticate the logged-in user to the operating system. The good news is that there is obviously no way for an attacker to learn any user passwords because the authentication will never be successful. The bad new, though, is that we can not use the described technique to detect those attacks.

If you are interested in detecting these kinds of intrusions, you need to focus on the log files generated by the FTP service. But this is a different story. I intend to write an article on how this can be done. If I find some time to complete it, I will post an update on this articles main site.

Detecting Suspicious Configuration Changes
There are many opinions on what a suspicious configuration change might be. In this sample, we assume we are dealing with an already configured web server. It again is a stand-alone server. There is not many need for configuration changes once a machine has reached this stage. Obviously, some of the notifications we generate here are overdone on a typical domain controller. Nevertheless, the example should provide an idea of what to look for.

Events we are interested in are these: