Detecting Password Attacks on Windows

Detecting Password Attacks on Windows

Optimize your email security and usage - Click for a free trial download

03.13.03

Search iEntry News:

Hi Readers,

Automation is a sys admin’s best friend. Whenever you can get your servers to automatically do something, that’s one less chore for you to do. Today, Rainer Gerhards offers some tips on automating one aspect of network security. If you’re using Windows 2000, you can set it up to automatically monitor certain types of errors to alert you when someone is trying to break into user accounts. Read on to learn about the different kinds of errors you can log with Windows, what they mean, and how to set things up so you only hear about the important ones.

Click here for a FREE TRIAL from BVRP

Do you have a funny “stupid user” story? Or did you ever turn the tide of panic by walking into a room and pressing the right button, saving the day and winning admiration of your peers? Well, write ‘em down and send ‘em in! SysAdminNews would like to hear your tales about where you work. Tell us about your best day, your worst day, the most jaw-dropping thing you’ve seen happen – almost anything relating to the life of a sys admin. Send them to jackie@sysadminnews.com. We’ll print them and give you and/or your company a nod.

Detecting Password Attacks on Windows
By Rainer Gehards

Windows servers and workstations have become a primary target for malicious users. Whether it's hackers trying to deface a web site, the Warez community in search for "free" FTP server space, or just your internal users interested in restricted files, they all have one thing in common - their desire to break in, either via a software vulnerability or by through a user account. This article focuses on the latter scenario - attempting to break in into a user account. Fortunately, this occurs rarely and 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.

Click here to get your FREE Tolly Report from Quintum

Detecting Failed Logons
Numerous failed logons is 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 frequently used as passwords (the dictionary) is simply tried on a given account. If the account password is carefully chosen, not only does the dictionary attack fail, but there are also 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 is disabled for a given period of time, and Windows also logs an event in the security event log.

WebmasterFree Downloads

Please note that there is a second type of attack, the so-called "brute-force" attack. Here, a massive number of passwords is automatically generated and tried. During a brute force attack, 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 many 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 these user account attacks. The option 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's sake, we will concentrate on the single server environment here. If you administer a domain, you should be able to adapt the settings quickly to your domain policies.

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

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

Activating this policy does not automatically write events to the Windows Event Log when a user is locked out by the system, so you will not yet see any evidence just by turning it on. To see the 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 at least enable “Success” audits for the “Audit account management”. This is circled in the screenshot 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 a 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.

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 (circled in red). This specific reason only is given when an account is locked out. However, this reason only occurs 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. We highly recommend to apply the most recent service pack (not only for this reason).

Filtering these Events
If you would like near-real-time alerts, I assume that you somehow move the event log data off your server to a central location, or have some local agent that supplies real-time notifications. I will state the general principle here:
Read the entire article

-- SysAdminNews is an ">iEntry, Inc. ® publication --
© 2003 All Rights Reserved Privacy Policy and Legal

Read this article online at:
http://www.SysAdminNews.com/2003/0313.html

archives | advertising info | news headlines | free newsletters | comments/feedback | submit article

To unsubscribe from this mailing list reply to this message with "unsubscribe 119" in the subject or ">click here.