- Weeding Through Endless Possibilities
- Creating and Analyzing an Audit Log
- For More Information
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Creating and Analyzing an Audit Log
All the events will show up in the Event Viewer. However, you decide which events to log. Given the fact that even routine activities generate a swarm of loggable events, you need to be selective. For authentication auditing, concentrate on the events that are most useful in spotting potential security breaches or other problems. (You may want to use a filtering tool to cut down the clutter, to aid you in spotting patterns in the events.)
You create an audit log using Group Policy at the site, domain, organizational unit, or local level. Here's the hierarchy:
Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policies
While you can audit and log down to the file level, for consistency you should enable auditing and logging at the highest level possible—usually at either the site level or domain level.
Once the log has been created, Windows has done its part of the job, and your work begins. Auditing is nearly as much an art as a science. In the case of authentication auditing, it helps to understand the kinds of attacks and the event trails they produce. You especially want to know the difference between accidental or random events and events that indicate an attack. For example, a single failed logon with an incorrect password doesn't mean much. Several attempts to log onto the same account with incorrect passwords needs a much harder look.
Although third-party analyzers can scan your logs looking for suspicious events, the basis of security log auditing is still the "Mark 1 Eyeball," backed by some knowledge and a lot more reasoning.
Logon Events To Watch
Table 1 shows Microsoft's descriptions of the event IDs for Logon and Account Logon events.
Table 1 Logon Events
|
Event ID |
Description |
|
528 |
A user successfully logged onto a computer. |
|
529 |
The logon attempt was made with an unknown username or a known username with a bad password. |
|
530 |
An attempt was made to log on with the user account outside of the allowed time. |
|
531 |
A logon attempt was made using a disabled account. |
|
532 |
A logon attempt was made using an expired account. |
|
533 |
The user is not allowed to log on at this computer. |
|
534 |
The user attempted to log on with a logon type that is not allowed, such as network, interactive, batch, service, or remote interactive. |
|
535 |
The password for the specified account has expired. |
|
536 |
The Net Logon service is not active. |
|
537 |
The logon attempt failed for other reasons. |
|
538 |
A user logged off. |
|
539 |
The account was locked out at the time the logon attempt was made. This event can indicate that a password attack was launched unsuccessfully, resulting in the account being locked out. |
|
540 |
Successful network logon. This event indicates that a remote user has successfully connected from the network to a local resource on the server, generating a token for the network user. |
|
682 |
A user has reconnected to a disconnected Terminal Services session. This event indicates that a previous Terminal Services session was connected. |
|
683 |
A user disconnected a Terminal Services session without logging off. This event is generated when a user is connected to a Terminal Services session over the network. It appears on the terminal server. |
Failed logon attempts are indicated by event IDs 529, 530, 531, 532, 534, and 537. A username and password guessing attack will produce events 529 (bad username or password) and 534 (disallowed logon type). However, these events also show up if a user forgets his or her password or starts browsing the network through My Network Places.
Making Sense of the Patterns
As in almost all auditing, what you're looking for here is patterns in the events. A single 529 event (bad username or password) doesn't matter much; it usually means that someone's fingers slipped on the keyboard. But a sudden spike in the number of 529 and 534 events, or a bunch of 529 events followed by a 528 (successful logon) after hours can indicate a successful attack. (Or, as Microsoft points out, a very tired administrator.)
Events 530, 531, 532, and 533 may mean that someone is misusing a user account. All of them mean that the account and password combination was correct but the user is running into problems with restrictions on the account, such as allowed time to log on (530), or logging on from a disabled account (531) or an expired account (532).
Event 539 is the usual result of a failed password attack. If there are earlier 529 events (incorrect password) on the same account, you may be looking at an attack.
Event 682 indicates an attempt to connect to a previous disconnected session and event 683 indicates that a user didn't log out after the Terminal Services session ended.
Table 2 shows the event log messages.
Table 2 Event Log Messages
|
Event ID |
Description |
|
672 |
An authentication service (AS) ticket was successfully issued and validated. |
|
673 |
A ticket-granting service (TGS) ticket was granted. |
|
674 |
A security principal renewed an AS ticket or TGS ticket. |
|
675 |
Pre-authentication failed. |
|
676 |
Authentication ticket request failed. |
|
677 |
A TGS ticket was not granted. |
|
678 |
An account was successfully mapped to a domain account. |
|
680 |
Identifies the account used for the successful logon attempt. This event also indicates the authentication package used to authenticate the account. |
|
681 |
A domain account logon was attempted. |
|
682 |
A user has reconnected to a disconnected Terminal Services session. |
|
683 |
A user disconnected a Terminal Services session without logging off. |
Event 675 isn't usually a security problem, but it will drive your users nuts. If the user's clock is more than five minutes off (default) from the authenticating system's clock, the authentication will fail. Log 675 events and reset the user's clock.
Event 677 means that the Kerberos ticket-granting service found something wrong with the account logon to the domain and refused the logon. This event probably warrants investigation.