Password Attacks on Windows
By Rainer Gerhards
Article Date: 2003-02-25
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.
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
Detecting Failed Logons
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.
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.
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.
a snapshot of a typical configuration for the account lockout policy:
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.
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.
note that I have also enabled Logon-related events in the screenshots. We will
later see why I have done this.
these settings, we will receive an security event 644 as soon as an account is
Screen-shot of the 644 Event
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 , 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.
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:
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.
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:
an email action to notify the admin once this happens:
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.
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.
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.
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
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.
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.
sample, we monitor a stand-alone server. So our filter looks like this:
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
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
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:
- 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 
- 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 .
By clicking on the event IDs, you a brought to detail parsing information for the respective
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 product, we would like to see neither of them.
create two rules in MonitorWare Agent, one for the highly suspicious events and
one for the others. Let’s start with the highly suspicious ones:
And this one holds the filter conditions for the other suspicious events:
for this rule-sets to work, we also need to tune our auditing settings. We now
need to audit "System Events" and "Policy Change", too. This will lead us
to these policy settings:
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.
Obviously, no security reference can be complete. Thus, I have created a
discussion forum specifically focussed on Windows Events.
Feel free to post any questions and comments you have. And be sure
to browse it from time to time - I will post updates there.
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.
2003-02-25 Initial version created.
rgerhards @ adiscon.com
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