| |
 Detecting
Password Attacks on Windows
By Rainer Gerhards
Contributing Writer
Article Date: 02.04.03
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.
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.
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:
We will create a rule that fires if our 644 event is seen. To do so, we need to
check that it is indeed a 644 event from source "Security" of the Security
event log. Remember: other event sources might also have a 644 event and if you
don't filter on the particular log and source, you might run into trouble. Of
course, the security log is intended to be written by Windows, only, but it's
better play it safe... Once you detect this event, you will probably notify your
administrator via email or at least log a potential security breach in one of
your central security repositories. For example, you may send a syslog message
to a syslog server specifically monitoring such events. The proper action is depends
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
along with the password. There are some hacker tools available that do this.
Fortunately, we can detect those attacks, too. The key to it is counting failed
logons. If the number of failed logons reaches a configured 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. On a web server that is just serving
web pages and where only administrators and web authors log on, for example, 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
should be treated with care. You need to select 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 number 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.
If you would like to use the 681 events, you need to consolidate them on a central
server first. There are some solutions out there for doing so - I have used MonitorWare
Agent [2] in my configuration.
When creating filters, you must ensure that the filter will only be triggered
if a specific number of those events occur. This is the important part here. For
example, you could filter to receive 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. I also suggest that you specify a minimum time to wait
between taking actions on the filter; for example, wait at least 2 minutes before
the filter is again allowed to match. If you use the settings I recommended, you
can than trigger actions, e.g. again sending notification, at maximum every 2
minutes when a suspect activity occurs. Obviously, the filter conditions will
need to be adjusted to your environment.
Detecting Suspicious Configuration Changes
Other than attempts to break passwords, you may also want to monitor for additional
suspicious activity. There is a wealth of security events logged by Windows. You
might want to review the security events and their parsing information [1]
to get an idea of what is available.
There are many opinions on what a suspicious configuration change might be. In
this article, I assume we are dealing with an already configured web server. It
again is a stand-alone server. There is not much need for many configuration changes
once a machine has reached this stage. Obviously, some of the notifications we
generate here would be 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:
- Account Management
- 624
– User Account Created
- 626
– User Account Enabled
- 627
– Password Change Attempted
- 628
– User Account Password Set
- 629
– User Account Disabled
- 630
– User Account Deleted
- 631
– Security Enabled Global Group Created
- 632
– Security Enabled Global Group Member Added
- 633
– Security Enabled Global Group Member Removed
- 634
– Security Enabled Global Group Deleted
- 635
– Security Enabled Local Group Created
- 636
– Security Enabled LocalGroup Member Added
- 637
– Security Enabled LocalGroup Member Removed
- 638
– Security Enabled LocalGroup Deleted
- 639
– Security Enabled LocalGroup Changed
- 641
– Security Enabled Global Group Changed
- 642
– User Account Changed
- 643
– Domain Policy Changed
- System Events
- 512
– Windows is starting up
- 513
– Windows is shutting down [3]
- 516
– Internal resources allocated for queuing of security event messages have been
exhausted, leading to the loss of security event messages
- 517
– The security log was cleared
- Policy Change
- 608
– A user right was assigned
- 609
– A user right was removed
- 610
– A trust relationship with another domain was created
- 611
– A trust relationship with another domain was removed
- 612
– An audit policy was changed
- 768
– A collision was detected between a namespace element in one forest and a namespace
element in another forest
All events are taken from the Event parsing information database [1].
By clicking on the event IDs, you are brought to detail parsing information for
the respective event.
Events in bold are uncommon on nearly all types of machines. Depending on the role a
server is playing, events not shown in bold can occur as part of day-to-day operations.
On such servers, they should obviously not trigger alarms. Again, on a fully configured
web server in production, we would like to see neither of them.
You can create filters in your analysis software to take care of the highly suspicious
events and one for the others.
Combine them with the necessary actions, like emailing an admin alert.
Please note that the events are not generated in the default configuration. In
order to see them in the event log, we need to tune the auditing settings. We
now need to audit “System Events” and “Policy Change", too. This will lead
us to these policy settings:
Conclusion
Windows provides many security-related events which helps us ensuring that the
server is not being compromised by an attacker. Also, Windows allows us to guard
against password attacks. Unfortunately, none of these things are done in the
default configuration, so we need to configure the security policies accordingly.
With a little effort, we can guard our system against passwords being cracked.
And please keep in mind that this technique works well for internal servers and
even workstations. Remember that experts think roughly 80% of corporate security
attacks come from the inside, so it is vital to take precautions here, too.
Questions?
Obviously, no security reference can be complete. Thus, I have created
a discussion forum specifically
focused on Windows Events. Feel free to post any questions and comments you
have. And be sure to browse it f
References
Related Software
The MonitorWare
product family provides near real-time monitoring and alerting. It can be
used to detect unusual system activity. It can be used to detect malicious activity
as the one described here.
Disclaimer
The information within this paper may change without notice. Use of this information
constitutes acceptance for use in an AS IS condition. There are NO warranties
with regard to this information. In no event shall the author be liable for any
damages whatsoever arising out of or in connection with the use or spread of this
information. Any use of this information is at the user's own risk.
About the Author:
Rainer Gerhards works for Adiscon,
who offers software for server monitoring. Visit www.monitorware.com
for more information and free downloads.
|
|
