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.
Click Here to Read the Full Article
About the Author:
Rainer Gerhards works for Adiscon, who offers software for server monitoring. Visit http://www.monitorware.com for more information and free downloads.
| | From the Forum: | | Beware on fresh installs |  We got talking about installing Windows XP and it came up about the MSBlast worm that is plague-ing the internet since mid-July. This also applies to installing Windows 2000 - ALL versions, Windows NT, and 2003 Server (but not 98 or ME).
Please note : when either installing a fresh copy of your OS or simply doing a repair installation, Windows is vulnerable to infection by the Blaster Worm simply by being connected to the internet! ...
|
    |
By
Rainer Gerhards